Estimating and delivering defined outcomes

Recently there has been a shift away from time and materials projects towards defined outcomes, driven by various legislative changes, specifically IR35, but also cost control in the procurement function of larger organisations.

This type of project shifts risk from the procuring organisation to the delivering one; they are now responsible for delivering a specific outcome for a pre-defined price. If the project is more complicated than initially thought but remains in scope, the delivering organisation owns the cost.

The key to reducing risk is explicit project scoping, communication to minimise assumptions and accurate estimation.

The Team

Before any activity the time requirements on all of the project stakeholders, domain experts and delivery team should be made clear. Building a truly combined team that combines technologists and organisational expertise is key to managing delivery risk. Keeping decision makers close to the process reduces feedback loops and keeps the project on track. Building relationships and understanding early in the projects simplifies resolution of any issues.

Project Scoping

Organisations embark on projects for the outcomes that they deliver, not to create a piece of software. This may seem obvious, but without a clear understanding of the context for the project being delivered, there is little chance of project success.

Wherever possible, the team should work through a discovery process with a client, starting with user needs and then getting into more detail. For smaller projects, the discovery can be an afternoons workshop, and for a more complex project it could be an entire sprint.

Significantly at the end of the project, there should be an output that is detailed enough to allow the delivery team to estimate the delivery process. The delivery team should also be involved in the discovery process to ensure that all assumptions are clarified.

Communication

Once the scoping activities are complete, and the output documented it should be presented back to the client. Reading back the teams understanding in this way, makes sure that all of the stakeholders are aligned. The output of the discovery process must be presented instead of being sent to read.

Accurate Estimation

There is an apocryphal tale of Roman engineers being made to sleep under bridges after construction or made to stand under the bridge as the first legion marches over. The closest actual reference to this is a little oblique, from a famous roman architect Vitruvius talking about a law in Ephesus that holds architects responsible for their works, that didn’t exist in Roman law.

[…] When an architect [in Ephesus] was entrusted with the execution of a public work, an estimate thereof being lodged in the hands of a magistrate, his property was held, as security, until the work was finished. […] But when more than one-fourth of the estimate was exceeded, he was required to pay the excess out of his own pocket. […]

This is a key part in having the same team that estimates the work be responsible for the delivery, if there is any disconnect, even with the best of intentions, will lead to issues. Any team estimating will naturally base that estimation on their own competencies and experience; this may not precisely match another team. Also, knowing that you are personally responsible for an outcome does clarify thinking wonderfully.

All of this planning and discussion can start to sound like Big Up-Front Design when companies are embracing agility. The key to remaining agile is to plan at the right level of detail, normally themes for a sprint, and then time box delivery on that theme. Time boxes create a mechanism for quantifying the level of investment in a particular theme or feature while still allowing agility in the details.

Issue Resolution

Creating an integrated team that includes domain experts and decision makers reduces the number of issues that arise. If issues still arise then strong team relationships and commitment combined with direct communication ensures they are resolved rapidly before any snowballing can occur.

A strong team can also deal with changes of scope and any resulting re-prioritisation, rapid feedback to decision makers ensures that all stakeholders remain aligned with the project outcomes.

Suitability

This way of working is not suitable for long running projects which would likely benefit from a more Kanban/Lean approach the focuses on throughput and efficiency instead of immediate impact.

Conclusion

Team continuity from the start of a client engagement through discovery, estimation and delivery reduces risk for both client and agency.