Perils of Outsourcing Software Development

Perils of Outsourcing Software Development

How not to fail when outsourcing software projects

 

In this blog post we examine the perils of outsourcing software projects and way to improve chances of success.

The odds are not encouraging: Four out of five new product launches fail and a whopping 75% of executives anticipate that new software development projects will fail. Yet, without new product development, companies would cease to exist. Teams and companies must pursue new projects because the cost for not doing so is too great.

The answer to beating the discouraging odds and attaining successful results from external software development shops? Be diligent defining the project fundamentals!

“By failing to prepare, you are preparing to fail”

Benjamin Franklin

Let’s take a deeper look into what that exactly entails.

Defining Project Fundamentals by Specifying the Following:

  • Why: Justification of project, User concerns
  • What: Features, Technical performance
  • Who: Roles and Responsibilities
  • When: Milestones, Deliverables
  • Where: Cloud, Mobile, Enterprise, Special Considerations: HIPPA, PCI
  • How: Methodology, Tools, Performance test, Underperformance consequences

Software outsourcing is becoming standard practice for multiple sized companies from startups to Fortune 100 behemoths. Marc Andreessen’s famous article, “Why Software is Eating the World” depicting the exponential growth and demand of software, continues to become more relevant in today’s economy. If you are considering hiring an external software development group, and are determined to be successful, read on.

The problem companies face is that software projects tend to fail on budget, timeline, scope, quality and/or performance. We will explore why projects fail, guidelines for successful software development, what to look for in a software development contractor and best practices when outsourcing software development.

Why Projects Fail

The core of why so many projects fail at some form or another is:

  • Loose scope definitions
  • Unrealistic expectations
  • Non-negotiable requirements
  • A budget that does not allocate for uncertainty
  • Aspirational timeline

For example, a typical project starts with the product/project manager defining the scope, which is then reviewed by the technical lead to verify specifications, risk, resources and effort. The proposal is then submitted to the executive sponsoring the effort. The executive usually adds a few more features or tasks and gives the project a budget defined by his finance team. Then the marketing team works on the product launch based not on project completeness, or team feedback but based on a tradeshow or a future customer meeting.

Variations of the above scenario are all too common, but at the end of the day the cause of the problem is lack of clarity or/and unrealistic expectations.

To avoid this recipe for failure, it is best to answer the fundamental questions of the project from the get go and to keep everyone within the communication chain.

Best Practices When Outsourcing Software Development

The secret for successfully outsourcing software development is simply clear communication. Clarity with project definitions and expectations is at your fingertips by applying the good ‘ol 6 interrogative question words learned in grammar school (5Ws +1H)-  Why, What, Who, When, Where, and How.

Why: Why are you pursuing this project? Do you want to increase productivity for an internal process or are you addressing a market opportunity to grow your company? Knowing why you are doing the project will help to define the final goal of what you want to achieve in relation to your strategy and vision while keeping your team motivated.

Sometimes, an outsourced provider can help you to manage 24-hour support events without requiring you or your team to lose sleep.  If the provider can help improve your support timeframe, reduce stress, or handle unexpected issues, you may find that the value is difficult to quantify, but easy to understand.

What: The “what” is the substance of the project. It defines actual deliverables and sets expectations for the software contractor. It is probably the most critical aspect affecting the success of the project. The “what” prioritizes scope and defines deliverables. It helps communicate with different stakeholders and reach out to contractors for detailed quotes on the project.

There are several documents that you can use for this purpose including: Statement of Work (SOW), Product Requirement Document (PRD), and Engineering Requirement Document (ERD).

Principles for Defining the Project:

  •       Define musts-haves and nice-to-haves:  Defining the difference between must-have and nice-to-have features will help to set up prioritization for the project. This will assist the development team to quickly set a functional goal, gain traction and recruit user feedback. Nice-to-have features are set as second priorities on an already valuable application.
  •       Make each feature traceable: Allow for each feature to have identification tags for traceability during development, test and acceptance.
  •       Define acceptance criteria at project level and feature level: Write a qualifiable acceptance test and performance for each feature.
  •       Accommodate for unknowns on the project: Every project has uncertainty, which translates to risk. Identify the unknowns of the project and have a plan to answer the unknowns as soon as you can. This will reduce the risk of project failure.
  •       Integrate user feedback during product development: Recruit the help of your users by exposing them to the user interface and make it easier for them to give you feedback during development. This will help develop a usable product.

 

Who: A critical aspect for the success of a project is its roles and responsibilities table because it clarifies the commitment from specific stakeholders for delivering a quantifiable outcome.

When you are outsourcing software, you might be responsible for some of the roles below.

Most Common Roles:

  •       Executive Sponsor is responsible for advocating the project to the company leadership. This will affect budget, timeline, resources, strategy, motivation, etc.
  •    Product Manager is responsible for the overall product success, defining requirements, objectives and deliverables. A key role is to advocate for the user needs and pain points.
  •    Project Manager is responsible for building and executing  the technology development, resources and maintaining budget and timeline.
  •    Technology Lead leads the technology vision, architecture, methodology and performance.
  •       Development team is the team of engineers who write the code. When outsourcing software development, you may have an array of options from local developers to international teams. Using international teams can be effective if you have experienced, internal product managers and technical leads. Otherwise, the risks of poor quality code, miscommunication and extended timelines are too high.

 

When: Measure, measure, measure! Keep track of deliverables and how actual timeline and delivered functionality compares to initial estimates. Many contractors promise an aggressive schedule to get you on the hook and then deliver on a different schedule. It is common practice to tie payments to deliverables. This helps to keep the contractor accountable for the promised schedule.

Do you know the difference between milestones and deliverables? Milestones are events that help you keep track of the project’s progress and should happen on anticipated dates. A milestone should confirm quality, time and cost. Deliverables are milestones with additional constraints such as a target performance or functionality.

Where: In today’s world of distributed teams, the physical location of the team is less important than the location of the software. With software hosting options like in-house servers, private cloud, public cloud, or particular providers, deciding where the software will be hosted is a complex decision with many consequences for the execution.

The technical lead, resources and team skills will influence this decision, but at the end of the day, make a pragmatic decision and quickly test functionality and value.

The reason to insist on teams local to your organization is if you have existing issues with communication, culture, or collaboration.  If your organization is not prepared to collaborate with remote developers, a local team might be a better fit. Over time however, an outsourced developer and team may be able to help develop a better environment.

How: This establishes how the project is going to be performed. This category includes software development methodology, tools, how to address scope changes, acceptance test, how to address lack of performance, missed deliverables, etc.

Before the project kicks off, everyone involved should be clear on the acceptance criteria and consequences if the performance is not met. Many teams leave these definitions for later, but then “later” never comes. This helps with knowing what steps to take when the contractor delivers something unexpected.

Another important consideration is to understand what to do when the budget runs out to support an external team. You have to be clear how the technology transfer occurs and who internally is responsible for taking over the code.

Conclusion

  •       Define project goals and what success looks like: Identify quantifiable objectives. Have clear expectations from all stakeholders.
  •       Know what you know and don’t know: Allocate a significant portion of your budget and time to address the uncertainty all projects face
  •       Status Updates: Regular deep dives in project progress, business environment and executive buy-in

Iterate: Break the project into business case testable functionality phases

If you want to chat about any projects you have in mind contact us.

Leave a Reply