Date-Driven Delivery vs. Delivery-Driven Dates

Businesses tend to set dates for project deliveries. They do so based on business considerations, such as financial-year targets, board-room expectations, or simply to have a deadline to look forward to.

Typical Approach of a Project

Projects tend to have a deadline attached to them. Projects of all kinds, though we will focus primarily on IT-related projects. Whether it is imposed by law or regulators, set by an executive sponsor before the project team is assembled, or by a project manager after doing the work breakdown and the estimation of the work packages, in most cases, a deadline is set as “The Release Date” (TRD) that the project team has to work towards.

That is a potential pain point for all parties in all cases.

If the deadline is set by law, it goes without saying it is inconvenient. It is an external constraint imposed upon a business and a technical team, taking no account of the realities said business and team have to face to meet the target date, and there is seemingly no wiggle room to review that date. The stakes are usually a fine, a revoked licence, or a cost, such as an increase in insurance premium.

A business setting a deadline creates just as uncomfortable a situation. Someone, an executive, or perhaps another sponsor, makes a promise (in good faith) based on intuition, instinct, to convince a prospective buyer, to counter the competition, or for any other reason. A strategic business decision based on instinct can sometimes work – Will Chu decided, against everyone’s advice, to implement delivery of quality food, and, in 2018, the resulting Deliveroo is doing rather well. A project delivery date based on instinct or analysis rarely trumps one based on hard facts, on the other hand – extremely rarely: the Channel tunnel received a green light in 1964; it was then forecast that building it would take five years. Digging started in 1986, at last. By 1990, the delivery date was forecast to be “by 1993.” In reality, Eurotunnel was not open for business until late 1994. The actual timeline proved to be almost twice as long as what the experts had initially forecast.

TRD extrapolated from the work breakdown is inconvenient for perhaps less-obvious reasons. TRD is based on an estimation of the work breakdown done by the project team at the initiation of the project. That seems sensible. However, just like the cost of said project (see How much does a story point cost?), its duration is very much dependent on its unknown unknowns. We previously talked about how it is impossible to plan for things one does not know are going to manifest themselves. That simply makes TRD impossible to predict with much accuracy. Imagine a project is set up to cable a new floor of the building the company occupies. That floor will then welcome new teams as part of the company’s expansion. Right as the contractor gives a date to start the works and a projected TRD, the freeholder objects to punching holes in the walls for the cables and initiates a months-long negotiation, delaying the works and the teams moving in as a result.

Those realities, by making TRD unrealistic, usually lead to what is perceived as a late delivery.

Dates set by external regulators and legislation are rarely as black and white as they initially seem; one may argue that there are only shades of grey, and that regulators can be negotiated with: they might decide to reduce, postpone or remove a fine, based on a temporary compromise leading to a long-term solution, they might take an action plan as a sign of good will to renew (if provisionally) a licence etc. There are multiple ways for a business to negotiate with regulators without damaging the company’s reputation and profitability. In any case, those dates are imposed by a body external to both the team and the business, and we will not look at that here. For the sake of simplicity, let us only look at the other two cases in this article: TRD set by executive sponsor and TRD set at project inception.

Managing a Project Deadline

Inevitably and understandably, a delay, real or perceived, frustrates the sponsor. They spent a lot of effort devising a plan to counter the competition and managing the expectations of their own stakeholders, and they feel the technical teams are now letting them down, potentially leaving them embarrassed in front of their customers, or in the board room.

The disappointed sponsor sometimes puts more pressure to meet TRD and/or asks the team for an alternative TRD that falls within boundaries set by the sponsor – e.g., “Give me a realistic date, and that date needs to be in no more than three months.”

However, such an attempt to regain control and steer the project in a direction that will see it achieve results will often end up with targets based on gut feel again, rather than facts, and will therefore not be more realistic. Those unrealistic targets will likely be missed, further increasing the frustration and disappointment, and further eroding the trust between the business and the project team.

To the question of what a realistic date might be, an Agile team who understands that dates based on instinct can usually not be met might reply: “We find it more effective to work closely with you and define how to achieve and measure success, one fortnightly delivery at a time.”

The sponsor’s representative (a project/programme manager, a delivery manager, a director of some kind) will often argue that expectations have been set, that downstream dependencies have been scheduled, or even that executive behaviour cannot be changed and that the team has to stick to the plan and follow the agreed timeline, this time.

However, showing authority and firmness in the face of delay does not make an unrealistic TRD more achievable, nor does it bring a project “back on track.” It merely ignores that TRD was unrealistic in the first instance.

