Project Management Frameworks

Overview
Sometimes you are faced with a project that could cost a small fortune—from hundreds of thousands of dollars to a few million dollars. As project manager, you are charged with delivering the project within cost, specification, and schedule. This is often the opening line for many project managers today. Without an effective project framework in place, it will not matter what you do—projects will undoubtedly be more complicated and troublesome. In this chapter, I provide a few project methodologies or frameworks used today across industry, as well as the components that make up these project methodologies. Sometimes, one methodology framework is not the most appropriate to use—you may need to adapt to some other methodology.

Vinod Khosla (April 2001) in "GigaTrends," Wired magazine, states: "Most of our predictions are based on very linear thinking. That's why they will most likely be wrong!"

In fact, the very success of the company could depend on the successful outcome of projects, so it becomes essential that you minimize as much risk as possible and approach projects in such a way that it almost guarantees success. But how do we do this? One technique uses a tried and tested project methodology, which covers all possible areas when a project starts. By employing the appropriate methodology, project managers are likely to deliver the solutions their clients want. I introduce and clarify two types of methodologies. Although they go hand-in-hand, there is a difference.

Project management methodologies (this lays the high-level project framework).

Development methodologies (this provides the detail on system design and development).

It is likely that you will encounter a project that consists of both a project methodology and a development methodology. You have the shell—dealing with the project approach, competencies, and so on—and then the content of the shell—which deals with the specific development approach. You can see more about development methodologies in Chapter 4 of this book. We concentrate on purely project methodologies in this chapter.

Some people would like to challenge my contention that many project managers often live a lie, perhaps by force, when it comes to adhering to a methodology. This normally happens when a project manager is assigned a project already half completed; he or she simply follows his or her best guess and proceeds from there—often ignoring key issues and steps that make a truly great project. He or she continues to plan, predict, and deliver as best as possible, working the best way he or she knows. It appears that many project managers do not want to create the wrong perception on their projects. As soon as the project starts, project managers jump in, build the solution one way, and when they encounter trouble, pretend to build it another way, flying by the seat of their pants. The lesson here is that rigid methodologies are often far too constraining and fall short in delivering a project into production. When we review many projects that have failed, we see that overhead is often created to prove that the methodology is on track.

When starting a project, many project managers gather as much documentation pertaining to the project as they can. They start creating elaborate project Gantt schedules, using sophisticated software tools, extending it to Pert charts, critical path networks, believing that by following a few simple techniques and a trick here and there, the project will start magically taking shape. However, being smart in a few project techniques and being flashy are not synonymous with great results. What's forgotten here is adhering to the methodology, as well as to the development model. You don't have to rigidly follow the project process step-by-step; you can tailor the framework at any stage for each project or solution.

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:

Use larger methodologies for larger teams.

Use denser methodologies for more critical projects.

Weight is costly.

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. Table 3.1 and Figure 3.2 show key areas that make up RUP.

Table 3.1: 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)



Figure 3.2: RUP project management process. Source: Life Cycles of the Rational Unified Process. Reprinted with permission.
RUP is not merely a process. It is valuable because it embodies many of the best project management practices available today, thereby making it a flexible framework to which project managers can apply their solutions. In other words, you could consider RUP to be a road map for project managers, analysts, testers, and so on. This allows resources to use a common project management terminology and a component "kit" on how to manage projects. If you already know project management, RUP merely becomes a checklist. However, if you are new to project management, RUP gives you a nice overview. Companies such as Wells Fargo and Merrill Lynch and numerous others have used RUP successfully (see Figure 3.3).


