Management Survival Guide Part 2: The best secrets of re-defining a toxic programme in trouble

If you are reading this article, I will presume you have read, Part 1: Recovering a Toxic program. Note, these are written in order. If you have not read Part 1, I would suggest you do so before proceeding.  Otherwise, some of the contextual references will not make sense.  The focus is a guided approach in recovering a toxic programme so good discipline counts highly!

Additionally, keep in mind we are recovering, per se, “a program” (e.g. “initiative”, “concept”, “project”, “new enterprise”, “strategy”, etc.).  Since this guide though is also useful also for setting up a program/strategy/initiative, we will deviate a bit from standard MSP.  Keep in mind, whereas the (project) outputs are important, your key focus is on outcomes. So do not get lost in the weeds, thinking at the project level.

Definition

Now that you have clearly identified the programme of work and have the required understanding and collateral, your next steps involves defining the programme of work.  This is a drilldown now to the next level, with key (outputs) outcomes as follows: –

1. Securing detailed information that will define the new capabilities. To include the method of how you will deliver the new capabilities.
2. Developing a delivery framework of how the Programme will be run & managed
3. Factual list of changes that will be delivered into the company (HINT: Program Brief >> Blueprint);
4. What benefits, costs & delivery timeframes, dates; delivered (HINT: Business Case);

This part of the recovery process is crucial to success.  The products/collateral will require deep level investigation, analysis and understanding.  Detail is extremely important at this stage as it will become the foundation for developing your overarching delivery plan.

Cost/benefits are a key factor also in the viability in any programme.  It may seem redundant in stating this fact, but you want benefits that outweigh the costs in a reasonable time period (typically 3-5 years max).   You wouldn’t for example spend £10,000 replacing all PVC windows in your house if you are only saving £200 a year in energy bills. It’s simply not cost effective.  so keep this first and foremost in your mind at all times.

Inputs, Controls, Outputs, Mechanisms (ICOM’s)

If you have ever seen an MSP framework model, you may note similarities to another older modelling language (analysis) framework referred to as “IDEF” (ICAM definition). Originally initiated in the 1970’s by the USAF, it was a pioneer model used for overarching integration definition.  It’s core concepts were so robust and insightful, you will still find its models in use today.  As it seems both MSP and I like its usage here, lets digress slightly for understanding.

The following model comes from an IDEF framework (NB: If you want to read more on IDEF).  ICOM’s is an acronym that simply put, tells you: –

• what to do (activities at the centre of the box below, always a verb/action)’
• what is needed (Inputs);
• what will influence the work (Controls);
• what the end result will be (Outputs, outcomes);
• what systems, parts, people will be required to make it all work (Mechanisms);

IDEF is a function modelling language that utilizes ICOM based flow and syntax. The following is an enhanced MSP flow model.  It will be useful for understanding, where to next.

Methodical approach

The following diagram is an extended ICOM model I have enhanced to paint a clear picture of all constituent programme parts.  Before proceeding, please study and have and read closely all Inputs, Controls, Outputs, Mechanisms and finally (in the centre), the Activities.

I am sure some will feel daunted here.  Remember, there were gaps in the previous running of the program.  If the program board were actively running the program, they would have acted on concerns (Risks, Issues).  The fact they did not implies either a gap in knowledge, a gap in collateral, or a gap in leadership.  Regardless, it implies a lack of methodical management of at a senior level. This is why you inherited this toxic program and you are now tackling this core issue. A functional model of the programme is very beneficial so that you gain (or develop?) an intrinsic “feel” for what you are attempting.

So take a deep breath, turn the actions around into a “definition” plan and tackle the list, one by one.  Delegate where possible but handle critical parts yourself.  You can for example have your Business Analysts develop the Blueprint.  However, you need to ensure you clearly read and endorse what they have written.  Let your Project Managers put together the strawman plans.  Do not forget!  You have the helicopter view so ensure you are OK with the activities, timelines, costs, owners.

Trust me, your leadership will feel more confident with a methodical approach this time around.  Especially if they are partially culpable and whipped the previous team for too much speed, too many shortcuts.

Useful tips Part 2

As in Part 1, more useful tips to help you along.  Note, some of the previous tips are re-suable so are also listed below.

1. DO re-enforce the understanding that you are in charge and report directly to the SRO/Programme Board. It will ensure you are able to secure desired support at key stages of Definition.

