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!

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.

The answer, as we PMO practitioners all know, is to elevate the prioritization decisions up to the company executives. This usually means some sort of cross-functional steering committee or other governing body. It’s great theory, with one major flaw. Those execs don’t readily participate. I can’t count the number of poorly attended steering committee meetings I’ve run across. The execs either don’t show or send a lower ranking delegate not empowered to make decisions. Which leaves the steering committee pretty powerless, and results in the CIO once again making the decisions. And once again taking the heat.

So, how do you get these all-too-busy executives to pay attention and take responsibility for prioritization? The best process I’ve found is what I call “shock therapy for the executive team”, and it involves three steps: Presentation, Argument, and Decision Time.

Step 1: Present the problem.This is all about making the problem obvious. During one of my CIO stints, we were creating a new IT infrastructure from scratch. This, of course, involved many parallel projects that could not possibly all be run in parallel. So, I formed an project steering committee and invited all the VPs. All but a few sent delegates, and we made no decisions.

Fine. So I put together a picture of the entire architecture, detailed in big blocks the major pieces, there costs, effort, and timelines and presented this big picture to the corporate executive team at the monthly monthly meetings. I showed them the millions in costs, all the projects going live in the same month, and the amount of resources (double what we had on hand) required to get the job done. The CTO, who ran the product development group, took one look and said

 ”Dave – if I were running this, there’s no way I could do all of this at once. What are you going to do? How will you prioritize this?”

My response: “That’s why I’m here”.

Which lead immediately to Step 2: Argument.

First, the VP of professional services demanded that his CRM piece was critical and had to go live ASAP. To which the VP of Sales argued that if the SFA system wasn’t put in place first, Sales would get stuck and Services would have nothing to do anyway! As you can imagine, each VP argued for there piece of the pie.

Which finally leads to Step 3: Decision Time.
I’ve written before about the use of various prioritization tools, such as scorecards, strategic alignment, etc. Here is where those tools finally come into play. They allow the executives, once they settle down, to look at some objective analysis to help them figure out which projects should come first. Whether that importance is based on fit to corporate strategy or critical operational needs, these tools are meant to be informative, not conclusive. You will also want to present any project interdependencies at this stage.

In the case above, the Exec Team quickly realized that some core processes were in dire need of automation, and that the ERP system was also the core of the architecture. Therefore, projects relating to ERP came first. The other VPs then understood why they had to wait. Even better, I was asked to present progress and new initiatives quarterly so we could decide as a body how to proceed. Note that in this case, we never even formed a Steering Committee. The Executive Team ended up taking responsibility directly!

I have seen this process work repeatedly, and the steps to “shock therapy” tend to follow the same pattern:

1 -Shock them with the enormity of the problem. And do it with graphics and simple numbers, not long lists of individual projects. If they get lost in the details here you’ll be back at square one.

2 -Let them argue for a while. As they struggle with the problem they will realize this is way too important to delegate to their underlings, the CIO, or the PMO. They will realize these are truly strategic decisions – that’s their job and they know it.

3 -Provide them with the information they need make these decisions. This information varies, of course, by company. So, you’ll have to work with your Exec Team to figure what information is most effective.

And good luck – while this is easy to write about, it’s no cake walk to execute. You’ll be relying heavily on the relationships you’ve built with each executive (you have done that – right?) to see you through this process!

1 – The CIO looks the list over and decides, then takes the resulting flack from the stakeholders who were denied. And often his decision is based on the squeaky wheel principle – who will squawk the loudest if they don’t get their pet project?

2 – the CIO has had enough of being the fall guy, and either brings the list up to the executive staff meeting or forms a steering committee to make such decisions. This is a huge improvement, in that enterprise level decisions are now owned by the stakeholders. The problem is, most of these discussions degenerate into VP’s arguing over their pet projects.

What that steering committee really wants is information. What are the benefits of each project? How much will it cost? What are the risks if we do it? What are the risks if we don’t?

This brings up problem #2 – how do you perform a cost/benefits analysis on 100 project requests? That’s a bigger effort than most of the projects themselves!

The answer is relatively simple – create scorecards that rank each request on a common scale over a number of attributes. But before we get to that, we need one more item – a good project request form.

In most IT departments requests come in haphazardly. The VP of Sales tells the CIO they need a new CRM system. An email comes into the PMO looking for a network upgrade in Boston. There’s simply no uniformity to how requests enter IT, and thus no uniformity to the type of information you get.

A good request form provides a method and channel for submitting these requests in a uniform way. While I could write an article simply on creating a request form, for our purposes we are looking for two items:

1.        Business benefits. What are the hard and soft benefits expected from this project?
2.        Impact. How many departments, users, processes, and geographies will be affected?

Now, on to the scorecard. The idea is to rank each request in 3 areas: Benefits, Costs, and Risks. By ranking each area on a common scale, we can compare apples to apples and make some decisions. A good practice is to break each area into it’s constituent elements, create a 1-5 ranking, then create a composite score for each area using a weighted average. For example:

Benefits: Elements could include Revenue Increases, Cost Savings, Strategic Objective, Customer Satsifaction, etc.

Costs: Elements should include Incremental Costs, Resource Hours (all staff, not just contractors), On-going Costs.

Risk: Elements could include Geographic Impact, Business Units impacted, Number of Systems Affected.

The 1-5 scoring depends on the size of the organization. For example, a Fortune1000 company might score incremental costs:
1 = $50-100K
2 = $101 – 500K
3 = $501K – 1M
4 = $1M – $5M
5 = Over $5 million

The same idea would apply to each element. Finally, add up the scores in each area and create a weighted average. The end result should be a relative Benefit, Cost, and Risk score for each project request.

Who should be deciding the scores? Obviously, the requesting stakeholder has the best grasp on benefits, which is why we asked those questions in the request form. Often, IT has the best feel for costs, and can use similar projects from the past to make a quick call on those scores. And both the stakeholder and IT have information on risk elements.

One more quick tip on ranges: Make them broad, so you don’t get bogged down in detailed estimating. At this stage you’re looking to make some quick cuts to get your request bucket down to a reasonable level. The remaining projects can go through a more detailed analysis for final decisions.

If you put all those scores in a spreadsheet or PPM tool, you can then plot them onto a classic quadrant grid. Anything in the high-cost, low-benefit quadrant can be tossed. The low-cost, high-benefit projects are a no-brainer – get them going! The low-cost, low-benefit projects are small and can often be squeezed in for some quick wins. You’ll have to really think about the high-high projects – but that’s what steering committees are for!