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.

I don’t know about you, but I invest in the stock market, and I want to know the payoff – not just the potential. How much did I really make from that investment? Yet, in a good 80% of the PMO’s I’ve worked with, post-project benefits are not tracked. There are a couple of major culprits for this problem.

First up is the “close the project” mentality. As project managers, we want to have a clean close to the project – usually when the new system is deployed. We’ve delivered the goods, lets do our lessons learned, dismiss the project team, and move on to the next project. But benefits often don’t accrue for months or even years. After an ERP project deploys, productivity actually goes backwards for a good 3-6 months. Those promised productivity improvements don’t get realized until after the adoption period.

Culprit number 2 is the lack of measurement. Remember the old maxim “if you can’t measure it you can’t manage it?”. How often do we start a project with projected benefits (say a 10% improvement in PO processing time) without measuring the metric before the project begins? Which means even if we do measure it after deployment we have no baseline and thus no means of measuring the increase.

Now there is one methodology that measured benefits quite well – Six Sigma. This process improvement method is built on finding the weak link in a process through measurement, improving it, measuring again, and then continuing to improve.  You can’t even start the Six Sigma improvement portion of the project without having measured. And you can’t close it without measuring again – to see if it actually worked. What a concept!

So, a simple proposal for regular project and portfolio managers. First, before selecting a project for the portfolio, make sure the business sponsor has defined not only what the benefits will be, but how to measure them – and the “before” measure. At PeopleSoft IT we had reached a point where we were requiring all project requests to be preceded by a Six Sigma effort to detail the solution and the benefits.

Second, add a phase after “close” called “benefits realization”. The project team can be dismissed, but the portfolio team can record the results of the post-project benefits. And then, we can roll up the actual returns from projects to see how our investments are actually paying off!

I know – there a lot of situations where the benefits are “soft” and hard to measure. And I agree. I’ll deal with that in another blog post

That’s my idea – but how are you dealing with this always challenging subject? The more we hear from each other about what works/doesn’t work, the better! So, please share your ideas and add your comments.

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!

Projects, however, are not all directly tied to dollars. Some projects improve employee moral, some increase market share, and some simply make current operations more efficient. Another way to look at this is to think of each project as a business outcome. Companies invest in a project to achieve a certain goal. Recent examples from EIG clients include:

• Web site re-vamp to increase sales and customer satisfaction by streamlining the web experience.
• Employee self-service application to improve employee moral and gain efficiencies in HR
• SAP implementation to automate financial processes and improve decision support.
• Stabilization effort to improve performance of various core apps. For this customer, this should produce increased sales, improved employee satisfaction, and reduced help desk costs.

How, then, to look at portfolios of such diverse business outcomes? Rather than simply grouping projects by size or business unit (which is valuable, of course), some companies are now grouping by strategy or like outcomes.

A classic is by investment type, and the two popular models are:

• Run, Grow, Transform
• Strategic, Informational, Transactional, Infrastructure

Portfolios of like outcomes might look like:

• Employee projects
• Customer projects
• Transaction automation projects
• Infrastructure projects

Portfolios by strategy might look like:

• Gain market leadership
• Most satisfied employees
• Double revenues
• Low cost provider

Wait a minute, does this look like strategic alignment? You bet it does! But then, that’s the real reason we start projects in the first place – to better execute company strategy. And that’s why all projects should be aimed at business outcomes, not simple financial metrics.