Define the Need Before Software Installation
Vital step can save rework and stress.

By Ian Vail and Joe Mikes, Business Process Architecture, Inc.
Posted 11-03-03

Defining the real need for new software and staying focused is tricky. There are so many variables along the way to a good software implementation that falling off the track is easy. There has to be a central theme to guide the decisions that will be made during the process. Simple steps early in the project keep decisions simple when times get tough.

A Needs Statement is the target that keeps the project focused and successful. Many factors must be managed or they ultimately could distract the team from the real need. These factors include cost/overruns, senior organizational changes, new groups that want support, each group feeling its cause is the most important, timelines shrinking and allowing shortcuts, and software requirements that are not a strong match to the real needs. An organization could face these diversions or others during the time it tries to install a new computer system.

As Roy Brandon, president/CEO of a technology firm in Sacramento, CA, said, “We can no longer assume we understand the client’s business needs; they have to be defined in the beginning and reviewed throughout the whole process of establishing a software solution.” The Needs Statement is absolutely critical to avoiding a huge cost overrun or a mismatch of software to your real business. The same tools contractors and consultants must use to keep projects aligned are the same tools organizations could use on their own. Understanding and defining the business needs upfront will save time and money.

Many diversions for project
To illustrate a project diversion, a new project manager (PM) came on board with a large U. S. city water treatment plant project. The project’s real need was for the plant to have better access to all the data staffers collect to make better business decisions and manage the release of treated water into the local river. Just as many projects go, the new PM did not have the Needs Statement spelled out and began to campaign for some new functionality that he had seen at a recent vendor display. The team was redirected to build the functionality that was described to them, and the time and effort to accomplish these new functions grew exponentially.

The team members solicited advice from many experts on how this new functionality could help the plant. They got great advice on how it could help and possible benefits that could be attained. The problem was the new functionality was not what the plant really needed; the functions were nice to have but not essential. The project went into an overrun of time and budget. In the end, months later, the team found themselves sitting around the conference table asking what the real need was for the plant and how they could get that accomplished with the remaining funds.

Steps to a focused project
There are a few steps that should be taken to maintain the necessary focus and avoid this dilemma. The steps appear to be easy. But any CIO who has experienced a significant project like this will tell you how deceptive these three steps can be:
• Define the “real need” in the beginning
• Market the idea internally
• Remain focused on the needs

Step one: Define the real need up front. Try to state in 50 words or less why the software is being installed. The statement can be very simple as long as the user community feels it is complete.

Here is an example that worked for a Los Angeles public agency while procuring and installing a multi-million dollar system that incorporated nine departments and interfaced with three major systems outside the new software: “The system must provide timely asset data to give us the information we need to improve asset management. The system must provide the employee data associated with the work. Finally, it must be able to track all material movements and translate all of this with the financials.” If an organization as large as this one can work with a Needs Statement as simple as this one, any group should be able to develop one and use it.

Step two: Market the idea internally. Post the Needs Statement where the team meets. Make a large poster or banner and hang it where everyone involved in the project can see it and remember it. Include it in periodic updates of the project. There are many hurdles and diversions on the path to new technology and there must be a tool available to the software installation team to keep on track.

Step three: Remain focused. A small city in Nevada decided to install an enterprise-wide solution and spent considerable time reviewing the choices available. The city was strapped for resources internally to dedicate to the project. It also lacked sufficient funds to buy all the consulting help needed. Each department had to do the best it could with the few people available on a part-time basis. In the end, there were only two out of seven departments using the system accurately.

One of the most critical reasons why the installation failed was because the five other departments had not reviewed their goals and objectives and had no clearly defined Needs Statement with buy-in from the users. Defining the real need after the purchase is much too late. For example, discovering the software does not manage the accounting correctly or the customer service tracking capabilities are insufficient will cripple the project and installation. Develop and define the need early, write it down, get the buy-in from the key people, and stick to it until the needs of the statement are completely met.

What if a really good idea comes out mid-stream of the project? What if the city in Nevada found out there was another module that would fit the police and fire departments’ needs as well? We strongly encourage you to stay the course approved in the Needs Statement and plan to add new departments or modules after the needs of the statement are completely met. In other words, stay focused.

These three steps can reduce headaches and lost time.

Responsibilities of leadership
There are also some related responsibilities for the person or group leading the effort. Three key executive leadership roles must be organized and monitored early to meet the goals and reduce the risks:
• Establish a clear Needs Statement (defining the track you are going to run on)
• Monitor the project to avoid slipping off track
• Maintain consistency with the Needs Statement until its specific goals are reached

The first time the executive leader makes any changes to the consistent message of the Needs Statement, the result could unravel the momentum. Although it is important for a leader to be able to negotiate and be open minded, we recommend those negotiations and open-minded ideas be collected for potential next steps that will occur after the needs of the current project are completely met. Do not disregard a good idea; just move the timeline out to assure the first objective is met.

Because the Needs Statement is so critical, it is very important that it be comprehensive to all the departments or areas of the business that will be affected by the software installation. The statement must capture the high-level requirements in a manner that gains the buy-in and support that will be necessary when the wolf comes calling halfway through the project. The trick is to have a plan for negotiating the solution after the needs of the current project are completed.

Let’s look at the typical diversions or problems again: cost/overruns, senior organizational changes, new groups that want support, each group feeling its cause is the most important, timelines shrinking and allowing shortcuts, and software requirements that are not a strong match to the real needs. Each one of these problems could be managed by having a strong Needs Statement that the organization buys into and supports.

Too many projects lack the guiding light or a path to follow. Some projects have a Needs Statement but lack the comprehensive buy-in from the user groups. These projects cannot afford to have a department or functional area misaligned with the overall goals. These early steps in the process can save organizations a lot of rework and stress.

Ian Vail and Joe Mikes are partners at Business Process Architecture, Inc. (BPA), 8534 Tambor Way, Elk Grove, CA 95758; (916) 682-9294