Why Your Project Does Not Need More People, More Time And More Money
“Instead the No. 1 worry among leaders we surveyed is that IT isn’t implementing fast enough to meet business goals. More than one out of five respondents (22%) cite it as a major concern. That tops not having enough IT budget (20%) and not having enough staff (17%). Those three factors were the only ones to register as serious concerns ….” 2011 Global CIO Report, Information Week, March 14, 2011.
I got a call from one of the owners of a business who also held the title of engineering VP. He wanted to talk to me about improving their software development efforts. We sat down with the software manager and the human resources manager to talk about what was needed in software. The software manager said he needed more people, more money and more time ….
Oh boy. This brought to mind a great quote I heard many years ago, that went something like “engineering is doing with $1 what any fool can do with $2.” These three “needs” of people, money and time are the classic requests. Yes, just about anyone can get the job done if they get these in abundance. However, I watched a Fortune 50 company pile on the money and people to get a late running major project to finish on time (obviously, not on budget). The results? Nine months late. So it looks like we must have them all, and not just part of them? Yes, now anyone can be successful!
In every successful project I’ve worked on, we always succeeded with the resources we had. In almost every case our success was centered on making maximum use of available resources with a laser understanding of what we were doing (methodology) and why we were doing it (goals and requirements, etc.). In fact, I have an informal rule that given any organization there is a subset of that organization, about 25%, that can do everything the organization needs to do in order to be successful (completed projects, effective services, etc.). This rule comes out of practical experience in turning around organizations that were regularly failing in delivering their projects on time (budget, functionality, services etc.).
While this 25% rule may seem scary to some folks (“oh no, he’s going to let people go”) it actually doesn’t work that way. Instead, we have about four times the capacity we thought we had and we rarely needed additional resources (though we might swap one resource for another).
I do find the need for more time or as related above “we are not fast enough” to be a consistent critical concern. Too often the request of more time comes in the form of “oops, we are running behind, we need another week” which then becomes another week, and another month and then we have a significant slip in the schedule (and associated costs and quality). Too rarely do I see a concerted request for “more time” at the beginning — in projects that then have significant schedule slips. These compressed schedules are often the result of the “we are not fast enough” mentality where we try to be faster by using a compressed schedule and hoping, this time, we’ll do it. In most cases we fixed missed schedules by using longer schedules up front that resulted in on time project completion that took no longer than previous projects that missed their dates by months (see it is the schedule stupid and in project management 9+3 is not 12).
If we find ourselves asking for the classic “more people, more money, more time” then we probably need to pause and take a good hard look at what we really need in our project. While this request might in fact be dead on, it is also just too easy to think that these will certainly solve our problems. We know from our own practice and from industry experience that they rarely do.
Do you have any good examples of where the solution ended up to be other than the requested additional people, money or time?
8 thoughts on “Why Your Project Does Not Need More People, More Time And More Money”
Comments are closed.
Another great article Bruce
Having traveled through construction superintendent and project manager positions, prior to becoming a project controls consultant; I saw first hand how project approach – project strategy is the x-factor.
I’m not talking about soft skills. I am talking about specialized advanced knowledge relevant to the task at hand.
I chose project controls consulting because only the schedule can be so leveraged to both model the project approach/strategy and provide guidance and monitoring of the project constraints; cost, time, quality/scope, risk.
Few managers realize that the valid schedule is to the building approach – what technical drawings are to the product design. An intuitive schedule design developed to the correct level of detail, maintained weekly and used to manage daily project activity packs a pow!
Why don’t they get it. Because in order to build/maintain a valid schedule, the scheduler has to really understand the project and how all the pieces go/work together. This is a tall order. Most project managers lack the required advanced scheduling skills and most advanced schedulers lack the requisite project expertise.
Consequently the schedule has been reduced to a fancy application to track progress and foster invoicing. The real work of managing projects has been saved for the more conventional, time tested, very popular, and always accessible To-do list … even on nuclear power plant outages.
Phil,
Sometimes I feel the same is true about accurate baseline schedules. But then I think there has to be a way; either through more intuitive design or more consistent level of detail or more streamlined updating processes to prove accuracy, to expose challenges, to model a more comprehensive scenario. But all that depends on the client being able to recognize the difference. The you have to develop ways to teach the client.
Don Santos
cpmschedules.com
Kevin,
“We know how long a particular project process will take based upon real world projects carried out by a number of project managers.”
Yes, yes, yes! It is surprising to me how many people don’t use this approach, which works very well. At best I’ll see folks saying “that takes us six weeks” but when we go look at the real time it has taken in the last few projects, it is closer to 12 weeks. So getting the data right is critical and when we do it, schedules are a lot more realistic (i.e., we actually meet them).
Keep it up!
Bruce
Phil,
Good point. I often saw both sides of the effort and was always amazed. I would see the teams argue for better schedules, but when it got rolled up and presented to senior management, there was very little push for a longer schedule. In one case I saw the manager go back to his organization and say “I argued with them, but didn’t get anywhere.” Since I was there, I knew he didn’t argue, at all.
My reference was to this kind of culture, where when it comes down to the proposal to senior management for approval there is no significant effort to ask for something longer than what was “needed.” Yes, someone who did come in and say “we’ll need three more months” will get shunted aside. Again, I know because it happened to me on a regular basis (but sometimes: http://pmtoolsthatwork.com/project-management-crisis-hurry-but-do-nothing/). I even had managers tell me not to ask for the longer schedule they said they needed because it would make them look bad!
Thanks.
Bruce
A great article, and a very common problem. Part of the reason for this is determining how a project manager or management team will utilise past experiences and expose risks and potential issues very early on before they happen.
What we do is try to show businesses how their processes are running on projects. By using, reviewing and improving processes and custom milestones on projects it gives us two very important pieces of information at the outset. We know how long a particular project process will take based upon real world projects carried out by a number of project managers, this can usually make estimates a little more accurate. Further to this we know where the pitfalls are and can implement steps into every project at the outset to overcome them. The upside to this? Less stress management, improved collaboration, improved cash flow, and therefore, profit stability and the ability to consistently review processes and improve as the business evolves. This can even be used to mitigate as many risks as possible with new services/projects.
I saw lots and lots of requests for extra time up front. (It would be more accurate to say that I saw lots and lots of initial schedule estimates that were reasonably accurate, but that ended up being truncated under pressure from senior management.)
Managers who insisted that the work would take that long would be shunted aside, get assigned less work, lose staff, and eventually leave the company.
Projects usually ended up being run by managers who claimed that they could hit the short dates. Of course they were wrong—the project ended up being delivered about when the initial estimates said they would be, except with more bugs and with less functionality, because a lot of time had been wasted trying to hit the impossible schedule.
For most of my career, I kept expecting that the senior managers would eventually figure this out. I kept thinking that they’d eventually spot the managers who could provide an accurate estimate and then hit it with high-quality software. That never happened. Eventually, I quit expecting it.
Turns out, there’s no career benefit in providing an accurate estimate. Managers who promise the impossible end up getting the work. Then—when short schedules produce a completely unnecessary crisis, and their team resorts to heroic measures to keep the project from being a complete failure—they get a bonus for successfully managing the crisis.