Project Methodologies Explained

Project Methodology Overview
Key decision makers must often determine whether a universalized project life-cycle methodology is sufficient for all their projects. The answer to that question is an unequivocal no! Very few people are capable of creating a state of-the-art, concisely defined, phenomenally small, highly prescriptive, measurement-intensive, fast, and cost-efficient methodology allowing project managers greater performance improvement (consisting of an expertly designed/optimized family of policies, procedures, plans, specifications, forms, logs, and metrics). Every company has its own process flow diagram. This flow originated from a methodology created to ease implementations of new technologies or new project ideas. These process flow diagrams have many different stages, all similar in nature.

Even dynamic project-based organizations such as Accenture, KPMG, Deloitte Touche, RCG Information Technology, Bechtel, and Keane are far more than a collection of individual projects. If that were all they were, they wouldn't be multimillion-dollar organizations. They all use various arsenals of project methodologies for each solution they undertake. Companies are becoming very much like small film studios. Each project is a "movie" all by itself and has its own "director" and "script." The movie needs project funding to begin and is short lived; project teams are also short lived, and, amazingly, in this brave new model, they follow a unique project methodology, because if they don't, no one will invest in a "movie" or project. Therefore, projects need to be innovative, they need process, and they need to adhere to the "script" or methodology. Each movie script is different from the next; this is where we focus our efforts throughout the book.

By simply assessing those project methodologies that exist today, we see that a universal project approach simply won't work. The main reasons that a single "be-all-and-end-all" methodology won't work from industry to industry are differences in:

Life cycle.

Market sector.

Product.

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.


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 braking systems to enable them to go faster rather than to slow them down. Likewise, in different industries, appropriate levels of control allow an organization to grow and flourish within appropriate boundaries. Both project managers and executives need to understand the impact that new developments in technology are having on business from the project, operational, and risk points of view. It is possible to split the responsibilities of methodologies into three broad areas:

Managing project performance.

Managing the project life cycle.

Managing the resources and communications aspects.

Having the right processes in place to address these areas is a challenge faced by every project manager. I address each of the components of the guidelines because I believe they provide a well-researched and practical solution to this project management challenge.

Everywhere I go, clients ask the same question: "How do our project practices compare with those of our competitors or with those of our peer organizations?" Until now, this information could be obtained only from consultants, market research, or other third-party sources. The project methodology maturity models provide information whereby an organization can carry out a self-certification to grade its own processes from virtually nonexistent to the purist levels, principally as a means of identifying improvements and actions to take.

It is essential that the management of any organization identify and articulate its critical success factors (CSFs). These are the ground rules that determine the appropriateness of the environment in which the organization operates. The CSFs set out the culture, behavior, and actions for management to take to achieve its objectives relating to project methodologies. The guidance provided in the chapter should be easy to apply in practice.

Assessing the Project Methodology Ecosystem
In the context of this book, a project management methodology is considered part of an overall larger ecosystem. The ecosystem can be viewed as a "give and take." Whenever you "touch" the ecosystem, there are things that are bound to occur. Table 2.1 lists what the ecosystem consists of.

Table 2.1: Project management ecosystem components Component
Example

Project standards and best practices
PMBOK, RUP, Java

Supportive processes
Change control

Project management infrastructure
PMO

Templates
Project brief

Performance metrics
ROI, BCA

Project activities
Testing

Project techniques
WBS, Use cases

Project tools
MS project

Project roles and responsibilities
Project teams

Core project methodology framework
PMLC process

Development methodologies toolset
Prince2, XP, Spiral


Figure 2.2 shows the makeup of the project management methodology ecosystem. Remember that any sudden change to the core methodology will result in a change to many other areas, such as templates and a ripple effect on supportive processes. Project managers wanting to deploy any methodology in an organization should realize this natural effect.

Best Practices for Project Methodologies
Most projects share a common life cycle. This is not to say that these projects are all designed and executed the same way, but they remain universal, as they pass similar phases during the life cycle of the project. When dealing with any methodology, ask the following questions:

How do we ensure that our projects develop and deliver successful products? Is the methodology able to accurately capture requirements and effectively manage the project against those requirements?

