#4 - Fool me once, shame on you; fool me twice, shame on the PMO.
In our SAP Success Report we discovered that despite the fact SAP implementations have been going on for more than 20 years, more than 50% of SAP projects still fail to meet their business objectives.
Why haven’t we learned from our mistakes in that time?
Ask anyone who’s worked around SAP PMO and Project Management and they’ll tell you that they see the same mistakes being made time and time again on SAP projects.
Well not anymore. Use your S/4HANA implementation to break the cycle of SAP projects that don’t deliver.
Start by building a PMO that helps the project to learn from their mistakes to make sure they don’t happen again.
What can you do?
To make sure the project doesn’t make the same mistakes time and again you need to run your project like a business. Use the PMO to enforce processes that drive continual improvement in project delivery.
Don’t just rely on lessons lists alone - the PMO needs to make sure that lessons lists are followed up by actions, periodic review, and projects that will implement updates to Delivery Framework, Vendor Management, Procedures and Tools to name but a few.
Why it works
First off, this works for the obvious reason that it ensures that the whole project takes real learnings from mistakes and creates actions to prevent them happening again.
If the PMO do not own this process no one will. After all, no one wants to be seen as being responsible mistakes in the first place.
If no one takes responsibility for logging mistakes and creating actions to rectify them you’re destined to see the same mistakes happening time and again.
Secondly, by having the PMO run the project like a business and driving continual improvement the PMO are more likely to get the sponsorship of Execs, Business Managers and Stakeholders. These groups are used to working like a business, so they will respect this ethos in the PMO.
Show the key sponsors that the PMO takes continuous improvement seriously and they will quickly become the PMO’s biggest fans.
#5 - SAP PMO processes need owners too
When working on projects people often object to the PMO. They think they’re just box tickers, fun- sponges, and do-gooders who don’t understand what it’s like to actually be delivering the goods.
But a big part of this might be the fact that people don’t see the PMO as individuals who also have deliverables and responsibilities. Instead, they see the PMO as faceless hive-mind that is governed by bureaucracy and spreadsheets (and when a PMO is run poorly this can be closer to the truth than you’d expect).
This makes the PMO’s processes seem static, unforgiving and at times even unfair if people feel they don’t accommodate how they like to work.
And, it can mean that when processes do need to be updated it can be hard for the required changes to be actioned as no one knows who is responsible for that process.
What can you do?
Just like business processes, PMO processes need clear owners with PMO team members who are empowered and encouraged to make improvements.
These owners also need to be made clear to people outside of the PMO so everyone in the business know who owns which PMO process and who to talk to if they have any questions, ideas or objections.
Why it works?
Giving PMO processes clearly defined owners works in two ways.
First of all it puts a face and a name against the PMO processes so that people working on the project and people in the business won’t feel like the PMO is just pointless paperwork and bureaucracy - they’ll understand it is a real job with real people working to get real results. It also means that people involved in projects know who to go to for best practice advice.
The second reason it works is that it will help drive continual improvement inside the PMO itself. By assigning each process with an owner it is clear whose job it is to action any required improvements, and it will give people the motivation to optimise the processes that they personally own. When you’ve got someone doing this for each and every one of the PMO’s processes the effectiveness and efficiency of the PMO as a whole increases.
#6 - Estimates are not your friends
Estimates sound scientific - but what does it mean in reality. It means you don’t know for sure.
When project plans are built on estimates it can fool people into thinking that they have been planned with accuracy. However, if someone told you “this plan is built on my best guesses” you’d probably take it less seriously, and rightfully so.
Plans built on estimates alone have a rocky foundation and in our experience have a high risk of failure - so what should you do instead?
What can you do?
Instead of relying on one or two estimates alone use experienced people to provide you with a number of estimates. Base the estimates on a rough order of magnitude to days - don't get too bogged down in the detail because an estimate is just an estimate and will almost certainly change.
Recognise that people can't work on too many things in a week, acknowledge constraints, and build in things like team ramp up time, holidays, sickness, and the inefficiencies of large teams.
Compare the overall estimates and validate them periodically to ensure they sit as close to accurate as possible based on the current information you have.
If the estimates are longer than you would like focus on efficiency and ways of working instead of trying to find different ways of calculating that will come up with a lower estimate.
Why it works?
Understanding the basis of someone's estimated duration of delivery is one thing, but humans are not machines, and the environment of a business is complex.
There will be constraints, problems and human factors that mean a plan is not the sum of its estimates. By getting a range of estimates and understanding the factors that have been considered to create them you can be better prepared for all eventualities.
View estimates as a spectrum of possibility rather than a fixed date and they become useful advisory tools rather than a stick to beat people with.
Read the next tips in SAP PMO tips part 3.