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.

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.

While this churn happens in many organizations, I’ve personally seen it many times in New Media companies. These are firms that create all the banner ads, quick videos, CD promotions, short videos, and other new advertising media. Typically, these engagements are like quick hit projects where items are designed and created in days. And a pool of Web developers or copy writers are working with multiple clients concurrently.

In these high-volume, quick-hit types of environments, we often see a malady we call “resource day-trading”. As the name implies, project or account managers are constantly trading resources to get their work prioritized. Like with stock day-trading, there are serious pitfalls, namely inefficient use of resources, lack of alignment, missed deadlines, and budget overruns.

So, how do you handle these high-churn environments? Set up regular resource planning meetings. We did this at one New Media client (the new media arm of one of the largest ad agencies in the US). We designed reports that showed utilization from the last 2 weeks, and allocations for the coming 2 weeks. These reports were produced on Friday. On Monday, the Account Managers (which are basically PMs) and Resource Managers met. They reviewed the reports, discussed the next week’s priorities, and re-allocated as necessary.

By re-allocating as a group on a regular basis, they almost totally eliminated the ad-hoc reallocation that caused so much trouble. And their productivity (as measured by revenue per employee) improved by 300%!

I have had several clients successfully implement this best practice. It greatly improves communication and makes sure everyone is on the same page. This is one meeting that is attended and is definitely not boring!

If the business would get their requirements right, we’d be able to deliver this project on-time!”

How many project delays have come from shifting scope and requirements? More than a few, based on my experience. So how does one approach this problem?

Part of the answer lies in the question itself. It assumes that the business is responsible for imparting their requirements to IT in such as manner that IT can successfully deliver. Yet “the business” often knows little about the underlying technology, and thus has a hard time articulating their requirements in terms the technologists in IT will understand.

What is needed – and what works in successful project and IT departments – is a translator. We often think of the business analyst role fitting the bill perfectly. Their job, after all, is to understand the business issues and help determine the technical requirements that will fit the bill. The problem is, they are not driving the project – the project manager is.

There is another issue in this conundrum: sometimes the business customers of a project think they know what they want in technology terms, and try to input their requirements in that manner. Something like: “We need a new sales force automation system that is web-based, syncs with MS Outlook, and integrates with the finance system”.

Why? Perhaps they are trying to increase the efficiency of the sales force. Or, perhaps increasing their visibility into credit issues through finance. Or, they need better visibility into the sales pipeline.

My point here is simple: For a project to be successful, a clearly defined business target is required. This is a vision that sits above the requirements. Indeed, if specific requirements don’t help produce that vision, they may not belong in the scope of the project. It also helps to separate the critical items from the “nice to have” requirements.

Given a business target, the project needs a Project Manager that understands the target and can drive the team to deliver. Why the project manager? Because business is a fluid undertaking, and the requirements may indeed change – but the vision should not. The project manager needs to be able to collaborate with business stakeholders – on their terms – to help sort through the shifting landscape and determine if and when changes to the project are required.

I was once asked to manage a large payroll system enhancement project. Lots of detailed requirements, lots of good business reasons to upgrade, including changing tax regulations and international expansion. And over 100,000 people on the payroll. I asked the VP in charge: “Why me? You have plenty of qualified project managers in IT.” Her reply: “Because, at the end of the day, come hell or high water, I know you will make sure all of those employees get paid.”

Now that’s a business target.

Why is this information so valuable? Properly analyzed, it provides insight into 3 key areas.

Feedback to project planning

In a PMO, we tend to concern ourselves with resource allocation to projects. We also spend a lot of time estimating task effort and resource requirements. Indeed, these estimates drive our project schedules, and ultimately the delivery dates promised to our customers.

So, how do we know if our planning is accurate? Most project managers rely on experience, and hope they’re close. But it’s the empirical date from time logs that reveals that the 40 hour task that completed on-time actually took 60. People worked overtime, or borrowed someone, to get the job done. And next time, we’ll estimate this task as a one-weeker again, but might not get so lucky.

Obviously, without tracking time, we are missing the feedback loop to our planning.

Analyzing resource constraints

So far, we’ve discussed time against individual projects. Of course, people often work more than one project, and there’s a lot of non-project work to be done as well. This leads to serious resource constraints, with employees and department manages alike complaining about the heavy load.

And what’s the first line out of an executive’s mouth when asked for more resources? “Prove it!” With proper time logs, you can. And you can prove it by department, resource type, skill-set, etc. And you may discover that your networking projects suffer not from a lack of resources in general, but from one skill-set in particular. At one client it turned out they had plenty of programmers, DBA’s, etc. What they were lacking were project managers!

Time is Money

The largest line item in most departmental budgets is payroll. Therefore, where a department spends it’s time is also where it spends it’s money. Analyzing time can reveal how much is spent on strategic vs maintenance, projects vs change-orders, etc. Instead of just looking at which projects fall into the strategic, informational, transactional, or infrastructure portfolios, the entire organization’s effort can be viewed this way. Put that in pie-chart report and watch the execs eat it up!

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!