There are widespread ways of “managing” TRD in case of a delay. The most widely-used is cutting scope, shedding less-useful features, in a bid to deliver on TRD. Although that may give the project a better chance of going to market on TRD, one negative side effect of doing that cannot be overstated: client perception. When cutting down scope, a sponsor will almost inevitably feel short-changed, because they have to compromise on what they asked for and will have to explain it to their own stakeholders on top of it. Besides, there can be a lot of throwaway work and regret cost associated with outputs that will never see the light of day as a result of being cut out.

Another frequent reaction is to throw more resources at the project, in the hope that more manpower will increase the speed of delivery. If there is one thing to take away from Fred Brooks’s seminal book, The Mythical Man-Month (Addison-Wesley), it is that adding human resources to a late software project makes it later (also known as Brooks’s law), with further erosion of trust as a consequence.

Immovable Dates for Outcomes

When an executive announces a date for a delivery, they are sometimes setting a deadline long before the start of a project. Two observations, here.

Firstly, such a statement, promising a delivery on a certain date, is rarely very clear about what that delivery is. The further in the future TRD is, the truer that is. The executive has set a date. What happens on that date, however, is not black or white. The promise might have been to launch a new Web site within six months. An executive will seldom detail what that “new Web site” really means. Is it a complete overhaul of the existing functionality, front-end and back-end? The addition of new functionality? A “mere” redesign of the presentation? All of them might be due, but if the statement was “launch the new Web site by date x,” then any of the above can individually be celebrated as a success by the executive.

The lesson here is that the immovable, hard deadline is mostly for an outcome, often a blurry, strategic one. It does not necessarily mean that a whole business change, or an exhaustive list of individual product requirements are bound to the same date.

As an illustration that such an immovable date is often for an outcome, Eurostar promised to launch a line from London to Amsterdam by the end of 2017. In April 2018, the line was opened, a little later than planned, and trains now go from London, straight to Amsterdam. As of October 2018, the return leg of the journey still has a stop-over in Brussels, because Amsterdam does not yet have the infrastructure to accommodate the British Border Force (because the UK is not in Schengen, the Border Force checks all inbound passengers from the Continent before they board). Is the project finished? No: there are still significant aspects to iron out and implement. Was the strategic goal achieved? Yes: Eurostar now goes from London to Amsterdam.

Despite a slight delay, the strategic goal was achieved and the line is already generating value, even though not all individual requirements have been fully implemented yet.

The second observation is that such a promise to deliver on a certain date may appear to be an executive behaviour that is impossible to change. After all, the promise is often made a considerable amount of time before the project team arrives, and often without the team or any sort of experts being consulted prior. Even though the desired, strategic outcome is blurry, it is still worth challenging the habit of setting a deadline upfront and explaining the consequences: various stakeholders will build different understandings of what the desired outcome really is, and develop the expectations to match, often with missed deadlines and frustration as results. Every chance to avoid that frustration is worth taking, as that is a situation in which no-one wins.

Business Roadmaps and IT Project Plans

Businesses everywhere have a planning horizon. They have roadmaps that show what they plan to work on for specific periods – the current month, the current quarter, the current half, the current financial year, the next five years etc.

The level of detail and certainty of the projects on those roadmaps is variable: a business will know that they will be rolling out a new API this current month, what its new features are and (hopefully), how they will measure generated value and, ultimately, success.

The further away in time, the blurrier the goal. A business might plan to open a new office in the coming two years; what that exactly means is open to liberal interpretation: is that a new building on an existing campus? An extension to an existing building? A new campus in a new city? Will that new office be bought from the competition? Will it be built from the ground up? How many people will it host? What type of services will be run from there? How will the administration work for that new office’s employees?

From the above list of questions, one can see that there are a number of factors that the statement “open a new office in the coming two years” does not answer. As the deadline nears, the business will have to define what success looks like and how that translates into an implementation timeline, in collaboration with the delivery teams. Chances are pragmatism has to prevail and a Minimum Viable Product (MVP) has to be defined so that the business and the executive sponsor are satisfied that the office is “open” on time, in other words: that enough value is generated to be considered a success.

The IT world works in the same fashion. A plan for the next two weeks is detailed and controlled to a degree (by the sprint planning, for a Scrum team), while a plan for the next two years will be vague and much less reliable. Along the path, the techies will look to the business to define what the MVP looks like, so business and executive can start generating value and claim success in a timely manner.

