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

Part 3 - Choosing a Balanced Approach

A Web development project is like a chess game: you have to plan every move to win, but you also need to be able to change the plan at any time. The only way to win is to understand all the options and apply best practice at every step.

In this section, we'll look at the fundamental elements of various process systems, and learn how you can choose the best approach when planning your development projects.

Maintaining Flexibility and Optimal Speed

Flexibility and speed are essential factors in any project. However, keep in mind that these are not the only goals -- a process that's too flexible might lead to a never-ending project in which the plan continues to evolve, preventing you from reaching release. Some clients benefit from a rigid process; others can handle a more flexible and progressive system.

The winning approach is to make a conscious determination regarding the level of flexibility that's appropriate to your client. If the client's operations, or their dealings with you, are typically prone to unexpected changes and scope-creep, and you wish to maintain a tight grip on the project, you should attempt to make a very comprehensive document trail. Create a series of signoffs at critical decision points, and agree up-front on a specified limit to the number of iterations you'll allow during development.

Conversely, if you have a trusted client who pays his bills, understands that a change order will impact the project budget and schedule, and participates well in process-driven management, you might take a totally different approach. A good client should be invited to participate in the review of many application iterations and is usually capable of making decisions without being 'locked-down' by a sea of documentation.

For each client, there is an ideal combination of project management elements, such as leadership, documentation, sign-offs milestones, and progress reports. Never begin a project without considering your client's perspective, history, and business interests, so that you can formulate the ideal plan for success.

Making it Easy

It's easier said than done! 'Make it easy for the client' is a lesson that teaches itself, as we try to work with clients using a process that is too daunting, boring, or complex for them. Clients come from all walks of life, and many may never have been through a Web development process before. Others might be disinterested, intimidated, or may trivialize the process with a 'just get it done' attitude.

Clients can always be educated -- they can learn to see the value in formal process and documentation -- but remember that they're the ones who pay the bills. They should be accommodated to the extent possible without compromising the project's success.

Typically, if you're having trouble getting a client to participate in your process, the process may be too hard for them, or they might not like it. In this case, switch gears and use this new information about your client to establish a creative solution in which their meeting, communication, or work style can be accommodated so that they can contribute positively to the project.

Iterations, Iterations, Iterations

Whenever I see a project plan that includes a long period of development followed by a launch, I get nervous. I've learned the hard way that, whether you like it or not, you are probably going to release multiple iterations of your application. After all, most launch dates consist of a few scrambled versions of the application, then a couple of fixes here and there during the early days. Documents, too, tend to get passed around several times before someone finally signs on the dotted line.

Hassle? No way. Iterations are a part of life, and they're a great way to enhance a Web development project. Use them to your advantage.

Let's say you're leading a 6-month project in which months 2, 3, and 4 are dedicated to development, with a final release at the beginning of month 6. How many releases would you ideally like to see in addition to the final release? Personally, I'd hope to see some kind of a beta after month 2, and 2 to 5 releases during months 3, 4, and 5.

There simply is no substitute for looking at a half-complete application on-screen and trying to decide if everything is going in the right direction. The iterative approach allows everyone, from client to developer, to be involved in the project from its inception, and lends a "step-by-step" feeling to the engagement, rather than the all-too-typical 'big push'. Iterations also bring more visibility to the project, as everyone can see where the project is at all times.

Although it's not always possible to plan the number of release iterations in a project plan, it's extremely wise to include a significant period of 'iterative development' during the build phase of a project. This gives the developers an opportunity to complete small releases, gain experience with the application migration and client feedback processes, and stay on track. Iterative development is an established, proven technique and is critical to most popular development methodologies today.

Email Is Your Best Friend

Wouldn't you love to have an employee who would do nothing but record every single word of your business communications 24 hours a day? Your email client and inbox are ready to handle the task.

The easiest kind of documentation is 'passive documentation' in which you simply capture the ordinary project communications and keep them handy for future reference. When you focus on using email communications for all-important correspondence, you are already creating a useful 'paper trail' for your projects without even trying.

If you can organize your inbox and are a decent typist, you have everything you need to ensure that you always have complete documentation of an entire project should there be any later misunderstandings, confusion, or legal issues. Always try to use email whenever possible (and appropriate), and keep a well-structured and clearly-organized inbox in which you can easily find anything you need -- this will help you avoid situations in which you make a decision on the telephone, then realize you need to discuss a detail without remembering the exact original agreement.

There are many ways to maximize the effectiveness of your email archives:

1. Write every email as if it might, one day, be read by a judge in a court case. Avoid being overly informal, and be sure that your communications are clear.


2. Don't allow long email threads to turn into a single long, scrolling email -- this only makes for more confusing in the future. Be sure that each email stays on a single topic, and if the topic changes, be sure to delete the existing thread before you send your response. If you have 2 ideas in a single email, consider splitting them up.


3. Use the subject line well. This is probably the simplest and most powerful tip in the list. A well written subject line makes the reader more comfortable, sets the tone for the email, and makes it easy to find and refer to in the future. Good subjects simply summarize the email, like 'response to change order from 1/3/03' or 'options for merchant accounts'. Avoid meaningless, casual or irrelevant subjects such as 'ok' or 'one more time' or 'moving forward', etc.

Signoffs and Versioning

Signoffs serve everyone. Many vendors see client sign-offs as something that should come at the end of the project. While there should certainly be a signed 'acceptance document' to indicate the end of the engagement, it's hard to agree on where that end may be if there were no signed-off project plans at the beginning!

Signoffs allow everyone in the project to understand when a critical milestone or document is being approved. It shows clients that you are organized and are taking their input seriously, and helps them to differentiate between making final decisions, and just providing opinions.

Signoffs also have a serious impact in the courtroom, or any legal proceedings. Although a signed document can still be disputed, it's expected that someone who signed a document has taken the time to read and understand that document. This allows you to be extremely clear about how the project decisions were made, who made them, and who assumed responsibility for what, when.

If nothing else, a project should always include signoff at the following points, no matter how small the project is:

1. The Contract


2. Project Specifications (can be a single document, or many)


3. Schedule/Workflow/Milestones


4. Acceptance (project completion)

Just One Person in Charge

It's exceedingly hard to manage a project 'by committee'.

Group leadership efforts usually result in a long, ineffective project flow and a poor result. Most organizations are not capable of managing a project as a group, and will gravitate towards a leader-and-process solution if one is offered. As the developer, it's your responsibility to assume this role and maintain control of all aspects of the project from beginning to end. It's very rare that a client has the ability or know-how to effectively manage a technology vendor, and those who try are usually doing it simply to keep control, or because they've been burned by a previous vendor.

Good documentation practices offer a solution for this dynamic, because the owner of each document is the only person who can determine how the document is structured, what's in it, and when the document is final and ready be signed. Thus, the owner of the document (or whoever is in control of it) is likely to be perceived as the leader of the project, or at least the person most knowledgeable about the details.

Another means of establishing control over an engagement is to arrive at all meetings (including phone calls) with a well-written and printed agenda to establish the meeting's objective, participants, and major points. Following the meeting, a meeting report can be emailed to all participants to sum up the conclusions and 'action items' that resulted from the meeting.

Ultimately, the best way to be the single point of control in a project is to demonstrate that you know what you're doing, that you have a process in place, and that you are the best person to lead the project. If everyone wants the project to succeed, they will frequently defer to the most promising leader. You can position yourself as that person by coming in to the project with a strong leadership attitude, and a clear idea of the steps ahead.