As an project manager with 20 years experience running projects with a “change role” reporting to the project manager, one of the biggest surprises I had when learning and applying MSP was that the project manager was not responsible for transitioning the change into the business. This still comes as a surprise to many project managers when they come to understand the BCM role and review the Delivering Capability and Realizing Benefits chapters in “Managing Successful Programmes with MSP (2011)”.
For most of them, it’s part of what they do as a project manager. And maybe they don’t do it that well. And maybe that’s not their fault.
Many of the people I train and consult to have difficulties with this concept. Traditionally, the project manager is appointed to deliver the project including the changes associated with this. After spending several years with MSP, I have developed a strong (supportive) view that “it’s all about the business” and that change and transition management belong to the business.
I have always been intrigued by the official research and statistics talking about ICT project success rates. We recently saw a statistic that nearly 70% of ICT projects fail in some way.
In virtually every case of failure, management fails to anticipate serious problems. Even in cases where challenges are likely, ICT failure is too often considered business-as-usual, with executives throwing their figurative hands in the air, in surrender to chance or bad luck.
ICT failures happen when managers exercise insufficient judgment, possess too little experience, hire the wrong people, ignore warning signs and, crucially, fail to involve affected employees in a way that eases the path to success.[1]
But the statistic needs to be clarified – what does project success mean? Is it the successful delivery of a solution or the successful transition of that solution into the business? We have all seen successful delivery ruined by poor business take up in the transition and the project gets the blame.
Although tempting to blame project managers for failure, we must point attention to senior executives for allowing the conditions for failure to exist in the first place. The underlying reasons fall into three categories:
1 Unrealistic and mismatched expectations
2 Conflicts of interest among customers, vendors and integrators
3 Corporate organization structure that conspires toward failure[2]
2 Conflicts of interest among customers, vendors and integrators
3 Corporate organization structure that conspires toward failure[2]
I recently participated in a discussion forum by suggesting that project success and failure needs to be clarified. Does success mean that the time/cost/quality/scope elements were achieved within tolerance? That is, is the deliverable fit for purpose and did it come in on time and budget? From the IT or infrastructure project manager’s perspective, that is what matters. But often you cannot determine the value offered by a project until 12 months or more after completion. Just because something met the rules of the triple constraint doesn’t mean that the business gained a benefit. And why did we the business spend all this money anyway?
The question about project success is one for the business. In MSP, it can be asked because the Business Change Manager is a business-side role and the success should be measured by the business against a pre-agreed measure of the expected benefit.
This is Blog 2 in a series of 4
MSP® is a Registered Trade Mark of AXELOS Limited; he Swirl logo™ is a trade mark of AXELOS Limited; Yellowhouse is an MSP® Accredited Training Organization
No comments:
Post a Comment