I was speaking at a SIM (Society for Information Management) event the other night, when the question came up “What’s the most common mistake you see PMOs making?”. A great question, and a really great blog topic! At EffectiveIT Group, we encounter several PMOs a month, and so we have ample opportunity to see the good, the bad, and the ugly of PMOs.
So, here are my most commonly observed PMO mistakes. Feel free to add your own or comment on these!
-
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. Continue reading Top PMO Mistakes
I was conducting a portfolio management workshop at one of my favorite clients , VWR, a couple of weeks ago when the topic of classifying portfolios came up. The usual investment class options came up, namely the MIT model and the Run Grow Transform model.
The MIT model (Strategic, Informational, Transactional, and Infrastructure) was first developed by Peter Weill at MIT and made popular by CIO Magazine earlier this decade. I’ve always felt it provided a nice breakout for IT departments in particular. I actually like seperating Informational projects (decision support) from Transactional (automating business processes). I’ve never really like the Infrastructure classification, however. While this represents keep the lights on type activities, it can easily be confused with the common perception in IT of the hardware and network infrastructure. In any event, VWR (and many of my clients) felt the model was overly complex and not very intuitive.
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.
OK – so the whole idea of project portfolio management stemmed from the concept of treating projects like an investment portfolio. Since companies invest a lot of money in these projects, we should monitor them as such. In most PPM practices I’ve come across, this metaphor is applied to project selection (which projects will give us the best returns?) and portfolio monitoring (how are in-flight project performing?). But what about actual returns?
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.
Continue reading Benefits: The forgotten stepchild of projects and PPM
Over the past few years I have certainly done my share of pontificating on how to balance staff resources against what seems like unlimited demand from projects (and other quarters). But when the rubber meets the road, we all have to find a way to make it work.
All that pontificating and consulting has lead to a request to write a chapter in an upcoming book on this very subject. But before I blindly write based on my experience (and that of my clients), I want to listen. What works for you? How do you really manage your resource loads? What techniques do you use to attempt to get all the work done without burning out your people?
You may reply to me privately, or share you thoughts in this blog post. And who knows, you may be quoted in the book (with your permission, of course) 
This week, I encountered an age old debate: which is better, planning from the top down or the bottom up? It happened to emerge during a discussion about resource planning, but it also applies to cost and budget estimates.
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!
With all the PMOs we work with month in and month out, one surprising trend has emerged. Almost none are relying on their ERP system for project cost control. Come again? Aren’t ERP systems designed to control costs? Aren’t they the source of record for all things financial in a company? To this former CFO, they certainly should be! Instead, we find client after client using excel spreadsheets to track planned and actual project expenses. And our Daptiv clients are using Daptiv applications to the same purpose.
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.
Continue reading Are ERP systems failing at project cost control?
. . .assigning people to projects. I’ll admit, the traditional view of resource management is finding the right resources for your project. But how often does that turn into a fight for scarce resources? How often are projects approved and activated, but as the PM looks for people they aren’t available?
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.
Continue reading The most important part of resource management isn’t . . .
While project portfolio management owes its genesis to financial portfolio management, there are some key differences. The first is the outcome of the portfolio. With a portfolio of financial assets, such as stocks, the return is measured in the same common denominator: dollars. This allows us to create some common key measures of performance, such as return on assets, price/earnings ratios, ROI, etc.
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:
Continue reading A Portfolio of Business Outcomes
When we’re heads down in the middle of a project, it’s often easy to focus on staying on task, on budget, and on scope – and all too easy to lose track of the original business proposition. Truth is, all projects start with a business value proposition in mind. This is what I like to call the business target.
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 . . .
Here’s a typical conversation from a manager to an exec:
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.
==============================================================
Most PMOs I work with face the same problem: too many project requests and not enough time to do them all! I will admit, I’ve worked with one group that did not have this problem. They have plenty of money and were told that if it’s a worthwhile project, there’s ample funding and they can hire all the people they need. If you’re in that situation, no need to read on. Rest assured – the rest of us are envious!
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?
Continue reading Project Intake: The sales funnel for PMOs
|
|
