Monitoring Your I.T. Projects
Don't be intimidated by your I.T. staff.
By Howard Baker
PROJECT management should be both a tool and a discipline. Unfortunately, in real life, it often is nothing but wishful thinking. Experts report that 85 percent of all technology projects in the United States are behind schedule, over budget, and/or out of scope. That leaves 15 percent that conform to the vision as originally conceived when the project was approved. Very few organizations would define a 15 percent success rate as applaudable!
When C.I.O.s inform managing partners in the private sector -- or the senior management team in the public sector -- that a "system" will cost several millions of dollars, those managers are not surprised. After all, it is understood that systems are beyond comprehension and cost a lot of money.
But senior managers need not abandon their responsibility to oversee these projects. With a little effort they can understand the need for a system, and comprehend design, cost and development issues. You can be an active, rather than passive, monitor of your organization's technology installations. Here are some tips to make it easier:
1. Do you need a new system?
This is called the planning phase, and the first question to be answered is what good a new system will be to the mission of the organization. Surprisingly, this question is rarely asked when considering automation projects. If you cannot answer the question then perhaps a new system is not needed.
2. Who will manage the development of the system?
This is called the "responsibility" phase. Whoever is ultimately responsible for key decisions in an organization should be the person in charge of I.T. development. Usually, this is the managing partner or agency head.
Traditionally, these folks are rarely responsible for I.T. development. There may be a development committee chaired by the partner or agency head but this person should make all key decisions. An organization should never leave the responsibility of I.T. development solely to the C.I.O. or the user community. If you do, you'll get a system that may not address the business needs of your organization or users. Instead, you're likely only to automate a paper process, rather than taking advantage of an opportunity to reengineer the processes to provide maximum profit or better service.
3. How will the development proceed?
Most projects start out as major undertakings with long development periods, and do not often get broken into manageable parts. Breaking projects into manageable parts is called the development phase.
All I.T. projects should be built around releases called "iterations." Each iteration contains a building block for the system that will give the user community something that can be examined and used while the development of the next iteration is undertaken. As the user community experiments with an iteration there will be suggestions which can be included in the next version of the release.
This should take place over 30-day development periods until all iterations have been completed and a full I.T. system is delivered. Never allow a developer more than 30 days before they "touch base" with the organization. Otherwise, the risk of failure increases exponentially.
Projects fail without enough communication. The user community speaks one language when telling the I.T. community about their tasks. The I.T. staff hear what they perceive as the user community tasks and develop an automation system. Many times the two are not in sync and what gets automated does not address a true business need.
To minimize this risk, the organization needs to undertake "Joint Application Design" sessions from project inception to conclusion.
JAD is a facilitated group which includes representatives of the user and development communities, where each group learns the language of the other.
Basically, these are advanced communication classes with the intended result being a greater understanding by the I.T. developers of what the user community is saying and the provision of a system that faithfully represents that understanding.
5. The hardest part: announcing when it is over.
During the development phase the decision makers decide how many iterations will encompass the system.
Once these iterations are delivered the project is over. The decision maker needs to make an announcement and the user community needs to start using the system.
(There will, undoubtedly, be enhancement phases that come after the end of any project.)
LTN Editorial Advisory Board member Howard Baker is based in Boston, and is the chief information officer for the executive office of public safety, Commonwealth of Massachusetts.