The Unified Development Plan

Over the years, various schools of developers have standardized their approaches to planning. While many of these have very real strengths, there is a good deal of technical exclusivity that isn't always an advantage to anyone else. Generally speaking, each method helps the project for which it was originally designed. Many developers cherry pick their approaches, a bit of this, a bit of that, and a bit of their own. With the idea being that form follows function, the longer developers contemplate their project, the more likely it is that the most appropriate format will surface.

For large, sophisticated projects, there are a number of complex, tiered, established procedures (for example, Prince2). Unfortunately, they don't scale down well as they tend to be managerially top-heavy and abstruse. So it isn't surprising that project management sometimes mushrooms into a function that threatens to dwarf the program development itself. Small and medium-sized projects need an approach that doesn't take up too much time yet addresses all key issues. This is where a template called the Unified Development Plan (UDP) comes in handy.

The UDP is designed to be short, unambiguous, and understandable, a practical document into which marketing, research, technical specs, design, and financial inputs are all streamed. It is essentially a functional document that brings together managers, technicians, and anyone else involved in the project.

A UDP differs from similar documents in as much as everything is contained in a single coherent document much like a corporate manual. Every member of the development committee contributes to it, approves it, and signs up to support it. The initial advantage of a UDP is that every participant learns to appreciate his colleague's contributions. And because it's written in plain English, arguments have to stand up for themselves. There is no hiding behind gobbledygook.

Any member's partner should be able to spot a flaw and any financier of the project should immediately be able to appreciate the plan's real strengths. Group heads should be able to easily explain the plan to their team so programmers grasp the importance of their work to the end users.

Once things flow on functional lines, there is less need for paper checks and more time and resources to get on with the job. However, the UDP is not a static instrument. It is more like a policy log that develops with time. Each of its sections is updated and explained as modifications are agreed. One excuse you should never hear is, "X had no idea what was going on."

The sharing process is amazingly simple if you take the following steps:

1. Take the initial marketing specification and verify it.

2. Identify the main components.

3. Calculate the gamut of resources required.

4. Draft, circulate, and redraft the document until there is general agreement.

Assume the Widest Readership

You never know who will need to read your Unified Development Plan—a subcontractor who is being considered for his specialist skills; a financier wanting to fund you; a potential client or government agency checking your specs, or the board reviewing the projects. As well as having a grasp of broader issues, there are times when they need to be able to appreciate why certain trivial things are important. Remember, the more clearly you tell it, the more surely you'll sell it.

Working in Sit-down Groups

If you have ever had the privilege of watching a good chairman in action, you know they are a joy to watch. They understand the subject sublimely, and they make everyone at the meeting feel that their presence is welcome. They steer the discussion without any noticeable leverage and bring in relevant people who might have not piped up and courteously move the subject forward when the meeting is stuck in a rut. The agenda is well planned and can be followed to the letter, and the meeting ends at the planned time with everyone knowing what they have to do and feeling confident that their time has been well spent.

How do these people do it? They are obviously consummate professionals and they have probably had a lot of practice, but the most important thing is that they have a realistic idea of how to get where they are going. They try to coordinate the team so the whole is greater than the sum of its parts.

Gathering Opinions/Feedback by Committee

Don't think if you are small, you are unimportant and therefore you don't need to behave in formal ways. The important thing about formality is that it is businesslike. So take your cue from the successful and take yourself seriously.

A good committee will normally take a show of hands at every point on the agenda and then publish the meeting's decisions in subsequent minutes. However, what seemed a good idea on a spontaneous show of hands sometimes makes no sense later on, especially when participants from differing disciplines such as marketing and programming strive for fusion.

To avoid conflicts later when decisions are more carefully examined, I suggest a minor innovation. At the end of each team meeting, the chairman or minute taker reads out the collective decisions. Any potential conflict between hand-raisers and non-hand-raisers can then be aired and sorted out then and there. This reprise should not be used to rake over old ground, but it can bring to light the real reason a minority didn't raise their hands at some particular point and shed light that helps to clarify a quandary. It may also serve to clarify priorities going forward, where participants need approval or directives, what should be done first, or who needs to liaise with whom.

A Few Tips on Writing Plans

Plans are meant to be used by a variety of people. You can hardly write one plan for programmers and another for the lawyer and another for the people who will lend you money. You have to find a single way of communicating with them all, and that means using a vocabulary that everyone can understand. Research shows that keeping technical wording to a minimum increases the readers' ability to assimilate ideas. This even applies to technicians reading papers on their own specialty. The reason for this is very obvious. The average developer has had 20 or more years' head start using plain English before they begin to acquire technical dialects, like computerspeak.

To carry the largest number of people along with you, use technical phrases only when there is no common equivalent. When you have to use technical jargon, don't overload your sentences or you won't give the reader time to absorb what you are saying; you'll just smother them to a standstill.

Insincerity has a way of showing through. If you don't believe in what you are writing, stop and come straight out with what is really on your mind; you can always phrase it more tactfully on your second draft. Readers are more perceptive than you might think. When something troubles you, work out why and swap the word or phrase for some alternative. Discuss it with family or colleagues and then redraft it.

You are not trying to out-write War and Peace. The more succinct your sentences, the more effortlessly your document will be remembered and the less room there will be for ambiguity. The average sentence length is 11 words, and anything over 16 is in danger of becoming too complex. Remember, a well-written document is widely understandable, unambiguous, and inspiring.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment