Some More Good Practices to Help Ensure Success

by S tuart Wier

Part 3 of Designing and Managing Successful Projects

• Project managers must establish clearly the reason why the project is being done. It may sound obvious, but when things go wrong it's often because different people had different ideas about the purpose of the project. Make sure you have a real goal, or there's a a problem to solve, before you start a project. Make sure the proposed solution actually is targeted at the problem, and is efficient, rather than being a bright idea or a poorly thought-through gimmick that really will not help much.

• Risk management is essential. If you don't manage your risks, the rest of the work may be a complete waste of time. To learn risk management see Risk Management and Risk in decision making by David W Farthing.

• Keep your fingers on the pulse of the project. Progress monitoring is of prime importance. You should have ways to measure and verify that progress is being made. Real progress should be made every week, or every month at the outside. Monitoring for progress every quarter is far too infrequent. If you are not progressing in six months, if your project has been renamed three times since it started, years ago, and it's not yet in real use, it's time for another job.

  The only way to truly control a project is to continuously measure its progress, compare that progress against the plan, and then adjust the development parameters to correct any deviation from the plan. - Robert C. Martin

• In software projects "code management" can take on a dominant position. Progress monitoring is more important. You can have damn fine code management and be going nowhere. Code management makes it look like you are doing something but maybe you are stuck. Make sure the code management system suits the kind of development you are doing. Creative development and line-by-line revision control cannot both take place at once. You can't dance in tar.

• As projects become more complex, and as the number of clients increases, any change is apt to have unforeseen effects. Think through all consequences of changes before any steps are taken. Test changes before use - testing will reveal most unforeseen side-effects.

• Project managers must give clear instructions to the staff about what is to be done. This seems very obvious but is sometimes forgotten. Telling the staff in April the deadline will be sometime between May 15 and June 4, and then saying nothing until June 1 when you announce the deadline is June 4, and then on June 22 stating the deadline is really July 7 will produce confusion and resentment. It also helps to announce before hand clearly what is expected, rather than sending testy notes later to persons who never heard what was wanted, asking for corrections, after the deadline. That is mediocre management. The managers talk together and know what is needed in detail, but fail to inform the staff in remote cities.

• Use good people, the top ones if you can. Cheese-paring economy on staff dooms the project to delays and poor results. One very good person is worth far more than two mediocre ones that cost less. You can't dispense with good staff. The men who invented the telephone, radio, polio vaccine, X-ray photography, television, the light bulb, and the jet engine could all sit around your dinner table. Hope you get someone like that on your staff. Bad management almost guarantees failure; good managers make a successful project possible, but only good staff can make it happen.

• Use people who know the subject. Trust your professional help. Experience and detailed knowledge of the problem is essential. Use it appropriately. Don't ask English teachers to design the science curriculum. Don't laugh -- it's been tried.

• Keep the staff small and of high quality. For example, coins designed by committee can be disappointing. Have you seen a "Susan B. Anthony" dollar lately? Coins designed by one capable artist, such as the 1907 Augustus St. Gaudens $20 piece, are treasured in museums. Just as an idea, cut the size of the staff you expect to use by two, pay higher salaries for better workers, and double the time you think is needed to do the job. The results will be far superior to what you would get otherwise, and be ready in less time than otherwise.

• Cherish your good workers and encourage them with significant incentives (1). Good, experienced workers are more important to a successful project than machines are to an assembly line. Do not treat your workers like interchangeable commodities if you want anything better than mediocrity. Do not expect that because you love the project so much you would pay to work on it that your workers can afford that point of view. They may have families to feed and tuition bills to pay. Do not expect them to keep working with little recognition and without significant reward. Little bronze plaques and pizza are for Cub Scouts who win knot-tying contests. Real companies give real rewards. Make the work itself rewarding, not drudgery. Listen to morale. Tie rewards to the success of the company or project. If you treat your workers as an annoyance, or do as little as legally possible for them, your project will be as dead as a magazine that disregards the interests of the subscribers. Understand what your workers want, not what you think they should be happy with. Kill morale and you kill all chance of success. Give your workers reasons to want to do their best, rather than reason to daydream about a better life. Just because you pay a salary does not mean you command devotion.