How can we deploy projects more quickly, avoiding overruns and poor performance, and for better value, lower cost, and better functionality?

When looking at organizational project methodologies available today, we realize that certain methodologies work well and some do not. Some are more proactive than reactive. For those that are not well planned, the organizations will simply not have success with those methodologies. Competitors will overpower them and deliver products faster to the market, and the organization will face competitor lockout. Some of the following best practices are needed before designing, purchasing, or benchmarking a prospective solution:

Provide standard proven processes and techniques.

Benchmark or leverage the best that your industry has to offer.

Create a list of "must-have" components.

Recognize the necessary processes you need to complete projects.

Consider the best cost and time schedules for your methodology.

Determine what core competencies are important.

Configure resources.

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. It's not up to you to start reorganizing the organization just for your project. First, see what's within your boundaries. Then act from there.
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).


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 doesn't 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 client's 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 don't 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 manager's 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 up.

Completion and Post-Implementation Audit
When all stages are completed to the satisfaction and agreement of all parties, it is important that the project be recognized as complete. At this stage, it is crucial that the project manager document the following before starting another project:

Job descriptions for operations staff.

Job descriptions for systems staff.

Working practices for operations and systems teams agreed on by management, operations manager, and systems manager.

Rolling plan for update, upgrade, and replacement of equipment over the next two to five years.

A plan to ensure that all documentation is complete and signed off.

A plan to ensure that all contractors, subcontractors, and self are paid up-to-date.

A postimplementation audit date for three to six months after project close-down.

In the postimplementation audit (PIA), the project manager returns a few months after responsibility for the new system has been assumed by the client (i.e., steady—state). The actual audit procedures should be determined initially, indicating that a team will return to see whether the system is working as designed. Most of this audit consists of ensuring that the project team is adhering to established working practices. It is quite surprising how people misinterpret documented procedures and invent ways around problems. These issues of documentation standards are beyond the scope of this book. The PIA has rarely been carried out in the past and is only now gaining a reputation for its usefulness.

Roles and Responsibilities on a Project Life Cycle
Table 2.2 reveals typical roles and responsibilities that one would encounter on a project. The larger the project, the more roles and responsibilities would be added.

Table 2.2: Roles and responsibilities on the project life cycle Roles
Responsibility

Verify resource allocation
Project Manager

Assign individual responsibilities
Project Manager

Verify project scope and change control
Project Manager

Estimate work packages and time to complete project
Project Manager

Monitor and control life cycles
Project Manager

Reduce uncertainty
Project Manager

Improve decision-making process
Sponsor

Attain effective solution
PM/Analysts

Establish continuous improvements to project
PM/QA

Maintain focus of project goals and objectives
Sponsor/PM

Provide continuous feedback to executives and stakeholders
Project Manager

Manage project plan
Project Manager

Avoid possible risks and issues
Project Manager

Maintain focus of schedules, budgets, and work plans
Sponsor


Likes and Dislikes of Project Methodologies
Often, one person may give a project manager the best kudos and praise for adopting a certain project methodology, but too often, the kudos arise mainly from the ranks of the management layer. Methodologies are like an onion—just when you peel off one layer, you discover another layer waiting for you. Some of the pros and cons seen by managers and nonmanagers working on projects are listed in Table 2.3.

Table 2.3: What managers and nonmanagers think of methodologies Project Managers Think
Nonmanagers (Team Members) Think

Methodologies define a set of deliverables.
Methodologies do not really represent what actually happens.

Methodologies adhere to a structured approach.
Phases are often overlapping with other phases.

Methodologies bring structure to a chaotic environment.
Methodologies are a waste of time and unnecessary overhead.

This is the way companies should be run.
No one clearly knows the true value of this path.

Methodologies don't always reflect the technical requirements.


Blueprints for Business Innovation
Because the introduction of a project management methodology and its processes possibly needs to be integrated into the existing business processes, it becomes necessary to stop to look at what we need to take care of before simply designing a methodology. Business process reengineering focuses on optimizing existing processes and facilitates the redesign of these processes if they are outdated and superfluous to departments or units, they do not meet clients' needs, or they are causing long delays for meeting organizational strategy.

