ahref.com > Guides > Industry
Managing Web Projects, Continued
Managing Risks
We've all seen it happen: just when a project seems to be doing well, the client unexpectedly changes the scope, a team member gets pulled onto another project, a technical problem doubles production time. Suddenly the schedule is a work of fiction. The project's success is jeopardized.
No matter how talented a project manager you are, unexpected challenges arise on every project -- challenges that threaten the schedule or the budget or the relationship with clients or team members. These are project risks. Risks are an unavoidable part of all projects. The key is to anticipate as many of them as possible at the start of the project, build in contingencies wherever possible, and manage any risks that do arise.
What can go wrong
The following are examples of risks that may threaten a project. A single project may suffer from one or (in cases of real trouble) several of these risks:
- The project's scope and goals are poorly defined. The project manager, the team, and the client should all have a thorough and identical understanding of the project's goals and scope.
- The project's timeline is unrealistic. The rush to launch a web product can lead to unrealistic schedules that don't allow for completion of tasks. These schedules often invite failure. Scheduling conservatively usually results in a more reliable launch date.
- The client doesn't have full authority to make decisions. This is one of the deadliest problems in the project-risk minefield. Beware of clients who aren't really calling the shots -- more often than not the project will be torpedoed, usually days before launch, by the higher-up who is.
- The business model hasn't been settled. Approach with caution any projects in which the client hasn't defined their business model, especially if it's an e-commerce application or an extranet project.
- Development begins before the planning is done. The adage "Measure twice, cut once" applies here. Putting your designers and programmers to work too early will only mean more revisions, headaches, and lost time.
- The project is understaffed. From what I've seen, the proportion of work to staff in web development groups virtually guarantees project understaffing. While it's tempting to try to squeeze in yet another project, be aware that the success of the entire pool of projects will be affected.
- Team members don't have the skills necessary to complete their tasks. One of the most uncomfortable problems a team can have is when someone isn't carrying their weight. Make sure every team member understands their responsibilities before joining, and make staff changes if necessary.
- Team members aren't invested in the project's success. For a project to succeed, the team members, project manager, and client must all be working toward its success.
- Progress isn't communicated to the team. It's not enough for the project manager to know what's happening -- the team and the client must also know where they stand, what they need to do next, and whether the project is on track.
- The pace of change on the Web itself may be a risk. With new technologies, sites, fads, business paradigms, and players appearing (or disappearing) every few months, the Web can be a risky project environment.
What can you do about it?
There are many practical steps a project manager can take in dealing with risks -- such as assigning additional project staff or negotiating changes with the client. But leadership and the right attitude are perhaps most critical.
From the outset, communicate risks clearly to the team and the client. Flag problems as soon as they arise. Create an atmosphere in which problems are discussed openly and solved quickly, creatively, and without finger-pointing. And be willing, if necessary, to start fresh or scrap the project if completion becomes unrealistic. Obviously this last option should not be undertaken lightly at the first sign of trouble, but only after all other constructive options have failed. |
