Do your resources have a habit of “disappearing”? Do you call a project team meeting and no one attends even if you supply donuts? It may not be that you need a better deodorant. Instead, it is likely that your company’s resource management methodology is wrong. Many companies apply single project methodologies and processes to manage their projects, even though they operate in a multiple project environment. This greatly increases the chances of (multiple) project failures.
The purpose of this paper is to help you understand the following:
- What the perceived causes of project failures are in multiple project environments and what companies/executives typically do to “resolve” the perceived causes
- What the root causes of project failures are (how resource non-availability is one of the main reasons, often the main reason, for failures in multiple project environments)
- Why project “through-put” is a vital principle in multiple project environments
- How to help move your organization to a multiple project methodology and how to increase project successes even if your overall organization refuses to move to a multiple project methodology.
In many companies where the resource management methodology moved from a single project focus to a multiple project focus, project success rates and project through-put have increased, often significantly. By applying the principles from this paper you can approach your management with solid recommendations on how to greatly increase the company’s project success rate. You will become the project management “hero” and raises and bonuses will quickly follow (well, maybe not).
Far too many projects fail due to poor project management methodologies and processes. Resource management is one key element within project management methodologies. If resource management methodologies are set up and applied properly, project successes often follow. If resource management processes are poorly defined or misapplied, projects often fail. While this is true in single project environments, the negative impact from poor resource management methodologies in multiple project environments is profound (yes, I said profound and I meant it). This paper will help you understand the folly of using single project methodologies in a multiple project environment. We will look at typical project failures and what management believes are the causes of project failures (but they really don’t have a clue). We will also look at the true root causes of project failures, particularly in multiple project environments.
A key (often THE key) root cause of failure in multiple project environments is a poor resource management methodology. Most companies insist on using single project resource methodologies even though they operate in a multiple project environment. The problems this causes and how to avoid or correct these problems make up the bulk of this paper. A key concept in multiple project environments is project through-put. This will be discussed in depth, and once you understand it, you will be able to say: “Aha! By Jove, this through-put stuff is indeed important.”
Lastly, we will discuss what steps you can take to move your organization from a single project focus to a multiple project focus and thereby increase your project success rates and overall project through-put. Sounds too good to be true? Oh, but it is true—just read on.
For All Kinds of Reasons
Is there any disputing the fact that far too many projects fail? Projects are late. Projects are over budget. (Can you say “way over budget”?) Projects fail to deliver full (any?) functionalities. The new accounting system was delivered six months late, doesn’t work well at all, and frustrates just about everyone. Sound familiar? If you are a project manager you want a perfect project—on time (or miracle of miracles, early), within budget, and delivering everything the customer wanted (and maybe a few value-added functions on top). So why is there such a struggle? The struggle is often about your resources.
Even experienced project managers will fail if good project management methodologies are not in place. If good project management methodologies are not in place in multiple project environments, failure is almost guaranteed. However, the project management methodologies are often the last areas that management considers as a solution to the project problems.
Why Projects Fail—According to Management
The higher up in management you get, the less you know about what is actually going on in the projects. But the VP is the individual who decides what steps to take to resolve the project issues. So the directors and managers review some reports and tell the VP what the project problems are. But they will not tell the VP their own group or their own processes are the problems—it is someone else. It’s the accounting system, the suppliers, the unreasonable customers—anyone but themselves. And suggesting that the overall methodology is wrong and needs to be changed? That would be like telling the VP he or she has set up a bad system that people can’t succeed in. So we’re not going there, are we?
So What We Get for Solutions Are:
The project managers are just not getting it done. They’re supposed to manage the project aren’t they? They need to kick some rear ends and get the project moving. This is the “Patton” approach to project management. It works okay for an army that has soldiers who cannot defect without threat of execution, but not so well for regular project team members. Sometimes it gets very short term results, but almost never over the long haul.
The project workers are not performing up to snuff. They need to get the work done, even if that means they have to work 60, 70, or more hours per week. Just get the dang work done already. This is the “It can’t possibly be management’s fault so it must be yours” approach. Depending on whether or not overtime is paid (more and more today it isn’t), this approach has varying degrees of success. But it won’t be successful over the long haul even if overtime is paid. Everyone needs rests and breaks and if project success means six straight months of 70-hour weeks, team members will burn out, crash from overwork and/or quit.
We need new software to (fill in the blank). When someone can’t be blamed, blame the tool. Get MS Project Server 2010 for your scheduling, get the latest risk management software, get better CAD software, get a new supply management system—get something, anything to appear you’re attacking the problems. But these rarely produce any significant results because they don’t attack the real causes of your project problems. Often they cause even more project failures because the project personnel are now required to learn new systems that don’t really produce better results.
Why Projects Really Fail
It’s the Economy Stupid! (No wait, that’s for the Presidential race, not project management—but it’s a good statement to keep on the tip of your tongue anyway)
It’s your Project Management Methodology (particularly resource management).
I’ve been involved in setting up PMOs for five different organizations and the lack of good project management methodologies has been the leading cause of project failures in all of them (in the beginning when the PMOs were being formed). In these situations, once in awhile you have a successful project when you have a “miracle worker” for a project manager who works 80-hour weeks and has amazing interpersonal skills that allows him to get unusual effort out of the project team members. But if you lose him, forget about any more successful projects.
Even if you have good standard methodologies in place, companies must recognize that there are significant differences between running projects in single project environments and running multiple projects. The major differences between the environments are resource allocation across projects and project prioritization. We will address the resource issue in depth and only touch on the prioritization issue in this paper.
Most companies force their standard single project resource allocation processes into their multiple project environment. They do this because that is what they are familiar with, and the move to a multiple project focus requires new processes and procedures and will take time and effort to put into place. However, as you will soon see (if you are paying attention—HEY, wake up and pay attention!), the move is not only well worth it, but continuing in the former mode is akin to corporate suicide.
Resource misallocation is a major (THE major?) cause of project failures in multiple project environments.
You can have wonderful scope definition, wonderful schedules, wonderful leadership, wonderful single project resource allocation, and still not have key resources available when needed. In this case WHAM, you fall behind schedule and can never catch up. Your project failed—so what the heck happened to your resources? They were working on other projects.
Multiple project environments demand a cross project methodology for allocating resources. Gone are the days when there were sufficient resources to fully staff all your projects. Everyone must now multitask. If you have 10 concurrent projects going on in your organization, it’s likely that many key resources are shared across several projects. When this occurs you have to apply a multiple project approach.
If you do not apply enterprise-wide resource management, there is no way to know whether or not your resources will actually be available to work your tasks when they are scheduled to be done. Your individual project schedule is well detailed, with good dependencies and accurate duration estimates. Additionally, there are no over allocated resources in your individual project schedule. The same is true for Bob, your project manager buddy who is assigned another important project. But unbeknownst (there’s a word I bet you haven’t heard in awhile) to each of you, there are major over allocations when the two projects are considered together.
This is why companies must take an organizational wide approach to their resource management. This is best understood when considering project “through-put.” Every organization has a set project through-put capability depending on the size and type of projects they manage and on the resources available in the total resource pool. Let’s look at an example.
Through-put is somewhat easily understood in standard processes such as a manufacturing line. Notice the manufacturing steps in Exhibit 1.
Most people can easily figure out that the maximum through-put for this system is 90/hr. You can increase your processes and efficiency for thru-hole to where you can process 150/hr, but it does the overall system no good. In fact, there is a negative impact because more products will be held up waiting to be processed at later stages, resulting in more lost and damaged sub-assemblies.
Through-put is harder to recognize in project environments, but anytime you have multiple projects, you typically have a maximum through-put capability. Notice Exhibit 2.
The project through-put capacity is six projects per year. You are limited by your coding resources who can only work an average of one project every two months. But Sales is always trying to add new projects. Managers and directors have their own projects they want worked and the VP has his eye on implementing a different financial system that he liked at his last company. Besides, most organizations don’t know their project through-put capacity, so they keep adding projects until the system crashes. Since the Analysis resources can process 10 projects per year, management forces 12, 13, maybe 15 projects into their group. They work franticly and push three or four at a time over to Coding. Coding could handle one every two months but instead four get tossed at them all at once. When this happens they are forced into a bad multitasking mode. Bad multitasking is moving resources back and forth between projects without using sound business decisions to make the moves. One director puts pressure on the resource managers to work his project so they are moved to that project. Not too much later, another director demands work gets done on his project so key resources are moved to it. Then the VP finds out that work is falling behind on his project so he insists the resources be assigned to his project (and who is going to tell him no?). This scenario goes on for months with little progress being made on any of the projects. As illogical as this approach is, it is SOP for many companies.
When you have the capacity to work an average of six projects a year and 12 projects are forced into the system, the organization will typically be able to finish two to four projects successfully. They could have completed six, but the in-fighting for resources between the management team caused fewer projects to be completed. And because resources lost focus in bouncing back and forth between projects, more errors were made and even the projects that completed were not particularly well done.
Moving to a Multiple Project Methodology
In order to stop this madness, organizations must apply a multiple project focus to their business. Four key elements must be in place to become successful in multiple project environments.
- Some form of portfolio management must be implemented. You don’t have to have formal Portfolio software (but it helps), you just have to have a recognized process for estimating you project through-put, and a project approval process that ensures you do not force more projects into the system than your resources can handle.
- An enterprise-wide method for applying resources to projects. Again, you don’t have to go full blown and use something like MS Project Server, but if you have a fairly large organization, MS Project Server or a similar tool is probably required.
- A focus away from individual project successes to an organizational through-put philosophy. This is harder to do than you might think because not many executives are familiar with this philosophy. When executives are not familiar with a new methodology, it is very difficult to get them to agree to try it.
(There is no fourth element; I just wanted to see if you were counting them as you read them.)
If your organization is managing more than 12 to 15 concurrent projects, you probably need a good portfolio management tool (like MS Project Portfolio Manager). However, if you have fewer projects than that, you can have a less formal portfolio process. Whether formal or informal, you need to set up several key processes:
Project Approval Process. Each current project and each potential new project must prove its value to the organization. Set up a list of project criteria and ensure all new projects are approved before work is undertaken (this may even stop the VP from implementing that favorite financial system of his, but don’t count on it). A portfolio management team needs to be established with the person responsible for overall organizational success being its chairperson. When new projects are considered, already approved projects may need to be cancelled or postponed (or additional resources obtained).
Estimating your Project Through-put. You may say, “Our projects vary too much to estimate a through-put capacity.” I’ve heard that many times from various companies, but each time the organization was able to come up with a reasonable through-put capacity estimate. You look back over the previous three to five years and see how many medium to large projects you completed. Then you factor up that value, recognizing that you have been working the projects ineffectively. If you have completed eight projects per year, your through-put capacity is likely around 10 to 12 projects. So if you have 15 concurrent projects in your portfolio, you must cancel or postpone several of them. While this will be like the democrats and republicans trying to come up with an agreed to way to cut the national deficit, you must do it to ensure the right projects get worked. Working fewer concurrent projects ensures that more of them get completed.
Project Prioritization. In addition to limiting the number of projects, the Portfolio Management Team must prioritize the projects. I have heard executives say, “All our projects are number 1 priority.” Hogwash. You do have a top priority project and it’s easy to find. You ask the question: “If we could do one and only one project, what would it be. When you determine the answer, that is your number 1 priority project. If you set up criteria for project importance, you can evaluate all your projects and find out which ones are more important than others. And beware of a Top 5 and remaining 15 out of a 20 project portfolio. When you allow this you make the #5 project on equal footing with #1, you relegate #6 to obscurity (even though it may be just about equal with #5) and you elevate #20 to be on equal footing with #6. Like MADD says about drunk driving—just don’t do it. Prioritize all your projects, 1 to 20.
Organizational-wide resource management. If you have more than 8 to 10 concurrent projects and more than 50 or so resources in the project resource pool, you need to consider an enterprise-wide tool like MS Project Server. I can highly recommend this tool because I have been involved in the implementation of Project Server 2003 and Project Server 2007 and the results have been very good to outstanding in both implementations. I also hear from trusted sources that Project Server 2010 is even better. But you do need specialized expertise both to implement and maintain this application.
Even in an enterprise-wide application, one mistake I see some organizations make is that they do not take the extra step to not only resource load the tasks, but to hours load the tasks also. This is where the concepts of Pure Time and Gross Time come in. Pure time is the “Stop watch” time. It’s as if you locked the resources into a room for eight hours every day until the task is complete. That’s not how resources work in multiple project environments. They work two, three, maybe four days on one project task and then move to another task (the first task needed further input, or there was some other reason for the pause in work). During the three days the resource was working, they only spent an average of six hours each day on the task (team meetings, emails, other items ate up two hours each day). When you planned this task, you figured if there were no interruptions, this task was a five-day (40-hour) task. This is the Pure time. But you know interruptions will occur so you enter the task in the schedule as eight days (this is the Gross Time). You must then follow up and hours load the task as 40 hours. MS Project will show this task as five hours each day for eight days. Now if the work doesn’t get interrupted much at all, it may complete in five days. With average interruptions it completes in seven to eight days and with extensive interruptions it completes in nine days or more. As a general rule, you do not want to load projects in Pure Time because when impacts hit the project, there is little available time to cut from the remaining Critical Path. If you have only a few multiple projects, you can use the database capability of MS Project Professional (desktop) version. You set up a common Resource Pool as a “project” and allocate resources to each project out of the Resource Pool using the “Share Resources” feature. When you find you have resource conflicts between projects, you use the resource leveling feature to resolve the problem. A word of advice: always attempt to resolve resource over allocations manually before resorting to the MS Project automated feature. If you do use the feature, level only one resource at a time. Remember, over allocations more than four or five months out in the future can often be ignored since by the time you get out four or five months, projects will have ebbed and flowed and the over allocation may no longer exist.
Moving to a Through-Put Philosophy. This is a recognition by all project personnel (and executives particularly) that the organization is focusing on many projects getting completed (bringing in revenue and or other values to the organization) rather than individual projects. When individual projects are the focus, there is in-fighting for the resources and less important projects get valuable resources when other much more important projects get them taken away. This happens all the time in organizations where single projects are the focus because each level of management has their own personal and professional reasons for wanting certain projects to succeed. Project success is often included in managers’/directors’/project managers’ appraisals, so they will raid resources from other projects if they have to—their pay and bonuses depend on it. When you move to a project through-put focus, you need to change the incentive to be based on overall organizational success, rather than individual project success.
Another element of a through-put focus is a recognition that the key resources belong to the organization, not to individual projects. Each month, projects must be statused and evaluated. If the #3 priority project needs key resources that project #15 has, then project 15 gives up the resources. This is recognition by all project personnel that it is more important for project priority #3 to succeed than it is for project #15.
This Stuff Really Works
Full-blown Through-Put Focus at Lucent Power Systems.
When we set up the PMO at Lucent, we had no project management methodologies in place. In a way this was a blessing in disguise because the project teams did not have to unlearn bad methodologies. The Executive Team had seen presentations on the Theory of Constraints (constrained resources) and Project Through-Put and decided to go to enterprise-wide resource management with the emphasis on through-put.
As our baseline measurement, we were trying to work 100 projects concurrently. The average project took 15 months to complete and only 33% completed on time and even fewer were within budget. Our through-put was 40 projects per year. Our products were good, but our customers were going to our competitors because we couldn’t deliver when we promised.
We set up a portfolio management team and prioritized our projects. Schedules were developed and resources were loaded across all projects. Project reviews were held every other week. We changed our incentive program to be organizational wide (through-put) based rather than based on individual projects and groups. At first, there was not much improvement. This is expected when you move to a new methodology. You may even have worst results for awhile (you are spending time learning new methodologies, which takes time away from the projects).
After about six months things began to change. In the project reviews, when higher priority projects needed resources, lower priority projects gave them up. The project managers had been reluctant to do this previously—they were not yet convinced this through-put emphasis was going to work. The higher priority projects began to complete faster. At the end of the first year we saw some definite improvement. Many of the higher priority projects were completing on time and a good number of the mid to lower priority projects were scheduled to complete on time. The bonuses were better that year than the year before because the overall results were better. Momentum began to build during the early part of the second year. In the project reviews, all the higher priority projects were now getting the needed resources because the project managers on the lower priority ones were volunteering to give theirs up. Projects were completing faster and faster and more and more orders were coming in when the word got out that we could deliver on time and quickly.
It was a very satisfying feeling so see an entire organization pulling together for the good of the organization. No silos and fox holes (none you could notice anyway). That’s because the bottom line results were improving so dramatically that everyone was practically giddy. By the end of the second year we had made profound (there’s that word again) improvements. Eighty seven percent of our projects completed on time and 91% completed within budget. The average project duration had been cut to nine months and we had a project through-put of 90 projects. Because bonuses were based on overall results, the average bonus that year was 40%.
A sister Lucent Division in Atlanta (Telecommunications cabling) implemented similar methodologies and saw almost identical improvements. Does that mean this will work everywhere? Probably not. At both Lucent Divisions, the executive teams fully bought into the through-put philosophy. In other PMOs I have led, moderate to significant improvements have been made, but none quite as dramatic as the Lucent PMO. The point is, there is almost always some significant improvement.
What Do I Do Now That I Know This?
Do I Need Formal Enterprise-Wide Software?
If you have more than 50 resources in your project resource pool or if you are running more than 8 to 10 projects concurrently, you will need an enterprise-wide application like MS Project Server. If you run only a few projects and have less than 50 project resources to coordinate, you can use the resource pool capabilities of MS Project Professional standalone version.
If you are going with an enterprise-wide application, do significant investigation into the cost and time needed to implement the tool. Many implementations fail from too rosy of expectations on how fast and cheaply they can be implemented. For any medium to large organization, you will need one and a half to two years to fully implement MS Project Server to where the projects begin to finish successfully. But don’t let the time required stop you. If you don’t move to a through-put focus, you will forever be mired in your current situation of fighting for resources and seeing low priority projects finishing ahead of truly important ones.
Whether you go with an enterprise-wide tool or not, you will need to find an executive that you feel will be receptive to the philosophies discussed in this paper. Have some one-on-one meetings with them and share this paper with them. Emphasize the logic of a through-put focus in a multiple project environment. If you can get a key executive to be your champion for this endeavor, you will have a good start and a reasonable chance to get most of the executive team to buy into it.
My Executives are Stupid—They Won’t Buy In—What Can I Do?
Yes, as we all know, executives can be stupid. However, even if you cannot get overall executive support, you can still implement the methodologies in this paper if you have a smaller sub-group within your overall organization that you can pilot the methodologies in. If some sub-group has most of the key resources resident in their own organization, you can implement organizational-wide resource management within that smaller organization. Here you need to find a receptive executive within that organization so that they are driving the culture change the through-put philosophy requires.
Projects Do Fail. We discussed the various ways that projects fail and the typical steps that management takes to resolve the causes of the failures. We discussed the fact that their solutions do not work because they do not attack the root cause of the failures.
It’s the Resources Stupid. We discussed that a high percentage of failures in multiple project environments can be attributed to misallocation of resources and the bad multitasking it causes. This must be resolved to truly solve the multiple project dilemma.
Through-Put, Through-Put, Through-Put. In multiple project environments, the emphasis must be taken off individual projects and moved to an overall organizational focus. You must match your projects to your project capacity in order to maximize your overall project results.
There’s Gold in Them Thar Hills. Yes, if you are struggling in your multiple project environment, you definitely have the potential for significant improvements by implementing the principles in this paper.
Enterprise-wide or Not—Decide and Move Forward. We discussed that you may not need an enterprise-wide application if you have a relatively small organization. If you are in a large organization, look into what enterprise-wide tool will be best for you. Find a receptive executive and go for it.
Lastly, remember the words of Rosanna Rosanna Danna: “What do you mean we are depleting our Project Resources?” No Rosanna, that’s Natural Resources, not Project Resources—it’s Natural Resources we’re depleting. “Oh well then, never mind.”