Robert Wederquist
UX Design + Scrum
Project management: Waterfall
If waterfall is a fact of your enterprise, you probably know that it comes with inherent risks, because you can’t back up. There is no reverse gear, and if you somehow manage to put a waterfall project into reverse for a brief period of time, the gears will grind. Skyscrapers and bridges are built in waterfall for a reason. Planning is done up-front and with care, because you can't un-pour concrete. You can only demolish it and start again.
Therefore, a waterfall project plan is focused on risk mitigation. If your team has no dedicated project manager — and you are asked to make sure everything gets done — you should follow some basic requirements.
- Have a kickoff meeting with every single person who will be part of the project present. Don’t decide that some team members are task-oriented and don’t need to see the big picture. A kickoff meeting is the first step in full-team product definition. Everyone needs to be there. (Check out Kevin Hoffman's excellent essay on “Kick Ass Kickoff Meetings” at A List Apart.)
- Determine what deliverables need to happen, and when. These are the project artifacts and final products, and an inventory will need to be established. Don’t get halfway into a project only to have a senior executive ask “Where is the journey map?” If a journey map or other artifact is required, get it in the artifact inventory right away.
- Avoid needless documentation. The only reason to create an artifact is to give other people on the team, as well as leadership, an opportunity to review progress, provide feedback, and push the project into the next phase. If an artifact does not create a need for review by others, ask why it’s needed at all.
- Have team members responsible for deliverables provide estimates for how long the work will take. Don't do this for them. Compressing projects into unreasonable time-frames creates a "moon-shot" mentality, and eventually team burn-out. If the estimates don't fit the delivery date, find out if the scope of the product itself can change. A minimum-viable product may be more appropriate. If this is not possible, leadership may need to allocate more resources.
- Do not silo team members by acting as a go-between. Waterfall is not Agile, but there's no reason why it should stifle collaboration. Is a design concept required? Make sure that a UX designer is available to provide input. Does the project start with wireframes? Not getting input from the visual designer on wireframes diminishes his/her layout expertise. Is the front-end developer available? Ask him/her to sit in.
- Determine what review points need to happen. A senior executive may not need to be involved in every brainstorm session (a busy executive should have several things on his/her agenda), but they are accountable for the ROI and can provide guidance. Team members need to have a sense of overall progress. Make sure everyone is offered milestones to critique artifacts and provide feedback.
When the project plan is in place, you should wind up with a schedule that looks something like this. Don’t forget to note holiday breaks, which can put a big dent in planning estimates.
Finally, when the project manager is checking in with team members (or even better, during frequent status meetings), the team should determine if the project is on track, at risk, or off track. It’s the project manager’s responsibility to be certain that every voice has been heard and accounted for. Everyone involved in a waterfall project should be aware of its status.
You might be reading this and thinking “Of course,” because it’s Project Management 101, and good organizations manage it all with grace.
But it's possible you've also worked at some companies where these basic princicples were not followed — or no project manager was assigned and team members were asked to figure it out among themselves. That typically does not go as well. If a project has no project manager, then one person on the team should be designated as the PM to keep everything on track.