Figure 3.3: RUP cycle. Source: Life Cycles of the Rational Unified Process. Reprinted with permission.
The preferred approach to using RUP is to first determine what is missing from the organization's project management environment. After this assessment has been completed, decide how much change the organization can handle. For example, if a company's biggest problem is requirements gathering, RUP offers this process. When this company starts using RUP, you can reassess how successful their requirements-gathering process has worked. Over time, a RUP-based project goes through four distinct phases: inception, elaboration, construction, and transition. Each phase contains one or more iterations. In each iteration, efforts are expended in various amounts to each of several disciplines (or workflows) such as requirements, analysis and design, testing, and configuration management. The key advantage of RUP is reduction of risks (see Figure 3.4).


Figure 3.4: RUP life-cycle phases comparison. Source: Life Cycles of the Rational Unified Process. Reprinted with permission.
Virtually any company can use and customize RUP to suit the needs of its projects. This implies that RUP is as heavy or light as the project wants to go. The implementation of RUP could take from a few weeks to a few years, depending on how much process is required. Above all, use common sense when implementing RUP, as no major tools and techniques are needed. In the future, many companies will use RUP as a project management framework, whereby they can "hang" their best practices. RUP also provides information to help in using other Rational tools for better software development, but does not require the Rational toolset for effective application to an organization. It, therefore, allows you to tailor the process if none of the "out-of-the-box" road maps suit your organization or project. RUP emphasizes the adoption of certain best practices of modern software development as a way to reduce the risk inherent in developing new software. These best practices are:

Develop iteratively.

Manage requirements.

Use component-based architectures.

Model visually.

Continuously verify quality.

Control change.
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) described in Chapter 4, 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."

Figure 3.5 shows that PRINCE2 is a process-orientated approach for project management. Each process has its inputs and outputs with associated project tasks and activities to be carried out. The methodology shows us that a project is decomposed in manageable phases, allowing efficient command and control. For example, look at project planning. This phase is mainly interested in focusing on results rather than planning when the activities will be done. PRINCE2 is largely driven by its business case (see templates), which describes the business justification, rationale, and motivation for the project. The same applies to all phases shown in the figure. Integrating this methodology into a company's existing culture and processes may require the insight and assessment by certified PRINCE2 project managers, who are knowledgeable of this methodology.


Figure 3.5: PRINCE2 life cycle.
On the upper tier of the illustration, note that the project(s) may report to a corporate program management function. Start at "Directing a Project," which runs from the start-up of the project until the close. This process is aimed at the project board, who manages by exception, monitors via reports, and controls through a number of decision points.

PRINCE2 Phases
The key processes of the project board are these four main areas:

Initiating (starting the project on the right foot).

Stage boundaries (commitment of more resources after checking results reached).

Ad hoc direction (monitoring progress, providing advice and guidance, and reacting to exception situations).

Project closure (confirming the project outcome and controlled close).

This process does not cover the day-to-day activities of the project manager. In the middle tier, we find the phases, which are equally important to any project manager wishing to adhere to this methodology. The phases are:

Starting up a project. The first process in PRINCE2 is a preproject process, designed to ensure that the prerequisites for initiating the project are in place. The process expects the existence of a project mandate, which defines in high-level terms the reason for the project and what outcome is sought. Start-up of a project should be very short and should include the following:

Ensuring that the information required for the project team is available.

Designing and appointing the project team.

Creating the initiation stage plan.

Agreeing whether there is sufficient justification to proceed with the project.

Establishing a stable management basis on which to proceed.

Documenting and confirming that an acceptable business case exists for the project.

Ensuring a form and accepted foundation to the project before starting work.

Agreeing to the commitment of resources for the first phase of the project.

Providing the baseline for the decision-making processes required during the project's life.

Ensuring that the investment of time and effort required by the project is made wisely, taking in account the risks to the project.

Managing stage boundaries. This process provides the project board with key decision points on whether to continue with the project. The objectives of this process are to:

Assure the project board that all deliverables planned in the current stage have been completed as defined.

Provide the information needed for the project board to assess the continuing viability of the project.

Provide the project board with information needed to approve the current phase's completion and authorize the start of the next phase.

Record any measurements or lessons that can help later phases of the project(s).

