Beyond the alphabet soup of PRINCE2, MSP, PMBOK, ITIL, Agile
If you have read any of my posts you will realize I am a fan of PRINCE2 as a project management methodology. In most cases I consult the manual regarding process and required content for the various management documents. The other day I struck a situation and realized a key limitation of PRINCE2.
Our organisation has grown significantly, twofold over the last few years. More recently our client profile has changed from a lot of small clients and projects to fewer larger clients with bigger projects. This shift has necessitated more emphasis on process and governance.
To ensure quality delivery, I have been trying to implement standard processes throughout the organisation – combination of PRINCE2 and ITIL. At times it is a battle to introduce process where there had been none. There is also resistance to change from staff who are in a comfort zone and used to doing things in a certain way.
I thought I will consult my bible … the PRINCE2 manual to find a technique to handle this. Unfortunately there isn’t one. The only technique it really describes in detail is the quality review technique. I am not totally surprised, but somewhat disappointed. When you look at the definition of a project – temporary endeavor to achieve a change to realize business benefits - would indicate change is an obvious ingredient in projects. Surely this resistance is encountered more often than given credit for.
In the end I went for the no surprises approach down the chain, explaining the purpose of the process and their role in achieving a quality delivery. I believe I got some traction. This has happened more than once for me to realize that this is not necessarily trouble making. It is simple human reaction to change. I have now recommended to the company management that the entire teams get tailored introduction to PRINCE2 and ITIL.
It is not sufficient for your project management staff to know about process. Buy in is crucial for any methodology and needs to include the people that deliver the specialist products.
Senior Project Manager at Eagle Technology, APMG Accredited ITIL, MSP + PRINCE2 Practitioner, governance expert, cricket fanatic, squash pretender. Opinions expressed are purely from my experience of leading teams and running projects, and in no way claims to represent those of my employers or customers.
Pingback: Conquer Your Resistance to Change | Create Your Life By Design
Pingback: Dealing with Ideological Resistance to Change « Martin Webster, Esq.
Pingback: Resistance is Futile « Martin Webster, Esq.
Even though I’m a big fan of questioning new things, I often wind up irked by the resistance to change. It’s not because people question my proposals; in fact, it’s because they don’t – they often simply resist change as a matter of course.
I would love to go head-to-head (amicably, of course) to iron out the issues, but I find I don’t get that many opportunities to do that either. So, my strategy is quite simple. Given that terms like Agile and ITIL are can cause a lot of commotion, I simply avoid using them and make it seem like I’m doing off-the-cuff planning. I’ll outline a work cycle and call it milestone instead of sprint. I’ll push for a demo at the end of the cycle without stating any specific reason.
Maybe one day I’ll drop the bomb
I agree. While the top management appreciate the benefits of having these qualifications when going for projects (we’re a professional services company), team members are harder to impose process on. I have taken to introducing a lot of these concepts by stealth … as a means to implementing good practice. I still believe it is beneficial for people to actually participate in targeted training.
That’s actually pretty interesting. I’ve had no trouble convincing my guys to work in certain ways. It is the management that I’m having trouble with. I work in a product company so maybe there’s a difference in mentality.
Pingback: Communication Round-Up « Martin Webster, Esq.