Look at how Dell Computers is able to reconfigure its production lines for flexible, more rapid market demands. They adapt more quickly than their competitors and apply great methodologies for their solutions. Look at how Walt Disney has moved beyond the realm of its theme parks by having its own line of cruise ships and entertainment—all innovative by design—reflecting that Disney is able to transcend the norm.

In Table 2.4, note that in any organization today, there are existing processes that directly interface with the aims and objectives of what many project managers are trying to do throughout the course of a project's life cycle. Remember that project management is about managing the triple constraints, which are (1) cost, (2) time, and (3) quality. It's not that simple for project or development managers to simply ignore existing processes to get their jobs done. The methodology should be tightly and seamlessly integrated into the existing processes, so much that they complement one another.

Table 2.4: Examples of processes in organizations Process
Function
Affects Project Management

Invoicing and posting of credits
Financial
ü

Purchasing of goods and services
Procurement
ü

Timesheet submission
Financial
ü

Financial monthly reporting
Financial
ü

Salaries
Financial
ü

Legal disputes and claims
Legal Council
ü

Recruitment of staff
Personnel
ü

Strategic prioritization of projects
Projects
ü

Quality control and assurance
QA
ü

Training
Training
ü

Profitability
Financial
ü


Methodology Design
The focus of this section is how project methodologies can be developed to support projects in a company. Developing a project methodology and adapting it to the situation often deal with changes on many levels—changes in culture, processes, and information systems. A culture can provide project teams with a shared frame of reference and facilitate communication. The processes can provide a structure of activities in the projects, which helps new employees and can provide a common language. Information systems may be linked to the process and provide the tools that influence the daily work.

The research is based on active participation during the development of a methodology for product development. The case illustrates the tendency to focus on the process level and underestimate the importance of influencing the culture and adapting the current system to the new envisaged processes. The results are analyzed to provide increased understanding of the success factors when new project methodology is to be developed. The aim is to create a framework that can be used by companies that want to develop a project methodology or improve their existing project methodology.

With any new process, the way an organization works—and its entire culture—changes. Hence, it becomes crucial that the project manager not only develop the project management processes themselves but also create:

Support plans.

Communications plans.

Deployment plans.

These elements facilitate cultural change in a company and are fundamental to a successful project management deployment. You should not "reinvent the wheel" for each client engagement. Tailor project management processes that best suit your needs. The project manager should understand business processes and be able to merge them with current and tested best practices to quickly and effectively produce a tailored, client-specific set of project processes. It's not easy—developing processes is a science in itself. The question is: Do you have time to implement these processes on your own? Or, is your time running out? How much help is needed to design these processes to support your project framework?
Project Methodologies Demystified
We now examine the relationship between methodology size, project size, and problem size. This discussion can be tricky because there is a tendency to think that more people must solve larger problems.

Project size and methodology are connected by a positive feedback loop. With relatively few people, relatively little methodology is needed. With less "weight," they work more productively. With greater productivity, they can address a larger problem with their smaller team and lighter methodology. On the other hand, when more people are assigned to a project, they need more coordination (i.e., more methodology). The heavier methodology lowers their productivity; therefore, more people are needed to accomplish the same work. Methodology grows more slowly than project size, so eventually they get to a point where they can solve the problem and manage the coordination activities (assuming sensible management).

Therefore, for a given problem, you need fewer people if you use a lighter methodology and more people if you use a heavier methodology. However, there is a limit to the size of problem that can be solved with a given number of people, and that limit is higher for a large team using a heavier methodology than for a small team using a lighter methodology (i.e., at some point, you will need both a large team and a heavier methodology). The difficulty is that there is no reliable way to determine the problem size at the start of a project and no way to know the minimum number of people needed to solve it. The number of people varies with the people in question. Finally, as the project grows in size, a different combination of methodology and project size becomes optimal.

To begin to consider what constitutes a good and effective project management or development methodology, you need to clearly understand what phases are available to use, within all the project and development methodologies that face you as a project manager. The most common phases you would likely encounter when discussing or designing a methodology are discussed in the following sections.

