So what happens to a web project when someone raises the red flag about the approching deadline? More often than not the first thing that a business will do is try to bring on more manpower.
The theory is that the more people on a web project coding away the faster they will advance through the schedule and thus making the deadline. However, Brook’s Law states that “Adding manpower to a late software project makes it later.” Fredrik Brooks went on to say that “The bearing of a child takes nine months, no matter how many women are assigned.”
When we look at this from a web project standpoint we know that the more people we have on a team the more important the role of the project manager becomes and the more detailed the schedule has to be. In addition to making the PM’s role more complicated it also makes communication on the team more complicated. Team meetings become 1/2 day marathons of information handoffs. Defining requirements becomes a committee effort. Assigning tasks becomes a game of telephone.
Thankfully there are tools avilable today to help make managing web projects easier. Everything from Basecamp and OmniPlan to timetrackers like Harvest and iCal play a role in keeping the project moving forward. But do tools such as these really solve the problem?
We all know that working in small teams has it’s benefits. A smaller team is far more agile than a larger team or even groups of teams. However, when it comes to larger scale projects, like enterprise level site redesigns, small teams can only take you so far.
Proactive Measures
So what can be done about tight deadlines? There are a few ways to be proactive about this:
- Define the Scope – Know as much of the the intricate details of the project as you can up front
- Write a Risk Assessment – Identify any known or even potential risks on the project and write them down
- Define the Utilization – Figure out what resources you have at hand and how many hours can be put towards the project. Compare the estimated hours for each part of the project with the available hours of your resources.
- Let the Schedule Breathe – Identify your budget from the beginning and plan for schedule slips where risks are found. If the deadline can’t change, the scope or price needs to.
- Over Communicate – I can’t stress this enough, it’s always better to be warning clients of potential schedule slips in advance and re-ittering them throughout the project than to springing it on the client at the last moment when there is no feasible way to recover.
Reactive Measures
Now, we don’t always have the luxury of being “proactive” about schedule slippage. More often than not the slippage only rears it’s ugly head near the end of a project no matter how prepared you feel you are. So here are a few suggestions that are more “reactive” to schedule slippage when the deadline can not be changed:
- Raise the Red Flag – Never be afraid to be the first person to raise the red flag… even if you feel the deadline is still likely to be met. Again, over communicating here.
- All Hands Meeting – Bring the team together for a short but effective meeting. Identify the issue at hand, allow the team to get involved with proposing possible solutions. Also allow them to give feedback on proposed solutions before initiating them. You’d be surprised at what a room full of web geeks can come up with to solve the problem.
- Prioritize – List all the tasks still needing to get done, prioritize them on a level of what has to be done for this site to launch, etc.
- Cut Scope – Things that rank lower on the priority level need to be cut from the expectations of what will be included in the launch.
- Phase Two – Things that don’t make it into the launch can be scoped out for phase two of the site which can take place shortly after launch.
These lists are not perfect and I don’t have all the answers here, but it’s a good first step list of some of the things you can do to resolve slippage issues.
Some Resources
- Manage Scope and Compete on Internet Time
- In Defense of Scope Creep
- Scope Creep Management
- The scope went through the roof
- Risky Business
- Project Management Institute
- The Mythical Man-Month (AKA M3) by Fredrick Brooks
- Brook’s Law on Wikipedia
- Exceptions to Brooks’ Law
- Brooks’ Law and open source: The more the merrier?
