How to Measure Anything Review
Just finished reading a great book, “How to Measure Anything”, by Douglas W. Hubbard. For anyone who is rusty on statistics, but needs useful knowledge now, without taking a bunch of college stat courses, this is a great place to start.
Get to Go-Live With Less Risk
As a Senior SAP Project Manager, I am always looking for better ways to get customers to Go-Live quicker, with less risk.
As such, and after exploring his great website, I did find one particularly disturbing graph, recreated here:
Total Project Man-Months
(please note that a man-month is different than total calendar project duration)
Disclosure: I do have a bit of a stat background (rusty) and know this is just a reasonable guesstimate at the current state of project cancellations.
ALL of my projects have went live so far, (and that is a bunch of projects, not just SAP), but I know plenty of projects that have not gone live or if they have, they have not realized their business objectives.
Lessons Learned from the Ones that Did Not Meet Their Business Objectives:
- The more you stick to standard out-of-the-box functionality, the higher the probability of success.
- Conversely, the more of a science fair project your project is, the more likely you will not finish on time, if ever.
- De-risking a project sounds good.
In practice, actually taking risk out of a project is very difficult. - The PMI Project Methodology states that the doers (usually SMEs or Subject Matter Experts) do the task estimations.
Not the Project Manager.
In practice, you better be prepared to wag it.
No SOW is ever signed (at least a fixed price one) where the tasks have not been estimated based on an assumption by somebody.
These assumptions are subject to wild variations once they meet the reality of a particular project.
How much can these estimates vary from actual results?
I was once brought into a project, during the 8th year of a 2 year project.
While interviewing the CEO, right before he went on TV to announce earnings no less, he told me that he had yet to see ANY return from the project. - If your project does not have a solid business case, you shouldn’t be on that project.
- If your project involves a large number of 3rd party solutions, at best, it is challenging.
At worst, the solution architecture is improperly defined or understood.
You might want to take a look at some of my experienced based, Top SAP Project Management tips to help you avoid some of these issues on your next project.
Thanks
