Your Start Affects Your Finish: A Butterfly Effect in Software Development Outsourcing

[article]
Summary:

Serhiy Haziyev and Halyna Semenova explain that your start affects your finish. A small but significant detail missed at the beginning of a project may multiply and eventually lead to missed schedules, failed expectations, and mutual dissatisfaction. You need to remember to invest in a preparation phase when outsourcing a project to a third-party organization.

When you launch a project in your own organization, getting it to the finish line on time and budget is just a matter of having the right people on the team and strong project management skills. This allows you to have control, understand the level of the team commitment, and continuously monitor the project’s progress and quality.

However, in today’s economy, most organizations don’t possess all the necessary skills and expertise in house, have a team that is large enough to complete the project in time, or have a budget that is sufficient to cover all of the above.

These constraints have led to a significant increase in outsourcing spending over the past few years. According to the IT Outsourcing Statistics 2012-2013 [1] provided by Computer Economics, the portion of a typical IT budget allocated to outsourcing is up nearly 23 percent in 2012 compared to 2011. According to this report, organizations are expanding their outsourcing budgets as they renew their investments in application development, flexible infrastructure, and cloud-based applications.

So, how can you ensure a software development project’s success when partnering with a third-party organization and have partial control and visibility of the progress? How can you make sure all possible challenges are discovered and addressed? At the end of the day, it is your organization, and not your software development partner, who bears full responsibility for the project’s success and reporting to your shareholders.

Years of experience in the IT outsourcing industry and a range of successful (and less successful) software development projects have taught us a pretty obvious lesson: Your start affects your finish. A small but significant detail missed at the beginning of a project may multiply and eventually lead to missed schedules, failed expectations, and mutual dissatisfaction.

The cost of correcting mistakes in a project increases exponentially [2]. This phenomena of sensitive dependence on initial conditions is known in physics as the butterfly effect [3]. This means that errors in early collaboration, requirements, and design are tenfold as expensive to fix in the coding stage and about 1,000 times more expensive after the release.

A Smart Project Start Leads to a Successful Finish
To avoid the scenario described above, when preparing to outsource software projects, we recommend investing in a timeboxed preparation phase. This allows all stakeholders to understand the business needs behind the requirements, analyze and address technological constraints, and, last but not least, establish full transparency between the partner organizations on collaboration and communication.

 

For the sake of simplicity, we’ll call this preparation phase “discovery” and introduce it as part of a three-phase approach to the outsourced software development lifecycle.

1. Engagement: A set of actions to explore the opportunity, identify the scope and resources for the discovery phase, and provide project ballpark estimates to support go/no-go decisions if the input information is sufficient. The efforts in this phase are usually internal investments by an outsourcing company requiring only a signed NDA from both parties.

2. Discovery: A short, fix-bid activity staffed by the outsourcing company with senior professionals and core team members responsible for the following:

 

  • Collaboration model and project risk evaluation (engagement manager)
  • Scope and requirements elicitation (business analyst)
  • Technical vision and estimates (software architect)
  • Project plan and resource allocation (project manager)

The discovery team may also include experts in DevOps, security, UI/UX, QC, etc. The final discovery team structure is defined according to the specific project drivers. The limited timeframe will ensure that the team doesn’t face analysis paralysis. And by early analysis of requirements, technology, and collaboration, the outsourced team will be able to develop a predictable project roadmap, discover potential issues and mitigations, and build a healthy relationship with your organization.

3. Implementation: The main software construction project phase has much more predictability and less risk, since it doesn’t start from scratch but from the results gained in the discovery phase. The core team is extended by software and QC engineers to its planned capacity. The price model may be a dedicated team, time and material or fix price contract. The SDLC may be agile (e.g., Scrum) or a traditional iterative lifecycle (e.g., RUP). The choice of the model is agreed upon between the parties (i.e. the client and the outsourcing company) earlier during the engagement or discovery phase.

One more reason why there is a strong need for a preparation phase is related to the Cone of Uncertainty or the evolution of the amount of uncertainty during a project [4]. The less we know about the project details (scope, requirements, solution, staffing, etc.) the more inaccurate estimates we get (see figure 1).

fig 1

Figure 1. Variability in the Estimate

Figure 1 demonstrates how estimates of the same project may vary in time depending on the project stage. The lack of preparation backfires in cost overrun. A good example is the construction of the Sydney Opera house with an original estimate of $7 million and final expenditures of $102 million. Ignoring the architect's request for additional time to tackle design challenges, the government pressured the builders to start the construction, which led to costs nearly fifteen times higher than the expected budget [9].

From this perspective, the goal of the discovery phase is to narrow the estimate within the 25 percent variability, so that it becomes possible to accomplish a project on time and on budget [5].

Methodology Is a Key to Project Success
Considering different project outsourcing scenarios, we can distinguish three common discovery phase types:

 

  • Assessment: for existing software systems or enterprise IT infrastructure
  • Solution design: for a brand new software product or an IT enterprise solution
  • Legacy modernization: for legacy software systems requiring redesign

