What’s the impact of approaching a PPM tool implementation in the “wrong” way?
I’ve worked on several PPM tool deployments, and one of my biggest frustrations is caused by the IT-led approach taken when implementing them. This isn’t helped when project management and PMO reside in IT.
The solution has been decided and the project mobilised to deliver the chosen software. It’s too late to ask why that particular tool has been chosen, too late to determine if the perceived problems it will solve are the organisational problems that really need solving.
Process improvement, organisational maturity or change management are unwelcome distractions for a technical project tasked with delivering a piece of software on time, within budget and with a scope determined by the capabilities of the chosen solution.
There is an expectation that the vendor will provide best practice guidance and insight into how to best use the tool; these vendors are often a) software sales people with no practitioner experience and b) configuration specialists focused on getting the software working in the technical environment.
We risk ending up with an unhappy project manager trying to juggle even more demands. With most PPM tool implementations, the impact is on the project managers, and the others that need to INPUT data.
With a poor PPM tool implementation, the project manager has to learn a whole new way of doing things that
- He didn’t enjoy doing anyway
- Already take up far too much of his time
- His training (if he had any) didn’t cover
If your PPM tool implementation is based around poor processes that add pain, you still won’t be able to answer those stakeholder questions the business case was built on – and you won’t be able to provide any of the project data you were originally reporting either!