Information systems project planning

by Erwin V. Martinez

IN TODAY'SDEMANDING business environment, information technology and systems are essential to keep pace with increased competition and soaring customer demands. Technology capability is changing rapidly, requiring continued investment in newer and enhanced systems. The stampede to e-commerce on the World Wide Web is just one of many examples that impel business leaders to further apply technology in their organizations. However, it is at this very time when the need for computer systems is most acute that we face the grim reality of computer systems in business: The projects that we use to implement information systems (IS) capabilities are faltering and failing at alarming rates.

This is a challenge that I am well experienced with. For over 15 years I worked in IS project management, specializing in large-scale systems projects. During that time, I developed models for better managing larger-scale IS projects [Martinez, “Avoiding Large Scale Systems Project Failure: The Importance of Fundamentals,” Project Management Journal, June 1994]. I am now a CIO at a medium-size bank and maintain oversight responsibility for about 20 systems projects. At a prior job, I had line responsibility for over 100 projects. In my years of playing the role of industry “insider,” I have refined some useful techniques for improving project success.

Erwin V. Martinez is CIO/EVP of Information Systems at the Silicon Valley Bank in Santa Clara, Calif. Prior to that he was vice president of Information Systems at SBC Directory Operations. Martinez is a member of the PMI^® Northern California Chapter and a member of the Project Management Council of the American Management Association.

Exhibit 1. Here's a model project management plan that covers the who, why, where, how, and why of project planning.

Research Points the Way. There are a few key ways to measure IS project success: on time, on budget, ROI, on schedule, and within scope. Within scope implies that the project fully addresses the business goals it was created to achieve. Most IS projects fail as measured by these factors. Consider some IS project data from the Standish Group [Chaos, The Standish Group, 1995]:

46 percent complete materially over budget and/or behind schedule

28 percent fail outright

84 percent come in late, over budget, or fail.

The Standish Group cites lack of “proper planning” as a key project success factor. Robert Glass in his book Software Runaways [Prentice Hall PTR, 1998] refers to research that indicates 48 percent of failed software projects result from “bad planning and estimating.” A plan that addresses the who, what, how, where, and most importantly, why of a project at a complete and high level greatly improves the chances of project success.

Project Plan Model. A key reason project plans are so important is that the act of developing a thorough project plan forces project managers and project sponsors to think through what they are about to do. Early planning will bring to the surface risks, issues, points of disagreement, needs to compromise, and so forth, that can be resolved up front, when it is easier to do so. Many project managers dive right into tasks under the mistaken view that it is better to get started with the “real work” than spend time on the “overhead” of planning. This invariably creates the perception of progress that some project sponsors like. “Wow, we've started programming already!” is a cry I've heard on many a doomed project. It all but assures that holes in the project plan will not be discovered until too late.

From one perspective, information systems projects are software engineering endeavors. Yet the IS field has not taken a basic lesson from other engineering disciplines: undertaking an engineering effort requires planning. How many bridges are erected without thorough planning? How many homes constructed? How many airplanes built? None! We should have the same horrified response to an IS project manager who begins “constructing” a software solution without a project plan as we would to a home contractor who begins building before blueprints have been developed.

Exhibit 1 contains a model project plan outline that is roughly the same as we use at my current company. Many organizations have plan standards that dictate similar sections in a standard project plan. When taken together, these sections provide a complete yet high-level overview of the project.

Exhibit 2. Three versions of a project purpose for the same project.

While the complete project plan is important, it is by driving excellence in the definition of purpose and objectives that the project manager ensures that his or her projects stay focused on the real business problem/opportunity. However, it is important to note that there is a significant difference between the purpose and objectives.

Project Purpose. The project purpose speaks to the bottom-line business benefit the project sponsors expect to achieve. A well-worded project purpose briefly (two to eight sentences) describes what will be achieved in business terms. It usually does not include a discussion of how the result will be achieved. It is, in effect, an explanation, understandable to nontechnical business managers, of what this project will deliver. Whether the result is achieved by implementing commercially available software, developing custom systems, or sprinkling fairy dust is immaterial to the project purpose.

A project purpose answers the question “Why do this project?” If your project managers, with the full participation of project sponsors, cannot write a clear project purpose, the project is either not worth doing or you have selected the wrong project managers. If project sponsors cannot agree on why they are commissioning the project, you have discovered a critical misalignment. It is best to resolve it before the project starts.

Exhibit 2 presents an example of a project with three alternative project purpose statements. It is based on a real example, and is presented to shed light on how easily a weak project purpose can be developed, with the best intentions. The Information Systems department calls the project the “Field Intranet Project” yet the customer is more comfortable with the name “Increased Sales Revenue Project.” For simplicity, project purposes of two sentences are used. Longer ones are often advisable.

A well thought through project purpose will provide greater focus to the project team and project constituencies. Consider how project team members would behave and focus their energies if they were given the first “bad” purpose as their rallying cry. For example, how easily would the IS team entertain alternative technologies given the first project purpose? IS might feel justified in giving primacy to enforcing technical standards without sufficient regard to any negative impact such standards would have on attaining the business benefit.

Project Objectives. Project objectives are more expansive than the project purpose. Where the project purpose describes “Why do the project?” the project objectives describe “What will the project accomplish?” Unfortunately, many project managers (and general managers) cannot tell the difference between the two.

Since project management concepts apply to nonsystems projects as well, consider, for example, a project to build a home. The answer to “Why do this project?” may be “To provide an economical home where a family of five can live in comfort and safety.” That is the project's purpose. The answer to “What will the project accomplish?” would be a much longer list. These are the project objectives. For example, the home-building project objectives may include adhere to building code standards without seeking zoning variances, or incorporate a garage with direct access to the home.

