Project

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.