Implementing an enterprise project management tool

I was looking at my TV remote control the other day and thought to myself, there are about 50 buttons but I only ever really use five of them. I wonder if anyone ever uses them all?

I was reminded about this when discussing, of all things, an enterprise project management (EPM) tool implementation. Enterprise project management, also known as portfolio project management (PPM) tools have many functions, but how many of them do we really need?

We were explaining to an organisation recently that the key to a successful EPM implementation is being very clear on what benefits they are looking for and therefore which functions they really needed, focusing the implementation on those while ignoring the others.

Picture a typical EPM implementation meeting between customer and vendor, where the focus is more often than not detailed requirements around configuration. The conversation might go something like:
Vendor: “What do you want?”
Customer: “Not sure, what can it do?”
Vendor: “What about this?”
Customer: “That’s cool.”

Instead we would argue that an organisation should prepare a Concept of Operations document, describing the objectives and context within which the tool will be used.

A Concept of Operations should cover:

• The primary objective of the tool (e.g. visibility to support governance) plus any secondary objectives (e.g. resource management, timesheeting etc).
• The intended benefits and value it will bring.
• A visual diagram showing information flow: from whom, to whom and how.
• The user responsibilities and hence profiles: who logs in (and who doesn’t), who should do what, who should see what, who will support it.
• The project management environment: decision gates, phases, work breakdown structure and milestone standards, project types, organisation structure, responsibilities.
• Project management maturity, highlighting likely gaps.
• Any specific program and portfolio management needs: roll up of data, dependencies, resource management, prioritisation, benefits tracking, history.
• Any specific integration needs, e.g. finance, BI, reporting, timesheeting.
• Any specific external needs, e.g. vendor provision/access to data.
• The types of data which will be kept in the tool, the expected level of detail and who ‘owns’ the model.
• The types of reporting which will be extracted from the data.

Once there is consensus on the scope of the EPM tool implementation, detailed configuration requirements can follow. The key observation is that unless people are experienced with the tools in question, they really need to see examples before they can comment in detail about what they want. In this respect, the process of developing a ‘proof of conceptp implementation typically works, as it provides an iterative approach to configuration, allowing the customer to ‘see’, fully understand and change needs.

So if you are working in the PMO space, and are considering enterprise project management systems, keep them simple. Don’t go overboard with complex functionality, coding systems, workflow or reporting needs. Start with the basics and focus on your primary objective.

Back to the TV remote control. It is fascinating how used to using the same five buttons I get. It’s comforting to know the other buttons exist, and I’m sure if I need to use them in the future I will figure it out. And I really love the little cover that hides most of the buttons I don’t use. It’s a shame one of them is a button I do need sometimes.