Understanding Project Methodologies

What is a Methodology?

In my quest to define methodology, I started by asking colleagues and associates some questions with the intent of "stirring the pot." I received at least 20 different definitions of what a methodology is and used only those definitions that seemed helpful. The questions I posed were: What is a methodology? Should there be many methodologies? Is one better than another? How would you know which phases to adopt? How can we apply these results to a project? The answers to those questions resulted in the following definition of a methodology:

A methodology is a set of guidelines or principles that can be tailored and applied to a specific situation. In a project environment, these guidelines might be a list of things to do. A methodology could also be a specific approach, templates, forms, and even checklists used over the project life cycle.

A methodology can also be defined in other ways; for example:

• A process that documents a series of steps and procedures to bring about the successful completion of a project.

• A defined process for accomplishing an end.

• A series of steps through which the project progresses.

• A collection of methods, procedures, and standards that define a synthesis of engineering and management approaches designed to deliver a product, service, or solution.

• An integrated assembly of tasks, techniques, tools, roles and responsibilities, and milestones used for delivering the project.

A formal project methodology should lead the work of all team members throughout the life cycle of a project. All members of a team should be familiar with and use the chosen methodology throughout their projects. Many project management methodologies address the management of a single project, without appreciating that many other projects in a company compete for the very same resources and attention. The project management methodology should also provide project managers with the perspective that there is a project management framework and associated methodologies present in the company. It may be useful to think about what a project management methodology is not:

• A quick fix.

• A silver bullet.

• A temporary solution.

• A cookbook approach for project success.

How Many Methodologies Are There?

There is no one-size-fits-all methodology. Some companies have methodologies that cover everything from an initial sales call to operational support, while others cover merely the aspect of design and development. Most published books discussing methodologies focus on one role—the IT community. These books elaborate on how specific IT designs should be performed, discussing a few techniques and a few drawing standards for a specific methodology. Fitting this into your company's idea of a project methodology framework is sometimes difficult to understand, impractical, and not always easy to implement.

There is an additional problem with the single universal project methodology approach. Many project managers have found that, in practice, you cannot simply use a methodology exactly as it stands. They soon realized that they needed to modify and tailor whichever methodology they selected to suit their own company project needs. They followed a "pick-and-choose" approach, using what they needed.

When examining methodologies later in this book, we see that a methodology is "larger" when it contains more elements. Because a methodology exists primarily for project managers to coordinate project team members, coordination is appropriately larger on a large project. The methodology grows proportionally to the number of roles and work product types. Therefore, we should not expect a small-team methodology to work properly for a big team, or a big-team methodology for a small team. Thus, you need to be practical about selecting an appropriate methodology.

Shortcomings of Many Project Methodologies

There are shortcomings to any methodology. Before we start by describing the best way to proceed with project methodologies, we need to first understand where methodologies can possibly go wrong. In my search for the über-methodology to recommend, I realized that many project methodologies:

• Are abstract and high level.

• Contain insufficient narratives to support these methodologies.

• Are not functional or do not address crucial areas (i.e., QA, CM, testing).

• Ignore the industry standards and best practices.

• Look impressive but lack real integration into the business.

• Use nonstandard project conventions and terminology.

• Compete for similar resources without addressing this problem.

• Don't have any performance metrics.

• Take too long to complete because of bureaucracy and administration.

Projects Influence Methodologies

Not one single project methodology can solve every project across all industries. For example, the Channel tunnel project linking the United Kingdom to France came with many problems and had major cost and schedule overruns. Project methodologies were developed to prevent such problems. Many project methodologies come close to preventing problems, and many are tailored to specific uses, but it finally boils down to applying solid project management principles. Methodologies affect project management; they affect any project universally in the sense that each methodology:

• Contains project phases.

• Measures progress.

• Takes corrective actions based on defects found.

• Assigns resources to various phases.

Project methodologies are useful to companies only when the tasks are appropriate and applicable. In many project studies, project plans are seldom updated. Why is this? Many projects focus only on satisfying clients during the initial deployment phases instead of conforming to the actual plan as the project proceeds throughout the project life cycle.

Defining a Project

Although this book focuses primarily on various project management frameworks and development methodologies, we first clarify what a project is—a temporary effort of work, a one-time event that meets the following criteria:

• Has a start and an end date.

• Has schedule, cost, and quality constraints.

• Is a unique endeavor and contains risk.

• Has a certain scope that needs to occur.

Typical everyday examples of where we could apply a project management methodology and a development methodology include:

• The development of a new freeway as part of an existing road network.

• The creation of a new business unit in an organization.

• The design and development of a new computer system.

• The search for a pharmaceutical drug for a life-threatening virus.

• The development of a naval or space vessel.

• The creation of a new political party.

Project managers should realize that any repetitive continuous process is not a project. They should be focusing on a one-time event. Traditionally, a business unit decides that an organization should develop a product and turns it over to the relevant project group to establish a plan and manage the project. Additionally, the project manager must ensure that the project actually fits into the project plan that was built. Executives or clients then routinely scrutinize this plan to check for variances and request the necessary corrections or deviations. Project management thus has an important role to play. Project changes and new requirements will always be present because of legislative, regulatory, technological, or new strategic initiatives. We see why in the next section.

Project Management Demystified

Before looking more closely at methodologies, we need to be aware of the key tasks that a project manager performs on any project. These are not all the objectives that you might encounter on a specific project, but the list will give you a basic feeling for what objectives are to be met.

Objectives	Responsibility	How
Obtain the user requirements	Analyst/PM, client	Interviews, URS
Define the project	PM, Client	Definition report, Business case, Feasibility study
Plan the project	PM	PBS/WBS, Gantt
Negotiate for resources	PM, Sponsor	Resource plan
Create the project team to perform the work	PM	Team contract, R&R
Execute the project, including changes	PM	Implementation plan, Change requests
Control and monitor the actual versus planned	PM	Status reports, Issue and Risk logs
Close the project and release the resources	PM, Client	Closure report
Review project and support postproject	PM, Client	Questionnaire review

Many companies don't have sufficient resources to perform multiple projects concurrently because of (1) turnover, (2) untrained staff, (3) unavailable staff, or (4) functional restrictions in their departments. It is important that project managers be aware of the resource commitments to other projects in their organization. A complete project management framework can determine these requirements upfront and well in advance of any crippling resource problems.

Project Management Responsibilities

Throughout the life of any project, project managers are responsible for the key areas. Some of these responsibilities, which tie in directly with any project methodology, follow:

• Obtain approval for the project to proceed.

• Determine the project scope and its feasibility to the overall business.

• Ensure the necessary project resources are identified and allocated.

• Plan the project to the relevant detail it requires.

• Ensure that the project methodology and associated processes are adhered to.

• Monitor the project in terms of cost, quality, and schedule.

• Identify and monitor project issues and risks.

• Provide updated reports and summaries to key stakeholders.

• Provide leadership to the project team.

Status of Projects Today

Across all industries—whether IT or construction—we are encountering many of the same problems time and time again, irrespective of geographic location. I have heard project managers in China, Brazil, Amsterdam, and Munich complain bitterly about similar issues on their projects. Problems such as cost and schedule overruns, poor sponsorship, no user involvement, and many other problems are encountered daily. These project managers either don't use their project methodologies effectively or don't use them at all. Project management is not simple; our primary role is to resolve or eliminate daily challenges. We now examine some of the universal challenges facing project managers.

Challenge	Questions Facing Project Managers
Competition gaining ground	How do we develop projects faster than before?
Constantly changing requirements	What do we need to meet both project and client needs?
Larger and more complex projects	How do we ensure quality is built into our projects?
Inaccurate designs	How do we ensure our methodology captures an effective design?
Ineffective documentation	How do we know which templates to use per project type?
Inadequate resources	How do we address resource requirements and plan for them?
Postproject support	How do we address handoff of our project to operations?

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.

Project Management Frameworks

Selecting Your Methodology

Every company currently without a project management framework needs to identify, select, tailor, or build one before managing a project. Some structure is necessary. If management wants their company to be successful in a project-based world, they should start moving. They should think about the following objectives before deciding on a project management methodology:

• The overall company strategy—how competitive are we as a company?

• The size of the project team and/or scope to be managed.

• The priority of the project.

• How critical the project is to the company.

• How flexible the methodology and its components are.

Best Project Methodology Practices

