The Four Phases of a Project

While I am not an "expert" on projects, I've managed enough and lived through enough to come to recognize a pattern.  I want to spend a few days or a few posts, whichever comes first, writing about project management as it relates to team productivity.  I've heard it said that the four phases of a project are optimism, realization, fear and doubt, but I think with the appropriate education and expectation setting we can all do better than that.  Here goes! If you've read along you'll know that I wrote a post a few days ago called Hum a few bars for me.  In that post I made the assertion that in a perfect world percent completion would track to time committed in a project on a linear basis.  In a graph that would look something like a line with a 45 degree slope, up and to the right.  However, none of us live in a perfect world.  Plotting the curve of % complete against time committed would probably look something more like an "S" curve, flat at the beginning with a steep increase late midway through the project, eventually plateauing and tapering off towards the end.  This is my hypothesis based on what I've lived through.  Your results may vary. If we were to simply break down the project into four equal phases based on the time committed, we could observe some very interesting attributes and features of most projects.  Let's dive a little deeper into the first phase - that is the time from zero to 25% of time committed. This is the Optimism phase.  The team is excited to begin a new project.  Everyone is coming together to do something important.  Optimism is high, since the project has been signed off by a big cheese and it promises excellent returns for the firm.  The team assembles for the first time, gets their marching instructions and starts to work.  There's only one small problem.  In most firms, none of these people have worked together before.  They have no common workspace, no common file sharing, no document standards, and even their language and compensation schemes are not in alignment.  This harkens back to the first documented project in the history of man - the Tower of Babel.  Compensation and communication schemes did that one in - and gave us a nickname for poor communication. I think we often overlook the efforts involved to get everyone working together efficiently and successfully in team projects.  This is a much more difficult effort than it appears, especially when the team is assembled with representatives from across the business functions.  Often you'll find that none of these people have much in common other than their business card.  Finance, for example, will have a different language, a different set of drivers and a different compensation scheme than sales or distribution.  All of these people have their own document standards, communication styles and so forth.  I'm not advocating a ropes course or a campfire sing-along to get everyone together, however.  I'd prefer some basic standards that are discussed and agreed at the start of the project.  Where will we store proejct documents?  What formats will we use to record our decisions?  Who decides what is important?  Secondly, I think it's important to compensate the team in a consistent manner.  If the team has disjointed compensation schemes, often it is hard to get everyone bought in to the sucess of the team if participating means missing out on opportunities in their business function.  I've lived through projects where the project meant that individuals had to choose between accomplishing their business functions (the "regular" work) and getting the work done for their project responsibilities.  Guess which set of tasks got done if there was a crunch?  The responsibilities that aligned to compensation. Third, we need to build in expectations for our projects that take into account the real team building that's required to get the project started.  In any work environment there is a certain amount of inertia, even in established teams.  In a new team, there will be a significant amount of work just to get the team working "at speed" and working to a common set of goals.  That's why I anticipate the "S" curve when examining percent complete.  It simply takes a while to get a team up to speed.  The "work" they do early in the project is not wasted if it is used to ensure the team can be more efficient and effective later in the project. There remains the temptation to skip all of this upfront stuff - just to plunge into the project without any preparation.  If your team is cohesive, the more time you spend developing a common approach, the more efficient and effective you team will be in the later project phases. Stay tuned for more on the remaining project phases.