Project Documentation | By David Carr | Read time minutes
Project management is a necessary service to be provided for all but the smallest project. What is the service that is being provided though? Is it a customer services role or an exercise in paper production?
The curse of the inexperienced project manager is that he or she believes that his or her goal is to bombard the customer and the project team with mountains of paperwork equivalent to a small rain forest. Sometimes the reasoning is that if you pass enough paper and/or emails around, nobody will read them. Often it is the case that every agreement, action or discussion produces yet another correspondence that goes unread until the **** hits the fan and everyone starts examining the project file looking for the get-out clause of an email that gives the message "I told you so."
This is not what project management should be. Project management can be thought of as part of your customer services team. In fact, nobody will ever get closer to your customer and their business than during a project. If your project manager can give up the pen and email, they can become a communication conduit between you and your customers rather than a bureaucratic blockage. Once this is understood and grasped the project manager can speak with the customer as often as possible and with the team only when necessary allowing the developers to keep developing and maintaining the customer relationship.
Of course project management does require the production of some paperwork and this does include some information that can be used for protection when there is a problem. We must not forget that there is always the risk of failure and the potential for things to end in the courtroom. So what are the key documents for the customer-services version of the project manager?
Project Plan
This is the most important document that a project manager should create and maintain through the life of the project. It contains the dates of all appointments, consultancy sessions, development work etc. It should be used to allow the project manager to understand when the project is on track and when there have been slippages. It should also plan for the delivery of products necessary to the project.
Goal Log
I find it amazing how many projects I have worked on that had no defined goals. A goal is not, "develop the new sales order processing system." This may well be the deliverable of the project but it conveys no information to the development team. A goal such as, "allow the automated processing of web orders" or better still "allow the automated processing of 20,000 orders per day" relays a message to the team. Visibility of these goals helps in design and decision making. They allow the team to understand the problems they are trying to solve. They provide an insight into the customer's business. They allow visibility of goals achieved during a project. In short they are essential.
Risk Log
It is important that everyone is aware of the risks inherent in a project. These may be as simple as, "the customer may not have appropriate hardware" to "the project may slip and miss the deadline." The risk log should be created as a single document with the risk, the agreed actions and the impact if the problem occurs. Everyone should be aware of this document and it should be maintained constantly. One line per risk should be suitable; a new document per risk is generally overkill.
Issue Log
Much like the risk log, an issue log should be maintained by the project manager. This is again a simple list of issues raised during the project with their intended resolution. These issues should be visible to all, and everyone should be given the opportunity to add new items.
Action Log / Agreement Log
Many project managers love to minute meetings, both internal and customer, producing huge sets of minutes detailing every word said, the quality of the coffee and the availability of jam doughnuts. This is understandable to some degree but again is a bureaucratic nightmare for everybody involved. The team members and the customer either ignore the minutes completely or spend valuable hours reading every detail, knowing the risk that something that is missed, badly worded or preferable not to be included could come back to haunt them. This becomes more difficult the longer the project lasts as reference to previous minutes is required to ensure that no two agreements contradict each other that could lead to a future argument about who said what.
By creating a log of actions and agreements rather than separate sets of minutes, the project manager can have a single reference point for these items. During project meetings these can be reviewed and contradictions highlighted. An action log is also a great place to identify who has completed their actions, what remains outstanding and how this creates risks to the project.
These six documents are those I use to maintain a project and I find that it works very well and minimises the time expended on paperwork without losing any of the quality of the project management. Indeed, I find I have much more time available for actually talking to the customer, understanding their concerns, identifying successes and improving the customer services offering of my company.
This article was reproduced with the prior permission of David Carr a Software Development Manager responsible for team management, project management and software development using Microsoft technologies.