To ensure a project's success throughout the entire methodology, project managers and project office managers should adhere to the following recommended best practices when selecting, building, or tailoring a project management methodology:

• Use standard-proven processes and techniques.

• Draw on best industry practices and trends.

• Use best practices to reduce common pitfalls.

• Look at implementation time and cost reduction.

• Minimize excess templates and administration.

• Consult industry leaders and subject matter experts (SMEs).

• Acknowledge the best path for project implementation.

• Recognize what should and should not be implemented.

The following summarizes four key principles in methodology design that should be reinforced:

1. Use larger methodologies for larger teams.

2. Use denser methodologies for more critical projects.

3. Weight is costly.

4. Interactive, face-to-face communication is most effective.

Methodology Utilization

When using any project framework methodology, ensure that it doesn't become bureaucratic and so administrative in detail that it actually stifles any sense of creativity or overrides common sense. For example, you have a project that must be completed within four months. You have to design and deploy a new product. As project manager, you understand that you cannot spend all your time creating elaborate documentation and hold meetings to create new processes. Time is against you; therefore, it would be wise to first adopt the correct methodology. Developing the organization's project management framework is one of the core foundations of any business to ensure project success. This framework should include:

• A total project management approach from start to finish.

• The key phases that the company would possibly use.

• Inclusion of quality gates or checkpoints during each phase.

• Necessary review points between each phase.

• Preproject and postproject phases (e.g., sales, operations).

• Project templates.

• Project processes per phase (i.e., change control, risk).

Using a proven project framework based on industry best practices and tailoring that approach to fit your organization's culture and practices are the keys to success. In the following section of this chapter, we review different types of methodology frameworks used by industry today.

Rational Unified Process (RUP) Project Framework

The Rational Unified Process, or more affectionately referred to as RUP, is a customizable project methodology framework aimed primarily at software development. It is a complete software development process framework that comes with several out-of-the-box examples. Processes derived from RUP vary from lightweight—which address the needs of small projects—to more complex heavyweight projects. To date, projects of all sizes have successfully used RUP.

This methodology enhances team productivity and delivers software best practices to the project team through a set of components, which in turn consist of guidelines, templates, and best practices from thousands of development projects. From large-scale enterprise to agile projects, RUP allows organizations to develop projects more rapidly and deliver quality even when using this process.

The components of the RUP framework

4 phases

8 iterations (minimum)

9 workflows

57 activities

270 activity steps (approximately)

114 artifacts

38 roles (up to 38 people)

PRINCE2 Project Framework

PRINCE2 is an acronym for Projects in Controlled Environments (second version) and is now the United Kingdom's de facto standard for IT project management. The Central Computing and Telecommunications Agency (CCTA) originally developed this structured project management methodology, which now forms part of the Office of Government Commerce (OCG)—a government agency—for the development and implementation of IT projects. In fact, this methodology is now so popular that many companies hire only PRINCE2-certified project managers. More and more companies are moving toward adopting this as their standard project approach. Companies such as British Rail, Nat West, Hitachi, BT, London Underground, and Royal Mail, among many others, benefit from using PRINCE2. Some of the many features of this methodology are:

• A defined project management structure.

• Flexible decision-making points.

• A system of plans for resources and technical issues.

• A set of control procedures.

• A focus on products—deliverables to the client.

• A focus on project deliverables throughout the project.

This methodology can readily be applied to non-IT projects as well; therefore, even the construction industry can use this methodology. It is a project management methodology specifically designed to be generic and independent of any particular project type and complexity. This makes PRINCE2 methodology even more interesting to consider. It is nonproprietary, easy to use, and, with some basic training, an excellent approach. Similar to the Dynamic Systems Development Methodology (DSDM). its use is dramatically on the increase in both the public and private sectors. A feature in PRINCE2 not seen in other methodologies is the concept of assuring progress from three separate but linked perspectives. Most organizations that adopt PRINCE2 choose it primarily for its wide applicability and use the pieces that actually "work for them."

System Development Life Cycle (SDLC) Methodology

Many projects follow the classic waterfall approach, and it is fairly straightforward to conceptualize. No rocket science is needed here. You simply have to focus on the logical progression of what needs to happen on the project. The SDLC is in essence a waterfall methodology. Successful companies such as Johnson & Johnson, Novartis, Adventis, American Express, and Nokia use and adhere to an SDLC approach.

Simple approach

Phases	Phase Description	Critical Plans
Discovery	Researches and refines organizational objectives for the project.	Strategy/roadmap
Design	Provides the design and solution to the organization.	Blueprint design
Construction	Constructs the product against the design blueprint.	Project plan
Implementation	Implements the tested solution into the organization.	Test/deployment
Follow-up	Ensures that solution is rolled out smoothly and irons out issues.	Maintenance

Project Templates and Techniques

Establishing a Template Road Map

Templates—also referred to as artifacts or boilerplate templates—are essential to the success of any project. Templates are seldom found bundled together nicely in a box, ready for use. Project or development managers do not want to spend the time to create new project templates for their projects. Instead, they benefit greatly from using a wide variety of tried and tested methodology templates, which gives them time to concentrate on the actual project.

This chapter provides a reliable source of useful methodology templates that might be required by project or development managers during specific project phases. Whether managing projects or actually developing the technical detail (i.e., design or build phase), you will face constant change. Methodology templates support the user in creating and maintaining project data/information in a formalized and structured manner. Templates also focus on guiding users to specifically define key deliverables, addressing issues such as quality, scope, resources, risk, and cost. These templates help project team members gain a better understanding of the project and its associated tasks.

Advantages and disadvantages of project templates

Advantages	Disadvantages
Reusable— no need to start from scratch	Needs custom tailoring
Saves time	May contain difficult style and ineffective format
Pick and mix
Ease of use— simply edit, copy, and paste
Format already exists

Although the lightweight methodology family discussed in previous chapters does not encourage large amounts of project documentation, it requires some methodology templates.

Template Selection

I recently bought a pair of snow boots from the Timberland Web site. After selecting the boots, I was immediately offered accompanying winter socks—an excellent way to cross-sell something I had not planned to purchase. Likewise, when choosing a methodology, you would surely need some templates to accompany it. After you have defined the methodology, add the appropriate methodology templates (e.g., concept phase would require a business case template and a feasibility template).

Purpose of Project Templates

The definitions and templates found in this book are best described as generic because certain methodologies and companies may have their own variations of the templates they need. Therefore, project templates should be modified based on the specific methodology to be used or tweaked to suit your company standards. Once you obtain the CD-ROM, there are 120 different project templates available for use. The structure is listed in possible phases you could expect to encounter on a typical project. If you have just started your project, you would open the Concept Phase folder and locate the relevant template.

Concept Phase Templates

Master Record Index Template for Project Start

The master record index is used at the start of a project. It lists all documents used during the initial phase of the project and indicates status of the documents (i.e., approved or not approved). The master record index assists in auditing and provides project managers with a quick reference of documents required for the project. This is a one-page document and the template is simple to complete.

Feasibility Report Template

The feasibility report is a formal report that provides the findings of the feasibility study, which is undertaken before the project starts. The report includes an overview of the request, the reasons for initiating the project, the findings of the study, recommendations either for going forward or for rejecting the request, and the estimated cost and effort of the project. If available, it also summarizes the expected advantages to the group (e.g., cost savings, less maintenance effort) of the new deliverable.

Product Brief Template

The product brief document describes the aim, benefits, and objectives of the proposed product. It could describe the development of a new photocopier, satellite, or medical drug. Additionally, it establishes the parameters for the work to be done, including tasks to be performed (scope) and tasks not to be performed (outside of the scope of the project). It may include expected deliverables, risks, the project team and their roles, and measures of success (close-out criteria).

Product Plan Template

The product plan document describes where the product will compete, development time line, scope, and resources.

User Requirements Specification (URS) Template

The URS document describes, in business terminology, the client's project requirements. Many failed projects have had either no or poorly documented user requirements. The client should typically complete the URS, but this does not always happen. In any event, be prepared to complete this template for the client, because the URS sets the entire direction of the project. Without a URS in place, you may encounter clients asking for more than what was originally bargained for. The URS usually precedes a system requirements specification document.

Design Phase Templates

Technical Specification Template

