Project Control: Do’s and Don’ts
Project Control is quite possibly the 2nd hardest part of project management with closing being the most difficult. If you are trying to manage a software development project using a waterfall methodology then good luck, you need it. Unfortunately for me, some of my first projects were based on it and it alone made a case for me as to why following best practices are important. Project control is part of the Manage and Control Project stage of a project. It is iterative, easily manipulated and prone to scope creep. It is also a very communication intense process that relies on more than status reports & systems. Here are some methods of managing this stage of the project without alienating the client or negatively affecting the project cost, time, quality & scope.
- Keep tabs on the project progress with internal teams (daily) and client (weekly)
- Document everything: phone calls, meetings, informal discussions. If a decision was made or an agreement was struck then summarise the conversation in an email and send it to them. This helps keep everything in perspective and avoids assumptions.
- Manage the communication between the project team and the client. In many software development projects, this phase lands the development team at client premises, where the client might start asking questions directly and before you realise it the development team has started making changes and accommodating client requests.
- Prevent gold plating of any kind. All the “nice to have” features rarely increase functionality and don’t do anyone any good.
- Instill the habit of sharing with teams. Ensure that they understand why the process is there (to safeguard the project) and what they need to do if the client has suggestions/ amendments.
- Don’t say “No” to the client at once. Exercise a limited number of No’s for the minor requests. Make use of the change request procedure/process and formally have the big change signed off. This ensures not just the quality of the deliverable but also clarifies the requirement for the client. There are too many instances where a change has been incorporated and no one remembers why it was done in the first place. Keep in mind that teams can change not just at your end but at the client end as well.
- Don’t think that a project control system will do all the work required. The system is only as good as its users and what is done with it.