There is almost always pressure to get started as soon as possible and deliver to a fixed deadline. Yet contemporary delivery methods are not designed to deliver to a single fixed deadline. A developer cannot promise to deliver in one or two sprints. The customer has to be realistic and flexible about when the technology will be ready.

Starting early doesn’t guarantee success either; getting on with code development prior to confirming user journeys and requirements will only cause friction and errors down the line. Starting ‘early’ can therefore undermine the whole project (as seen on the illustration to the right).

External factors to code development can have long-term and major dependencies, such as a media launch, integration into a large system or a regulatory approval. These can all take months beyond the code development, so stakeholders need to be mindful of sequencing the tech change into a wider business. The reality is that all projects need to follow a logical sequence that cannot be cheated whether or not they are agile.

1. Unrealistic and unachievable timelines
2. Change is more cost-effective when done earlier
3. It takes longer to get going when you are big
4. Expectation by customers to crunch the timeline
5. Be aware of external factors such as regulators. Take account of other functions in the client’s organisation
6. Optimism bias (rule of thumb: everything takes 1.6 times longer)
7. Tech implementations compromised by achieving deadlines rather than MVP or good quality

Good planning often includes difficult conversations early on. However the benefit is that delivery becomes realistic, and all stakeholders are aware of what they are required to do and what risks, dependencies and constants need to be managed. Above all, planning brings a dose of reality to the proposed timelines. This is discussed in the next section.