A technical specification document is needed because it formalizes the technical details of the project. It should detail the development methodology to be followed for the solution. The technical manager of the project should work in conjunction with subject matter experts (SMEs) or vendors to create the required technical specification documents. There can be more than one technical specification, depending on size and complexity of the project. For example, you could have billing, software, and integration specifications just for one project. The technical specification document can be formal (e.g., for heavyweight methodologies) or informal as a workflow or software code (e.g., for lightweight methodologies).

Provisional Implementation Plan Template

During the initial phases of the project, the provisional implementation plan document should be used to start planning the implementation of the project.

Provisional Back-Out Plan Template

Developing a project back-out plan is rarely considered in many project organizations today because those involved assume the project will succeed. However, only 16.2 percent of projects succeed; thus, 83.8 percent fail. A back-out plan is necessary because the initial project plan may not be successfully launched or it may fail because of technical difficulties. The backup plan, which should describe a safe, alternative route, then takes effect.

Functional Specification Template

The functional specification is a technical document, usually prepared by the development team. It describes the user requirements in technical terms in preparation for system development.

Master Record Index Template—Design Phase

This index lists all the documents that are required during the design phase of the project. This is a good way to keep track of the approved documents in each phase—you can readily open the project binder and determine which documents were approved and used during the design phase.

Resource Allocation Template

The resource allocation document can be used by a project manager to document all resources (team) working on the project. It helps manage the resources' time over the entire project. This useful template allows monitoring of percentage of resources' time and monthly costs to the project.

Provisional Service Level Agreement Template

The provisional service level agreement sets out the necessary levels of support needed for the project after it is deployed. The provisional service level agreement defines the services needed and states to what extent they will be met.

Deviation/Concession Template

The deviation template is a formal document used by the project team to indicate any deviation from the original scope of the project. It signifies that a deviation has been made and that all parties agree to the change.

Actual Cost Spreadsheet Template

The actual cost spreadsheet is useful when a project manager would like to capture actual costs of the project—staff, equipment, suppliers, and associated costs.

Build Phase Templates

Master Record Index Template—Build Phase

This index lists all the build phase documents that may be required by the project during the build phase. It helps keep track of the approved documents for each phase; you can readily open the binder and quickly determine which documents were approved and used during the build phase.

Acceptance Testing Template

Acceptance testing is performed by the QA team to test and accept the solution that has been built before release to the client. Many clients have their own acceptance testing staffs, who need to be included in the development of any acceptance testing documents.

Test Plan Template

The test plan lists specific situations or events (test cases) to test for functional (incorrect logic) or interpretation (miscom-munication at the design stage) errors. Test cases and expected results are prepared before the test phase.

User Acceptance Test (UAT) Plan Template

The UAT document lists the specific business requirements (test cases) to test the business logic and flow of the solution. This includes testing to ensure the system meets the business needs (tests against the business requirements).

Development Testing Template

This document, which tests for functionality and stability, may be performed at (1) a module or program level and (2) a system level, which also tests the interaction between modules or programs (operational test procedures).

QA Error Log Template

The QA error log is used to record all errors on the project after finalization by the deployment team. The error log lists all errors found by the QA team and should include specific examples of how and when the errors failed during the test process. Until all the errors have been resolved, the product or solution cannot be delivered to the client.

Project Processes and Trends

Process Considerations

Looking beyond your company's portfolio of projects—products and services that it works so hard on—reflect on those core processes needed to support overall objectives. Beyond being passionate and committed in your work, there must be a fundamental focus on having the right processes in place. There will always be opportunities for you as project or development manager to tailor processes; therefore, you must understand how and when processes come into play. Someone once said, "We don't use standard business processes; we have unconventional ways of recharging our entire business, which totally support our project and development methodologies."

On any project you undertake, you may encounter situations from which you need to remove certain processes because they are not in your project scope. For example, you don't need to do financials on your project (on many projects, project managers don't touch finances). In this case, you would drop the financial process and use the rest. Or, you are using a Waterfall methodology on a project and your client insists on document management (i.e., version control, distribution). In this case, you need to add this process to the project scope. Project methodologies:

• Demonstrate the ability to get the job done.

• Meet certain criteria set by auditing or certification groups monitoring the company.

• Allow the company to prioritize resources accordingly, based on the project's progress.

What Core Processes Are Available?

Core processes are typically those key processes that transform "what the company does" into valuable outputs for its client. Without these key process areas in place, projects would struggle to meet their schedules.