Exhibit 3. Here is a three-tier model useful for identifying all project objectives.

Project objectives describe what the project will achieve, both along the way to delivering its goal and at the completion of its goal. In contrast, the project purpose is concerned with the product and not with the means of creating that product. Even more to the point, the project purpose is concerned with the intended effect of the product and not a stark delineation of the end product itself. In our home building example, the project purpose is not concerned with the precise number of baths and texture of hallway carpets, but instead with the “comfort” quality of the home.

The Hierarchy of Objectives Model. A common pitfall when developing project objectives is to settle for any reasonably long list of objectives. But merely having a long list tells one nothing about whether the list is complete or valid. A better method is to structure the project objectives according to the hierarchy of objectives, as shown in Exhibit 3. Developing objectives according to this model would force project managers and sponsors to think about objectives in terms of three areas: purely business objectives, the composition of the product, and planned accomplishments during the course of the project. This model provides a measure of assurance for defining a complete set of objectives.

In general, a higher-level objective can be achieved even if a lower-level objective is missed—but not the opposite. For example, the home may have space for a family of five to live comfortably even if the objective of having four bedrooms is missed. Perhaps cost or schedule considerations during the project created the need to compromise on this objective. If so, it was important for the project managers to keep the achievement of the higher-level (and therefore more important) business objectives secure, while reducing the influence of the lower-level system objectives.

The opposite way of managing this project by still having four bedrooms but making them too small for five to live comfortably would be ridiculous. This is laughable until one considers how many times such gaffes are committed on information systems projects. It is an all too frequent occurrence for an information systems project to meet its functionality completeness (that is, systems) objectives while missing the ease of use (business) objectives.

Accomplishing the project objectives is actually how the project purpose is achieved. Yet, the particular project objectives are not the only objectives that would support achievement of the same project's purpose. Stated another way, project objectives are not a unique path to the purpose but are the defined path to the purpose. Conceivably, other project objectives could have reasonably been delineated and substituted. For example, a system end objective of having a silent alarm would be very consistent with the project purpose and business objectives. Yet, in our example, the sponsors/customers did not choose such an objective. Most project purposes can be achieved through different objectives. But the unique objectives of a project describe how the particular sponsors/customers of the project want their purpose achieved.

When the project is over, the project objectives can be used as the measure of project success. It is not merely by the achievement of the project purpose that project sponsors/customers judge success. In the world of projects, the ends do not justify the means. For example, project sponsors/customers may not deem the home-building project to be successful if the right home is built but rework was required along the way.

At Silicon Valley Bank, we have a project that will ultimately introduce a new Human Resource Information System (HRIS). In summary, its project purpose is to improve the accuracy and efficiency of HR processes from the employee standpoint. The HRIS project's list of objectives includes:

Business objective: Lessen the rate of HR Department headcount growth.

System objective: Automate the screening, filing and scheduling of employee candidates.

Project objective: Implement a portion of the system by 4Q00.

Notice in Exhibit 3 how the system objectives and project objectives enable the business objectives. They are derivative of the business objectives. When defining project objectives, it is important to begin with a complete delineation of business objectives.

One final note about project objectives relates to how one would know when a project has a sufficient number of objectives. This is a common question, but one that is off the mark. There is no magic number of objectives. It is important to follow the three-tier structure and define only those objectives which enable the project purpose, which the team and sponsors have passion about, and upon which the sponsors have agreed to measure project success or failure. Otherwise the list of objectives becomes exhaustively long and leaks into other project planning areas such as scope and approach.

Managing With Objectives. The three-tier project objectives model is not useful just in the project planning stage. It also is vital during the course of the project. It implies a priority for project decision-making. It provides the project sponsors/customers and senior management with a common logic and language with which to resolve issues and question project status.

Consider our increased sales revenue project example in Exhibit 2. The project team may approach the project sponsors with a request that the project be delayed for two months in order to accommodate recent changes in the intranet development standards. Certainly, developing to technical standards is enabling of the business direction. Technical standards ensure flexibility and cost-effective ongoing maintenance. However, technical standards are not more important than the business's project objectives. System ends objectives cannot be logically discussed in absolute terms as if tradeoffs with other objectives are not being made. The discussion of the merit of the delay should be discussed on that basis. For example: Is it worth delaying $500,000 of revenue gain by two months in order to be on the latest version of development standards? The answer for most projects would likely be “No.”

There is considerable power in using the three-tier project objectives model (Exhibit 3) to drive project decision-making. This practice can rather handily blunt the common occurrence of information systems practitioners and project managers losing focus on what is really important to the business. How many times have we seen projects hijacked by well meaning techies who want to build new skills in the latest technology? As well, project managers can be tempted to compromise the quality of a system and therefore the system's ability to meet business objectives, by instead meeting project means objectives such as programming milestones or testing phase budgets.

Yet the three-tier project objectives model is not always easily used as a strict decision-making tool. For example, meeting a testing phase budget is not always less important than creating a solution that will enable a 15 percent increase in sales revenue. Real projects are more complex than that. Project managers who insist that the functionality of a system must be compromised in order to meet a budget should be challenged (and should challenge themselves) to think again: Is that system objective really more important that the business objectives that will be shortchanged by that decision?

THE PURPOSE AND OBJECTIVES drive the project manager's thinking on the rest of the plan. Following a model such as the hierarchy of objectives will help project managers develop a complete list of objectives that is more than just an unstructured wish list. Proper planning is the key that opens the door to overall project success. ■

Reader Service Number 202