The Impact Of Initial Project Scope On Outsourced Software Product Development

The Impact Of Initial Project Scope On Outsourced Software Product Development

Why scope is crucial

Assuming you want to make profits rather than products, scope is the main driver of your economic results. It ultimately determines the value you will deliver to your customers and, consequently, the revenue you will be able to generate from your product or software-enabled business venture. On the other hand, it will drive costs which will feed into the bottom line, more specifically, the expense of product development as well as the cost of support and maintenance. Since scope impacts your project schedule, do not overlook the cost of delay, i.e. the revenue you will lose as a result of deferring the launch of you product. Get it to the market too late, and you may discover your target customers are already locked into competitors’ solutions. Though the cost of delay may be hard to see, it may be much more important than the tangible costs you experience when parting with cash.

Failure to manage scope with the economic implications in mind, often leads to:

  • developing products with no market fit – the worst scenario
  • delays and lost revenue
  • budget overruns
  • high maintenance cost
  • motivation melt-down
    Conversely, manage you project scope well and you are much more likely to develop a profitable product – a product which sells well enough to provide ample excess of revenue over the costs incurred. Some say it is easier said than done. They see the point but lack the determination to do it. Others consciously, genuinely and persistently try to do it well and – with luck – they sometimes succeed.

Project type & initial scope definition

Software development projects – outsourced or not – vary in type and size, which determines how well scope can and should be defined upfront. On one hand, you may need to port an existing well-documented application, in which case what is to be delivered is relatively easy to define and unlikely to change. At the other extreme, you may want to create a new application with high market risk, in which case your initial scope is often a guess – a collection of assumptions which will be tested with potential customers and/or users. Initial requirements are incomplete and very likely to change. In between the two extremes there are a number of other project types which vary in terms of how well scope can be captured upfront.

Project type impact on scope, process and team management

Since the type and size of the software project you intend to outsource determines how well you can define scope, it will have an impact on:

  • the way scope will be managed
  • the degree to which workload, budget and schedule can reliably be estimated upfront
  • the payment mechanism you might apply when outsourcing
  • the process / software development methodology you should adopt
  • your (in-house team) role and the degree of involvement in the development process
  • the vendor’s team you should choose to develop your software solution
  • the degree of customer / user involvement needed
  • the amount of collaboration required to execute successfully

In this way, each project poses specific challenges and calls for tailored solutions which fit the project type and size. Fail to account for such differences, and you significantly decrease your odds of outsourcing successfully.

Well-scoped projects

Going back to the examples cited above – what if you are outsourcing the development of a fairly well-defined project type?

Your initial scope definition is known and thus should be complete, unambiguous and consistent. Both functional and non-functional requirements are specified, and scope change management is not going to be a major challenge on this project type. Consequently, the vendor is able to assess the workload accurately before implementation starts and you may expect them to commit to a fixed-price. Likewise, their schedule estimates should be reliable, and they would need a good reason to divert from it. As regards process, your accurate initial scope definition means that your collaboration with both your customers/users and the product development team can be less intense. You will obviously have to provide some feedback, monitor progress and accept the deliverables on a periodic basis. Still the team have been provided with sufficient information to execute successfully without frequent and intense communication.

Fuzzy and volatile project scope

What if you are creating a new application or software-enabled business venture with high market risk? You have an overall product concept and high-level requirements but the whole scope cannot be specified accurately enough for efficient implementation. Worse, it is likely to change dramatically as you pivot.

Developing detailed specs in this case is a pure form of waste and may lead you to develop a product with poor or no market fit –  a product nobody needs badly enough to use, let alone pay for. What do you do then? Working from the high-level requirements, you develop detailed specs for specific project milestones. The product development team may try to guesstimate the overall project workload, cost and timeline but they commit to budgets and schedules on a per-milestone basis. Some vendors are more comfortable with a time-and-material / hourly rate payment approach but you should pass on some risk to them. In fact, you do have a basis to expect it and that is your well-defined milestone scope. The team should ensure there is an efficient process and tools with which to track scope and its changes as well as their implications for overall cost and implementation schedule. You will need an iterative, agile process which requires close and intense collaboration between you (your market team) and  your customers/users in the first place. You do not outsource the whole software development lifecycle (SDLC) – the customer development process and product ownership remain your ultimate responsibility. With an agile approach your collaboration with the vendor will be equally intense. You will synchronise to provide feedback much more often. You may even consider face-to-face collaboration with the vendor, for example, at the beginning, for the fuzzy-front end and design activities or at important moments in the project implementation.

So what can you do?

If you understand the characteristics of the project you want to outsource, you are in a much better position to successfully manage the project scope, the process needed and the team(s) to be involved. And the next time you meet an entrepreneur pursuing Eric Ries’s lean startup methodology asking the development team to quote a fixed-price for the project or, alternatively, hear of a development team charging by the hour for a small, well-specified application, be sure there is a different way which makes much more sense for both sides. Ultimately, they are all in the same boat.