Project Management

The Business Driven PMO

Stories from the trenches and practical advice on how PMOs can more effectively support, prioritize and fund strategic business initiatives.

About this Blog


Recent Posts

What’s So Bad About Spreadsheets?

Top Five PPM Trends to Watch Out For in 2014

Insights and Trends: Current Project Portfolio Management Adoption Practices

Life after project completion: Is a project complete without benefits realization?

How Important is Adoption for a PMO?

Improving PPM Maturity: Resource Leveling

A quick trip to Wikipedia yields the following definition for resource leveling: ‘a project management technique used to examine unbalance use of resources (usually people or equipment) over time, and for resolving over-allocations or conflicts.’ In other words, through resource leveling we can ensure that the project schedule is reasonable and realistic from a resource perspective – that the people or equipment needed to execute the work will be available when and where they are needed.

Sounds simple? The reality is that resource leveling needs to take multiple factors into account and can be anything but simple. And, like anything else that’s really complicated, most of us are looking for better tools to help us accomplish the task. That’s when the question about automatic resource leveling comes up.

While some project scheduling tools provide a process to see if resources are overloaded, others also provide a function that will recalculate the schedule to eliminate any overloads. As exciting as it may sound, in practice, it’s common to see that managers either never use it or even if they do, they don’t use the resulting schedule without making a lot of other adjustments. Why? Because even though automatic resource leveling can quickly ‘resolve’ overloads, it typically does it by delaying tasks until the resource is available. What it cannot do is account for human or project variables; all it does is throw some simple numbers. The solution uses elementary level math to solve a calculus-worthy problem.

While some project managers often take advantage of the speed of automatic leveling they really don’t trust the inferences drawn from the calculation to make their final decisions. They recognize that a resource leveled schedule requires a deeper understanding of the project work and the resource requirement to perform that particular task. It also requires a deeper analysis of more subtle options, tradeoffs, or variables to yield the optimal schedule.

In order to level resources in an efficient, meaningful way, a manager must keep in mind the following:

  1. Resource leveling is not just a math problem. A project manager must consider more than the singular question of effort required over the duration of a task. Instead, one must also think about what makes sense for the type of work being performed. Some tasks can be completed in less time by adding more people but sometimes splitting up the work canactually increase the time required to complete it, since multiple efforts need to be coordinated and integrated- which makes it even more time consuming. If you have a team member that needs to attend a three-day class, adding another person will not reduce the time for the class to one and one-half days.
  2. Keep an open mind. There are many different alternatives to consider when resource leveling. Sometimes it makes sense to work on multiple tasks concurrently while for other kinds of work dedicatedeffort is more practical. For example, having a team come together (either physically or virtually) to work through a plan or work through the details of a project deliverable may take less time than going through multiple cycles of email. Conversely, if we expect to have a document out for review, it is entirely reasonable to schedule the same resources that created that document to work on another task. You may also want to consider alternative ways of accomplishing the work – such as rearranging the order of tasks or using technological advances to reduce the time required for a given task. You also need to consider general workload –even though your estimates may indicate that someone can work on 20 tasks simultaneously, you may be building in inefficiency by asking people to juggle too many things at once. Ever tried reading a book in an airport and realize that you’ve just read the same paragraph three times (or more)? The fact is that each time you’re interrupted by a flight announcement, you probably don’t pick up at the exact spot you left off – you end up re-reading from a logical spot. The same happens when we try to rapidly switch between multiple tasks – the very act of switching makes us less
  3. Don’t try to be too precise – Remember that everything in the schedule that you’re trying to level is based on estimates – timelines may change along the course of the project. Good resource leveling requires that you keep your eye on the big picture rather than micromanaging or focusing on granularities. Also, keep in mind that the further into the future you go, the less sure you will become of everything. Give up on the notion of leveling to the hour six months into the future – resource leveling is about making a reasonable schedule, not a precise schedule. The more granular you are, the more you will need to adjust when things change.

Resource leveling is an important part of the project management process, but it can’t be done automatically. While an automatic tool may be handy, it is not a substitute for good old-fashioned common sense from a real-live human being. A software package cannot appreciate the need for variation in an individual contributor’s day, nor does it understand, as a good manager would that sometimes tasks must be performed concurrently, and they are other times when it they cannot be. The bottom-line is that an automatic tool can begin the resource leveling process, but it cannot finish it without human help.

On a closing note, if you haven’t read Fredrick Brooks’ book, The Mythical Man-Month: Essays on Software Engineering, now would be a good time.

Posted on: August 24, 2012 05:45 PM | Permalink | Comments (5)

Has PMO become a bad acronym?

What’s in a name? As far as PMOs are concerned, it matters quite a bit. Standard parlance maintains that PMO stands for Project Management Office. Back in the days when the PMO literally ran a single project or program, the name was fine. But over time the PMO has evolved. Its scope of work has increased manifolds- first, it performs its core responsibility- to run all projects, next it sets up a methodology, and finally serves as a center for strategic portfolio planning. The charter of the PMO has now evolved to a point where the acronym bears little relevance to its traditional meaning.

To begin with, there is this notion that the new strategic PMO can be run by a good project or program manager. Indeed, most PMO Directors that I’ve met come from the project management ranks. While many perform admirably, their first inclination is to enforce methodology discipline – the death knell of many a PMO. Without a solid business background PMs are often ill prepared to handle the strategic trade-offs of the portfolio selection and planning process. Portfolio management is in essence a business process requiring strategy and operations expertise. In fact, analyzing competing business priorities does not require PM skills at all. It requires keen facilitation skills to handle the contentious debates that crop up between VPs arguing for their pet projects. Furthermore, a solid understanding of what makes a company tick while holding business stakeholders accountable for business cases.

Consequently, this leads to another area where PMO struggle and that is Benefits Realization. If we’re going to posit a business case during portfolio planning, shouldn’t we harvest the results as feedback? Shouldn’t we hold the business sponsors accountable for the benefits they claimed would be returned? Yet this is, again, a business function that occurs post project, and is often not dealt with by the “Project Management Office”. Project Managers like to “close” projects and assume they’re done once they hit “go-live”. But, benefits take months and even years to be realized and gathered and so fall outside this traditional project management thinking.

Finally, even if a solid PMO Director is in place, the “project” moniker still invokes too narrow a scope in the minds of business stakeholders. Without their full buy-in to the strategic nature of the PMO charter it is very hard to succeed.

So, the question here is – how to fix this problem? Is it really just about changing the name? Well, in my opinion that’s a start but what would really help is a change the way organizations perceive the charter of the PMO and its implementation process. The evolved PMO is really a strategic planning function focused on implementing change (the project management part) in the organization. It should facilitate portfolio planning, monitoring, and results to ensure strategic alignment and analyzing benefits returned for th investment. Project Management, Resource Management and the like are tools in service of the broader business goals. Several new acronyms have been proposed, including Portfolio Management Office (keeping the PMO moniker), sPMO (Strategic PMO), Project and Portfolio Management Office (PPMO) and the more light-hearted 3PO (Project, Program, and Portfolio Office).

The PMO has already grown well past the Project Management Office charter – isn’t it about time the name did as well?

Posted on: August 16, 2012 03:14 PM | Permalink | Comments (1)

"Computers are useless. They can only give you answers."

- Pablo Picasso