A Successful Transformation (3) The Delivery Capability - Part 1

A Successful Transformation (3) The Delivery Capability - Part 1

My article on my third dimension of Transformation is so big, I’ve had to split it into two, sorry!

 As a reminder, I see there are 4 dimensions to a successful transformation:

1.       Benefits definition

2.       Alignment of Executives and stakeholders

3.       Delivery capability (and quantity) of the teams managing the work

4.       Engagement of your people

 

My next two articles focus on 3) The Delivery Capability and ask:

1.       Do you have the right Transformation structure, KPIs and governance?

2.       Do you have plans and risk management?

3.       What about risk management?

4.       Does your Programme Management Office and reporting work?

5.       Do you have the right capability and number of Transformation staff?

 

Q1 - Do you have the right Transformation structure, Key Performance Indicators (KPIs) and governance?

When I say structure, I don’t mean what you call the transformation (always subject to vigorous debate, and best left to marketing or internal comms), but how you break it down and then loop back to check it will deliver the strategic objectives.

How to break it down? This is another one that is subject to much discussion, but generically you will need a blend of programmes and projects that sit under neatly communicable (to shareholders and your people)  pillars or headers, so they understand how it all fits together, e.g.

·       Revenue generating / digital projects: innovations of product or service, international expansion, often supported by customer facing systems

·       Large internal commercial system:  optimisations or re-platforms

·       Large internal back office system:  optimisations or re-platforms

·       Enabling Functional projects:  such as Target Operating Model design, Organisation Design, other people initiatives, strategic sourcing, compliance etc.

 

Once business cases are complete for each programme or project, it is critical to link these back to the Transformation and organisational KPIs. The KPIs can be financial, operational, qualitative or quantitative, but without them you can’t guarantee alignment or measure success.

Governance structures  – there is no one-size fits all solution to this. The bigger your company or more regulated it is, the heavier the governance required, and it may even be dictated to you. However, the minimum is broadly:

·       A quarterly Transformation review – looking backwards and forwards to the next quarter

·       A monthly Transformation governance meeting with the Executive Board

·       A monthly or bi-weekly Programme Steerco

·       Weekly project meetings

·       Daily standups for technology teams

 

Q2 - Do you have plans and risk management?

Dwight Eisenhower is quoted to have said “Plans are useless, but planning is indispensable”. This seems paradoxical, but he was right.

 

Without sitting down to think and plan at the beginning of a project and periodically thereafter, you won’t consider all the alternative routes to delivery, the risks / pitfalls and implementation issues and without doing this, you will not know if the goals or timings are achievable.

 

I have sat down on countless occasions with programme leaders and doers and forced them to create a plan, and it is the process of thinking that is the most important element – it creates “aha” moments that can sometimes lead to a delivery deadline moving to the right, or a whole new set of activities that no-one anticipated needed to be done. When in the middle of a transformation, that up front thinking can make it easier to anticipate and react to bumps in the road. Good questions for the planning process would be:

·       How do we want to do this, what’s our approach?

·       What are the alternative approaches?

·       Are there company events or deadlines that will impact our timeline (e.g. a Global Town Hall)?

·       What could go wrong, or could there be unanticipated consequences of this action?

·       Who needs to be involved / consulted?

·       Is this realistic, does the plan (or scope!) need to change?

 

Where the 34th US President is also correct though is when you are in the middle of battle (analogy – transformation) , the conditions are complex, ever changing and sometimes hostile, so you should not be hostage to the original plan.

 

How to avoid planning (and re-planning) pitfalls?

1.       Don’t plan too far out - unless you have to (e.g. large waterfall projects with 3rd party suppliers) – define what outcomes you need to achieve over 12 months, what you will have done by Q1 and Q2, with detailed activities for Q1

2.       Re-plan quarterly – review the last quarter, then re-plan the next quarter in detail

3.       Open and democratic dialogue – we all know programmes have the optimists and the naysayers – let them all speak for they will all add value to the thinking

4.       Stakeholder management – an experienced programme team will be managing their senior stakeholders, any deviation from the stated path needs to be managed carefully, including forewarning that there may be issues ahead

 

(3) and (4) are affected by your functional or corporate culture. If people don’t want to speak out in fear of over-reaction or even (what sits in many people’s minds in a toxic culture) losing their jobs, then open dialogue will not be achieved easily.

 

The Plan on a Page - POAP – there are numerous planning tools out there, but I have not found one that is suitable to put in front of a Board, so unfortunately for Programme and Project Managers, to get visual engagement of what is important, they need to create a POAP. It is typically represented in Powerpoint and fiddly to change, so the bane of one’s life.

 

The POAP serves many purposes:

·       A visually accessible representation of what is important, including dependency arrows or key risks where relevant

·       Education to the Board on all the programme buzzwords that are a natural language to transformation team, but a foreign and difficult one for the uninitiated

·       A communication tool to stakeholders

·       A reporting tool on progress

·       A reference point for all to remember key dates and activities

 

What about risk management?

Let’s face it, risk management to many is boring, then because it is boring, risk logs don’t get updated to the right level of granularity. However, having a risk log is a good start, the question is how to maintain it?

 

Firstly, your teams need to understand the difference between an issue and a risk. To this often asked question I respond “a risk is something that might bite you in the bottom, and issue is something that has already bitten you” i.e. a risk might arise, an issue has happened - it is live and a big problem.

 

Secondly, you need to review your top (by all means not all) risks and issues with the Executive monthly. This does not have to be formulaic (e.g. every red risk), but a good PMO will know which are the ones worth raising to get the right level of discussion on how to solve them at that moment in time.

 

Thirdly, regular maintenance of risk logs is necessary, but a Programme lead should at least once a quarter sit down with team members and stakeholders and have a mini “workshop” on what’s worrying them, and identify potential new risks.

 

Finally, risk management is everyone’s job, but it is generally the project manager’s role to update the risk log – so in every meeting a problem is discussed, you need to check if that’s a new risk that needs managing and ensure it gets added to the log.

Yasin Zackaria

IT Architecture and Strategy

9mo

So true about having the right dimensions

To view or add a comment, sign in

More articles by Melissa Davies-Wright

Insights from the community

Others also viewed

Explore topics