SAP Project Quality Management
When I was growing up, I was surrounded by men who had been in one or another war, from WWII to Vietnam or even just in the military. Some had suffered grievous injuries, others had escaped unharmed, sadly, many were spoken of in the past tense; they didn’t make it. Today, more are.
At the time, I can’t say I really considered how their experiences would influence my life as a project manager, nor my choice when it came to joining the Air Force as an Aircraft Mechanic. But, looking back, I can say that at a deep level, I had decided that should I find myself in their situation, I would want to have as much control as possible of the situation.
Ultimately, this must, at least partially, explain my role as a Project Manager, both within the SAP world, as well as the military world. My experiences may not make for very exciting war stories (but that doesn't mean I don't have a lot of them, some of which might even be true:), but I think I have learned some valuable lessons that are worth passing along.
Your Project Plan Coupled with Skill Will Determine How Well You Control Your Project
Today, I would like to delineate 15 of those lessons learned, with regards to Project Plans.
I have previously produced a series of videos on the subject of SAP Project Management, but none focused exclusively on what I look for in a project plan. A project plan in this context is really just MS Project, versus the PMI Project Management Plan, another beast entirely..
- Tasks should be short, usually a day or less, even less if you have the bandwidth to monitor them.
As a project manager, ensuring these start as scheduled and finish as schedule is the first performance metric I look at.
Taken together, they yield a Key Performance Metric, is the project on-schedule, behind-schedule or worse, status unknown. - Conversely, a task should never be 17 days long or any other ridiculous number.
Tasks that are too long have a well known habit of suddenly being 'about to be late', but known by the PM only the 17th day. - Tasks without deliverables are time sucks.
Far too many project plans have many tasks that, though they are indeed tasks, don't have an actual deliverable defined. Yes, this can be hard to do. And common sense should be used when coming up with a defined deliverable. But it can be done. - Tasks without resources assigned, generally won’t get done on time, if at all.
Remember, resources can be both human resources and equipment or external services. Project Management tools like MS Project allow you to create a resource sheet, assign them to tasks and track both usage and cost. - Tasks should have a lead resource, the person responsible to get it done. 2 or more chefs spoil the dish.
It's fine to have multiple team members on a task, but always make sure someone is in charge of delivering the results. - Yes, you can use resource leveling to figure out when you will complete.
Don't ignore it when it tells you your Critical Path has suddenly shot off the chart, it is just math. Something is wrong. Diagnose it, fix it. - You can also resource level just a portion of the project, and protect your end time.
This works well when a client, an attempt to drive project delivery cost lower, has divided up the implementation team between the blueprint and realization phases (or any of the phases, depending on your methodology).
It does not actually work well from a project cost reduction standpoint nor from project delivery standpoint. But you can expect everybody to keep going down that road. - Not a bad idea to make different versions of a project when doing forward or backward scheduling-just in case.
Make sure you remember to baseline a project and rebaseline it when you have approved change request. - Hero efforts, though admirable, are not how you want to live.
When a project starts to fall into this category, which many do, it's time to slow down and replan. Your initial assumptions were wrong and have not gotten any better. - Distance x physical nodes x unclear requirements x communications channels equals an “interesting project”.
Your very best project team configuration is everybody in one place, preferably in one big room. - Getting the level of detail right in a plan is critical and you’ll almost always miss it on the first past.
This is why you need a large-format printer onsite. You're going to want to print out the project multiple times, often, especially early on. - If you have multiple related plans, you can create a Master Plan with Slave or Children plans.
However, I recommend you have at least the Enterprise version of MS Project up and some sort of sharepoint type environment.
Inevitably, 3rd party projects, which you will not have as much control over, will be the ones you spend the most amount of time trying to chase status on. - You need to print a project plan out on wide format paper.
It needs to be big enough for vision challenged stakeholders to glance at and quickly get a feel for where a project is.
Don’t go for the “we will have it printed by an outside firm” routine.
You won’t print it but once that way; it will quickly lose credibility, and ultimately, you will miss what the plan is trying to communicate to you.
Wide format printers can be had for between 2000 and 3000 USD, and it is money well spent. - Don’t be afraid to run MS Project reports.
Most people only scratch the surface of what you can pull out of the plan. - Learn to trust the plan.
It is your instrument panel.
When you hit the cloud bank of uncertainty, run afoul of stormy politics, or will miss your approach to Go-Live, always look to the plan and what it is trying to tell you.
SAP Lean Project Management
Finally, when it comes to lean project management techniques, I will have to address my approach to that slightly different way of looking at things in a future blog article, as it is very different doing a lean SAP implementation and say, doing a lean aircraft depot overhaul.
SAP Project Planning Phase Checklist
In the meantime, if you would like some additional tips about my personal "Best Practices" broken down by each phase of the SAP ASAP Project, you can read my checklist style guides on the subject. These make excellent project quality checklist documents. You can access the first one by pressing the button below.
People Who Read This Also Read:
5 Keys to Successful Strategy Execution
10 Critical Chain Project Manager Techniques
10 Reasons You Need a SAP Project Review
Take Your Project Live with Our Go-Live Phase Checklist
10 Advanced SAP BW Project Estimation Techniques [Online Tool]
Understanding Embedded Systems vs SAP HANA
8 Secrets to SAP Enabled Spend Performance Management
Got some tips you want to share, leave us a comment!
Thanks
