Business executives who sponsor system development projects need a way to assess them as they move through the define, design and build sequence. This checklist can be used to assess any IT development project, and it will reveal quite clearly whether things are going well.

GOODNESS OF SYSTEM DESIGN
In the first two to six weeks of the project — the define phase — ask yourself and the system builder in charge of the project the following questions:

What is the business goal of the project?
In two sentences or less, state the action the company is going to take and the desired result of that action. This is the goal. It is the target, the destination the project is supposed to reach. Figure out what it is, or stop the project.

Which performance criteria is the system supposed to meet?
State requirements the system will meet in four areas:

Business operations

Customer expectations

Financial performance

Company learning and improvement

These are the specific measures that will determine whether the system will be a success. Make sure that you and the people designing and building the system know what they are.

Do you believe that a system that meets the preceding performance requirements will accomplish the business goal you are striving for?
If you have a feeling that important performance requirements have been left out, add them before the project gets any further along, but make sure that you add only requirements that are strictly necessary to accomplish the business goal. Requirements that are too broad will result in increased system complexity and less chance that the system can be successfully built.

Which existing computer systems in your company does the new system design leverage?
The new system should leverage the strengths of systems and procedures already in place. That way it can focus on delivering new capabilities instead of just replacing something that already exists. If you decide to replace everything and build from a clean slate, you had better be prepared for the considerable extra time and expense involved and be sure that it’s worth it.

Does the overall design for the new system break down into a set of self-contained subsystems that can each operate on its own and provide value?
Large computer systems are really made up of a bunch of smaller subsystems. Your company should be able to build each subsystem independently of the others. That way, if one subsystem runs into problems, work on the others can still proceed. As subsystems are completed, they should be put into production as soon as possible to begin paying back the expense of building them. If all subsystems must be complete before any can be put to use, that’s a very risky, all- or-nothing system design. Change it.

How accurate is the cost-benefit analysis for the new system?
Have the business benefits been overstated? Would the project still be worth doing if the business benefits were only half of those predicted? Cost-benefit calculations usually understate costs and overstate benefits. You are the one who is best able to judge the validity of the calculations. Do you believe they are accurate? The bigger and riskier the project, the greater the benefits must be to justify the risks and expense. Don’t spend more on a system than it’s worth.

How has the system builder demonstrated that his system design and project leadership skills are appropriate to the demands of the project?
If you don’t have a qualified system builder in charge, the project will fail from lack of direction. Management by committee won’t work. If this person lacks the necessary design and leadership skills, he must be replaced, no matter what other skills he may possess.

Which of the strategic guidelines have been followed, and which have not?
If all seven of the strategic guidelines are followed (see box, below left), the design of the system is very good. It’s acceptable if one of the guidelines — except the first one — isn’t followed. If two aren’t followed, there had better be very good reasons. In that case, determine which extra precautions will be taken to compensate for the increased risk. If more than two of the guidelines aren’t followed, the design is fatally flawed. The system can’t be built on time or on budget, if it can be built at all.

---

PROGRESS MADE DEVELOPING THE SYSTEM
As the project moves through the design and build phases, ask yourself, the system builder and the project teams the following questions:

Are the project plan and budget in place? Do people pay attention to the plan? Is there a project office group that provides regular and accurate updates to the plan and the budget?
Multimillion-dollar system development projects involve a lot of people and stretch across some period of time. The project plan is the central coordinating instrument that tells every person exactly what he’s supposed to be doing at any given time. If the plan isn’t kept current, the people on the project have no way to effectively coordinate their work. The system builder will lose track of the details. Delays, cost overruns and confusion will result. People won’t know how much has been spent to date or how much more is required to finish. When this happens, the project goes into a death spiral.

Are the subsystem teams organizing their work into clearly defined design and build phases? Are these phases getting done on time and on budget?
The project team working on each subsystem should spend one to three months creating a detailed design and system prototype (design phase). The detailed design should then be turned into a working system within two to six months (build phase). If things take longer than this, the project is moving too slowly and it will lose momentum and drift. It’s the system builder’s responsibility to keep things organized and moving. Make sure this person is capable.

How are the six tactical principals for running projects being applied? Do you believe the answers you hear? Can the system builder explain this clearly, using plain language, or does he resort to the use of jargon?
A qualified person can give you straight answers. The system builder is, in effect, the general contractor running the job. He can make or break the project. Get a new one if you need to.

What’s the situation this week?
Spot-check the project plan and budget from time to time. Have the system builder review the current project plan with you, show you the money spent to date on each subsystem, and the estimate for remaining time and budget to complete each subsystem.

---

COMPETENCE AND CONFIDENCE OF PEOPLE ON THE PROJECT
Ask the following questions of yourself, the system builder and the project teams:

What are the design specifications?
As each project team completes its design phase, ask them to show you the design specifications, the process flow diagrams, the logical data model for their subsystem, the user interface, the technical architecture diagrams and the system prototype. Can they tell you how this system will deliver the business benefits in the cost-benefit analysis? Do the design specifications make any sense? Do the people on the team know what they’re talking about?

Are the project team members as confident as the project team leaders? Are the team leaders as confident as the system builder?
If people believe they have the right skills and a good system design, they will be confident in their ability to build the system. If people at every level don’t share and reflect this confidence, there’s a problem somewhere. If people are trying to transfer onto the project, that demonstrates confidence. If people are transferring off the project or leaving the company, that indicates lack of confidence. Expect the project to fail.