How Do You Know Have a Project?

How Do You Know Have a Project?

When people speak of projects, they normally mean the large, expensive, visible, cast-of-dozens projects that characterize systems development. Few will argue that these do not require some level of management. But what about the smaller activities, the ones that are not so obviously risky or critical to the organization? When do these become projects requiring the attention of a project manager?

For example, the hardware is being upgraded with additional memory, additional disk capacity, and, coincidentally, a new version of the operating system. Is this a project, or can it be left to the systems people to simply do the work without imposing a project structure on them?

There is a gray area between activities that are part of someone's daily responsibilities and activities that constitute a project. That gray area has forced many organizations to wrestle with the question, ''How do we know when we have a project?" Exhibit 1.1 provides a set of criteria and a checklist that should help answer that question.

If two or more boxes are checked, particularly those that involve coordination or risk, then the activities are a project. It will not be large, nor will it occupy much of the time of an experienced project manager, but if it is not properly managed, the company is at some 

Exhibit 1.1 Project Definition Criteria

The activities will involve more than two people.
__

The activities will require more than two weeks of effort.
__

The activities will require more than one month's elapsed time.
__

The activities involve substantial risk.
__

If the activities fail, there will be a significant impact.
__

The activities will require coordination of two or more departments.
__

The activities will involve outside partners.
__

The activities will involve new technology.
__

The activities fall outside the scope of normal operations.
__

A hardware upgrade was scheduled for installation before month-end processing. The upgrade was needed in order to complete month-end reports on time. But installation of the new hardware required shutting down the system, and nobody had cleared this with the users. The user manager refused to permit the shutdown without two weeks' notice for rescheduling staff time. The result was that the month-end reports were delayed because of insufficient capacity and the company lost business.

A new version of the operating system was being installed. Since the application had been successfully tested, the new version was installed at night, ready for the next day. But this version required changes in network system tables, and nobody had notified network support. By the time the problem was fixed, production had experienced four hours of downtime.

The purpose of project management is to reduce risk and ensure timely delivery. As these examples illustrate, problems are not restricted to projects with a six-figure price tag. Anything that could go wrong deserves to be managed.

SOME COMMENTS ON PROJECT METHODOLOGY

Most textbooks on project management deal extensively with the author's preferred systems development life cycle (SDLC) or development degree of risk.

One of the barriers to defining simple sets of activities as a project is the bureaucracy that this imposes. The temptation is to say, "Let's just drop the overhead and let the people get on with the work." This appeal to action is attractive, and it is true that in most cases, small sets of activities get done more or less unobtrusively. However, consider the risks and the costs in these examples:

methodology. They spend chapters describing the phases of the SDLC, the interrelationships among phases, and the project management needed to produce the SDLC deliverables. They therefore introduce three problems: They intertwine project management with project methodology, they implicitly reject other approaches to projects, and they ignore projects that do not produce code.

Project methodology deals with how the work is done; project management deals with doing it. Project methodology is analogous to a construction blueprint that shows, for example, where water pipes are to run. Project management ensures that the work crews place the pipes properly so that when the toilet is flushed, the right things happen.

Project management does not depend on any particular SDLC or development approach. As a project manager, it is certainly your job to ensure that you know how you are going to reach the end goal of the project, and a workable development methodology can help, but good project managers can handle any proven approach.

Furthermore, to associate project management with a particular SDLC is to ignore (or reject) evolving ways to develop systems. The conventional "waterfall" approach is being supplanted by concepts such as rapid applicationsa development, evolutionary prototyping, iterative design refinement, and the "spiral" approach. Even conventional SDLCs are being used more flexibly.

Finally, SDLCs are aimed primarily at systems development projectsthose that produce code. To focus on them is to ignore other types of projects, such as defining application requirements, implementing major packages, upgrading hardware, designing a technology architecture, or developing a systems strategic plan. These are projects as well, and they also need to be managed.

This book does not deal with methodologies. It describes how to manage projects.