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, 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.

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.

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

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!

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!