I am in the process of researching the effectiveness of Project Managers in relation to the number of projects they are managing at a given time. The assumption, that I am sure everyone will agree on, is as the number of projects increase the effectiveness will decrease. I am interested in what the breaking point is; the number of projects that jeopardizes the success of all projects. You could relate this to program management, but in some scenarios the projects that are being managed by one Project Managers are not focused on the same business objective.
If anyone has any information on this relationship, I would be happy to hear from you.
In addition to looking at the number of projects you must also consider the complexity (technical, organizational, etc.), scope (dollars, deliverables, people), and experience of the project manager. There were times in my past where I could manage one or two large complex projects. Now I can handle two or three, a half dozen medium size, or a bunch of small. Lots of variables to your question. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
I have found the number of projects that can be managed at one time is also related to the number of resources that are being shared between those projects. The more dedicated the resources the better. If the project's ROI justifies dedicated resources then trying to eek out productivity by having people split their time across multiple projects is acutally detrimental to the bottom line. Also, the more self directed and focused the teams the more scalable the projects. So self managing dedicated teams help to design out project complexity. Saving Changes...
As an alternative to Michael's suggestion about dedicated resources, one could manage the multiple projects vis a vis the ability of the shared resources to work them without multi-tasking. Dedication of resources is an expensive way of driving out multi-tasking and protecting projects from one another. Another way is to understand the potential resource constraints and synchronize project launches to their capabilities.
In this kind of environment, if these projects are also managed via buffer management, then the "self-managed teams" can be easily facilitiated as everyone knows where the best use of their time is in order to maximize organizational benefit.
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
I agree with Frank - dedicated resources can be expensive. And resource scarcity and management is the key to such things. I have done it both ways. Most my projects have 10x or more ROI. Many have delivered millions of dollars on return over very short time periods. In those cases I have found that being efficient with people' time was the least critical component to success. Having them dedicated even if it meant unutilized at times paid big dividends. In one instance I had a CEO keep my on tap 8 hours a day so that when his time was available so was I. Often at midnight. When I explained how underutilized I was he just stared at me. Then calmly explained that his time was worth 1 million a day to the company and that if deoptimizing my time meant maximizing his ability to deliver value then it was okay.
Sometimes I think we labor under a false work ethic. Too much focus on people yield instead of project yields. Not all projects warrant dedicated resources. Some projects do. Its all a function of payback. Maybe that is why professional sports teams don't like to see their players engaged in multiple sports at one time. Or keep extra bench strength around. Maybe its why we don't rent our car when we are not driving it. Or rooms in our home when we are not using them. More important they stay dedicated to our needs so when you need them they are there. Sometimes its not about utilization but about success and elimination of complexity.
Abundance is rarely achieved through economy. I am sure this goes against the grain big time for many. But then again controversy is what keeps debates and thinking alive sometimes. :) Saving Changes...
Some ideas you also should consider: 1.)The importance of the client and the project it self for your company 2.)What kind of clerk support does your project manager have 3.)In which stage are projects managed by your project manager 4.)Set expectations with your client about the activities your project manager must perform.Some times client's project manager can do a lot of work and be very helpful. Saving Changes...
Jan SchillerPartner and Chief Project Officer| Berkshire Consulting LLCArizona, United States
I attended a D&B seminar YEARS ago, and was provided with the rule of thumb that the breaking point is somewhere between 3 and 4 projects (and I agree, there are a lot of variables but this rule of thumb provides a consistent guideline to start from). Saving Changes...
While I agree with the groups sentiments that there are many variables here, it is my contention that no matter how large or small the projects, there is a hard number of projects that any one PM can handle effectively. We often refer to our time using the term "bandwidth", borrowing from telcom. I believe that the term is very appropriate here. When bandwidth is multiplexed (split out), there is a gap that must be placed between each separate segment of the signal. I find my time looking much the same. When I switch from one project to another, there is a ramp-up time to get my mind back into the project I am focusing on. If this ineffectiveness gap is 5%, then after you get more than 5 or 6 projects, regardless of size, you are almost completely ineffective.
Even though I have more than a decade of PM experience on very large and small projects, for me, the number is about 5 projects. Beyond that, I am only giving them lip service. Saving Changes...
I am a newly appointed PM;although business management teaches a lot about ROI;specifically in the software industry for application development projects-whatz the common way of calculating ROI?can someone enlighten me? Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
You might want to look at the JUSTIFY section of JPACE here on gantthead. Generally ROI is ROI; software is no different nor technology. First you must define the value that the project will deliver. Second comes the cost factors over a reasonable time frame (Capital and Operating ---- Development and Maintenance). Then you plug this into the ROI calculation.
The tricky part is defining what the application will deliver to the company. To that you must look at the value the current environment is delivering or detracting and then what that environment will deliver after the implementation of the application (whether new or improved).
I all comes down to understanding and quantifying the business benefits that will be delivered.
Michael is right. The hardest part of putting an ROI together is converting qualitative benefits into numbers that an ROI calculation can deal with. Soft costs like time spent, efficiency, competitive advantage are examples of benefits that must be quantified. Saving Changes...