Let’s review these three types in detail and highlight the practices and methods that help achieve significant results during the short cycle of the discovery phase.

Assessment
An assessment is one of the fundamental steps allowing the outsourcing partner to obtain knowledge about your existing system. The assessment delivers the benefits of knowing the system readiness for the planned changes, identifies potential risks (both technical and resource), shows the improvements roadmap, and justifies estimates for further evolution.

The assessment criteria are mostly driven by the project requirements, the solution type itself, and, of course, by the known problems. Naming it architecturally, the assessment should discover how well the existing system meets the quality attributes [6]. For example, typical system qualities for a SaaS/cloud solution are multitenancy, availability, scalability, and performance. The business qualities are the cost of operations and the economy of scale. However, every unique software product has its own set of qualities and it makes no sense to have all of them perfect.

The goal of the assessment team is to define which qualities are relevant, their priority, and their impact on the overall software system along with the recommendations on improvements in comprehensive language for all stakeholders, including non-technical people.

Solution Design
There is no doubt that some work on design should be done in the beginning of a new project. Diving right into development when the technical vision is unclear and the technology stack is not finalized, jeopardizes the project’s budget, schedule, and quality. And the larger the project, the more serious the risk.

On the other hand, waterfall-like big design up front may not be a solution with today’s demand for total agility. So what is the right balance between up-front design activity and the actual implementation, and how do you achieve reasonable software quality and predictability?

The answer to these challenges in today’s architectural methods is reference architecture [7]. Why start from scratch if the majority of the system requirements in the same technology domain are common across different projects?

In the technology domains of SaaS/cloud, business intelligence, and data warehousing, mobility, enterprise application integration, and other software families, we understand that there is commonality, especially in non-functional requirements and approaches.

Thus, a ready-to-use reference architecture that addresses typical challenges with proven approaches to solve them (i.e., patterns) significantly speeds up the design and implementation process, making it more predictable and economical.

This method works well especially in outsourcing companies that develop multiple projects in different technology domains and have established a practice to collect case studies and analyze what works and what doesn’t work (which is even more meaningful).

Legacy Modernization
During a software product’s lifecycle, it may become clear that the software does not fully satisfy new requirements dictated by the marketplace or the competitive landscape. Some examples of modern drivers for legacy software modernization include: a rapid shift from desktop to an online model and handling much more data than the system was initially designed to (i.e., facing big data challenges, and users’ demand for mobile capabilities). What is worse is that your in-house expertise may be desperately outdated. In this case, in order to reach the level of modern tools and approaches, the options you have are either hiring skillful employees (expensive) or finding a trusted outsourcing partner with a good portfolio of successfully modernized projects.

Moreover, software technologies drastically change roughly every five years. Remember Windows .NET WinForms (a desktop technology) from the early 2000s, then Silverlight, and, finally Microsoft’s recent movement toward HTML5 with the end of life of the current Silverlight framework in eight years? [8]

From the discovery phase standpoint, when migrating legacy software to a new technology, it is vital to consider that there are at least four migration strategies: horizontal, vertical, mixed, and rewriting from scratch. Unfortunately, there is no room in this article to get deeper into the selection of the right strategy, just let us note that this decision should consider not only the existing architecture or the amount of reusable code but also such process aspects as team structure and frequency of upcoming software releases.

Summary
In this article, we emphasized the importance of investing in a preparation phase when outsourcing a project to a third-party organization. The cost of mistakes at this stage will lead to the “butterfly effect,” which is revealed by numerous industry studies [2]. The article also provides an overview of the preparation phase (i.e., discovery), its goals, and the outcomes important for building an effective relationship between partner organizations. Finally, we describe three different discovery scenario recipes that we have successfully executed in dozens of projects for middle and large businesses, including Fortune 500 companies.

 

References
[1] Outsourcing Statistics 2012-2013 ( http://www.computereconomics.com/page.cfm?name=outsourcing)

 

[2] Error Cost Escalation Through the Project Life Cycle ( http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670_2010039922.pdf )

[3] Butterfly Effect - sensitive dependence on initial conditions ( http://en.wikipedia.org/wiki/Butterfly_effect)

[4] The Cone Of Uncertainty (http://www.construx.com/Page.aspx?cid=1648)

[5] Part 1, Chapter 1.5, “Software Estimation: Demystifying the Black Art”, by Steve McConnel

[6] Quality-Attribute Auditing: The What, Why, and How ( http://msdn.microsoft.com/en-us/library/bb508961.aspx)

[7] Reference architecture (http://en.wikipedia.org/wiki/Reference_architecture)

[8] Microsoft Silverlight Support Lifecycle ( http://support.microsoft.com/lifecycle/?c2=12905&wa=wsignin1.0)

[9] A View on Cities – Opera House, Sydney ( http://www.aviewoncities.com/sydney/operahouse.htm)

About the author

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.