Get Control! An Introduction to Process and Documentation Parts 1 - 5 - Connecting the Dots

Part 5 - Connecting the Dots

Now that we've had a look at the major points of documentation and process, let's walk through some essential best practices and practical tips to help make it work for you. Keep in mind that process systems for Web development need to be flexible, manageable, easy, and effective if they are to be worthwhile.

Despite what you'll read on so many Web development firms' Websites, there is no magic sequence of events that you should ideally follow. On the contrary, effective project management is the result of a series of wise selections from a variety of documentation and process techniques. The simple secret is to take the time to consider the project, the client, and the objectives, then, to make a great plan.

Try to explore the following issues and select the appropriate approach from the available process and documentation techniques:

1. How experienced is the client? How much documentation do they expect? Do they understand the benefits of process?


2. Which documents are mandatory and should be part of the original project plan, and which documents might be included if deemed necessary during the project?


3. Which documents need to be signed off by the client?


4. Who will be doing the collaboration for the client? What is their availability and skill level?


5. Should a large number of iterations be allowed, or should the project be more rigid?

In addition to some quality planning early on, it's important to understand how these elements relate to and enhance each other. With experience, you will soon learn that well executed process feeds upon itself, and that the effectiveness and return on time-investment increases as your process skills improve. Fortunately, it's not necessary to fully commit to a process system and execute accordingly -- there is incredible benefit to implementing the basic pillars of good project management as best practices, such as those that follow.

Signoffs Are Gold

Many people assume that the purpose of a sign-off is to prove that the client accepted something in the event of a legal dispute. The real benefit, however, comes from the effect a sign-off request has on a client's expectations and level of participation.

A client who is about to sign on a dotted line is much more likely to pay attention to the matter at hand. In addition, the client will know that the document is significant and is therefore more likely to understand that changes to the content following sign-off will be less welcome (or, better yet, billable).

This kind of understanding on the part of the client benefits everyone, improves client participation, and helps to manage expectations. Gain sign-off at every reasonable point in the project, and make the client used to signing-off documents from time to time.

Use Cases are Test Cases

Use cases and test cases are among the most frequently ignored requirement types, but are also two of the most useful. Be sure to consider writing use cases during the requirements rounds of your projects, and keep in mind that use cases have some additional benefits and flexibility you may not have realized.

Use cases are, for the most part, easily converted into test cases. In some cases, a use case can literally be used as a test case. This is a huge benefit when testing comes around, because test cases provide a framework for the testing and verification of functionality.

Developers and project managers are notoriously poor at testing their own code, and there's no easy way to have an ordinary 'user' test your application comprehensively. By repurposing your use cases into test cases, you'll have a simple list of activities in an easy to understand format that you can provide to your testers. They simply follow the sequence of events in the use/test case and note the results.

Requirements are Acceptance Criteria

When writing requirements, always keep in mind that the requirements can (and should) be used as 'acceptance criteria' at the end of the project. This means that a clear definition of the end of the project will be established, reducing the possibility for the 'endless project' in which details that hadn't been considered stretch on for months with no clear picture of whether they were part of the original bid.

This mentality is also helpful when writing requirements, because it forces the author to think about the requirements as 'things the application won't do,' in addition to 'things the application must do.'

In other words, when you write requirements with acceptance criteria in mind, you are more likely to predict and document possible conflicts and write the requirements with those in mind. Technical requirements related to deployment, installation, or migration, such as 'The application will be delivered to the client on CD and all installation and configuration will be performed by client,' are helpful to clarify the migration and finalization of the engagement, reducing confusion.

Change Orders

Perhaps the single most significant benefit of a well documented and organized project, the change order is important because it impacts directly upon your bottom line.

Simply put, a well-run project is a breeding ground for successful projects, happy clients, easy change orders, and other essential elements of a successful Web development business.

When a client requests an alteration, expansion, or enhancement to a project mid-stream, your ability to get a fair value for your increased effort is directly tied to two things:

1. The expectations, level of understanding, and attitude of the client


2. The clarity and completeness of your documentation

A volume of coherent, complete, and signed-off documentation usually achieves both. Having read and signed multiple documents, the client's expectations have already been adjusted enough so that they realize the requested change is 'not in the specs' and will require discussion. Once the issue is raised, there is little debate that the request is new and it will be much easier to get the client to pay for it.

Writing the change order is now an easy task, too. Simply make the requested additions to the original requirements document, and have the client sign it again in connection with a new agreement stating that the requirements have changed, the project value has changed, and perhaps the payment terms have altered, too.

Conclusion

Whether you leap full-force into a complete documentation and process system, or simply improve your basic practices to move towards a more effective workflow, there is undoubtedly some benefit to be had by improving your documentation skills.

The benefits of good process will become self-evident once you get through the initial learning curve, and your business will become more successful as a result. At the very least, you might sleep better at night knowing that you are well prepared for any project contingency or conflict.

Good luck, and remember that the best process systems are always being improved, modified, and customized to better fit business needs.