Put And Get It In Writing
Whether you’re a one person company, or large corporation, solid project documentation is good insurance. It provides a blueprint for the work to be done, serves as a valuable reference during the project’s lifecycle and is tangible evidence that communication has occurred.
There are several important pieces of information that should be part of any project’s documentation. On larger projects each may be its own document, or on smaller ones they may be combined into a few key documents.
The Proposal
This is probably the first thing a prospect or client reads. It’s the first written impression one makes and should set the tone of how one’s business is conducted. Often the proposal is a response to an RFP, or a meeting where a project was discussed and the work is not yet sold.
This is the time to communicate your company’s background, experience, and philosophy – the boilerplate stuff. It’s also the chance to envision how your company understands the project and perceives how the project is to proceed. Chances are there is not enough detailed information at this point to truly understand the entire project, or offer a final solution, but it can showcase creativity, intelligence and experience.
It is also not likely that a firm price can be quoted at this time. More requirements are almost always needed. An estimate with a price range is the best way to position costs. The cost estimate can be ballpark, plus or minus 25%.
Letter of Agreement, Contract
When the project is agreed to by the buyer and seller, it’s time to finalize that agreement with a binding document. A Letter of Agreement and Contract are two common terms used. This document should provide a project overview, terms and conditions of the relationship, any legal stipulations, and any high-level project parameters available at that time. It should also say whether any further documentation is being created at a later date that will be binding and part of the agreement. This document should require signatures by principal stakeholders from the buyer and seller.
Preliminary Scope, Statement of Work, Charter
The Preliminary Scope, Statement of Work and Charter are the second time the project is described if a proposal was written. There should be more information available since the work has been sold and the client has had a chance for more thought and discussion.
Content in this document should include everything known about the project:
- Description of services and/or products provided
- Business reasons for the project
- Benefits
- Constraints
- Risks
- Assumptions
- Success factors
- Stakeholders
- Sponsor
- Deliverables
- Cost estimate
- Timeline
On smaller projects there may be enough detail in this document to successfully describe the project, but larger projects require a discovery period to learn more, make conclusions and offer valid solutions.
Cost Estimate and Payment Terms
It’s a good practice to provide cost estimates with a range in the beginning and as the project gets defined better the estimate can be adjusted for accuracy. Plus or minus 25% is a good initial range with a final range being plus or minus 5%.
There are several acceptable ways to structure your cost. Here are a two common ones used in web development:
- Fixed fee – buyer and seller agree on a fixed price. This is good for the buyer; they know what they are going to pay up front. The risk is placed on the seller to complete the project within the budget.
- Time and material – Buyer pays an hourly rate for services plus the expense for any hard costs. This is good for the seller. They get paid for the time spent on the project. The buyer has the risk of exceeding the budget since it is difficult to calculate the cost at completion during the project’s lifecycle.
There are any number of ways compensation can be structured: half up front and half upon completion, thirds, all upon delivery, weekly, monthly and deferred payment. It depends on the nature of the cost structure. Use the compensation structure as a negotiation tool. A better overall price for a project may be attainable if the payment structure is favorable to the buyer. If the seller has cash flow issues they may get the needed money earlier in the project if the overall price is discounted.
Detailed Scope Statement
The scope statement could be the third attempted at describing the project fully and is the project blueprint. It is usually drafted after a discovery period when more information is available and needs to be as detailed as possible. When a scope dispute arises between the buyer and seller and the issue is not detailed in the scope statement the buyer usually wins.
Process
Describe the entire project lifecycle process to be used on this project, not the boilerplate version in the proposal.
Deliverables
List exactly what the deliverables are and include how many of what. Usage and ownership rights should be detailed too.
Parameters
Parameters are part of the requirements gathered from the client. They create the “box” in which the project resides. They can be technical and creative, dependencies, constants, guidelines and anything else that defines dos and don’ts.
Assumptions
Assumptions are often overlooked and can be a gray area if not noted. It’s easy to assume common things.
Examples:
- Access to resources – “access to servers”
- Extra expenses that may be incurred – “stock photos not included in cost”
- Responsibilities to handling related issues – “data is delivered in a spreadsheet”
Constraints
Constraints are things that are limitations to progress.
Examples:
- Time – “client may have difficulty getting timely approval on design”
- Financial – “funding may not be available for phase two”
- Technical – “network support not available”
Risks
Sellers often do not want to bring up risks, but it is wise to make clients aware of consequences that could occur if certain events happen. This is part of client education and expectation control. Making the client aware of risks also goes a long way to building a healthy level of trust. Detailing risks also helps justify certain expenses and processes required for the project that may not be apparent to the client initially.
Acceptance
It’s important to define what is to be considered an acceptable deliverable, or when the project is considered completed. Without this a project’s scope can creep when the client does not think all the requirements have been met. When defining acceptance refer to the quality and quantity of the deliverables and how acceptance is communicated.
Timeline
Often a timeline is created and the only person that pays attention to it is the person that created it. It is important to keep a project moving and to know when resources are required and a timeline is the best tool for accomplishing this. All parties should be accountable for adherence to the timeline and it should be approved along with the scope. Make sure the timeline has milestones denoted as well as responsibilities required at these important checkpoints.
Project Closure Agreement
Closure is as important as initiation. Formal acceptance is required from the buyer to this point. A Closure Agreement can be as simple as a payment in full, but better yet a document that states the project is ending and why: the requirements have been met and deliverables accepted, failure to deliver acceptable work, or buyer is terminating the project because of issues on their end.
If there is going to be subsequent work involved with the client, project closure provides a distinct division of services and can help when communicating what was covered in the completed project and what is new work to be done.
Conclusion
As a project progresses more information becomes available and requirements may change for a variety of reasons. It is certainly acceptable to revise and update any document that is no longer valid. It is nearly impossible to have perfect documentation right from the start, especially on larger projects. There should be a process in place for making and approving these changes. This change control process could be outlined in the Scope Statement just as scope control would be.
There is much more to project documentation than what is touched upon here, but hopefully the importance of proper paper work is obvious. The cost to document a project properly is nothing compared to the cost of confusion and arbitration when things get ugly and the client relationship turns south. It is protection for all parties and is indicative of handling business in a professional, competent fashion. Project Management
|