Discovery/Concept/Idea
A well-conceived idea is the creative stuff that makes everything important. It's why the project started in the first place. There is no launch if there is no acceptable initial idea. Brainstorming is an effective technique to help you develop a prime idea. Be aware of the effect that the external environment (customers, competitors, market, etc.) has on the idea. In the concept stage, the exact definition of the idea and strategy is derived. The objective is to develop a protocol with defined target markets, product concepts, and attributes.

Engagement/Concept
Because each project is unique and must be approached very differently from the next because of client requirements and demands, in the engagement or concept phase, the project manager and sales executive actually meet with the client and discuss possibilities and begin to extend the communications process between the parties involved. This is often the most important phase as it sets the standard going forward. This can initially be a single occurrence or a series of meetings that brings the stakeholders together. It identifies key role players in the project and starts setting responsibilities.

Analysis/Feasibility
The analysis or feasibility phase determines that the project has been thoroughly assessed and deemed economically or strategically feasible to continue. If the analysis weighs against the project's success, the project is discontinued or returned to executives for further discussions. It is highly recommended that projects be analyzed before commencing to the next phase of the project life cycle or methodology.

Strategy Planning
Every company needs to have a system for deciding on and formulating the necessity and priority of launching any project or product. Whether a new design or new release of software, the strategists need to plan within the framework of the business model. The strategy planning would allow decisions about launching additional projects to support a priority project or delaying certain projects to favor a more important project's getting to market.

Feasibility Assessment
Before committing time and resources to any development, it may be necessary to establish the need for the project. Sometimes, it's not feasible to commit the organization to even attempt the project because it simply duplicates another effort or costs too much to gain a successful foothold in the marketplace. Additionally, the technical feasibility of the project may be unknown, and without performing a proper feasibility study of the technology, the project would result in negative cost and schedule delays.

System Analysis
After the project is launched, it becomes vitally important to establish client requirements to start designing the eventual system or product. At this stage, the project team should use techniques to fully understand what the project should deliver.

Design/Development
On any project methodology, one of the key phases is the design or development phase. The phase represents the solution build. Key staff—such as designers, architects, or engineers—develop a solution based on either partial or full user requirements. This design will form the basic building blocks from which the project team will work.

Deployment/Execution
After the project has been built, tested, and proven to work as designed and specified, the project is ready for installation or rollout. It is during this phase that the product or system is finally assembled and installed. In addition to simply implementing a system, users must be trained.

Testing
This phase indicates the formal testing of the solution. Testing can be done either incrementally or at the end of a development phase if following a waterfall approach.

Quality Assurance
In the quality assurance phase, the solution is validated and tested against the initial specifications of the project.

Training/Education
Before any system or project is fully deployed, users need to be identified and trained. This phase may involve establishing the training requirements for the project and generating either the necessary training courses or documentation.

Rollout/Implementation/Deployment
This phase is the delivery of the solution within the client organization. The rollout takes effect when the system is ready to be installed either in a series of small increments or as a fullblown deployment. During this phase, it is crucial to have an implementation plan and schedule to assist with the details of rolling out the project to the client.

Maintenance/Support/Operations
After the project has been finalized and the product launched, it is considered operational or in production. Therefore, the product must now be maintained. Many products need constant updates or changes. For example, after a new software is launched, it is likely that some updates will be needed. Therefore, the project needs to address exactly how postproject changes will be handled and executed. Considerations such as how incremental changes will be implemented must be resolved. On many other projects, fulfillment and restocking of vital spare parts—including the vendors' support—are crucial in making this project a success. (Methodology support is discussed in Chapter 6.) In this phase, the organization or client introduces operational support for the project once completed. Tasks such as arranging help desk support, service level agreements, and monitoring and diagnostics are performed in this phase.
The Importance of it Methodologies
As many industries use information technology and focus on the development of software, it is appropriate to describe the IT environment to explain why different methodologies are needed for different things. For example, many construction companies that use the standard waterfall methodology are today using IT methodologies—such as RAD—to bring in their predictive and "heavy" schedules more quickly than before. And it appears to be working successfully.

With almost all IT projects today, we typically encounter any one of the following scenarios in which we need to adopt a development methodology. An IT project may consist of three core tiers:

Graphics User Interface tier (front-end). Usually done by visual development languages using tools such as Visual Studio.NET, Java.

