1 of 4 pages
Vital Signs
0 Comments on this document
Document Transcript:
Vital Signs 1
Vital Signs
By Michael Hugos
Here's a crash course for business executives who sponsor system development
projects. Business executives who sponsor system development projects need a
way to assess them as they move through the development sequence. This
checklist can be used to assess any system 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
Center for Systems InnovationVital Signs 2
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.
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
Center for Systems InnovationVital Signs 3
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.
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. Do you believe what you hear? Can the system
builder explain the situation clearly, without tech talk? How does the most recent
estimate of time and budget compare to original estimates? Is it still worth the cost to
complete the project?
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.
Strategic Guidelines for Sponsoring Projects
1. Closely align projects with business goals.
Center for Systems InnovationVital Signs 4
2. Use the system to change the competitive landscape.
3. Leverage the strengths of existing systems.
4. Use the simplest combination of technology and business procedures to achieve as
many objectives as possible.
5. Structure the design to provide flexibility in the development sequence used to create
the system.
6. Don't try to build a system whose complexity exceeds the organization's capabilities.
7. Don't renew a project using the same organizational approach or system design after
it has already failed.
Michael Hugos is a mentor and practitioner in business agility at the Center for Systems
Innovation in Chicago, Illinois. He is an award-winning business architect who integrates
technology and business process to create decisive competitive advantage. This article
is excerpted from his book, Building The Real-Time Enterprise: An Executive
Briefing, published by John Wiley & Sons, 2005. He can be contacted via
www.MichaelHugos.com
Amazon Listing:
(http://www.amazon.com/gp/product/0471678295/qid=1139160816/sr=1-3/ref=sr_1_3/002-
2846775-5905602?s=books&v=glance&n=283155)
Center for Systems Innovation
Vital Signs
By Michael Hugos
Here's a crash course for business executives who sponsor system development
projects. Business executives who sponsor system development projects need a
way to assess them as they move through the development sequence. This
checklist can be used to assess any system 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
Center for Systems InnovationVital Signs 2
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.
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
Center for Systems InnovationVital Signs 3
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.
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. Do you believe what you hear? Can the system
builder explain the situation clearly, without tech talk? How does the most recent
estimate of time and budget compare to original estimates? Is it still worth the cost to
complete the project?
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.
Strategic Guidelines for Sponsoring Projects
1. Closely align projects with business goals.
Center for Systems InnovationVital Signs 4
2. Use the system to change the competitive landscape.
3. Leverage the strengths of existing systems.
4. Use the simplest combination of technology and business procedures to achieve as
many objectives as possible.
5. Structure the design to provide flexibility in the development sequence used to create
the system.
6. Don't try to build a system whose complexity exceeds the organization's capabilities.
7. Don't renew a project using the same organizational approach or system design after
it has already failed.
Michael Hugos is a mentor and practitioner in business agility at the Center for Systems
Innovation in Chicago, Illinois. He is an award-winning business architect who integrates
technology and business process to create decisive competitive advantage. This article
is excerpted from his book, Building The Real-Time Enterprise: An Executive
Briefing, published by John Wiley & Sons, 2005. He can be contacted via
www.MichaelHugos.com
Amazon Listing:
(http://www.amazon.com/gp/product/0471678295/qid=1139160816/sr=1-3/ref=sr_1_3/002-
2846775-5905602?s=books&v=glance&n=283155)
Center for Systems Innovation