• Persons who have power, prestige, and seniority may run the show, or appear to run the show, so long as they don't mess things up by interfering. But if they know what they are doing, those who know about the subject make the design decisions. If the managers do have real experience in the project area, that may help. However - managers who are too focused on technical matters, who have too much fun personally fiddling with the details, can get a project way behind the goal. They keep re-inventing slightly better solutions to problems already solved, while missing the big picture and letting opportunities pass by. There are managers who know little about technical details, but who know what the client wants, and who know what can be done, and who know how to get the staff to do it, and who are very successful.

• Give each staff member an area of responsibility and let them handle it. Advise, but do not override their decisions unless the results are unsatisfactory.

• Avoid single points of failure. The road to success must not include a single unavoidable bottleneck. Have options and several ways to get to the goal. A new airport depends on subways below the runways to move passengers between the "terminal" (check-in and baggage claim) and the "gates." If the electricity fails, or the computer fails, or a single train part fails in the wrong spot, the entire airport shuts down. Departing passengers cannot get to planes, and arriving passengers cannot pick up baggage or even leave the airport. Having pedestrian walkways parallel to the subways would ensure continuing operation in place of disrupted airline flights all over the U.S. due to a jammed door in a subway car.

• One of the ugliest parts of managing a project is meeting a deadline. This monster will eat you up if you are do not conquer it first. The first step is to be blindingly honest and realistic about your abilities from the very beginning. Do not let egotism or enthusiasm be in control. A manager that tells all potential clients that his team can solve their problems in "about six months," when he knows he can only solve one of many such problems in six months, is heading for trouble.

• Build into your schedule from the beginning a period for testing and revision after implementation is complete, before the final deadline, and stick to it. You need to have time to consider the quality of what you are delivering, and time to fix problems. Do not allow development up to the deadline. There is a tremendous inclination on the part of the "professional promisers" to keep adding new features right up to the end. This allows the monster in the door. You must find a way to stop development and do testing before the deadline. Your clients are not the testing department.

• When a deadline problem is looming, there are only two solutions. One is extending the deadline, if that is possible. The other is to reduce the features of the project due at the deadline, a reduction arrived at by negotiation with the clients. Like creditors, clients would rather have something of value on time, even if not the whole amount, than nothing or something that amounts to nothing. (Don't think you can solve a deadline problem by asking workers to work harder. If morale is good and your workers are good they have not been idling; if they aren't any good telling them to work harder won't help anyway.)

• There is no formula to insure success. Many have been proposed; if one that really works comes along it will be adopted fast and you will soon hear about it. Good judgment is required, as in all things, and that cannot be reduced to any method or process. Successful leaders lead successful projects. They create new workable solutions to the issues they confront. Persons who lack good judgment, no matter why they stay in power or what others think of them, never run a project that is successful in real operations. Look at your managers and list what successful operational solutions they have led. It is surprising how little some managers have to their credit. Don't rely on one of them to solve your problem!

  Success or failure turned time and again on the elusive factor of personality. - David McCullough, on the Panama Canal

• Recognize that any new system, no matter how successful, will not be entirely free of gripes. Some undesirable effects are unavoidable; that is the nature of solutions in the real world. Something is going to be less appealing than the old way. Hopefully the overall result is a net gain!

• Treat your people with respect, and earn theirs.

The iterative prototyping approach may appear to delay completion. In fact, this entire process may shorten development time, improves quality and ease of use, and helps ensure success.

• clear objectives

• clear plans with milestones

• a good team

• risk management

• quality controls

• progress monitoring

  from David Farthing, University of Glamorgan, U.K.

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.