Most people realise that large IT projects are risky (research indicates between 70-90% fail to deliver), so have you ever considered how we end up with them? One factor is a belief that we can satisfy all our key stakeholders at one future time and that it will be more efficient doing it all at once rather than in "bits and pieces". Find out how a change of perception can help structure projects to deliver early, on time, on budget, and "delight" your stakeholders.

There is a thirteenth century Latin proverb : Plus valet in manibus avis unica quam dupla silvis (A bird in the hands is worth more than two in the woods), which means that it is better to have something now, than the promise of something in the future. It is thought to come from the context of hunting where if you have caught or shot a bird, you know you are going to eat tonight, whereas the prospect of catching a few birds isn't yet a meal on the table.

What do your business stakeholders prefer? Are they "hunters"? Would they prefer a small project deliverable next week/month (and further ones in the following weeks/months) that add some practical value to their operation or the hope of something larger in one or two years time. Most people we ask prefer a bird in the hand, so how do you create a project to deliver it?

It starts with the business requirements. Many requirements documents we see are long lists of functional requirements with no attribution of requirements to people, i.e. the person who wants that requirement. Without the people linkage it is difficult to identify the business improvements (the value and benefit) a requirement is seeking to achieve, the fundamental requirements.  These long functional lists, are often in the some form of solution specification, losing the structure of the value proposition. If there is some desire for incremental delivery, that solution is broken down into deliverable packages. However, those packages may not deliver the improvement (value and benefit) until all the packages are in place. Over the course of delivering the complete package, the business has probably changed its requirements.

An alternative is to rank all fundamental requirements in order of the business value they represent to the stakeholders. This forms a delivery route from which you can design a small part of the overall solution to deliver the first value step. It requires lateral business-wide thinking, as not all steps will be technological ones, for example there might be early value in giving some key people extra skills with the current system. Delivering early value to stakeholders through small improvement steps also has a major benefit to the project team; they LEARN about the real problem domain as a result of practical experience in the real business world, for example the workforce may not have the skills required to use the advanced system the project team originally had in mind. The business users also LEARN. Maybe the original requirements they had in mind aren't quite what they wanted. These lessons are put into the design of the next and perhaps revised value delivery increments. Gradually a series of small solutions grow around the architecture for meeting the overall benefit goals.

Let's consider efficiency of delivery. This iterative or evolutionary approach may involve going over the same requirements several times. Learning from the feedback of practical delivery has the perception of taking longer than getting a finalised requirement list approved and frozen and then dedicating a team to delivering it. In the IDEAL world this might be the case, but the IDEAL world is where we have a 100% accurate and unambiguous requirement specification and a world where things don't change. The REAL world for most projects is far from this ideal. The real world is where 90% of large projects are seen as failures, i.e. a lot spent for very little return. Efficiency of delivery is rarely defined explicitly, so it means little to people in practical terms. Some evolutionary steps in projects will also fail, but failure is always a possible consequence of taking investment risks. Without risk, there is no reward. The advantage of failing in small delivery steps is that it costs less than large project failures. Perhaps efficiency of failure should be a concept to investigate further?

So back to addressing the original question of how do projects get to be large. Not having identified the stakeholders and the value they associate with their requirements is a factor. It allows additional requirements to be easily added to the overall set for solution delivery until either the budget or time constraint is reached. Projects grow. An evolutionary approach based on stakeholder value, shrinks a project to a series of the smallest delivery steps, i.e. a project becomes lots of small projects. Try it. You will either delight your stakeholders with business value early, or fail early and cheaply but learning something useful in the process. The alternative is deliver lots later or fail expensively. Your best option depends on whether your stakeholders prefer a bird in the hand or two birds in the woods.