For many, the Holy Grail of PM tools are those that are able to automate all aspects of the project portfolio management life cycle. There is something very appealing about being able to guide PMs, sponsors, stakeholders & team members through a methodology by removing any opportunities for inconsistent usage. The assumption is that presented with a single path, everyone will dutifully follow that path resulting in higher quality decision support data for executives.
There are a few challenges with this Utopian scenario:
1. A common cause of PMO failures is a lack of “fit” with their host organization – the same can be said for PM tools. If the tools don’t fit the culture and maturity of the teams that have to use them, active or passive change resistance will impact tracking and reporting quality.
2. Since there is no “one size fits all projects” PM methodology, the same will apply to the tools supporting the methodology. Unless the PM tools are also able to support multiple approaches to the PM life cycle (e.g. big vs small projects, waterfall vs agile approaches), what works well for one project will be inappropriate for another. Of course, if the projects are all of a particular type (e.g. implementing the same COTS application following a consistent process for multiple clients) this might be less of a concern.
3. “Best practices” are only suitable if they are “best” for your organization. Given the infinite variations on process workflows and information gathering needs, no single solution can claim to have a built-in set of best practices that will apply to more than a handful of situations.
4. Removing flexibility from the PM process stifles creativity. Unlike producing widgets where process control and total consistency of execution is needed, the uncertainty factor on projects requires people to think outside the box. While I am not advocating the chaos that emerges from having NO processes or supporting automation, the opposite extreme is equally bad as staff run the risk of spending more time blindly following the processes than thinking for themselves.
5. The tool shouldn’t replace normal delivery assurance practices. It is a fallacy to assume that process compliance will automatically lead to improved project predictability. PPM or PM tools are there to support decision making, and not to replace it.
6. If your sponsors & stakeholders are not performing their roles appropriately based on human feedback, will system-provided feedback be any more effective?
A better approach might be a coach/mentor expert system – for example, the tool could suggest an appropriate decomposition level for the WBS, or could notify the PM if the risk register is getting “stale”. It is still left to the PM to decide whether or not to accept the advice, but such a system coupled with a feedback loop (e.g. “was this advice helpful?”) could change the role of the automation from Big Brother to Bagger Vance.