Don't Start the Project Until Dependencies Are Met

Many people don't realise that there is a pre-delivery phase to most projects. In fact, the pre-delivery phase is almost always much longer than the delivery phase, and many projects go through multiple failed pre-delivery phases before they actually get to kick off "proper".

Pre-delivery is the bit before funding—the stage before we get to resource our project team and get stuck in. It's easy to underestimate how much work is conducted during this phase, the cost of which is borne by the business's "Business as Usual" (BAU) or year-to-year stable budget, rather than the one-off funding from "capital expenditure", which is normally associated with IT projects.

Back in my Ernst & Young days, I was frequently involved in the pre-funding phase of projects—presumably because the skills and experience required to write a business case are more often learned through osmosis in consulting firms rather than being taught directly at university. With a foot in both phases, I noticed a way to minimise the risk of cost blowouts in the delivery phase: by moving most of the activities for sorting out technical and operational dependencies into the pre-delivery phase.

In any significant digital project, there is a slew of dependencies that need to be met in order for the work to be completed. Common examples include:

• Building and/or provisioning integration points to and from other systems.

• Implementing organisational structural changes to accommodate new activities or changes in responsibilities in people's roles.

• Designing and provisioning infrastructure.

• Marketing campaigns.

• Public relations announcements.

It turns out that these dependencies are the hardest to manage because they are not under the direct control of the project team. More importantly, the cost implications of suffering delays due to these dependencies are extreme—because at some point, the entire project team becomes dependent on them. You might have ten people burning through the budget day by day, unable to do any meaningful work because the dependencies have not been met.

For a small project, you can easily burn through $10,000 per day waiting for an infrastructure issue to be fixed—without making any significant progress. It gets worse the closer we get to the end of the project. At the beginning of a traditional project, there are usually other activities to keep the team busy, but this is not the case toward the end.

The way I get around this is by inserting an interim "dependencies" phase between the approval of funding and the resourcing of the full project team.

This isn't always easy, as sponsors have often waited two or more years to get the funding approved, and as soon as it's there, they're in a rush to get the job done. However, in my experience, a small amount of patience for a small amount of time dramatically reduces the risk of cost blowouts during the delivery phase.

During the dependencies phase, we typically need one or two part-time resources to work with business sponsors and the rest of the organisation to set the scene so that the project can succeed. There is real work to be done here, but it typically requires just one to two days per week per resource. Most of this time is spent waiting—waiting for meetings to be scheduled with governance groups (especially architecture teams), waiting for work to be done, and then testing to ensure the result is working before we resource the full team.

In the olden days (before 2010), I would actually separate out the establishment of infrastructure as a pre-project project. This was because it involved so many people, was a significant part of the budget, and was a fundamental dependency for any meaningful project activity. But now, with cloud V2.0 services, this activity is entirely unnecessary.

I think about this from a mathematical perspective: every day we're delayed in establishing the dependencies before we start the project costs us at most one full-time equivalent (FTE). However, exactly the same delay for exactly the same reason—once we have the full project team on board—costs us at least ten times this.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.