#7 - Plan to the right level
We can all be prone to a bit of control-freakery.
It’s understandable to think that your inner control freak could actually be useful when it comes to planning a project - ensuring every single aspect of what is going to happen has been planned, logged, and accounted for.
The reality is though this highly detailed type of planning can often be more of a hindrance than a help.
Not only does it take a great deal of time, things will likely change along the way anyway -rendering the latter half of your plan useless.
Here’s a better idea.
What can you do?
Of course you need a general plan of how the project will work in a perfect world - but the majority of your planning time should be spent on things like identifying dependencies, validating assumptions, acknowledging constraints and breaking delivery down into discrete items.
When, and only when you have your delivery broken down into smaller more manageable chunks should you worry about planning in any detail - planning how the next chunk of work or the next product will be delivered.
Why it works
This method is so effective because people deliver better outcomes if they can simply focus on delivering products rather than worrying about rigidly sticking to a plan.
By allowing people to work more freely instead of to a rigid plan it means more time can be spent on improving efficiency a and identifying and avoiding risk.
As the PMO it should be your job to clear the way so the project team can get on with doing what they do best – delivering products. If you’re spending half your time telling them how they’re going to do a job they’ve spent their whole career’s becoming experts at you’re doing PMO wrong. If someone needs to crack the whip let it be their team leader of line manager.
Investing time in areas like tracking the RAID and increasing efficiency rather adherence will help people be more effective the forcing plan adherence down their throats.
#8 - Project teams are for life (not just for Christmas).
When you live in SAP land you can forget what it’s like to work in a normal job.
In normal jobs - where a big chunk of the workforce aren’t contractors - management generally try and get staff to stay with them for as long as possible.
That’s because onboarding staff is a pain in the arse.
It takes a long time and you still have to pay them despite the fact they add no value while they’re being onboarded.
Why then in the SAP world are we so content to chop and change teams mid project, bringing in new staff on a whim and giving people new responsibilities at the drop of a hat?
It’s costly and means lots of project time is wasted on onboarding and team ramp up.
So stop doing it.
What can you do?
One of the things the PMO should do to increase project performance is resource forecasting and retention focussed activities. By doing this they can significantly reduce the amount of staff swapping that goes on across the lifetime of the project.
On top of this, the PMO should also create a slick and repeatable onboard routine utilising modern training assets that will help people to understand the project, the business case, their key deliverable and any other important information that they need.
(Hint - it should be more YouTube than print-outs!).
Get this right and you’ll dramatically decrease onboarding time and get people feeling comfortable in a snap.
Why it works
More continuity of team members improves ways of working - which seems obvious when you think about it. The longer you work with someone the better you know how to work together.
It also means less time is wasted onboarding people (such as technology access not being available for a role) and ramp up time is reduced.
If the PMO can take this process by the scruff of the neck and standardise it across the entire project you can make teams work better together for longer, and onboard people faster so they can start adding value the day their bum hits the chair.
#9 - Standardise status reports
Status reports are important documents – this is a given. However, different people will often want unique status reports to be created just for them.
Whether this is simply an ego trip on their part, or a valid claim as your current status report is lacking some vital information, it is never a good policy to start creating custom status reports for different people.
Not only is this time consuming, but on an SAP Project it is vital that you have one version of the truth. By having a standardised status report that is shared with everyone you ensure that this happens.
The process of status reporting should be about measurement and escalation, not the production of more status reports. You need to minimise the time spent creating them as much as possible so you can spend more time acting on the information within them.
So how do you quell the demands for custom status reports?
What can you do
An important part of standardising status reports is about getting the template right. Ensure reporting templates are aligned and linked via standard KPI’s that everyone understands and sees the value in.
You should also map all reported issues and risks to owners so people can clearly see what the problems are and who is responsible for them.
Why it works
When you standardise reports in this way they can be easily combined into Programme or Portfolio reports, and teams who receive the reports understand how the Project delivery is being measured and how they need to act in response.
It’s easy to get bogged down in the process of reporting and miss the time to act. A good PMO doesn’t just make reporting easy to do - it makes sure reports are acted on.
By standardising reporting you’re better equipped to do that.
Check out part four here - SAP PMO tips part 4.