So we turned to Run, Grow, Transform. This seemed a much more intuitive scheme. Having just been to a Gartner conference, they of course had  gotten a thorough understanding (this being Gartner’s preferred model). But there were a couple of issues.

First, they felt that the Transform category had too high a threshold. It is the rare project that actually transforms how a typical company does business (with the exception of the high-tech world, of course). It is much more common for them to undertake strategic projects, which we loosely defined as furthering the strategic goals of the company. I’ve noticed many PMOs actually use the Transform bucket in this manner. But rather than keep with tradition and simply us Transform to mean strategic, we decided to rename the category.

Next came Grow, which on its face sounds pretty obvious. But does this apply only to projects that help the company grow? What about automation? We supposed that improving efficiency would grow the bottom line, but suddenly this was less intuitive. After bandying about several alternatives it was either Mike or Roger (that’s Mike Rinehart and Roger Larson to give credit where its due) came up with Improve. This was defined as anything that improves the operations or effectiveness of the organization. This then encompassed the grow projects along with any others that are more than simply maintenance.

Run did seem pretty intuitive. The idea of work required to keep things running (or KLO – keep the lights on) is pretty self-explanatory, so we kept that.

We then reviewed their portfolio and found we could much more readily identify projects as being in Strategic, Improve, or Run. And what do you know, Mike pointed out it also has an easy acronym – SIR!

So there you have it, a new project portfolio classification scheme, SIR. What does the community think? I’m really anxious to hear thoughts on this one!

Dave B.

In the finance realm, we are quite use to a top-down model. At the corporate level, an overall budget is set based on expected revenues and the desired profit margin. This is then argued over by the executive team as budget numbers are set for individual organizations. Each VP then takes their allotments back to their directors with specific allocations for each, who then come up with a budget for their specific department.

So, what happens when we apply this thinking to projects?

Using the above model, a cross-functional steering committee would be given a total allocation of both spend and resource effort to cover all projects for the year. They would then set targets for various project investment categories. Perhaps they want to allocate 33% for strategic projects, 33% for tactical, and 33% for maintenance (KLO) projects. They then look at the project requests in the queue and choose based on these allocations.

To complete the top-down picture, these requests have been through a scoring exercise that uses big buckets for benefits and costs (eg: <$50K, 51-100K, 101K – 250K, etc). For more on scoring, see the blog post Too many project requests? Scorecard them!

Of course, there is a counter to top-down, which is bottom-up planning. In this method, each project is analyzed and planned down to the task (WBS) level. Effort is estimated for each task and materials costs are developed for each item to be purchased. The results are then rolled up to the project level, revealing the “true” effort and cost required for each project. These fully vetted requests are brought to the steering committee for approval, and the total of all approved requests gives us the size of the portfolio.

Hmm – both seem to have some merits and some problems.

Bottom-up, or detailed planning, provided a more thourough, and theoretically more accurate, estimate. However, the amount of analysis required can overwhelm the business analysts and project managers. Further, it is common practice to add some buffer to each task in a plan. This can lead to quite a bloated overall estimate.

Top-down, or high-level, planning is much more efficient. It also provides the constraints and big-picture view required to ensure the final list of projects is aligned with company objectives and fits its spending targets.

So, which to use? Truth is, in finance, we use both and then reconcile then meet in the middle. In PMOs, I advocate the same idea. I like high-level planning during the intake of projects so excessive time isn’t wasted on analysis and to ensure the portfolio is within overall targets. But once the initial selections are made, detail planning is crucial. And comparing he detailed plan to the high-level plan can lead to much better overall estimates.

As an example, I had a PM present a detailed plan that was 40% over the initial estimate. Now, the initial estimate was based on actual time and expense records from several similar projects. So, I was able to direct the PM to rethink they’re detailed plan to eliminate unnessecary buffer.

On the other hand, I’ve also seen detailed plans that revealed flaws in our high-level thinking, causing a re-calibration of the high-level estimates.

How do you perform planning in your project driven organization? This is one subject area open to lots of great ideas – and we’d love to hear yours!

So, here are my most commonly observed PMO mistakes. Feel free to add your own or comment on these!

1. PLAYING COP. If there is a common refrain to failed PMOs, this is it. The PMO becomes the “Methodology Police” and enforce an often ill-fitted SDLC rigorously. This leads to complaints from project managers at best, and open revolt and ignoring the methodology at worst. Rather than becoming an aid and guide to project managers, and creating consistency in PM practices, this PMO has become the PM’s worst enemy, loses visibility into the project portfolio, and leaves a bad taste in everyone’s mouth.
2. IMPLEMENTING AN SDLC. OK – this might sound heretical, but hear me out. I have seen many PMOs implement an SDLC, literally a “Software Development Life Cycle”. This is great for the software development team, but drives the infrastructure and process improvement folks nuts! The point here is, one size does not fit all. A better structure is an overall project management framework, with just the basic phases and gates and a few key controlling artifacts (business case, project schedule, status report, etc.). This is sometimes known as a PDLC (Project Development Life Cycle), and many different SDLCs can fit under the framework, tailored to the need of the project type.
3. NOT IMPLEMENTING A METHODOLOLY. What, am I contradicting myself? Not really. If the PMO does not implement some kind of overarching framework, it cannot create an apples-to-apples view of the projects in the portfolio. Further, federal regulations, especially Sarbanes-Oxley, require methodologies that meet their requirements.
4. NOT MATCHING DEMAND TO SUPPLY. I’ve sat in on many a Steering Committee meeting, and the focus is almost always on prioritization. That’s great, and a good prioritization process results in a good understanding of project demand. But when it comes to deciding how many of the top projects can actually be done, discussion usually turns to pure guess work! – “How overloaded is you department, Tom?”. “If we take on the top 10, can we handle the load?” Without a metrics-based understanding of resource capacity, it is impossible to match that wonderfully organized demand with the actual supply of human resources.
5. NOT LOGGING TIME. This is actually the source of number 4. Without tracking actual time worked on actual projects AND other work, it is impossible to know any department’s true capacity. Planning, even at the most detailed level, is merely guesswork if it does not involve the feedback loop of actual time.
6. GATHERING UNECCESARY INFORMATION. PMOs are great at gathering all sorts of statistics, from very detailed SDLCs (see number 1 above!). If that information is not used in the decision-making process, why gather it? It just creates an extra burden on the project team without generating any useful result. Example: gathering time data at the detail task level, including sub-day tasks like “Enter time”, “Check email”, “Respond to email”, “Attend staff meeting”. These may be useful reminders as tasks, but for planning purposes all we really need to know is how much time each resource is spending performing “Admin” tasks.
   
   That’s my list for today. I’m sure you have others to add to the list – please do! And if you want to hear more on any one of these topics, please let me know. I’ll try to address it in a future Blog.