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!

So – why are these PMOs (both IT and non-IT, btw) using unofficial and sometimes kludgy tools to manage project finances when the source of record is readily available? Turns out there are two main causes of these “workaround” financial systems.

1 – The information is too late. That’s right, while purchase orders and invoices are both entered into ERP systems as they hit accounting, project managers don’t see this data for up to 45 days. Why so late? Data extracts sent to PMs and other managers tend to come out after the books close. In most companies, this is a 15 day cycle after month-end. So, a PO that was issued July 1 won’t show up until the Aug 15 report. Way too late to take any corrective action!

2 – Finances categories are useless to PMs. While finance wants to slice and dice costs by cost centers and accounts, project managers need different categories. Typical would be hardware, software licenses, software maintenance, contract labor, etc. Many ERP systems do not have their account structure set to reveal this valuable information.

So – what’s the frustrated PMO and project manager to do?

 My first suggestion is to ask finance to run the purchase order and invoicing data out on a weekly basis. When they balk that the data is not yet official and/or those documents are not yet approved, simply let them know you are using it for planning, not official reporting.

As to how expenses are categorized, it is important that standards be agreed and set for project cost accounting, and these implemented in the ERP costing structure. After all, and Enterprise Resource Planning software should be used as a planning tool – not just a financial record keeping tool.

If the latter fails, at least get your data feeds from finance more frequently, import them into you tool of choice, and slice and dice from there.

What’s your experience with project cost control and ERP? Is it working for you, or do you have a “workaround”  system in place? Please share your thoughts and approach so we can all learn from your valuable experience!

Dave B.

So, that would lead us to actually doing some resource planning! Many organizations will start charting out their resource needs by role during the initiation phase, giving them a head start on finding available resources. Let’s see, I need a PM full-time, 20 hours a week of a DBA, another 20 of a programmer, and so on. Of course, I’m already knee-deep into serious analysis work on the project, and may have already tapped out all the business analysts with all this initiation work going on. So, role planning is not the most important element of resource management.

Backing up one step further, PMOs are often called on to do capacity planning. Now we’re looking at the pipeline of requests and asking the question – How many can we take on? This will be based on an analysis of available resources in aggregate over time. So, if we have 10,000 hours/week of staff time, and 15% is consumed by administrative duties, and another 20% is consumed by support work, and a final 25% is consumed by non-project “enhancements”, that would leave 40%, or 4000 hours/week, for project work. Hooray! And if we currently have projects in-flight that consume 3000 hours, we can take on another 1000 hours of project work. So, let’s approve project requests with estimates up to 1000 hours/wk of work!

But wait! How do I know the organization is consuming those specific amounts in each of those buckets? And how do I know if the same numbers apply to my applications group and my network engineering area? And beyond that, when I do get back to role planning, how do I know how many hours the typical network office rollout consumes of a given role, like a network engineer? And when the PM actually lays out his/her project plan, how do they know how long a given task usually takes?

For most PMOs today, they rely on past estimates. That’s right, they’re making new guesses based on their prior guesses and hoping they’re right. Resource management must be the one area of business today where we don’t employ a feedback loop to measure our actual performance and use it to refine our estimates.

That leads us to the real “most important part” of resource management – time tracking. If everyone logs their time against all their activities, project and non-project alike, we’ll build that feedback loop.

Indeed, when I was at PeopleSoft, we had 2 years of time data. So, I knew exactly how much time our IT organization spent on individual projects, on projects in general, and in each non-project bucket. When we did capacity planning, I didn’t have to guess how much time current projects were consuming – I knew! For projects we did on a recurring basis, like simple application upgrades, we already knew the amount of each type or resource consumed on average based on the last 5 times we did it.

If you’re looking for the best way to get started with resource management, start by logging time – all of it! This will give you the data you need to build out a resource plan with confidence.

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.

A while ago, as an exercise in a project management class I was teaching, I asked each of the PMs to tell us the purpose of their project. The first PM said “to upgrade the payroll system”. Oops – that’s not much of a purpose. Why would we want to spend lots of dollars just to upgrade a payroll system? Turns out there were new tax rules coming in that the old system couldn’t handle. So – the real purpose of the project was to enable compliance with new tax regulations. Obviously, if this could be done with a few minor tweaks, that would be better than a full upgrade. Given it could not, the upgrade was on.

My point , however, is that even the PM lost sight of the business target in the middle of the project. What a PM really needs is a laser focus on this target. There are several benefits to a well thought out and clarified business target.

First, it’s easier to reign in scope creep. If we need taxes to be right come January 1, but HR wants to add some new vacation tracking functionality, it’s easier to say no – especially if that might endanger the Jan 1 date.

Second, the odds of success are much higher. Back in my programming days, I remember a project where we did a great job of defining requirements, and even added mock screen-shots and reports to the specs. The customer signed off on the spec, we delivered on-time and on-budget, only to hear “it’s exactly what I ordered, but not what I need!” Ever heard that one?

