« PMI Program Management Certification | Main | Monday Monday »

Biggering and Biggering

At a certain point projects get too big for some people and they just can't handle it anymore. One example is Windows Vista which has slipped extensively over the past year or so. And to the people on the inside (and to any number of people on the outside) the slips have not been unexpected. Philip Su, who was involved deeply in the development writes:

They knew months in advance that the schedule would never work. So they told their VP. And he, possibly influenced by one too many instances where engineering re-routes power to the warp core, thus completing the heretofore impossible six-hour task in a mere three, summarily sent the managers back to "figure out how to make it work." The managers re-estimated, nipped and tucked, liposuctioned, did everything short of a lobotomy -- and still did not have a schedule that fit. The VP was not pleased. "You're smart people. Find a way!" This went back and forth for weeks, whereupon the intrepid managers finally understood how to get past the dilemma. They simply stopped telling the truth. "Sure, everything fits. We cut and cut, and here we are. Vista by August or bust. You got it, boss." (source: http://blogs.msdn.com/philipsu/archive/2006/06/14/631438.aspx

Of course this is not just confined to Microsoft. A look at some of the recent events in the world will bring up any number of situations where a top down version of the truth is imposed upon a certain initiative or action with predictably unsatisfactory results. I have observed similar behavior with large development teams being exhorted to achieve the unachievable through methods which seem laughable in retrospect. I've seen situations where the project managers are squeezed between lying to their bosses and lying to their teams.

What do these situations have in common? Well, one common factor is size. With size comes heirarchy and with heirarchy comes a certain distancing from the reality of the situation. This gives more room for those at the top to believe that their desires actually can influence what the results are. In a smaller group, people are quickly deposed of this fiction as they can see the effects or lack of effects on the team.

Another common factor is that the size is frequently bigger than anything they have done before. Here size is shorthand for a host of things such as complexity, team size, geographical size, duration etc. The skills and behaviors that worked with smaller teams and smaller projects just start to run out of steam. They don't always scale up. It isn't that they couldn't scale up, but rather I think that the issues of scaling up are not taken into account. People take their previously successful tactics and try and make them work. Nothing wrong with that. One rule of successful projects is to minimize risks. One way of minimizing risks is to minimize change. Or at least it minimizes risk except in cases where change is required. The unfortunate truth is that big projects sometimes do require change.

Now is the point where project managers of superprojects jump in and say "In my industry ..." and cite a methodology or process or mindset or all three which does work on big projects. And the response is "great but" and goes on to argue it is a bit heavy for small projects. This can echo back and forth for a while. But it would be just a lot easier if people would just acknowledge that the skills and processes and the people needed on a big project are a bit different than those on a smaller project. Ignoring this is a cause for failure. Pants too small rip embarrassingly when you bend over too far. Pants too large drop at inopportune moments. My only point is to think about these things in advance and if possible try them on before you buy. If you can find a good tailor then go that route. You just don't want to end up in a situation where you are asking the team "does my butt look big in these?" and expecting to get good data back from them.

  • Seeing Other Scheduling Software
  • All your models are belong to us
  • Schedule Assumptions
  • Trouble with Assignment Units in Project 2010?
  • PM Web #001 - Glen B. Alleman's Herding Cats
  • Books to Consider – Decision Making
  • Taking and Passing the PMP Exam - Part 15 - PMBOK version 4
  • Project Management Office and the Monorail
  • The Cashmere Bikini
  • Project Management Immaturity Model

  • Comments (1)


    Great post. The difference between large and not-large projects is related to size and the resutling complexity. But a Systems Engineering view (see The Systems Bible, John Gall) is the embedded chaos that results from the number of interfaces between the parallel activities.

    Here in aerospace, certified disaters are common. No amount of good process seems to save several projects I have observed from the outside (SBIRS being the local one). Yet there are counter examples (success) of large projects using the same processes with similar complexities coming in on-time, on-budget and meeting the requirements.

    The study of large projects produces papers in the literature, but so far there is no real understanding of how the succeed, butlots of ways for them to fail.

    If the MSFT example is true, then the fundamental rule of large projects was violated. You must tell the truth about progress. You need some un-asailable way to measure the truth (and there are several ways in aerospace). But "telling the truth" is the core process. Without that the project is lost no matter what process is applied.

    I spent several weeks in Paris and London. Terminal 5 at LHR has a big sign "on-time, on-budget: it can be done." It'll be interesting to read how they did it. My direct experience is with Rocky Flats (www.rfets.gov), where on-time, on-budget, on-spec was done for $7B of work. The "how" is still buried in the details of the day-today work.

    Post a comment

    (Comments are moderated to fight SPAM and will be published after I have a chance to approve them. Thanks for waiting.)


    The previous article is PMI Program Management Certification.

    The next article is Monday Monday.

    Current articles are in the main index page and you can find a complete list of articles in the archives.

    Creative Commons License
    This weblog is licensed under a Creative Commons License.
    Powered by
    Movable Type 3.34