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

Visit the average Web development firm's site and you're sure to find a section devoted to 'Our Process' or 'Our Approach', which usually consists of a simple diagram showing the relationship between 3 or 4 'easy steps to success'. Some Web companies try to make their processes seem a bit more catchy by making all the steps start with the same letter -- 'Define, Develop, Deliver' -- or by creating a friendly acronym.

This approach may look attractive to potential clients, but beneath the word play, the vast majority of small, medium, and boutique Web developers have no true process to speak of. Managing Web projects is almost always a challenging and unpredictable exercise. Still, the majority of Web design and development firms rely on a haphazard trail of email and word documents to manage their projects.

This series is for developers who wish to enhance their service offerings, professionalism, and revenue capacity by incorporating industry-proven approaches to their development process.

Through this series, we'll explore the realities of documenting and managing projects for the Web, compare some typical approaches and process systems, and learn how to apply them to maximize their value to both you and your clients. We'll also look at some concepts that should help to convince you that the time and energy you invest in process, documentation, and best practices, is the absolute best investment you can make to ensure your clients satisfaction and your own profit.

Here's what we'll discuss in each part of this series:

1. Documentation Techniques for Web Developers (starts below)


2. Common Processes for Web and Software Development


3. A Balanced Approach to Process Planning


4. Writing Specifications that Work


5. Connecting the Dots -- Real World Implementation

Part 1 – Documentation Techniques for Web Developers

If you produce $1000, brochure-ware sites for a living, you don't handle multiple projects simultaneously, and you have only cooperative, friendly clients, you might not need any of this information. There are plenty of independent contractors who successfully deliver projects using little or no documentation or methodology, but these individuals are few and far between.

Many developers choose to 'wing' their way through project after project and are skeptical about the value of process systems. The majority of Web developers and designers, however, hope to grow their business, improve their client retention and product quality, and make more money.

If you fall into the latter group, read on as we explore the possibilities and benefits of process and documentation.

Why Document? A Leap of Faith

Having faith in the value of great documentation is usually the result of doing it the 'hard way' for too long. Poor documentation is very, very expensive, and this becomes painfully evident once you learn to connect the impact of poor documentation to your bottom line.

It's always obvious who 'believes' and who just talks the talk. Vendors who insist on using real process are usually doing it for themselves, not for their clients. They want to save time and money. They want to improve profitability and maximize client retention by doing quality work. The best way to do quality work is to implement a process that allows both the client and the vendor to have clear communications, a shared role in the project, well-defined goals, and the flexibility to handle problems.

Good process and documentation practices help to achieve this in the following ways:

1. Good requirements and specifications ensure that a project maintains adequate profit margins by 'locking-down' the project scope, thereby avoiding costly changes due to ambiguities or gaps in the project plan.
2. A good paper trail combined with mandatory client sign-offs encourages clients to read and understand the specifics of the project, or, at the very least, to sign off the documentation and take responsibility for what was agreed upon.
3. The document trail establishes and enforces consistent nomenclature, providing a framework for reference that is specific to the project by assigning names to each page, data type, or other structure. This makes it easier to communicate ideas, changes, bugs, or other issues as the project progresses.
4. Great documentation protects both parties in the event of legal dispute. In court, there is simply no substitute for a comprehensive paper trail.
5. Early documentation phases reduce risk by illuminating risk areas, elements that require further discussion, ill-defined functionality, or other miscommunications early in the project, before development begins.
6. A well-documented project is less stressful and more fun for everyone involved, reducing employee turnover and burnout. Developers will always have a higher degree of satisfaction with their work when it's right the first time, and doesn't need to be 'redone' repeatedly during the project.



7. Well-written documents from one project can be easily repurposed for later projects with similar scope, allowing the documentation and process to become easier for everyone over time.
8. As your business grows, you'll want to win bigger jobs from more mature, legitimate, and established clients. These larger clients will be much more familiar with process systems, and will expect to see well executed development process from day one. A mature client can spot a bogus process right away.

Paying It Forward

The reason so many Web developers forgo the above benefits in favor of the 'cowboy style' process (i.e. no process at all) is simple: they just don't have faith that the benefits of a documentation phase will outweigh the impact to their schedule and budget, and they can't see fit to embark on a long documentation phase of seemingly little value.

They may believe in the value of process and documentation in concept, but to actually sit down and spend 12 hours writing specifications requires more than a conceptual agreement with the idea of documentation.

Unfortunately, a short-sighted approach usually results in an expensive development phase, a less satisfied client, and can even cause the dreaded 90-10 dynamic. The 90-10 dynamic refers to the late stages of many projects in which 90% of the effort goes into the final 10% of the project, usually as a result of 'surprise' requirements, misunderstandings, and general confusion regarding the work to be performed. After all, if you don't have a well-written roadmap for the project, you really don't know when the project is over!

Many Web professionals learn the hard (and expensive) way that a well-documented project is more profitable, and for that reason alone will begin investing time in process. Once the mental decision is made to use real process on your project, things slowly get better and better, and the idea of spending time writing specifications suddenly seems like a good one. Ultimately, you'll also need to get your client involved if you want to maximize the benefits of a process-oriented work style, and this can be trickier then it sounds.

Convincing the Client

Occasionally, clients will resist or even refuse to take part in your recommended process. This is sometimes the result of the clients having an 'I pay you and you get it done, so what do you need me for?' attitude, and sometimes the result of their being intimidated or overwhelmed by your process. Unfortunately, this attitude is contradictory to best practices and some gentle persuasion might help to get the clients seeing things your way.

There are two rules to remember when you are frustrated with a client who refuses to participate in your development process:

1. Even if the client doesn't participate at all, it is still very much in your best interest (and your wallet's best interest) to continue on with your process full-force. The results are best when the client is 100% committed to the process, but it's still a worthwhile even if the client doesn't take the documentation seriously.
2. Tie the process to the client's satisfaction level from day one. Make it clear to the client that his or her participation in your process is critical to the success of the project, and that you are prepared to provide assistance, or explain the purpose of any aspect of the process at any time. Most clients will gravitate towards a process if they believe they will get a better product as a result.

Conclusion

Making the leap of faith to embrace the concepts of process and documentation may not be easy, but it's certainly worthwhile.

Not only does it protect the interests of all parties, documentation can also save your business money (across the short and longer term), help you gain client buy-in and co-operation for the project's duration, and allow you to implement best practices and take you business's professionalism to a new level.

In short, the decision to embrace project documentation is the first step to better business.

Next, it's time to talk processes. We'll dissect a few of the more common processes in place in the Web development and software industries, and see exactly what we can learn from them -- and how they apply to our own operations.