The Need
Has your company ever been required to complete another software project on top of ongoing work?
Most organizations eventually have to complete an additional software project without disrupting their internal software development team’s work. Sometimes this just means simple staff augmentation with contractors.
But other times this requires an entire external team to complete the new project. Offshore/outsourced development teams are cost-effective and time-efficient when your employees are engaged in work that cannot be interrupted.
The Painful Truth
Unfortunately, many of us have experienced the painful side effects of using offshore/outsourced development teams. One of the biggest drawbacks is that the code quality is not up to the standard of our internal high-performing software development team.
This can lead to a complete rewrite once our employees get their hands on the code. Stability issues, production support, and bugs are a few of the signs that the work performed wasn’t up to snuff.
Of course, those issues only occur if the software project is completed. Sometimes the work is abandoned with the realization that internal team members are required due to the technical nature of the software system or a lack of documentation.
It’s Not Their Fault
Contrary to popular belief, it is not entirely the fault of the offshore/outsourced development team. Many of the pain points experienced with off-site development result from a lack of clarity about expectations. Those missing pieces include:
- Clarity about requirements
- Clearly defined and documented architecture
- Communicated coding standards
- Oversight and design/code review
Your own experience may vary, but ultimately the aptitude or technical savvy of the off-site team is not the root cause of most failed outsourced software projects.
Software engineering training can teach your team the engineering principles and planning necessary to turn unsuccessful outsourced projects into wins.
Key Players Required
The number one risk when embarking on a new quality software development project is not having a dedicated Solution Architect.
A trained Solution Architect will have the necessary skills to gather the requirements, document the use cases, decompose the system, document the Architecture, design a construction plan, and guide the development team through detailed design, building, and testing of the software system.
Although this person can have other responsibilities, such as guiding another team on another project, their project priority must be clearly defined and backed by management.
Another key player in efficient software development is a dedicated Product Owner. The Product Owner understands the users’ needs and can articulate the project’s business requirements. They can also identify use cases throughout the project.
The Success Process
Once these key players are assigned to the project, the process is consistent and repeatable. Following the System Design (yielding the Architecture) and Project Design (yielding the development plan) phases performed by the Solution Architect, the development team is assembled to build the system.
It is here that most projects fail because they lack the proper guidance for the offshore/outsourced development team during construction and testing. It is essential that proper Detailed Design is performed by Senior Developers if available or by the Solution Architect if not.
Detailed Design is the designing of the code. This design process includes:
- Abstractions in terms of Service Contracts (interfaces)
- Data Contracts (DTOs)
- Class hierarchies
- Code structures leveraging design patterns
The output of Detailed Design also includes sequence diagrams for all use cases which serve as a guide and visual aid to the developers during development.
By assigning the architecture components or small combinations of components to the individual developers along with the sequence diagrams, interfaces, DTOs, and class structures, Detailed Design limits the scope of work to just the implementation and not the design decisions.
This is the key differentiator in engendering a successful outsourced project. We must provide sufficient design guidance to the development team and code review the work to guarantee success.
The Transition of Ownership
When the project is nearing completion, there needs to be an opportunity to familiarize the internal team with the software system.
The review of the documented Architecture should include:
- The activity diagrams of all use cases
- The strategy used during decomposition
- A series of call chain diagrams depicting how every use case is satisfied by the architecture
- The sequence diagrams illustrating the detailed design interactions
- A review of the code, tests, and test plans
The internal staff should have the opportunity to ask questions, build and run the system, and learn how the system is tested. Since all the code will adhere to the corporate coding standards, there will be immediate familiarity for the internal staff.
Ready to Successfully Complete More Projects?
Successfully building software with an offshore/outsourced software development team should not be a significant risk.
To eliminate the risk, your team should follow a structured approach that doesn’t leave important design decisions to a group of external resources unfamiliar with your domain. Having the right key players dedicated to the project ensures success by orchestrating the right sequence of use case analysis, design, and architecture artifacts that can be followed by an external team for development and testing.
The key to improving software development lies in providing that much-needed design guidance to the development team and reviewing the work throughout project execution.
On your next offshore/outsourced project, let me be your guide and show you how to complete more high-quality software development projects when your internal staff cannot be interrupted.