Is Your Program going up in flames? How to Navigate the Crisis and Reset towards Success.

####First, context:

Recently, I was called by a friend in the industry to come help their company with a significant customer challenge. 

The prospect of helping out one of the biggest digital transformation and systems integration partners in Australia, with a strategically important customer (that also happens to be the largest privately owned company in the country^1,2)  was an opportunity I couldn't ignore. 

The brief was clear: help the customer understand why their most important program of work was floundering. 

####The engagement:

The program was well funded, had exec buy-in, and was genuinely critical to their core service offering.  In fact, it was urgent. The existing digital platform was unable to handle load, underservicing demand, and worse - negatively affecting the ability for the retail stores to service customers at point of sale³. 

Intrigued and a little bemused, the engagement began:  I was introduced to the customer. The first port of call, listening. Understanding the current state; the issues, challenges and frustrations.  The only thing the stakeholders from top to bottom, internal, consultants and external contractors agreed on was; it was not working!

Boy oh boy, were the backs up and the knives out! And for good reason. It felt like I’d walked into the program equivalent of 300. Everyone was either battleworn, defensive, exhausted, frustrated, feeling let down….or all of the above. Let's just say it wasn't the easiest way to enter a conversation; feeling like now you’re being quizzed by a consultant: on top of all this to ‘please explain’.  

But to their credit, they are a resilient bunch. By and large, most stakeholders were just looking for a bit of sanity, some support, and a way to move forward.  Nothing drains an organisation than the feeling that all the work you are doing is futile, doomed to fail. Either on the ground, or on the exec team.

Jumping to the end, lest this start to compete screen time of The Odyssey, the truth is someone needs to be accountable for a crisis and some people needed to change, but a lot more work was needed to hit reset on some key processes, the way the organisation managed projects, BAU and critical ops, as well as, the resourcing model.  Some fresh legs, a reality check, re-calibration, identification of some unhelpful practices and everyone jumped back into action. 

####So, what lessons can be learnt?

I'm glad you asked:

• *SteerCo’s are not just a kind of high-level project status meeting. But a forum where all key stakeholders are not only kept informed but, where risk and issue impact together with mitigations are discussed, owned and actioned.  This is literally the place to have hard conversations. Make space for reflection and thinking too.  A SteerCo might need a follow-up to give stakeholders the room to digest and revert; not leaving it to the next scheduled meeting, or getting pressured into a snap decision, or worse no action at all! Avoid the next-day long email to the group. Rather create the focused space and time to knock these items out head-on.
• *Frequently circle-back to the outcome of the initiative and make sure the senior team is aligned. Be open-handed with the destination; things change, market factors change, design changes, new needs are identified and priorities change. It’s true, changing mid-flight can be frustrating. And there are things that need to get finished to realise any value, even if there is already a delta in expected outcome. This frequently happens in design-led engagements on digital products.  The initial concept from the agency is new and shiny, and mid-way through the platform or workflow uplift, the shortcomings of the design / experience become clear. Time has passed, use cases have changed or matured, or a competitor lands a similar concept first. Nobody wants to be the canary.  Or it's just easier to start to undermine the delivery through side-channel conversations. We’ve all done it. 
• *The process we use to deliver, the methodology,  the ways of working and the style needs to meet the organisational context. Too many teams enforce processes that are simply self-serving and not really benefiting the stakeholders. In general consider: who is reading this report? What do I expect from this mass email? There’s just too much fluff.  What is there is not specific, not associated with an owner, and not genuinely collaborative in working to resolution. 
• *Keep a decision log. It's not the CYA. The reason you made the decision is important, together with who made it. Lets choose to believe that a given role at a given point in time is making the best decision they can based on the information available to them.  Note that down.  The reason we keep it logged is so that we can learn from that decision (for both the positive and negative outcomes). If we don't, then we’ll never understand why, and worse, we can't learn from it.  Try to create a culture of making decisions. Nothing kills programs of work like a lack of decision-making, or deferred decision-making (which is worse). Organisations can do well to support decision-makers, even when it doesn't turn out the way everyone hoped. 

####A few notes: 

• *This post is my own opinion. It expresses my observations as I experienced them. The learnings are not verbatim, the core is aligned to the engagement. But I have expanded on them based on my experience and similar engagements. 
• *I’m a firm believer in process. Even if  we are all sick of the “trust the process” mantra already. But we need to use our brains here. The process is there to serve a purpose. Understand the purpose and then tailor the process to that.  For example: there is literally no point in having SteerCo’s when the data and information to support a SteerCo is not available. That's the first action. The second is to make sure everyone is aligned on their role and the expectation.  How you present the information and document the SteerCo should be relevant, digestible and easily accessible to the audience. 
• *In general: it's easy to blame the Project/Program/Portfolio manager. And this might be where the issue is. But often, it's a convenient scapegoat. Reflect on what their role is.  If they are doing it right, it should be the role that is the most invested in its success, and by implication, the one raising the flag for any obstacles getting in the way.  Consider if you are an obstacle.  In my experience, the most difficult thing to do as the lead on a program is to highlight that the person paying the bills is possibly the risk. 
• *Suggestion for engaging any delivery/project/program/portfolio lead: interview for 1 thing: assess if they care.  Not about their report, their process or their certifications. Rather, do they care about what the outcome is, and why its important?  If they do, the right level of ownership and process is likely to follow. If they don't you are likely to be in a world of pain; documentation and emails for days, but stalling delivery.