If an IT team or department seems reluctant to commit upfront to a date for the delivery of the whole project, or for the delivery of all individual requirements, it is simply because dates cannot be guaranteed that far in advance, and because the IT team does not want to mislead the business with promises based on nothing reliable. IT teams generally understand they serve the business and are therefore keen to support said business, rather than set it up for disappointment.

Continuous Delivery

Since setting TRD upfront for all individual product requirements brings frustration of many kinds instead of success, and since there is no strategic constraint to do so, why not turn the approach upside down? Why not focus on delivering small increments quickly and often, then let the business decide when a critical mass has been reached and when it makes sense to go live with an MVP? That certainly helps set realistic expectations more than gut-feel-based promises and that is the whole purpose of the industry becoming Agile.

In order to help the business into that position, it is unwise to develop complex business functionality straight away. Efforts are better spent laying the rails for continuous delivery. Continuous delivery is the automated mechanism that will ensure that whatever is developed can be deployed seamlessly and at a low cost. Although the business might initially see that as a delay to the overarching delivery, or as focusing on purely technical tasks that are not visibly beneficial to the business, it is the same investment as building a road, whereas the application itself is a car. And really, what good is a Ferrari, if there is no road to drive it on? What we advocate here is to build a road one can walk on, skateboard on, ride a bicycle on, take the bus on, then take the Ferrari on when the Ferrari is built and ready to gobble some tarmac.

The legacy way of building business requirements first, and thinking about how to deploy later has multiple undesired consequences: 1. Development costs the client money until the application is live. The longer the go-live is postponed, the later the application starts generating value and the later the costs are recovered 2. By the time the application is deemed ready to go, the business and its needs tend to have moved on, with the consequence that the application does not help the client meet their targets 3. A deployment that is left to the last moment is costly and risky. The longer is spent building the application, the more complex the application becomes. The more complex the application, the more dependencies it has and the more costly and risky its deployment as a result 4. During the whole development process, anticipation builds up. Every stakeholder has a set of expectations. Not meeting those expectations leads to client disappointment and breach of trust between the client and the project team

Focusing on continuous delivery first has the following positive consequences: 1. By delivering and going to market often, we ensure the product generates as much value as possible, as quickly as possible 2. The product therefore can start paying for its own development long before it is considered “finished” 3. Going to market often helps the client assess their direction and priorities, based on factual results and statistics, rather than instinct. If a feature does not generate the anticipated value, it can be abandoned in favour of another that will 4. Corrective patches can be deployed at will 5. By deploying often, we reduce the risks associated with deployment. By paving the path to live, we gradually remove many of the hurdles that we will face when deploying the “complete” product. Instead of a collection of hurdles, we tackle one at a time. It is more manageable, cheaper and the outcome is more certain

The point of #5 above in particular is to make delivery a non-event. Everyone likes a round of applause for their hard work: it is rewarding and encouraging; it shows that the client appreciates the effort and the commitment.

Humans function best in a routine, however, at least if they are to perform durably. The cost of that rewarding round of applause is long hours, stress, risk and delays, caused by complicated, manual steps. Teams at large tend to not only dislike long hours, stress, risk and delays, they also operate less well under those circumstances and are more prone to error, with consequences on quality and reliability. Another long-term cost to the client is often a higher-than-desired attrition rate, as team members burn out and leave.

Companies are primarily set up to generate value and, as a related point, to control costs. A smooth deployment helps them achieve those two aims more efficiently. Cheaper deployments mean money can be spent on things that matter more. And happier teams mean money savings too, as the company spends less on recruitment.

Continuous delivery is an enabler that helps keep operations cheaper.

Conclusion

The traditional approach to managing deadlines, trying to produce a detailed plan across the entire delivery timeline of months or even years, then driving it as if it were matter-of-fact is not a recipe for success. When a business, a sponsor, or a project manager sets and advertises a release date for their project, they are setting potentially unrealistic expectations which are hard to adjust, later, and potentially damaging for all parties.

A team will work hard to help meet TRD. However, they do not do miracles and delays are very rarely the team’s sole responsibility.

The best approach is to set up continuous delivery early on – the mechanisms to release to production early, often and cheaply. That gives the business the option to define a Minimum Viable Product on the go and release it when they think it will generate value, then release incremental changes after that. With its short and controlled cycles, continuous delivery allows a business to understand timescales based on evidence, and, therefore, set expectations accordingly. It also allows teams to work towards tangible, manageable goals within short timescales (typically, two weeks at a time).

In this day and age, patches and updates can be pushed transparently: even something as strategic as Microsoft Windows works like that. It is by far the most cost-effective way of working.