Are you doing the right project? Understanding your project’s DNA

Some years ago, APM used ‘doing the right project’ as one of its themes – which meant knowing exactly what it was you were supposed to be delivering. It’s a very important thing to get right, best done at the outset of a project or programme.

What are you really delivering?

Let’s be honest – a sponsor, board or client will do their level best to define what it is they want delivered, but often a lot of detail is left unsaid. This isn’t necessarily their fault – often the assumption is that this is somehow understood. By everyone.

An example of this might be a project brief to transition an organisation to a new enterprise resource planning (ERP) system; this might be a system that has already been agreed, perhaps already purchased. The deal is done. Your job is to get it installed and get everyone using it. Just a migration job, right? Get it sized up, check where everything is and will end up, how many users to train, go-live date, overall budget for the migration, that sort of thing. And off we go….

Hold on a minute! What about:

Do all users really want the new system? Were they actually consulted? You may need to still convince some, while respecting their reasons for not wanting to change.
Has there been an honest change readiness assessment done? What did it recommend?
Is all the content where you think it is (or have people got illegal copies of documents in special places)? Which ones are the latest?
Does everyone want out-of-the-box, or will some department need a customisation? Has this been planned and budgeted? Does the supplier know?
Are there predetermined hard business dates (like end-of-year accounts, office relocations, mergers and acquisitions activity etc) that will affect rollout?
How many people need to be trained? Do you need different types of training, conversion, top-up etc?
Where will training be done? By whom? Is this a global migration and if so can you train everyone in all locations (and languages)?
Are there any compliance, audit or other assurance constraints to be planned in? Do you have any say in these processes or their dates?
Are there pending changes in legislation that will affect anything?
Are there any planned server upgrades, Windows 11 rollouts and other system changes?
What is the organisation’s hybrid working profile? Will it change? What happens if there is another lockdown? Does your migrating system support any of this?

I could go on. By now, seasoned project professionals will already recognise a lot of this. My point though, (with the exception of the last two bullets) is that these are organisational not technical factors. Exceptional sponsors may be aware of some of them, but many will not. The overall change is bigger than the narrower project.

My belief is that it’s the job of the project professional to anticipate all of the above and more; and to make recommendations to the sponsor or board. They might not thank you for this, but they’ll likely roast your backside later if you don’t.

The job in hand

It’s crucial to understand the dimensions, and to make sure everyone involved knows what this will mean. The project may be a lot bigger and more complex than described. Anyone glancing at advertised job descriptions will see this writ large – often by people who don’t understand how change works.

Typically the list of our duties includes the core know-how in implementing various systems, but also being an expert in communications, reporting, tendering, assurance, training, safety, managing subcontractors, auditing, convincing and so on. Try adding up the time you, as a project professional know you would have to spend on all these ‘duties’. It’s a lot more than you think. It’s likely that the non-technical change aspects will need more time than the core technical deliverables, but this is often missed by recruiters.

Sadly, project organisations can get it wrong too. When contracts were drawn up to appoint contractors to design and build Crossrail, they were written by people with considerable expertise in civil engineering, signalling, construction, tunnelling etc. It wasn’t foreseen that there would be a voracious appetite for assurance documentation needed to hand everything over to the satisfaction of governing authorities and sponsors. Some 200,000 additional documents needed to be written, checked, tested and of course paid for.

Nor was it understood there would need to be multiple iterative levels of integration between all the parts (it was assumed that ‘Interface Control Documents’ written into contracts would provide easy flows of compatible information between all parties).

In other words, it was always a systems project of massive proportions, not, as had been assumed, a contract-driven civil engineering project. Partly because of this misapprehension it delivered late and over budget. It was not, simply put, the ‘Right Project’; the DNA was wrong.

Stop! Look! Listen!

This road safety campaign was highly successful in reducing road deaths. It could be applied in our world of increasingly complex projects. Perhaps we would be wise to adopt it, giving ourselves a better chance of delivering the ‘Right Project’ before we find out it’s the wrong one:

Stop – to read everything and think about all the dimensions, including future dimensions you are going to encounter. Do not be rushed.

Look – at the organisation, the environment it lives in, the deadlines, constraints and legislation that will affect it, where technology is pointing.

Listen – to the stakeholders who will deliver it, and, you hope, become ambassadors for the change about to happen. Take their wisdom on board.

You may find a RAID matrix is useful to get all this initially documented (Risks, Assumptions, Issues, Decisions) and then continually reviewed; personally, I find mind-mapping tools are great to kick this off, as they let you map the project’s DNA in one place.

You might be surprised by what you find when you take the time to Stop/Look/Listen and check what it is you are actually going to be delivering. Naturally your sponsor or board should be made aware of what you find, and a grown-up discussion ‘should’ convince them that you know your stuff and are acting as a critical friend.

You may also be interested in: