A Ten Step Path to Developing a Successful Project

by S tuart Wier

Part 2 of Designing and Managing Successful Projects

1. Create a charter. Make a general statement of your goal -- what you want to accomplish -- as precisely and concisely as possible. Be clear who are your clients or who is your audience. The charter serves to clarify the goal for all participants. Don't use technical jargon or grand woolly phrases. Anyone at all should be able to read the charter and understand your intentions perfectly. Something like "this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth" will do for a multi-billion dollar project. Your goal does not have to be much more complex than that.

2. Draw up a list of all possible requirements, a compilation of all possible features and capabilities. Some may conflict with others, some may be unnecessary, some may be optional or even undesirable. That doesn't matter, include everything you can. Incredible to think, some managers suppose their work is done by handing off a list of requirements to the developers. Don't kid yourself, you haven't even begun yet.

3. Draw up a list of objectives -- the requirements you choose to achieve. Go through the requirements list and select the ones to achieve. Some items in the original requirements list will be modified or ignored. This is a activity involving everyone concerned, especially the clients. This is one of the hardest parts of some projects. It is not always possible to meet everyone's desires. You can't please all the people all the time.

The objectives list are the things to achieve. It must be as well defined as possible. If you must specify numerical criterion, keep them as few as possible, and open-ended -- things might work better than you expect. Do not specify small details. They will emerge in development and testing. The objectives, like the charter, should not change during the project, unless you make a fundamental change of course. The objectives, like the charter, should be precise and concise. A list of 25,000 specifications (yes there have been such projects) dooms any project to failure. Remember the United States stands on a Bill of Rights with 10 items. If an entire nation can get by with 10 items you can too.

Clients are essential for determining the objectives needed to make a successful project. Involve them from the start, and at every stage. Leaving out the clients will cause delays and frustration.

At this point write down your charter and objectives, so there is no disagreement later.

4. Stick with the charter and objectives as stated. If they are up for revision anytime someone changes their mind, you might as well quit. Design details, what people are most concerned about, may be changed as outlined below.

5. Come up with an initial design; a program of action, a plan to meet all the objectives or at least the ones you want to begin working on at first. Write down the design. Your initial design need not be perfect or complete; you will improve and extend it as you learn more through testing.

Realizing precisely what design elements you need to achieve the objectives is one of the most difficult and most important parts of most projects. Many projects spend a great deal of effort in finding what they need to do and how to do it. If the design details were clear and complete from the beginning most projects would be a great deal simpler. Unfortunately often there is no way to know those details in advance. Steps 5 through 10 are a controlled way to gradually find what should be done and to move that into the project.

6. Implement the design. No design changes during implementation! They come later.

7. Test the new system, during development, in operational use or in good simulations, to find out what you need to do, and to ensure that the solution you offer meets the goals. Do not skimp the testing! Do not fudge the testing to pretend the project is usable and complete. Face the music. Be prepared to give up cherished assumptions about how to meet the objectives. Note errors or non-functional parts to fix. Shine a spotlight on the ineffective parts. Look for improvements: let the users tell you how to improve the system.

The developers always want to tell the clients how things should work, but they can't see the forest for the trees. The developers have a lot to contribute, but they can't do everything, and they are not always right. Never use the developers to test the system, except to see what they did functions as intended. Only the clients can say if the project is providing what is needed.

Never adopt a component or idea merely because someone else says it will work, or because it sounds like a good idea that ought to work. You can't use new ideas or methods from other projects without verification and expect success. You never can tell if something will work until you try it.

8. Modify the design, adding in corrections and improvements. Re-use what you can, but throw out things that don't work or are no longer needed, no, no matter how much you worked on them or how much personal involvement some people have in them. Your goal is to succeed, not to provide a showplace for personal creativity or ivory-tower theories. Re-implement.

That's the way the creative process works. We learn more from our mistakes than from our successes. We stumble along in a partially-random, partially-directed walk from mistake to mistake until we finally get to something that looks reasonable. - Robert C. Martin

9. The Best is the Enemy of the Good. Efforts to create the best possible solution may fail to achieve anything at all, if time and other resources are not adequate for the job. The same resources might achieve a simpler result, one good enough to solve the problem. Since projects generally take more time and resources than expected, it is best to plan to do only what you are sure you can achieve without any doubt, and not stretch for an ideal goal. If you succeed, you may be allowed to improve things later. If you fail, you never will. And you will have lost time and opportunity, and done harm in all likelihood. Be wary of striving for the perfect ideal, if a simpler approach is satisfactory.

Strenuously resist "creeping featuritis," the tendency to add cute new ideas. Everyone will have a few. Strive hard to keep things as simple as possible. Complexity increases chance of problems, breakdown, failure, and poor performance.

Never change the design or objectives while you are implementing it. Only do so when re-designing after a round of testing. Never let the developers contrive features as they go along, beyond their design area of responsibility, other than implementation details.

Strenuously resist the "solid gold syndrome." Developers love to come up with the absolutely most modern, powerful system with all the latest ideas. Sometimes all you need to go to town is a bicycle, not a Rolls Royce. Keep the project as simple as possible, but no simpler. Meet the clients' needs, not what the managers or developers think should be the clients' needs, or a guess at future needs.

There is nothing really wrong with the gold-plated approach, but it takes longer to create, costs more, may be more difficult to use and maintain, and may not solve the problem better than a solution which is as simple as possible. Take your choice.

So that you remember these principles, keep repeating this saying inspired by Casey Stengel: Sometimes better is no good.

10. Repeat the entire process of re-design, re-implementation, and testing, until the the goals are met. Projects that are untested implementations of bright ideas, just assuming they are sure to work, as intended, right out of the box, are almost sure to be unsatisfactory.

Some might complain that this "reworking" could be avoided by a little forethought. However, forethought is seldom very accurate. For a large project it is not very likely that we could truly anticipate the final structure ... Look at it this way. The work we are doing on the early slices is the forethought. - Robert C. Martin

You may think it impossible to test the project before it is complete. There seems to be no way to try the thing out before it is all done, as in designing a new airplane. But in practically all cases we build on earlier similar experiences. The landing on the Moon was certainly a first, but it was preceded by four manned Apollo missions, one of which flew the lander to within a few thousand feet of the lunar surface. Practically all such notable "firsts" were preceded by many similar trials of slightly less complexity. The Wright Brothers were experienced aircraft designers and builders before they added a motor to an airplane, and experienced glider pilots before they tried powered flight. The invasion of Normandy was based on other amphibious landings planned by the same teams and using the same kinds of equipment. Lindbergh set a record flying his plane across the US before he crossed the Atlantic. This preparatory work is usually forgotten but is essential to success.

Send email to swier@earthlink.net.

Copyright © 2002 S tuart Wier. Retransmission or reproduction in any form prohibited without prior written consent of the author.

Initial version April 1997. This revision July 1, 2002.