Integrate with suppliers and parties.

Understanding Project Life Cycles

After the project life cycle is defined, the project budget and technical aspects must be managed together. And this is important. Can you imagine delivering a project within cost and schedule but that the project does not meet its technical specifications? I think not a project life cycle must be efficiently managed if the project is to be successful.

An iteration is defined as a distinct sequence of activities with an established plan and evaluation criteria resulting in an executable release. If we examine the set of illustrations describing the waterfall approach, we can see that an iterative approach does have advantages over a straightforward waterfall approach. This analogy should help reveal other ways to manage projects.

On many projects, where dates have been preset either by sales executives or senior corporate stakeholders, project managers often do not have the luxury of changing the fixed end date. Hence, how do you meet a fixed end date? Would a System Development Life Cycle (SDLC) or a Rapid Application Development (RAD) approach work better for you (i.e., incremental versus an iterative approach)?

Delegates attending my project presentations often ask: How do I make my view of the world work, when working with new technology projects? What methodology do I follow? I always respond by stating that you have control over only the inputs you receive, and you define your projects based on those constraints. Its not up to you to start reorganizing the organization just for your project. First, see whats within your boundaries. Then act from there.

iJJ..HI8

CIPOC A Conceptual Approach

When I try to place any project life cycle or methodology into perspective, I always go back to the Client, Input, Process, Output, Clients (CIPOC) approach, a slight deviation from the supplier concept. It is one of the greatest examples of a primer that gives a high-level conceptual view of the way all project methodologies fit into the grand scheme of things (see Figure 2.3).

- I-ц i- I *- ~. I-bj

Hot УШ i мсют сот

Figure 2.3: CIPOC technique to reflect methodology usage.

CIPOC works like this. A client has certain requirements for which he or she needs a certain solution. This can be a new skyscraper, submarine, spacecraft, software, or even a rock concert. It doesnt matter what kind of project. These client requirements are formed into inputs, which in turn serve as the defining moments or starting point for the process which can be virtually any methodology you want to use (e.g., Waterfall, SDLC, PACE, RUP, XP, MIL-STD-1612, PRINCE2). The project manager uses his or her chosen methodology and proceeds to design, build, test, and deploy the solution. These are the control points. When complete, an output has been generated that is then accepted by the client. The client can be involved anywhere in the CIPOC approach; the client readily provides feedback at any stage.

All assumptions must be made upfront at the onset of the project process start. This is one of the control points. If the project manager cannot control the assumptions, the project may come back and bite, irrespective of methodology employed.

If you need 500,000 kilowatts of power in a remote location, how do you do it? How do you meet your clients needs? You need an approach, and, typically, you would follow a CIPOC approach. Similarly, the Winter Olympics held in Salt Lake City was a phenomenal project itself. The Olympics organizers, too, would follow the CIPOC approach.

If we examine major companies such as Ernst & Young, RCG Information Technology, and IBM, we find that these major solutions companies have total soup-to-nuts project methodologies in place. These project methodologies embrace everything from the initial sales call, defining the solution, right through to deployment. They can identify the appropriate resources needed per project life-cycle phase (i.e., account executive, recruiter, designer, tester, project lead). These methodologies are well documented. If we examine other companies (e.g., home builders, software developers), we find that many dont have the luxury of such an elaborate project methodology in place. They simply adhere to projects in their own informal manner.

Understanding Project Model Terminology

Project Feasibility and Justification

The project managers first task is to become familiar with the feasibility of the project. He or she should reaffirm to his or her own satisfaction the findings of the original study, which may have been some time ago, certainly before he or she accepted the job. Thus, reaffirming the feasibility and justification of the project is crucial.

User Requirements

The most important phase in any project is to find out what is actually needed. Without proper establishment of the requirements, no one is certain what is really required. This is not covered fully in the Project Service Request (PSR); therefore, work and effort are needed at the start of the project. Subsequent time may be wasted if the user requirements are not established and understood.

System Design

After establishing and agreeing on the requirements, a high-level design of the main functions of the system can be produced. This is followed by considering the development of each of these main functions in more detail.

Detailed Design and Buy or Build

These follow the established meanings found in most development models. Each activity in the work breakdown structure (WBS) is given sufficient individual attention so that it is designed in detail ready for building. These phases apply equally to the design and creation of documentation as well as software. They also apply to hardware, except that items needed to run the software will be ordered from suppliers instead of building the items. The hardware design is determined by the software requirements.

Acceptance

The acceptance phase is the running of integration tests at system level to prove all documentation, software, hardware, and other equipment. These tests must be designed carefully and not left to the suppliers (of equipment, software, and documentation) to construct. Otherwise, we find that suppliers may test only the parts that work and may deliberately not consider the whole system, which may lead to problems for the end users. Notice that testing occurs throughout the project not delayed until a single testing phase when and where it would be too late to rectify faults efficiently. This phase is about testing to accept the whole system, not testing to see if it works.

Commissioning

Every component is built, tested and integrated. Commissioning is the setting to work of the proven and integrated system. This is the time to introduce the end users to their relevant parts of the working system and then cut over to the live system. During this stage (or even before in some projects), user training takes place and the help desk is set