My least favourite assignment over the years has been (and still is) doing post mortems on ‘failed’ transformation projects or programmes. It’s just not fun digging into the guts of someone else’s work, where they worked damn hard for years, but still ‘failed’. Chatting to others who perform services in this space, none of us enjoy it. We all have experience in transformation and have been in similar situations to the programmes we review. We do have some empathy for the pain we see.
There is some hope though. There are a lot of recurring themes and I do believe that every ‘failure’ I have picked through was preventable. What can we do differently to get better outcomes? My Seven Step Serenity Plan may help.
Step 1: Start with a Growth mindset
Didn’t expect that at the top of the list, did you? One thing I have never seen in a project management textbook is any discussion around nobody can see into the future. There is too much emphasis on predictability of outcome. Your plans will be wrong, accept this. Allow the team to get things wrong. Your assumptions will be tested and found wanting. This is normal. Allow the team to go ‘hang on, that didn’t work the way I expected’. This is not failure, it is learning. There are enough checks and balances to pick this up before you have a major issue on your hands. Be receptive to information that indicates a pivot in approach, and act.
Step 2: Get the basics right
This is the project management 101 stuff. The content of most project management introductory courses. Yes, the really basic (boring) stuff. I am agnostic as to whatever delivery methodology you ascribe to, just make sure you understand the essentials and apply them. Strike a balance between bastardising it to the point where you have lost the value in applying it, and demanding absolute conformity to every process step. You need to be pragmatic here.
Whatever you do, make sure the following is robust:
- Your initial business/investment case. Done right, this gives the delivery team real clarity of intent and understanding of what is valuable to the business. Done poorly, they are directionless at the outset.
- Complete your planning. Yes, all the steps your methodology may prescribe. Time and cost are an output of this. The quality of your promises as to time and budget are directly related to the quality of your planning. It’s in your own best interests to get this right (or near as dammit, it will never be perfect).
- Agree your business requirements before you do the work. How you do this I leave up to you. Just be able to go hand on heart, we all know what is required.
- Don’t go live with major defects. Trying to clean the mess up afterwards is just not worth it. And be very wary of last minute jettisoning of scope to hit a milestone.
Step 3: Let the delivery team plan the delivery their way
This should be obvious, but it is not. There is no point in bringing onboard highly skilled (and expensive) resources and then dictating how they should do things. This may be to comply with your inhouse methodology or whatever. Don’t do it. You devalue their expertise and create a delivery risk. Of course, the plan needs to make sense and you need to be comfortable with it, but let them use their expertise, you will get a better outcome.
Step 4: Governance needs to support delivery and facilitate decision making
Don’t hamstring and distract the team with unnecessary process masquerading as governance. Governance should be an extension of your corporate governance. It should focus on decision points in the delivery plan. Governance needs to be adapted to suite the delivery, not the other way around. It should help all concerned to deliver safely. Governance should not be compliance. Be flexible as to the application of the process of governance, but inflexible as to the controls you expect to see. How they are applied should support all concerned, including the delivery team.
Step 5: Manage your optimism bias
Optimism is good. Without it nothing could ever be achieved. You want your delivery team to be optimistic rather than a team of Eeyaws (how depressing that project would be). Just don’t let it blind you to warning signs that things aren’t okay. And don’t let your groupthink become a ‘cult of optimism’. When projects miss deadlines or go amber or red, or when you have a review that has some worrying findings, don’t hope things will magically right themselves, they won’t. Using your growth mindset (i.e. not mercilessly beating people up), establish root cause quickly and take corrective action.
Step 6: Don’t flog a willing horse
People who work in the transformation space do it because they like to create and transform things. They want to do it. They are some of the most passionate and creative people you will meet in any business. They want to achieve, and they thrive on challenge. Don’t abuse this, even unknowingly. (As for those that are unwilling, replace them). Two things to be mindful of:
- Never schedule more than a 40 hour week in your project plans. Yes, they will work through the night if they must, but can’t every night. As soon as you schedule them at 40+ hours you lose any buffer down the line.
- Manage stress. A bit of stress gets the energy flowing, don’t overdo it though. I’ve seen people break, their judgement cloud and preventable errors occur. Don’t let the team get to this point.
Bottom line, you wouldn’t continually redline your car, you’ll break it. Don’t do it to the delivery team, you’ll get the same result.
Step 7: Never do anything for the auditors
No, I don’t mean don’t cooperate when you are audited (please do). I mean never do anything to provide an ‘audit trail’ or because ‘the auditors want to see it done’. If there is no reason to produce a document or follow a process other than ‘for audit purposes’, don’t do it. Auditors want to see how you reached a decision, what was the process/document/meeting etc. Writing a business case three months after the decision was made is pointless. Focus on your decision making and what you (not the auditors) need to be comfortable with the call that needs to be made.
No responses yet