When we last met, I was touting the virtues of simplicity when it comes to an Enterprise Portfolio Management deployment. I am a firm believer in the ‘walk before you run’ approach in most scenarios, including EPM deployment. Here’s why.
Odds are, by the time you come to the realization that your organization is in need of an EPM solution, your project portfolio has reached a threshold of complexity. The complexity likely arises from one or more of the four main components of project management: scope, schedule, resources (human or otherwise) and quality. You likely also have a plethora of projects in your portfolio, each replete with individual challenges. So you are living in a complex world, and looking for a better way to get a handle on things. In a word, you are looking for simplicity, or at least a degree of simplicity.
Given that we are awash in complexity, there is a natural tendency to assume that a complex solution is required. Off the top, I refute this reaction with Occam’s Razor, which (paraphrased) suggests the simplest answer is probably the most appropriate.
Let’s get down to some brass tacks. Your environment is complex. As mentioned last month, the EPM solution itself has a potentially complex nature, given Microsoft’s mantra of meeting all needs of all users. An EPM solution can provide a staggering level of detail in support of all aspects of project management. For instance, for resourcing alone we have options involving timesheets, effort or duration-based tasks, pooled or named or generic or skill-based resources, tracking actual hours and/or percent complete, earned value, resource and project calendars, resource leveling, demand management, and fixed duration versus fixed work versus fixed units. You likely appreciate that many of these elements have tentacles that reach into other areas of project management; the potential for exponential growth of complexity in your EPM solution is enormous. At the same time, you may look at that list and think, “Yeah, we need all those things. Then we would be in great shape”. That may well be true, but bear in mind that this list represents just a narrow spectrum of EPM functionality.
Now, I am not arguing against complexity and I grant that a complex world does demand more that simplistic solutions. My argument is that we should grow into our complexity by taking manageable steps.
Imagine your EPM deployment as a grid with axes of Functionality and Complexity. The intersection of these axes then represents ‘Ease of adoption’:
As the intersection of complexity and functionality increases, the ease of adoption increases proportionately. Remember, implementing the EPM technology is typically the smaller part of the overall solution, in comparison to the processes and discipline required to maintain the project data.
The argument for a low-complexity deployment comes down to two factors:
- By keeping the functionality and complexity simple, you can get your EPM solution deployed and begin realizing benefits more quickly. By using the product sooner, you will be much better able to gauge the priorities for subsequent iterations of your EPM solution. While you may think you can predict your organization’s future needs today, even a basic EPM solution is likely to expose heretofore unrecognized issues with your portfolio. That’s what they call it Enterprise Project (or Portfolio) Management.
- If you plan out your functionality in excruciating detail with corresponding complexity, not only will the end product face major hurdles to adoption but you will probably miss the functionality mark. In the time it will take you to anticipate and plan solutions for the expected problems, those unknown unknowns will come out of the woodwork. Better to use EPM to address a specific need initially, and let your EPM solution grow.
Keep it simple to start. Let the complexity evolve by iterations of your EPM solution.
