A Ten Step Path to Developing a Successful Project
Part 2 of
Designing and Managing Successful Projects
by St uart Wier
A Ten Step Path to Developing a Successful Project
Part 2 of
Designing and Managing Successful Projects
by St uart Wier
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.
Sme managers suppose their work is done by handing off a list of requirements to the developers. Don't kid yourself, you've just begun.
3. Draw up a workable list of provisional final requirements -- 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 requirements are the things to achieve. This selection must be as well defined. 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 requirements, like the charter, should not change during the project, unless you make a fundamental change of course. The requirements, 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 services or features 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 requirements, so there is no disagreement later.
4. Stick with the charter and requirements 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 requirements 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, with actual users, 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 often want to tell the clients how things should work, but you cannot rely on the developers always knowing what the users want and need. Developers often want to use the newest cool thing, which may hinder or block success. Use developers to test the system, to see what they did functions as intended. Only the clients can say if the project is providing what is needed. The clients may need your help to figure out what they really want, and to learn what is possible and what is not feasible, but they must be involved if a successful outcome is desired.
Never adopt a new 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 without verification, and expect success. You never can tell if something will work until you try it. Often managers have bright new ideas to try. That's OK, but don't accept them without testing with the users. You can kill a project with a few cool new ideas.
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.
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.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
Keep repeating the Wier-Berra Principle: 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 success builds on earlier similar experiences.
Great achievements are preceded by trials. 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. 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 previous large 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 by the public but is essential to success.
Send email
Copyright © 1997, 2002, 2011 S. K. Wier.
Retransmission, reuse or reproduction in any form prohibited without prior written consent of the author.Initial version April 1997. This revision April 3, 2011.