A key factor for a successful EPM deployment – organizing your organization’s Enterprise Project Management processes.
Put simply, Project Server is a tool. A means to simplify the complicated.
It’s a very powerful tool with an enormous range of capabilities, but an EPM deployment is a function of the underlying processes. All the workflow rules and task update details in the world can’t compensate for inattention to process.
At some point in your path to EPM deployment, your implementation partner will ask you about your underlying processes. Do yourself and your partner a favour and devote some serious attention to this question.
Often we hear “Our processes are pretty good. After all, we are managing our projects.” Fair enough. Your projects are in hand, and are getting completed. And yet, you are considering an EPM deployment.
But are your processes effective and consistent? If you can give an unreserved positive response, well, congratulations. You’re in the ‘one percent’ of organizations. Your EPM deployment will be flawless. Feel free to stop reading.
For the ninety-nine percent of us, here are a few process-assessment pointers:
- Do you (or your stakeholders) say things like: “why aren’t we doing [process ‘x’] on this project the way we did it on [project ‘y’]?
- Take two current status reports from unrelated projects. Do they have the same information? Are there any objectively measured Key Performance Indicators? Are the subjective KPIs consistently interpreted across projects? How can you tell?
- Have a look at your project repository. (If it is in Excel, I can almost guarantee it is internally inconsistent.) Are all the columns filled in for all the projects?
- Review your current Project Lifecycle methodology diagram. Think about your current (or a recent) project, whether it was successful or ‘challenged’. How well did it track against the methodology?
Likely these pointers have revealed to you that there are inconsistencies with your processes. If you retain current processes in your EPM deployment, you will have simply facilitated those ineffective processes through automation. The caliber of your project KPIs is not likely to improve. (But they may become more visible, which is one path to process improvement, though an expensive one.)
A better approach to process improvement is to mirror the best practice ‘incremental’ approach we recommend for your overall EPM solution.
First, identify your priorities. A great exercise here is to define your pain points. Which aspect of your current project or portfolio management practice is most dysfunctional? Resource Management? Project Intake? Project Closure? Measuring ROI? Scope Containment?
Your EPM deployment should focus on addressing your most significant pain points. In some cases, the tool can do the lion’s share of the work – but it can never do all the work. Resource Management is a good example.
Project Server can readily reflect back to you the resource-demand implications of your project portfolio. But your EPM tool cannot intuit resource demands for individual projects.
Your organization requires a consistent method of defining resource requirements (for active projects) and expectations (for candidate projects). The tool can help you by identifying resource bottlenecks, and handling the implications of re-scheduling projects (and corresponding resource demands).
If your process is rigorous enough to identify skillsets in your resource pool, Project Server can even help you find candidate resources for your project. But you need to do these things:
- Define (and maintain) your enterprise resource pool
- Define (and maintain) your project resource forecasts.
The good news is that it is very likely that your organization is already doing both these things. A list of employees exists, likely with job titles and potentially with skillsets. And you almost certainly have some form of resource projections for projects. If you can provide these in a consistent manner, then Project Server can make them visible to stakeholders throughout your organization. Note the ‘if/then’ construct. As you may recall from your computer systems 101 course, the conditional clause relies on the predicate:
If [you have reliable processes] Then [your EPM deployment will be successful] Else [Your EPM deployment will be threatened]