Application middle tier. Usually addressed by a business-centric methodology.

Database tier (back-end). Usually accessing one or many databases to retrieve data or information, using tools such as SQL, Java, or object components.

The same development cannot be used for each tier. For example, you are tasked with an IT project in which you have to use only the top layer—the front-end—then you need to consider your specific development options. They may be application specific. The same applies for the other two tiers.
Identifying Your Project Maturity
Many companies are very aware of the important role project management plays in their companies, but many are somehow unable or unwilling to make a transition to develop their project philosophy to the next level. Companies want to know exactly (1) how well they are currently doing and (2) where they would like to be on a project maturity level. After all, a company is more than just existing processes, policy, and procedures.

To use an analogy, if you had to take a life-saving drug that was developed by a company certified at capability maturity model (CMM) Level 5, compared to a company with only a CMM Level 1 certification, you would go with the company with the Level 5 certification. After all, it gives you the sense of a mature project-based organization, which has its act together. If project management is to take a leading role in a company, it needs to be good in a few areas, which follow:

A project management philosophy is firmly entrenched in the company.

Management has bought into project management as a core competency.

The company is focused on making projects succeed.

The necessary project processes and infrastructure are established.

An effective reporting system is established.

The project methodology and development methodologies are well documented.

Project staff is provided continuous training to update their skills.

Project information is communicated continuously.

Projects are monitored against performance.

Quality and delivery excellence are built into all projects from day one.

Projects are routinely audited for compliance with company standards.

The Capability Maturity Model (CMM)
So what is the buzz all about when it comes to CMM and why should we care? The Software Engineering Institute's (SEI) CMM is not actually a life cycle methodology, but rather sets of strategies for improving the software process on a projects. Therefore, I have not included CMM in Chapter 3. Many companies using CMM are stuck in a default waterfall methodology mentality and have neglected the spiral or iterative development methodologies. This is not CMM's fault at all, but project managers should understand that the waterfall approach is not always the best way to proceed. However, CMM has made advances in covering aspects of iterative methodology projects, although this doesn't always come across as being communicated to the project community. CMM tends to overemphasize inspections, peer reviews, and enforces strict quality assurance (QA) adherence, forcing many projects into paper and meeting "overload," which is also not good.

The primary objective for any company is to achieve a Level 3 CMM certification. Many companies are rated on how well their processes and systems meet the best project standards. In other words, if it does the prescribed set of foundation project activities, it is a Level 2. If it then does a prescribed set of project activities as a "company," it is Level 3, and so on. Essentially designed by SEI to help organizations overcome their problems, the system provides an effective and proven method for gradually gaining control of and improving product development processes, a yardstick against which companies periodically measure their production process, and data with which to prioritize and manage improvement efforts. I have included CMM in this book because many people are convinced that it is a variant of a project methodology, which is untrue. The areas of CMM are: (1) SW-CMM for software, (2) SE-CMM for systems engineering, (3) IPD-CMM for integrated product development, (4) SA for software acquisition, and (5) P-CMM for human resources.

An instrument for assessing a company's current maturity level and project practices is a software capability evaluation (SCE), which determines whether a company "says what it does and does what it says." Therefore, to gauge a company's actual performance, you need to perform an accurate assessment, which is not always done; instead, CMM is applied as both the development and assessment standard. The RUP or ISO 12207 standards are other references.

Together, this set of strategies is being integrated into what is now known as CMM Integration (CMMI). The CMMI is a more activity-based approach, which integrates many of industry's modern best practices and discourages an alignment with the waterfall mentality. Hence, CMMI is more iterative in concept versus the traditional CMM waterfall concept.

CMM describes both unique product development practices and the common management practices that any organization must perform. These practices are organized into five levels, each level describing increasing control and management of the production environment, starting with ad-hoc performance and culminating in controlled, structured, continuous improvement. An evaluation of the organization's practices against the model, called an assessment, determines the level, establishing where the organization stands and which management practices the organization should focus on to see the highest return on investment.