Controlling a stage. This process describes the monitoring and control activities of the project manager involved in ensuring that a phase stays on course and reacts to unexpected events. The process forms the core of the project manager's effort on the project and handles the day-to-day project management tasks and activities. Throughout each phase, there is a cycle consisting of:

Authorizing work to be done.

Gathering progress status on work.

Watching for changes.

Reviewing the situation.

Reporting.

Implementing the necessary corrective action.

Managing product delivery. The aim of this process is to ensure that planned products are created and delivered, by:

Making sure that work on products allocated to the team is effectively authorized and agreed on.

Ensuring that the work conforms to the requirements of interfaces identified in the work package.

Ensuring the work is done.

Assessing work progress and forecasts regularly.

Obtaining approval for the completed products.

Closing a project. The aim of this process is to execute a controlled close to the project. The process covers the project manager's work to wrap up the project either at its end or at premature closure. Most of the work is to prepare the input for the project board so that they may sign off the project. The objectives for this phase are:

Checking the extent to which the objectives set out in the project initiation document have been met.

Confirming the extent of the fulfillment of the project initiation document and the client's satisfaction with the deliverables.

Obtaining formal acceptance of the deliverables.

Ensuring to what extent all expected products have been handed over and accepted by the client.

Confirming that maintenance and operation arrangements are in place (where appropriate).

Making any recommendations for follow-up actions.

Capturing the lessons learned from the project and completing a lessons learned document.

Preparing the end project report.

Notifying the host organization of the intent to disband the project resources.

On the lowest tier, we find the planning process. It is important because it considers key project processes, which are:

Planning an initiation phase.

Planning a project.

Planning a phase.

Producing an exception plan.

Overall, PRINCE2 proves to be a sensible and practical project methodology. The best feature is that no license is required for using this methodology, except one obtaining the required documentation. Additionally, it is not necessary to purchase special project management tools, as PRINCE2 allows use of any project management tool to manage projects. Project managers who are familiar with PRINCE2 are able to:

Establish terms of reference as a prerequisite to the start of the project.

Use a defined structure for delegation, authority, and communication.

Divide the project into manageable stages for more accurate planning.

Ensure resource commitment from management is part of any approval to proceed.

Provide regular but brief management reports.

Keep meetings with management and stakeholders to a minimum but schedule them at vital points in the project.

Required PRINCE2 Artifacts
There are essential artifacts required by a typical PRINCE2 project. First, the business case artifact used by PRINCE2 is a reasoning or justification of the project. After all, as mentioned in Chapter 1, companies must focus on pursuing only those key strategic projects that produce innovative products and services. Together with this, project managers must ensure that all project risks be identified in the business case.

The business case should be routinely updated to reflect any change to the project, should new risks be identified. It is true that much time is spent on the business case, but this ensures proper planning and coordination. Therefore, the business case gives a clear picture of what is to be delivered. At the start of a project, the product specification is drawn up, which reduces the risk of delivering the wrong product. Although the PRINCE2 methodology does not directly deal with social or "soft" management skills, such as negotiations, presentation techniques, coaching, or leadership, it is necessary for a project manager to possess these skills to be successful.

If your company plans to implement PRINCE2, you would most likely start by training your key staff on the best practices and detail on the methodology and then provide overview training to those who would need to be aware of the methodology. Advantages and disadvantages of using PRINCE2 are discussed in the following sections.

Advantages of PRINCE2
The method is independent of the application domain such as IT software development, marketing, building and construction, and change management. Domain-specific methods such as DSDM, product development methods, or domain-specific standards can be applied in the PRINCE2 teams. This way, the method is generically applicable to any project. PRINCE2 provides a layer over the disciplines that are needed in the project because it defines a flexible "project language" that suits multidiscipline project teams. Therefore, the method bridges the gap between IT and business, for instance.

The method is in the public domain, and services (training, consultancy, and tools) can be obtained from several independent suppliers.

The method has active user groups in the United Kingdom and the Netherlands.

