Here's a crash course for your business sponsor in what he needs to know about your IT project
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:
1. Business operations
2. Customer expectations
3. Financial performance
4. 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 "Strategic Guidelines for Sponsoring Projects", below), 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.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.