SEI Fellow Watts S. Humphrey created CMM in 1987. CMM is more than 10 years old and has greatly influenced the software industry by having us focus on the development and project process. However, technological shifts are taking place that require development to be more proactive. Originally funded by the U.S. Department of Defense, CMM is used by more than 5,000 government and private companies in more than 42 countries. Large portions of the Level 5 assessments that have been made are based in India. One of its primary goals is to identify and reduce errors during the initial coding process and thereby reduce the amount of rework required from finding errors during testing. The CMM is organized into five maturity levels:

Level 1: Initial. This describes a company with an immature or undefined process. The software process is characterized as ad hoc and, occasionally, even chaotic or unpredictable. Few processes are defined, and success depends on individual effort and heroics.

Level 2: Repeatable. Project management structures and controls begin here. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. The key components of project management at this level are: requirements management, software project planning, software project tracking and oversight, software subcontract management, software quality assurance, and software configuration management.

Level 3: Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. The key process areas at Level 3 address both project and organizational issues. At this level, the company establishes an infrastructure to institutionalize software engineering and management processes across all projects. Compliance with these standards for all projects and by all project managers and development teams is needed.

Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood, controlled, and evaluated by an executive and related staff. The key process areas at Level 4 focus on establishing a quantitative understanding of both the software process and the software work products being built. They are quantitative process management and software quality management. It is at this level that analysis tools such as function point analysis and other performance metrics are implemented.

Level 5: Optimized. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. The key process areas at Level 5 cover the issues that both the organization and the projects must address to implement continual, measurable software process improvement—defect prevention, technology change management, and process change management.

Getting your company to make an effort to move up the CMM ladder may not be easy. CMM focuses mainly on activities and supporting documents associated with a conventional waterfall process, such as plans, specifications, QA audits, inspections, and formal documented processes and procedures. It's very documentation orientated, and this drive to produce more documents can actually slow a company down. However, this needs to be better addressed by CMM.

Many companies simply do not have the commitment, time, and resources to graduate beyond Level 1 or 2 on the CMM scale. So they stay there. The downside is that these companies eventually lose business, because nobody wants to hire a company who is rated as "ad-hoc" Level 1 on the CMM scale. There are even fewer companies identified at Levels 4 or 5. However, at these levels, you will undoubtedly find that more reviews, inspections, and meetings take place just to satisfy the CMM auditing and certification requirements.

In conclusion, assessing your project management in your company and thereby gauging yourself against others requires that you apply some form of metrics to your projects. CMM/ CMMI techniques are a way to do this, showing you know how your project management measures up to the rest of the industry. It's a clear way to determine if "you're doing what you say you can do."

Using the Mind-Mapping Concept
The one effective way to lay out the envisaged framework of a project methodology is to illustrate or mind map it on paper first, thereby addressing all areas of the organization. Figure 2.4 shows a typical mind-map framework. You can easily start developing a framework in this manner. Look at the way we mentally organize our thoughts—as this is very relevant to thinking about methodologies. If you cannot map out a process, it is futile. However, the human brain is so sophisticated that the mind-mapping method guides the methodology development process. Your brain initially encounters biochemical or electromagnetic resistance along its pathway, where thoughts are reduced. It's like trying to clear a path through a forest. The first time is a struggle, as you have to fight your way through the undergrowth. The second time you travel that way, it is easier because of the clearing you made on the first pass. Frequent repetitive events make it easier for you. Likewise, creating mind maps and documenting them in creative graphical formats assist the human brain in receiving, holding, analyzing output, and control. What happens in your brain when you want to design a project methodology? The answer is both simple and amazingly complex. Every thought or bit of information entering the brain—experiences and memory (template, code, word) can be represented as a central sphere that radiates tens, hundreds, thousands, millions of hooks—which represent associations—that in turn have their own links and connections. The number of associations you have can be thought of as your memory or database. As you read these words, you can be assured that in your brain is an analytical super computer that is far superior to many of the world's most advanced computers. The mind-mapping technique offers us the following approach:

It has a central theme.

It has branches of themes, which radiate from this central core.

These branches contain keywords and are connected.

This together creates a "picture" of the solution or idea you need.


Figure 2.4: Mind-mapping methodology.
A mind-mapping method can be extended easily to designing or conceptualizing any project methodology in existence in a graphical manner. From this, anything is possible.