Project Life Cycles

Every project has a number of phases to mark the beginning, middle, and end of the project. The project life cycle is the composition of these multiple phases, which can be laid out on a timeline. In an ideal world, all deliverables from one phase would be complete and approved prior to the start of the next phase. In reality, the various phases of a life cycle can overlap. The term for starting one phase prior to the completion of a previous phase is fast tracking . This is normally done to shorten the project schedule.

Project life cycles vary widely between different industries and to some degree even within an organization. Although project life cycles are diverse, you will find several key elements. A project life cycle should depict at the highest level the deliverables for each phase and the category of resources involved. A life cycle should also depict how the project will be folded into the operational business on completion.

Now let's take a look at some examples of typical life cycles of IT projects.

IT Project Life Cycles

Every IT project has a life cycle and a series of phases. The software development life cycle (SDLC) closely parallels project management process groups with its five phases: planning, analysis, design, implementation, and operation and support. The following is a closer look at each of these phases.

Systems Planning

The systems planning phase begins with a formal request to IT for a system that will solve a problem, or provide an upgrade or improvement to an existing system. The formal request is called a systems request and embodies the problem and business processes that need to be addressed within the given system.

A systems request has two potential outcomes : a preliminary investigation and a feasibility study (depending on the size of the system). The preliminary investigation basically maps to the preliminary requirement-gathering process that you go through when you're in the Initiation process group of project management. From this preliminary investigation you may derive a feasibility study that denotes the cost-benefits associated with the request as well as recommendations that drill down into the various factors involved, such as operational, time, economic, or technical conditions.

But systems planning goes beyond the notion of 'we've got a system we'd like for you to build.' It also gets into the idea of how that system fits into the overall corporate scheme of things-does the system enhance the corporate vision and goals?

Additionally (and more subtly), good systems planning may well point back to the need for a change in business processes in order to more closely accommodate the stated desired results. Sometimes automation and technology can't (or shouldn't) solve a problem, when a change in the way that a business process is currently being done will do nicely .

Systems Analysis

You've solidified a feasible system request and you're planning on going forward. The systems analysis segment is the next logical step in your progression. In this phase you develop a logical model of the system by diagramming the logical flows of the data. You'll map out what the requirements are for the new system.

Note  

Some good system analysis techniques (but beyond the scope of this book) include data flow diagrams (DFDs) and use case scenarios and entity relationship diagrams (ERDs) that illustrate the various inflows and outflows of the system, in addition to the anticipated way that people will interact with it.

If you understand the goals of the business manager that is requesting the system and you couple that with the logical flows that you derive for the system by going through a business process analysis, you can make your job much easier in diagramming, at a high level, how the proposed new system will operate . A visual representation of the basic business flows will also help others understand how the system parts interoperate and help nontechnical people understand how you think about their business process.

In the analysis phase you begin to knock out what it is-the nuts and bolts-that this system consists of. Through your previous analysis process, including interviewing various stakeholders, performing fact-finding analysis, and formulating solid objective ideas about what the system should be comprised of and what it should do, you can build various enterprise models that include the data objects themselves . You also can understand the various process and data models that are involved. Also, fleshing out a prototype at this point will prove to be a worthwhile effort because prototypes give stakeholders a way to visualize the new system.

The systems planning and analysis phases roughly correlate to the Initiation and Planning process groups, which we'll discuss in more detail in Chapter 2.

The final outcome of the systems analysis phase is called a systems requirements document . The document spells out what you heard the business representatives say that they wanted in the new system. You got here by going through a variety of processes including interviewing various experts in the business process, sitting with them to watch how they go about their work, questioning the manager, and other such methods . The document is about the business for the business. Like a da Vinci charcoal drawing intending to help the artist understand what it was he was going to paint, the business requirements doc will help you derive your new system.

Systems Design

In the systems design phase you denote all the components that will be included in your IT project, including all of the inputs (such as data flowing into the system or keyboard input by a data-entry clerk), outputs (such as screen displays or reports ), and processes involved. Additionally, at design time you flesh out the various controls required, whether automated or manual, that will contribute to the system's successful operation. If you're working on a project in which code has to be written, you'll draw out the architecture that the application(s) will use in a document, called the system design specification (SDS), a detailed document that allows the project team members to exactly build the desired system. The SDS illustrates exactly how programmers are to create the system.

If the system doesn't require software development, but does require database or infrastructure creation or enhancement, it's key that all stakeholders, from management to end users, understand what you've designed and how you imagine it will work, and that technicians be able to build the desired system. If you're using a Commercial Off The Shelf (COTS) program, you'll design its integration into the system that you're building.

Note too that other elements such as infrastructure additions or renovations, cabling upgrades, WAN connectivity (including wireless), new types of computing such as PDAs, telephony integration, and a host of other things may be included in the design of your system. Just because your system primarily uses software does not mean that the underlying components don't need to be addressed and freshened as well.

Systems Implementation

In the systems implementation phase of the IT project life cycle, the system is constructed . Whether that means that programmers write programs, you purchase COTS programs, or you come up with some in-between system that uses elements from both worlds , you'll want to deliver a completely functional and fully documented system.

This phase includes such elements as the conversion of old data to new tables, training the users, testing, and migrating to the new system. You'll also prepare a write-up called the systems evaluation to provide an earmark as to how well the system performs relative to your stipulations in the system design specification.

Systems Operation and Support

Mapping somewhat to the Closing process group, which we'll discuss in just a moment, the systems operation and support phase means that you put the system into routine operation, and provide a method whereby the system can be supported if there is trouble. However, the operation and support phase goes beyond Closing in that it calls for elements such as change management where you have maintenance or enhancements that need to be performed and you provide for some modicum of scalability in the system, should it need to be added to later.

You need to know two other things as a manager of projects in the IT project life cycle: setting milestones and checkpoints. Let's discuss this further.

Project Concept Documentation

Let us mention here another type of document that you might want to consider when you're meshing two management methodologies together (i.e., project management and the SDLC): the Project Concept Document. At initial requirements-gathering time, the systems analyst will generate a document that contains the high-level requirements she discovered upon examining the customer request. This document could act as a starting point in the project planning process as well. A systems analyst may not be a project manager, or may be-it depends on the way your company is laid out and the complexity of the project before you. But we know that good quality systems analysis and design leads to high-efficiency systems, especially when built under a well-developed project management paradigm. A starting-point document for both players- the project concept document-is an ideal way to flesh out the skeleton of the project and get the two parties talking.

Note that the systems analyst will go on to develop some very elaborate flows out of her initial requirements-the project manager must be in lockstep with the elements being worked out.

IT Project Milestones and Checkpoints

Any good SDLC process should include the milestones on which you see the project pivoting. For example, perhaps a significant milestone for an e-commerce project would be the purchase, acquisition, installation, configuration, and deployment of the web servers that will be used for the system. A very discreet set of tasks are needed in order to accomplish this milestone. At its accomplishment, in the systems design world, we'd step back and ask project stakeholders such as the managers and technicians to give us a go/no-go decision regarding whether the project should move forward.

Additionally, in between milestones, good projects include several checkpoints along the way that reveal whether we're on time and within budget in our project. A prudent number of checkpoints (not too many to be burdensome) can reveal the pulse of the project at any given point.