Size.

Technology. Situation.

For instance, a nuclear plant or space shuttle project has very specific heavyweight life-cycle components (e.g., work breakdown structure, activities, tasks, task durations, priorities, skill sets, and economics) compared to a small construction project. In other words, they use different phases and activities on their projects (i.e., communications and navigation equipment, operating systems, and a variety of technologies).

In addition, the life cycles for construction projects (e.g., bridge building), compared to information systems projects (e.g., three-tier architectures), may be vastly different from one another. This means much tweaking is needed if you have to accommodate every kind of project. Hence, different methodologies are needed. Therefore, we have a catch-22 situation various technologies and industries make it very challenging to design a one-size-fits-all project life cycle. It does not seem likely that an individual project manager or executive can actually design a highly operational, functional project methodology that meets the needs of every single project irrespective of its technology or industry. Hence, some creative genius is needed to bridge this gap. A project life cycle is, therefore, a collection of project phases. Project phases vary by project or industry, but some general phases include:

Concept. Development. Implementation. Support.

Remember that products also have life cycles. Many companies have project managers or executives who are unwilling to follow systematic project methodologies all of the time. Instead, they tend to rely on standard business activities to get them through the project. They are simply trying to keep up with all this talk of project methodologies and associated processes and techniques. Questions such as Why are there so many methodologies? and Which one do we use? often arise. Over the years, even those involved in managing projects have observed that projects have common characteristics that can be formalized into a structural process, which allows them to manage projects more effectively.

Each phase can typically be brought to closure in some logical way before the next project phase begins; and each phase results in discrete milestones or deliverables, which provide the starting point for the next phase. Project methodologies should be structured to take advantage of the natural phases that occur as work progresses. The

phases should be defined in terms of schedule and specific accomplishments. Define how you will know when you have finished each phase and what you will have to show for it.

Cost and schedule estimates, plans, requirements, and specifications should be updated and evaluated at the end of each phase, sometimes before deciding whether to continue with the project. At times, you may want to hold off or cancel the project. Large projects are usually structured to have major program reviews at the conclusion of significant project phases. These decision points in the life of a project are called major milestones. Figure 2.1 shows how project phases are somehow linked to one another. This is the basis of how project phases, once incorporated, form a typical project development methodology.

IHi-m;-

A; Bum

Figure 2.1: Depiction of general project methodology phases.

Milestone decisions are made after conducting a major program review in which the project manager presents the approved statement of requirements, acquisition strategy, design progress, test results, updated cost and schedule estimates, and risk assessments, together with a request for authorization to proceed to the next phase. The early project phases tend to shape the direction for all further efforts on the project. They provide requirement definitions, evaluation of alternative approaches, assessment of maturity of technologies, review of cost, schedule and staffing estimates, and development of specifications.

A relatively short-term or technically straightforward project may have only a few basic milestones or deliverables following a (1) proposal, (2) feasibility study, or (3) business case. Nevertheless, the project manager should report to clients and executives at intervals to keep them up-to-date on project progress, thus ensuring project direction. (See lightweight methodologies in Chapter 4.)

On small projects, if no formal agreements are written, the project manager should deal with clients and executives in an informal, yet somewhat structured and logical, manner. This means managing expectations and making clear agreements about what will be produced and when. You simply cannot do this on the fly.

On long-term projects, you may find project phases take place over many months or even years, and, in this case, it is vital to provide interim deliverables to give the clients and executives a sense that work is being accomplished, to provide an opportunity for feedback, and to capture project successes in documented form. This is exactly why a project methodology works. How else are you going to do this? (See heavyweight methodologies in Chapter 4.)

It is wise that the project processes be built around the specific project methodology. Particular care should be given to defining the work to be accomplished in each phase. This should include definition of the deliverables to be produced, identifying testing and demonstrations to be completed, preparing updates of cost and schedule estimates, reassessing risks, and conducting formal technical and management reviews.

Background to Project Methodologies

Project management has grown from the early initiatives in the U.S. defense and aerospace sectors in the late 1950s and 1960s. The U.S. Department of Defense and NASA achieved early project management successes mainly promulgated through their internal policies, procedures, and lessons learned. From this flowed numerous white papers, articles, seminars, and training programs that expanded the project management genre, although much of the theory centered around the use of tools and techniques, such as:

PERT/Gantt charts. Critical path. Scheduling techniques. Organizational issues.

Conflict management and others.

From the early 1970s, project management societies began to provide communication on the discipline, basically through journals, conferences, and seminars. This continued until the mid-1980s when, first, the U.S.-based Project Management Institute (PMI) and, later, the U.K.-based Association for Project Management (APM), embarked on programs to test project management professionalism. This brought about certain guidelines and bodies of knowledge (e.g., PMBOK, APMBOK), which addressed some methodology but did not address every industry and type of methodology. Other organizations developed their own versions of a project methodology.

In the pioneering days of project management, it was common practice for project staff or managers to devise their own methods of moving through the life cycles of their projects, which were often influenced by information technology, engineering challenges, or financial constraints. It was a time when a project was driven by the events that occurred while on the job. This was fine for certain projects, but it led to the failure and delay of many projects because of problems that started to show (1) poor or inconsistent project designs, (2) poor project analysis, and (3) ineffective project communications. It seemed projects lacked the rigor and key ingredients to make them more effective. Sometimes, it takes a complete outsider to show how to expedite projects more quickly than before, in innovative futuristic ways. Look at what BMW has done you can today log onto their Web site and purchase a customized vehicle, specified by you instead of selecting one from a standard showroom floor model. The production-to-delivery process is drastically reduced and flexible.

A great analogy of the need for appropriate control is found in Formula One racing. Here, the powerful cars have