Project fundamentals - spot and remedy red flags

22.04.18 05:59 PM By Matt Koopmans

In all the programs I have ever come across, and these are many over the course of my professional career, they all have one thing in common: the fundamentals. None of the programs I witnessed succeeded without them - no matter what fancy additional things were implemented. Below is a list of common red flags - warning signs of dangerous currents in the program ahead.

 

Fundamental 1 - Why?

Why embark on such risky program? Why go into the deep unknown of Digital Transformation? Why change the highly customised ERP? Why look at CRM systems? It all starts with the benefit analysis. Most organisations complete a benefit analysis in the business case, and then the business case is locked away until the program is completed.

The benefits in the business case make up the "why" of the program. This should not be locked away, and hope that somehow the program keeps on track against realizing these benefits. Benefits must be front and centre for each department involved in the program - the "north star" for each stream. 

RED FLAG: departmental leaders do not want to sign off on the benefit realisation plan.

The benefits are so fundamental to the execution of the program, that it is virtually impossible to succeed without having them as explicit goals in each stream. Otherwise, what are the teams actually aiming for? Without a destination, any direction is equally valid. Without a goal, every failure is as good as a success. Departmental leaders should sign off on the targeted benefits - they are the ultimate owners of the process, and their decisions impact both budget and benefit.

 

Fundamental 2 - What?

The benefits need to be distilled in an actionable scope. This is usually done by the program manager, or by the implementation partner/solution integrator. Typically, these are written in a Statement of Work - however, the what tends to get decoupled from the why. 

RED FLAG: the stated scope is not referred back to the benefits it seeks to have accomplished.

For example - the scope definition states that an e-procurement system will be implemented with features x, y, and z. Following the scope definition may not actually deliver a system that enables the benefit realisation. It is essential to establish in each scope section the expected benefit, so that if the program goes different than expected (which it always does), each change is tested against the potential of realizing the benefit - not against whether or not the original scope is delivered.

 

Fundamental 3 - Who?

There are two aspects to who is delivering the program: your internal team and contractors, and the system integrator or partner. Starting with the internal team, who is going to be freed up for the work? And how much time can they spare? Too little, and the program misses out on the essential know-how. Too much, and the business continuity could become an issue. Another consideration is how much change is desired - too much detailed knowledge of the current process tends to lead to process inertia. Too few departmental leaders, and you are at risk of low commitment and buy-in - too much involvement, and you are at risk never getting down to the detail.

RED FLAG: you do not have an opportunity to interview the key partner resources

The team of the system integrator or implementation partner is just as important to get right - it is absolutely within your rights as a customer to interview the key members (even in a fixed fee arrangement!). It is not so much an aptitude test - the system integrator/partner selection would give a good indication of the level of resources that can be supplied. It is the interview of the core team, the leadership team supplied, that will give you insight into the behaviour they bring to the table - culture is the culmination of the dominant behaviours on the program. Ask behavioural questions and beware of inconsistencies between the key players.

 

Fundamental 4 - How?

How are we going to deliver the program? This is more than just the statement of work - although that is a very important contractual document - it is also the project charter, the communication plan, the escalation process, etc. These are just as important as the statement of work itself. All these documents remain meaningless if it is not inherently part of the program team's DNA.

RED FLAG: the kick-off event is cramped in an hour or less, or worse, skipped altogether

Take time to form the team - generally two to three weeks before the kick-off have the core members of the team work through the delivery and culture. This all comes together at the kick-off, a hugely important event (and not only on symbolism), where the wider team is introduced with a series of workshops, presentations, and activities, to the desired culture. The core members form the "culture agents" in the group. This is not a formal role or position, but they do drive the desired culture and behaviour through leading by example (it is therefore important that this core team forms a critical mass to drive the culture - too few and the desired culture will not take hold). If culture eats strategy for breakfast, it is not difficult to imagine what it will do with statements of work and project schedules!

Bringing it all together: Execution, Execution, Execution!

Doing all the above does not guarantee success - it now comes the execution. The quality of the architects, consultants, project and program managers. Ignoring the red flags, and even the best resources will struggle against the stream pulling the program towards failure. But addressing the points of:

·  Why - there is a set of benefits that are owned by the departmental leaders, driving every decision in the program

·  What - there is a clear scope statement which leads back to the benefits to be realised, with a mechanism to measure any scope change against these benefits to ensure return on investment

·  Who - the team is appropriately balanced from experience and know-how to creative and eager to try new things. The system integrator/partner team is culturally aligned with the desired program culture.

·  How - there is agreement on how the team behaves towards each other, how reporting is done and how often, what communication lines and methods are used, and what escalation paths are available.

It does not simply stay with documenting and agreeing - it is the actual auditable execution that makes the difference between planning for success, or merely hoping for it.


Originally posted: 27 September 2017

 

Matt Koopmans