2. DON’T be shy about handing out work and assigning owners, especially in terms of Risks & Issues. Place your Risks/Issues log in a visible area so all stakeholders can review this as needed daily.  Ideally, owners should be able to update this with progress as/when needed (e.g. Sharepoint, Teams, or some other collaboration tool).  Check it, daily, for updates.  If people are missing target dates or not updating the register, contact them directly for updates.

3. DO define a standard template for the Program Board. You cannot afford to waste time with a new template each meeting. Secure approval with the Board and ensure it is clearly updated before every Board meeting. Ideally arrange a Board meeting on weekly schedule, worst case would be fortnightly.  Flag anything greater than fortnightly as a “High Risk” item in the Raid Log! 

4. DON’T be afraid to ask for resource “Mechanisms” to support the program. If you need more BA’s, push for them.  More PM’s, push. More report leads, push. This is especially important if you have a need for Interim Funding.  Just be clear as to why when you explain the “Need” here.

5. DO challenge people for good honest feedback, especially in reviewing emerging collateral. If you ask for a review, ensure the feedback is meaningful. Be especially mindful where some of the owners are “co-responsible” for certain collateral; e.g. the business case would be co-owned by Responsible Finance stakeholder and SRO.

6. DON’T fudge costs or benefits. The expectation is that at this point, you will have a target estimate of costs +/- 30%.  Similarly on the benefits.  If the variance is outside of 30%, you have not thrashed this out enough.  Get further into the detail and nail this down.

7. DO practice good version control. Every release of a core product should have Title, Date, Version embedded directly in the file name.

8. DON’T forget to crosscheck your documentation for accuracy. Especially where you are publishing costs or benefits.  g., Costs/Benefit profiles should be in accord with Blueprint and Business case.

9. DO challenge negative attitudes and/or behaviours wherever you see them, but at a one to one level. These are a subtle form of sabotage and are extremely damaging to any program. Do not be harsh.  Just advise the person in question that you would appreciate their positive support.  Diplomacy goes a long way here!

10. DON’T forget to review the Program Definition Plan with all key stakeholders, especially the SRO/Sponsor. Then issue as a formal Version 1.0 and circulate to ALL team members, stakeholders, and anyone associated to the program. Lock this under firm change control.

11. DO ensure you have a robust communications strategy outlined. Clear communications of plans, intent, progress are one of the biggest failures in programmes.  People will worry if they do not see regular progress, even if everything is going perfectly!

12. DON’T forget formal approvals on all key documents. If you are not clear on which documents are “key”, then agree a formal list with the SRO/Sponsor.

13. DO be consistent on everything you do. No matter what the circumstances.  If you have to cancel a regularly scheduled call more than twice in 3 months, you are entering dangerous waters.  If you are not around, have a delegate run the call.  If you are running late on issuing a product (e.g. revised plan), issue an apology and do not let it slip again.  Even if the plan has no changes, people will want that re-assurance.

Additional guidance that may help

Try not to “re-invent the wheel” here.  There are many excellent websites that have great templates you can uplift for your purposes.  My favourite is the Association for Project Management (APM) website.  A treasure trove of knowledge!  Do not be fooled by the word “project”.  It does deal with projects and programmes and you will find much of the collateral interchangeable.  Alternatively, here is a site that offers free MSP templates, ILX Group.

Do not forget that people will look to you for guidance.  You should be absolutely “radiating” confidence, blinding people with your positivity!  A good attitude will be immeasurable helpful.

Finally, do practice diplomacy, coupled with positivity.  I do not endorse lying but that does not mean you have to put things in very negative context either.

For example, if you have slipped a date, an honest message could be as follows. “Yes, we missed the target but are recovering the date and there will be nil impact on the plan”.  Alternatively, if you are over budget, an honest message could be as follows.  “Yes, we overspent in this area by £20K but we believe we will remain on target within the variance and we don’t foresee any further problems here”.  How you tell a truth, is sometimes more important than the actual message itself.

What next?

In continuation, I hope you are finding value in using an MSP framework.  By this time, you should be finding that your hard work is paying off and attitudes are changing for the better! The teams should be more switched on now with positive “can do” attitudes.

The next instalment of these Survival Guides will take you to the next step of Managing the Tranches.  I hope that you have secured a book here on MSP as advised earlier.  Moreover, you have been diligent in reading it, cover to cover.  If you did follow this key advice, this should all be making much better sense.

Look for my next instalment. Coming soon!