Project Methodologies Explained

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:

1. Managing project performance.

2. Managing the project life cycle.

3. 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

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:

1. 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?

2. 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

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.