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:
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.
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?