Processes	Area Addressed	Resource Needed
Change control	Configuration management	Configuration manager
Procurement	Purchasing of equipment	Procurement manager
Issue and risk	Problems on the project	Project manager
Documentation	Document management	Configuration clerk
Estimation	Project cost forecasting	Cost estimator
Communication	Project communications	Project manager
Recruitment	Hiring new project resources	Human resources/personnel
Marketing and sales	Marketing and sales	Marketing and sales manager
Project framework	Actual project methodology	Project manager
Finance	Budgeting and invoicing	Financial manager
Audit	Project	Quality assurance
Quality assurance	Project quality	Quality assurance manager
Training	Training	Trainer
Product development	Developing/manufacturing	Development manager

Decide which processes you need on the project. You could use either all of them or only a selected few. However, they need to be available and ready to execute when a project manager wants them. Companies that are ISO certified or regulated by groups such as the FDA or CMM often have their processes in place, which implies that these companies have defined key processes across the organization and their staff are familiar with them.

Project management processes have been around for years, but have never been fully integrated into the project management "space" or ecosystem. Recently, processes have been reemphasized through changing technology and commercially available methodologies that necessitate leveraging all processes, which were possibly never fully used before. However, organizations have been slow to adopt them because most off-the-shelf processes are too generic to work effectively.

Key factors for defining processes

Provides guidelines for efficient development of quality systems and solutions.

Reduces risk and increases predictability.

Captures and presents best practices.

Promotes a common vision and culture for the organization.

Provides a roadmap for applying tools and techniques.

Easy to understand and simple to use.

Project Methodology Processes

As discussed in earlier chapters, the necessity for having solid project processes in place remains undisputed. Some of these essential project processes are:

• Issue management process.

• Risk management process.

• Change control process.

• Procurement process.

• Planning process.

• Estimating process.

• Quality assurance process.

Issue Management Process

An issue is something that has happened that can threaten the success of your project. With issue management, you encounter typically four different scenarios:

• Unconscious issues (there, but unknown).

• Conscious issues (not publicly known, although discussed with the right people).

• Shared issues (shared but remain unresolved).

• Shared and resolved issues (the ideal scenario).

Change Control Process

When we speak about change control, then I have to address the whole issue of scope creep, both on the end user's side and on the developer's. The business plan (should) define the value that will result from the expenditure of money and resources. This value definition needs to be translated into specific measurable requirements that then become the functional specifications for the developers. Then the change management process can track the impact of new insights and understandings as the project matures without losing scope of what it was that was originally determined to have enough business value to warrant the project in the first place.

A change management process should control changes in any project environment affecting products or services being developed by the project team. A core change team must assess the impact of any proposed changes to gauge cost, schedule, documentation, and training, plus the change's impact on retooling implications. The change management process identifies, defines, evaluates, and approves these changes before any implementation. This configuration management process must be introduced to the project, through the implementation of five key formal processes for:

1. Submission and receipt of change requests.

2. Review and logging of change requests.

3. Determination of the feasibility of change requests.

4. Approval of change requests.

5. Implementation and closure of change requests

Submit Change Request

This process provides the ability for any member of the project team to submit a request for change to the project. The following procedures are completed:

• Change requestor identifies a requirement for change to any aspect of the project (e.g., scope, deliverables, time scales, organization).

• Change requestor completes a change request form (CRF) and distributes the form to the change manager. The CRF provides a summary of the change required, including the:

  • Change description.

  • Reasons for change (including business drivers).

  • Benefits of change.

  • Costs of change.

  • Impacts of change.

  • Supporting documentation.

Review Change Request

This process allows the change manager to review the CRF and determine whether a full feasibility study is required for the change approval group to assess the full impact of the change. The decision is based primarily on the:

• Number of change options presented.

• Complexity of the change options requested.

• Scale of the change solutions proposed.

The change manager opens a change request in the change log and records whether a change feasibility study is required.

Identify Change Feasibility

This process involves the completion of a full change feasibility study to ensure that all change options have been investigated and presented accordingly. The change feasibility study involves definition of the:

• Requirements.

• Options.

• Costs and benefits.

• Risks and issues.

• Impact.

• Recommendations and plan.