The method is applicable to small and large mega-projects.

The method focuses on project results in terms of the standard time, cost, quality, and functionality parameters but also has a strong focus on business case and the benefits the project results deliver.

The method integrates change management that controls the changing environment.

The method uses management by objectives and management by exception approaches.

Disadvantages of PRINCE2
It is a method and not a cure for any project. People who use PRINCE2 should continue to think.

Some people apply and interpret the methodology in a rigid way and do not tailor it to the project at hand. Huge bureaucracies might be constructed if all checklists are used in a paper format and not adapted to the project.

Human factor or soft issues are not within the scope of the methodology and are desperately needed for project success.
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. Table 3.2 describes the basic methodology phases available for a project.

Table 3.2: 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


The project manager should pursue the options and choices of which project methodology to use, depending on the engagement. Tables 3.3 and 3.4 reflect similar methodologies available to project managers when working with a client and deciding which approach to adopt.

Table 3.3: Complex approach Phases
Phase Description
Critical Plans

Definition
Identifies the project team and lists assumptions.
Project schedule

Data collection
Collects data for the intended solution.
Analysis forms

Develop model
Develops a conceptual model of the solution.
Specification

Verification and validation
Confirms that solution performs as required and compared to all measurable results.
Validation plan

Optimization
Ensures that the solution meets predefined success criteria.
Optimization plan

Delivery
Delivers the solution to the client.
Deployment plan

Table 3.4: Generic approach Phases
Phase Description
Critical Plans

Needs analysis
Determine exact client requirements.
URS, Business case

Project concept
Establish business objectives and deliverables from the client.
Project definition

Project design
Start designing the solution for the client.
Specifications

Training
Provide training to users in the client organization.
Training plan

Project delivery
Implement the project per the identified project schedule.
Deployment plan

Project support
Address all support-related aspects of the project.
Support plan


For numerous SDLC-type projects today, the trend and style of these methodologies frequently involve completing one phase after the next. Many are monolithic in nature; they are time consuming and some methodologists are calling these formal giants the dinosaurs of project methodologies. SDLC methodologies at least provide a framework for completing projects, but it's not that these methodologies follow the often-quoted maxim "Ye shall release early and release often"; rather, they rely on "Ye shall wait till each phase is complete before releasing resources for the next." In today's complex digital world, where faster is better, project managers struggle to complete projects where complex, unknown technologies are being used. Clients do want to see results much earlier than before. They insist that you follow a project approach, but they want to see results much more quickly and want deliverables to be delivered sooner. My advice is to go through the various approaches mentioned here and select one that is best suited for your needs, and tailor it accordingly. In addition, refer to Chapter 4 of this book to start a journey into methodologies (see Figure 3.6).


Figure 3.6: Complex life-cycle methodology.
Approach
Needs analysis. This phase is used to determine the specific client requirements for the proposed solution. The needs analysis aids in identifying the exact business and functional requirements.

Project concept. The project concept establishes the business objectives and assumptions, risks, and deliverables into a project concept, which is usually documented and presented to the client for acceptance.

Project design. This phase allows the project design or development team to begin creating or formulating the design for the solution.

Project training. The training phase is an important part of this methodology because it includes training as part of the project. It assumes that training for the user is necessary.

Project delivery. The implementation of the project occurs after training has taken place. This phase ensures that the project is delivered at the relevant location(s) within schedule.

Project support. This phase of the project ensures that the necessary support for the solution has been coordinated and managed. Tasks such as support level agreements (SLAs), escalation processes, and contact lists are performed.

Solutions-Based Project Methodology
Solutions methodologies offer consulting companies the opportunity not only a way to work with clients but also a structured manner in which to deliver projects. They form the standard approach to doing the work. As each solution is different from the rest, it becomes important to adhere to a consistent manner in which projects are managed and executed.

Ray Lane of Kleiner Perkins Caufield & Byers states:

E-business is about rebuilding the organization from the ground up. Most companies today are not built to exploit the Internet, their business processes, their methodologies, their hierarchies, the number of people they employ ... all of that is wrong for running an e-business! (p. 1)

There are numerous e-commerce project and development methodologies available today. They vary largely because of their architectures, technology, and target dates. At a minimum, e-solutions methodologies should consist of the following phases.

Objectives.

Strategy.

Design.

Content.

Development.

QA.

Test.

Launch.

Maintenance.

Creating a Basic Methodology
If you are new to methodologies, you should start with a simplistic approach for your project. The first step is to list a few key phases you think suit your type of business. In the following example, we start building a methodology. Assume you have a small project team in your company and that your aim is to avoid any lengthy documentation or additional steps that will impede project delivery. You can always start elaborating as your project starts gaining momentum. For the purpose of the example, I have randomly selected three basic phases of our methodology:

Explore. Here you need to ensure that the focus remains on completing the business requirements for the upcoming solution. This includes obtaining project information, meeting with your client, and creating a list of assumptions and a project brief or business case. You should drill down into some level of analysis and determine what the project scope is or is not.

Develop. During this key step, start creating at least the project plan, together with any technical specifications you need to build your product. This may include case diagrams and flowcharts. Additionally, during this phase, the role of the deployment plan is highlighted.

Execute. During the execution phase, the physical solution is developed and tested to the point where the solution is rolled out to the client.

With the main phases documented, we need to identify the minimum artifacts or project templates needed. Table 3.5 shows that we need at least a business case document during the "explore" phase. After you have the templates defined and in place, assess which processes you need to support this methodology. Assume that your company or project will be purchasing considerable hardware and services from different vendors. In this case, you need to ensure that you have a procurement and financial process in place to make things easier. If these basic processes are not in place, it is likely that you will be spending more time doing administrative work than managing your project.

Table 3.5: Solutions-based models Basic Phases
Phase Description
Basic Artifacts Needed

Explore
Examine the deliverables needed, as well as resources.
Business case

Develop
Develop solution against specification.
Technical specification

Execute
Implement the solution.
Deployment plan


After the processes have been identified and established, run a simulation or demo to see that everything works the way that you designed it to work. Tweak the methodology by either adding or deleting pieces to the methodology. If your company or project is small, you want to be flexible and able to communicate to fellow team members in an efficient manner without any complexity. Many companies make the fatal mistake of having reams of documentation do the communicating between parties instead of face-to-face communications. But our example is fine. We have kept the methodology to a minimum set of templates and processes, and we have our project team sitting together in a comfortable and relaxing work environment.

As our team or project becomes larger, it will require additional coordination and, regrettably, slightly more documentation. In addition, depending on the technology, we want a highly dynamic project environment that can create this solution quickly (e.g., we want to create a national database that collects and interprets intelligence data from multiple government agencies).

Creating Hybrid Methodologies
There are circumstances in which it may be necessary or appropriate to combine two methodologies to create one perfect tailored methodology. Sometimes, it is more feasible to dynamically build a methodology from other methodologies. You may find yourself starting out using a waterfall methodology, then during the life cycle of the project (i.e., development), you realize that using a RAD methodology may be more appropriate. Remember that each methodology offers its own set of strengths and weaknesses from a methodologist's perspective. In the Air Force, to keep mission-critical aircraft serviceable, the "one-from-two" principle is sometimes employed—two unserviceable aircraft are stripped down and critical parts are used to build one fully functional aircraft tailored for a specific use. This is the concept of the hybrid approach.

For any project manager, this option should remain open, but with sudden change comes risk. Points of safe cutover from one approach to the other must be clearly defined, and the project manager should assess the impacts on schedule, cost, and resources. There are issues with the user involvement in the different streams of development, project management issues including possibly different approaches to change requests in the two approaches, and organization management issues. This is permitted, provided the project management framework in the company can support various development methodologies