Let’s look at the outsource developer and client scenario. The premise here is that a developer commits to deliver a well-defined application or larger system for a predetermined cost and often on an agreed schedule. For those keeping a tally, this sentence contains four assumptions:

1. Deliver – the client must be ready and able to use the software
2. Well-defined – there is a complete, unambiguous description of features and functionality
3. Cost – the developer understands the effort and resources required
4. Schedule – developer and client anticipate all the internal and external dependencies that will affect designing and building

Moreover, both parties have to try to answer these questions in advance, with limited planning and without the experience gained from actually working on the project. Building software is by definition creating something new; even development on an existing application involves appraising how a new context could affect the best-laid plans. (Let’s exclude the simplest cases of buying and configuring an existing product.) Thus, the likelihood of all four assumptions being correct is … zero. 

So how do you move forward and manage risk considering the odds against you?

One method is to take an agile approach to project management. Agile practices emerged from the realization that no methodology - from formal specifications to model-driven development to code generation - could adequately address this basic problem. Software, by its intrinsic nature of being changeable and adaptable to evolving requirements, cannot be built effectively without accommodating the human conditions for how we conceive and build it. In my experience the core of agile development is to work iteratively and deliver incrementally. The other constructs of agile planning and execution – sprints, user stories, and the tooling to support continuous delivery – are the necessary infrastructure to make an iterative and incremental approach possible.

Yet, agile practices alone can be insufficient. Clients need to understand the cost and timeline for development, and therefore often turn to an alternative approach: a fixed cost model to guard against the work costing more than anticipated. In theory, the developer bears the risk here since they commit to delivering, even if the effort or time exceeds the initial plan. In practice, though, what does this mean for a client, as requirements evolve during development?

As the understanding of the actual requirements evolve on a fixed-cost project, the developer or client has the option to formally recommend changes to their agreement, such as adding functionality, cost, or time to the schedule. These change requests can be simple and easily agreed upon, but some change requests require significant discussion or introduce conflicts. For example, a developer might submit a change request to discourage unwise shifts in direction, mitigate underestimation of the project, or purposely underbid the effort to win the work. A client can resist a change request due to budget constraints or driven by the judgement that the needed functionality was actually part of the initial (and too often vague) specifications. In the best case scenario, the developer and client expend a lot of time and effort on change requests, which is a distraction from the main objectives of a project. There are also many ways that these discussions can go wrong, money and reputation always sharpening the dialog. The worst case scenarios can be fundamentally damaging or even catastrophic for the project. Thus, change requests effectively limit adaptability - and increase risk - on a project, due to the effort, cost, and potential for conflict involved. 

Moreover, the more complex and correspondingly important the initial specification is to a client’s business, the less likely it is to be sufficient. This is the implicit functional risk that a client accepts in a fixed cost agreement. In other words, this is the risk of not getting the application or system that is actually needed, or at least not supporting requirements that a client really needs. If this type of shortfall between needs and technology occurs, there can be dramatic implications – higher operational costs, lost or disaffected customers, missed business opportunities, or the total cost of ownership of a system that does not quite work as needed. Thus, in many scenarios, functional risk is arguably much larger than the total cost of the project. 

I’ll close by observing that the above is also true for business sponsors within the same organization as the IT team, although the penalties for a team going over-budget or delivering late are less tangible than with an outsource developer. Internal teams usually have greater slack to remediate shortcomings in subsequent releases. Over time this dynamic of vague specifications produced by business stakeholders, late and over-budget deliveries by an IT team, and mismatch of software and requirements creates a dysfunctional organization Thus, functional risk is just as important in this context, but it’s penalty is only seen in the long-term.