By focusing on the business proposition it’s easier to work with the customer along the way and even make suggestions that would better enable the project to deliver against the proposition. This may require some course adjustments. In the case above, we would have changed the design for a smoother work-flow, rather than sticking to the original specs. These adjustments may well have caused the project to be both late and over budget. But isn’t a little late and over budget better than delivering something useless that happens to meet the original requirements?

One project manager I spoke to recently put this idea quite succinctly. He was taught that for any project, he should be able to give the “elevator pitch” for the project. An elevator pitch is a sales term, and every salesperson can give you that 15-30 second pitch for why you should buy their product. If you can successfully give a 30-second elevator pitch for your project, you’ll be well on the way to a truly successful project with happy stakeholders.

Now, viewing projects as business outcomes has some serious implications for how portfolios are managed. More on that in my next post . . .

Manager: “I need 2 more project managers”

Exec: “How do you know?”

Manager: “Because my PMs are overloaded. They tell me they’re really busy and can’t handle the workload.”

Exec: “So, how overloaded?”

Manager: “REALLY overloaded.”

Exec: “Prove it!”

Oops – all the manager has is anecdotal evidence from his or her overloaded PMs. They say they’re overwhelmed, but the manager doesn’t really know by how much, and therefor doesn’t know how many PMs they really need to hire.

Same thing with bringing on new projects. A new project request comes in, and the PMO Director tells the CIO they’re already overwhelmed and can’t take on new work. How do you know? Where’s the evidence? More often than not, the CIO will point out how important the project is and direct tell the harried PMO Director to “squeeze it in”. Or, there is a whole slate of requests, and the CIO draws a waterline and says to take “the top 10″. Why 10? Why not 15? Why not 5? 10 big ones or small ones?

Without data, it’s hard to get good execs to respond, and their decisions may seem arbitrary. However, the conversation changes entirely with data.

Manager: “I need 2 more PMs”

Exec: “How do you know?”

Manager: “This chart shows my PMs are working on average 60 hours per week. In addition, this other chart shows 5 more projects coming on-line next quarter requiring another 40 hours/week of PM effort.”

Exec: “So that’s an overload of 80 hours per week, or 2 PMs – correct?”

Manager: “Exactly”

Exec: “So, we need to either cut the projects down or hire PMs. OK – I can work with that, and I have some budget. Let’s hire one PM and cut out these 2 project requests.”

Don’t believe me? Try it – but make sure you go in with real facts and figures. Because if you just site statistics and don’t show them the charts and data, they’ll send you packing just like before!

But if you show them your analysis, based on real data and presented on paper where they can see it for themselves, you might get the answer one client I have got from they’re CEO:

“That’s the first IT meeting I really understood!”

==============================================================

Need some quick help analyzing and packaging your data to sell your PMO story to upper management? Not sure what will make a compelling case that will get their attention, or if you are even gathering the right data? Contact me at dblumhorst@effectiveitgroup.com. We can help you solve this conundrum, and our targeted engagements are measured in days or week, not months and years.

==============================================================

But, if you’re like the other 99% of PMOs in the world, you need a way to manage this onslaught of potential work.

In the sales world, they have what’s known as the sales pipeline or sales funnel. This is a process whereby potential opportunities are matured, step by step, to fruition as a completed sale. Along the way, opportunities fall by the wayside. They may not have budget to buy, may not need the products on offer, or just don’t have enough interest.

Sales will draw this process as a funnel that has several stages. At each stage, a number of opportunities will fall out of the pipeline. Hence, the funneling effect. They start as opportunities (hey – I’ve got someone’s phone number!), progress to prospects (they actually my call!), become qualified prospects (they have budget!), and finally customers (wow – they actually signed the contract!)

What if PMOs could have a similar process? What if we had a funnel that allowed us to qualify project ideas step-by-step?

Currently, most PMOs take an idea and spend a lot of time and money giving it a full analysis before presenting it for final approval. How much time and money could be saved by funneling those ideas through some filters so that only qualified ideas are analyzed?

That’s the idea behind a Project Intake process. We start with an idea (hey – let’s redo the company website!), progress it to a request (here’s why we should re-do the website. It’ll pump up revenues!), qualify the request (the scorecard for the website redesign looks good!), create a full-blown business case (wow – the numbers for this redesign really pan out), then finally it becomes a project (the committee approved the re-design! Hooray!).

To work effectively, this really should be a portfolio process – not a project management process. Why? Because as we’re taking requests through the pipeline, they need to be compared to each other and winnowed down to the organizations ability to execute (budget, resources, and skills). By comparing requests as a slate early on, we can narrow down the number of requests that get the full analysis treatment, saving tons of money. By using a funnel approach, we can ensure the outcome is a portfolio of the most worthwhile projects that fit our organization.

So, do you have an effective Project Intake Funnel? If not, contact us. We can help you design one that fits your organization. And we’ll do so on an advisory basis, which gets the job done for a lot less than a consultant that looks like an FTE taking up desk space!

Just need a scorecard to help with that initial winnowing? We’ve got a best-practice scorecard that can be used as a starting point! And, of course, we can help you develop one tailor-made for your PMO.