Project Risk Management Tools & Techniques

Project Risk Management is the process or activities associated with identifying risks, analyzing risks, developing appropriate responses to risks, and monitoring risk triggers. Risk management is a primary role of the project manager. While other project team members will be involved in all of the Project Risk Management processes. It is the responsibility of the project manager to ensure that risk management is done and that risk triggers are being monitored.

The PMBOK has defined Risk as, "an uncertain event or condition that, if it occurs, has an effect on at least one project objective." The objectives are identified during project initiation and include the major elements of scope or deliverables, key milestones, budget constraints, or any other aspect of the project identified as a key success criteria by the stakeholders.

Risks can be positive or negative. Typically we focus on negative risks, and these are the ones that are likely to result in project failure. However, there are positive risks which are opportunities for the project team to perform better than required on at least one of the major objectives. In my experience, positive risks, referred to as opportunities, must be identified early in the planning processes to take advantage of them in the project. Otherwise the cost and schedule impact of changing the plan will typically outweigh the benefit. Negative risks, referred to as threats, can be avoided if addressed early. However, these must be monitored and tracked throughout the life of the project.

The process of project risk management typically is viewed as a five step process. The first step is Risk Identification. Next is Qualitative Analysis and, when necessary, Quantitative Analysis. Once analyzed, Risk Responses must be developed for those risks that require them. Finally, Risk Monitoring must be done for those risks that require ongoing monitoring. I prefer to manage this process using a Risk Register.

Risk Register

The Risk Register is a spreadsheet that tracks the management of risks, both threats and opportunities, through the project lifecycle. The register not only aids the project manager in the process of risk management, it creates a document for archiving with the project files that can be used for Lessons Learned and a historical record.

The Risk Register is structured so that each row is a risk and the columns track information associated with the various risk management processes. The precise columns you use are a matter of personal preference. I like to have columns that identify the risk and where in the project the risk will have an impact. I then have columns indicating the results of qualitative analysis and quantitative analysis. I also have columns showing the selected risk responses and the status of any mitigating actions or the risk triggers that are being monitored.

Risk Identification

In order to do effective risk management, you must start with risk identification. That sounds really "Duh," but I have set in many project reviews and asked questions about the risk identification process only to find that it was never done. Instead someone copied the risk list from a previous project and started working with it, even though many of the items did not apply to their project.

There are many ways to identify risks and if your organization has a standard approach that works, use it. When there is no standard approach, my preferred method is to use a variation on the Fishbone or Ishikawa diagram. I start with a major project impact such as, "major schedule delay" or "test failure." I then try to identify all the possible reasons why that might happen on this project and document those in the bones of the Fishbone. I normally will do several of these diagrams, one for each major project impact. I will do these for both project threats and project opportunities. For instance, I might have one for, "Early completion" or "Major Under-run." All of the items that are listed then are transferred to the Risk Register for further analysis.

Qualitative Risk Analysis

Once the list of potential risks has been developed, the next step is to analyze them. This can look to be a daunting task if there are many risks. Therefore, the first step in the analysis is to filter the risks to determine which are the significant risks and which are insignificant. There are many techniques for this and they are known as qualitative risk analysis. I will discuss three of my favorite, the red-light/green-light rating, the risk matrix, and the urgency assessment.

The red-light/green-light rating is a subjective assessment of whether the risk will likely have a major impact on the project. The risks are divided into three groups, one is "red" risks, one is "yellow" risks, and the last is "green" risks. The thresholds for these categories can be based upon the cost impact, the time impact, the quality impact, the probability of occurrence, or a combination of these. I normally view the "red" risks as those that are likely to occur and will significantly impact one of the project objectives. These risks must be addressed; usually with an immediate change to the project plan. The "yellow" risks are those that may have a major impact on the project, but that I believe we can manage through with the current plan. However, they are serious enough that they are watched closely. The "green" risks are those that either are insignificant or they are risks that were once "red" or "yellow" and have now been mitigated.


The next approach for qualitative risk analysis that I use is the risk matrix. This matrix can be setup as a 2x2, a 3x3, a 4x4, or a 5x5. What size you use is based upon personal preference. The vertical side of the matrix is labeled probability and the horizontal side is project impact. The scale on the matrix goes from low to high on each side. How low or high are defined should be based upon the major objectives of the project. Once the matrix is created, I place each identified risk on a post-it note and then locate the risk in the appropriate spot on the matrix based upon the likelihood of that risk happening on this project and the impact to the project objectives if it did occur. The risks in the upper right corner are major risks that must be addressed in project planning. The risks in the lower left cornere are minor risks and can be ignored.

The third approach for qualitative analysis I use is an urgency assessment. In this analysis I consider when in the project the risk must be managed. Some risks do not have the potential to occur until late in the project, others would occur early, and still others could occur at any time. The urgency assessment identifies anything that is an immediate issue for the project management team and which risk issues are not yet in play.

Quantitative Risk Analysis

Quantitative risk analysis are techniques that attempt to quantify the project impact of the risks. These techniques are generally much more complex than the qualitative techniques and therefore require much more time and effort to complete. I find that if I do the qualitative techniques first, I then can focus my quantitative techniques on just the few high risk items. These are the items that are most likely to require a significant amount of project management effort and possibly discussion with stakeholders to address threats to boundary conditions. Prior to the stakeholder meeting, I like to have a quantitative analysis done so that when I meet with stakeholders we can focus our discussion around the business impact of doing nothing as compared to doing something. The following is the list of quantitative techniques I recommend.

Sensitivity Analysis - in this technique the project plan is developed without the risk factor occurring and then the risk factor is introduced and the plan is redone with the risk impact in place. This provides a demonstration to the stakeholders of why the risk is important and needs to be addressed.

Failure Mode Effects Analysis (FMEA) - this technique is excellent for addressing technical or quality risks. It is not very effective for addressing cost or schedule risks. However, since the risk is quantified based upon safety and security issues, it can be very useful for explaining why a change in project requirements is needed.

Decision Tree with Expected Monetary Value - this technique can require a significant amount of time to set up, but once established it can easily be reused as project assumptions start changing and the project is forced to react to the changing circumstances. The decision tree shows the impact of decisions and risk events on project activities and the expected monetary value quantifies those impacts.

All of these techniques require hours and possibly days to complete. There are other quantitative riak techniques, however, I find that they are even more time-consuming and expensive. The results of the other techniques are typically no better than the ones listed above.

Risk Response Techniques

Based upon the analysis, some risks will require a response in the project plan, some will only require a response in the project monitoring, and some will not require any response at all. If a risk is deemed to be high, it needs a response. Responses to negative risks - threats, are one or a combination of these six responses:

Avoid - the project plan is changed so that it is impossible for the risk to occur because the project is never susceptible to that type of risk. Some risks cannot be avoided.

Mitigate - the project plan is changed so that when or if the risk occurs it will only have minor effect because the threat has been anticipated and provisions for addressing it are in place.

Transfer - the project plan is changed so that an outside agency assumes responsibility for addressing a portion of the risk impact.

Escalate - the project plan needs to be changed beyond the boundaries set in the Project Charter.  This requires stakeholder approval.

Accept - the project plan is not changed because the risk is so insignificant or the risk is so improbable that no change is needed.

Contingency Plan - the project plan is not significantly changed, although a risk trigger is established that can be used to indicate whether the risk will occur and if so in what fashion will it impact the project. If possible a "Plan B" is developed, or at least has been considered. If the trigger occurs, the "Plan B" is put into effect and the project is changed at that time.

There are also six possible responses for positive risks - opportunities. In almost every case, these opportunities must be identified early in the project if there is to be any hope of realizing the positive benefits they entail. The six responses to opportunities are:

Exploit - the project plan is changed from the normal approach for this type of project to take advantage of the unusual condition that is occurring.

Enhance - the project plan is changed so as to create an opportunity for improvement in the ability of the project to achieve one of its objectives.

Share - the project plan is changed so as to bring an outside partner onto the project that creates opportunities to improve one of the project objectives.

Accept - the project plan is not changed because the opportunity is so small or so unlikely that the risk of change creates a negative risk outweighing the opportunity.

Escalate - the project plan needs to be changed beyond the boundaries set in the Project Charter.  This requires stakeholder approval.

Contingency Plan - the project plan is not significantly changed, although a trigger is established that will provide notice that an opportunity is now available to improve on one or more of the project objectives.

It is important to note that in the absence of choosing to do something different, the "Accept" option will apply to any threat or opportunity. If "Acceptance" is not appropriate for the risk, action must be taken to either change the plan or to begin monitoring the risk trigger.

Risk Monitoring and Control

Risk monitoring is much of what a project manager does once a project moves beyond the planning stage. As project activities are being accomplished, the project manager should be tracking the risk triggers to see if any project changes are needed. The risk triggers should be listed on the team-level project dashboard. In addition, I revisit the risk register whenever a project goes through a replanning and at major Management Reviews to determine which risks have been eliminated and to add new risks to the register.

I also use the risk register to document the result of risk monitoring activities. The risk register tracks the status of project changes or mitigations that have bee initiated to address risk issues. The risk register also captures the impact of mitigating actions for those risks that are mitigated.

Project Complexity and Project Management Methodology

The Complexity Spectrum considers the project characteristics that drive project integration difficulties. The higher the degree of integration complexity within a project, the higher the level of project risk. Projects with a high degree of integration complexity are likely to require more robust risk management techniques than those with little integration complexity. Some of the project management tools and techniques work well with simple projects but are unable to efficiently handle high degrees of complexity. Some project management tools and techniques manage complexity very well but are cumbersome and difficult to use on simple projects.

There are many possible ways for assessing integration complexity. In our experience, two factors that are relatively easy to estimate prior to the development of a project plan and provide excellent correlation with complexity are a high level estimate of the project effort and a high-level estimate of the project duration. Neither of these factors needs to be determined with any degree of precision when assessing them for the Project Complexity Spectrum. A general understanding of the amount of effort, based upon an approximate number of tasks or deliverables is adequate. Also, a general estimate of the project duration will suffice.

The Project Complexity Spectrum differentiates projects into four categories, Simple, Focused, Full-scale, and Complex. Simple projects are short projects with limited scope and activities. Typically they require about fifteen to twenty tasks or activities in order to complete them. The duration may be from several days to several months. Focused projects are those with a major category of deliverables or business milestone requiring a significant amount of work, however, there is usually only one major category of deliverables or one business function involved. We sometimes refer to these as "100 day projects" since they often take three to four months to complete. Full-Scale projects typically require many major deliverables. The integration issues on these projects are significant. The hundreds of activities and deliverables require a high degree of technical integration. These projects usually are six to twenty months in duration. Complex projects include "programs" as defined by the Project Management Institute. They are large, multi-year, multi-deliverable, multi-stakeholder, multi-team member location projects often with multi-million dollar budgets. Given all of these "multi's" it is no wonder that integration is at the forefront of the project management activities on Complex projects.

Simple Projects

As sated before, Simple projects are short projects with limited scope and activities. Typically they require about fifteen to twenty tasks or activities in order to complete them. These projects are usually completed by one person or occasionally a small team. Normally there is only one deliverable and one major stakeholder that needs to be kept informed of project progress.

The characteristics of the simple project do not require the use of project management tools that are focused on integration complexity. The major project integration risk on Simple projects is that the individual doing the work becomes distracted by the other aspects of their job, creating errors and delays. The project management tools that often fit best with the Simple project are personal productivity tools. Prioritized tasks lists and network diagrams are excellent tools for planning the project. There is little or no need for internal project integration meetings since the work is usually being done by just one person. The only project reviews needed are periodic pulsing meetings with management or the stakeholder to report progress. These meetings are usually short and conducted informally.

An example of a Simple project would be an individual who is using plans in a "handyman book" to build a deck on the back of his house. He first plans out the steps that must be accomplished, obtains the materials and then builds the deck. The project is likely to be accomplished over several weekends. The Stakeholder reviews are conducted over coffee with their spouse.

Focused Projects

As stated before, Focused projects are those with a major category of deliverables or business milestone requiring a significant amount of work, however, there is usually only one major category of deliverables or one business function involved. Usually there is a small team of individuals who are assigned to this project. There may be multiple stakeholders for this project, but they typically are in agreement on the project charter. The project leader role is not a "full-time" position so the project leader is either one of the team members with technical responsiblities (for example - the database engineer) or a full-time project manager will be managing several focused projects. The major integration risk on this project is the technical integration of the tasks required to complete the project deliverable(s). Focused projects are often sub-project's within larger more complex projects or programs.

Focused projects require all of the basic elements of project management and they benefit from the use of a standard methodology associated with the type of project (eg. software development, facility construction, Six Sigma). When the organization does not have a standard project management methodology, a "hero" can still often manage this project to success. These projects should have a charter or initiation document, though it is often only one or two pages. The project leader role is part-time and the project leader is usually a technical contributor on some activities within the project. The project leader defines, organizes and staffs the activities with support from stakeholders and management. The project control activities will include appropriate technical reviews (usually only one or two) and regular reviews with stakeholders.

An example of a Focused project is the individual who hires a contractor to build a sunroom addition onto the back of his house. In this case there is a formal bid and proposal process and selection of the contractor. The contractor, who may also be the lead carpenter on the job, commits to a cost and schedule. There are several workers and other subcontractors on the project, including concrete for the foundation, electricians and carpet layers. Also there is a building code permit and inspection. The project takes several months to complete all of the exterior and interior work. There is a project plan and the home owner reviews it with the contractors on a periodic basis. The major risk issues are the technical integration of the activities, such as did the electrician finish roughing in the wiring before the dry wall was put up.

Full-Scale Projects

As stated earlier, Full-Scale projects typically require many major deliverables and hundreds of tasks and activities. These projects usually involve many departments within the organization. The projects should be managed by a full-time project leader who is supported by a cross-functional core team which is often located at multiple locations. In addition to the complex technical integration, the cross-functional nature of the work and the multiple locations creates significant team and organizational integration issues. Also these projects usually have multiple stakeholders with varying objectives, all of which must be integrated into the project plan. Since these projects usually are six to twenty months in duration,they will often be reviewed in at least two annual budgeting cycles. As budgets change and business priorities change, the project will almost always experience at least one point of significant re-direction.

Full-Scale projects require effective use of the full complement of project management tools and techniques. The complexity within these projects are such that the project leader is seldom able to "muddle his way through" the project. A standard project management methodology is very beneficial on these projects. The methodology clarifies for the project leader and the core team members what is required and who has responsibility for the various project deliverables. These projects are often managed in a phase or "toll-gate" approach so as to provide appropriate management oversight over the project progress. In my experience, all of the project management processes described in the PMBOK will likely be used on these projects

The focus of the full-time project leader is typically on communication and risk management. They are balancing the triple constraint of scope, schedule and resources (budget). The core team members are managing the technical activity definition and completion for their portion of the project. The project leader is tracking the issues that inevitably arise and to ensure the issues don't turn into major risks. The project leader is also spending much of his or her time communicating with stakeholders, both to understand whether their requirements are evolving and to inform them of the status of risks and mitigation actions with respect to quality, schedule and budgets.

Continuing with our home construction theme, an example of a Full-Scale project would be the design and construction of a custom home. The home owner would hire a general contractor and an architect. The contractor and architect would develop plans, including budgets and schedules, and identify building sites. Once the owner approves the plan, the contractor and architect begin the permitting process and identify subcontractors. The general contractor is balancing the work of all of the subcontractors, the overall cost and schedule, along with interacting with all of the regulatory agencies. As the construction begins, there are appropriate reviews by the owners and the zoning committee or permitting agencies. Inevitably, the home owner will want some changes as they see the construction progress. Eventually the home is built, the interior is decorated, the landscaping is installed and the homeowner moves in.

Complex Programs

Complex projects require a full-time program manager and they are best managed by subdividing the work into a portfolio of "Focused" and "Full-Scale" projects. Systems engineering and configuration management become crucial components of the project management tools that are used by the program manager. The overall program goals and objectives must be allocated to the subprojects and invariably tradeoffs must be made between subprojects in order to achieve the program goals.

The program manager for Complex programs is less likely to be personally using all of the PMBOK practices. He or she is relying on the subproject leaders of the Focused and Full-Scale projects to project manage those subprojects appropriately. The program manager maintains a high level program Work Breakdown Structure that shows the allocation of effort among the subprojects. Also, the program manager maintains a high-level, milestone schedule and the overall program budget. All of these are reviewed and kept current at regularly scheduled program reviews where each subproject presents their status and their major risk issues. The program manager balances the risk between the subprojects and watches for high-level risk trends.

Integration is the focus of everything the program manager is doing. The program manager will have a master schedule that incorporates the major elements of each of the subprojects detailed schedules. The program manager will have the overall program budget, allocated to the subprojects, with a reserve to address unexpected problems within a subproject or areas that are overlooked by each of the subprojects. Also, the program manager will have a program requirements document, usually many pages thick. In addition, the program manager will have created a set of subproject requirement documents. These map the program requirements to the subprojects and the interfaces between each of these are managed closely by the program manager.

Applying the concept of a Complex program to the home construction example that has been used with the other project types leads us to the construction of a large subdivision. The program manager is integrating with all of the construction managers on each house and working with zoning committees. The program manager must ensure that roads and utilities are being installed. They also need to integrate all of these activities so that multiple things are happening at the same time without interfering with each other. For instance, when the road crew is paving, the individuals working on home construction still need to be able to get to their job site. Integration is the key to success so that each house construction project can maintain their schedule and the infrastructure of the subdivision can be installed on time and on budget.

Project Uncertainty and Project Management Methodology

The Project Uncertainty Matrix, based upon work developed by Robert Wysocki and presented in his book, Effective Project Management. considers two factors: 1) how well the project requirements are understood at the beginning of the project, and 2) whether the specific tasks, activities, and decisions needed to conduct the work of the project are known at the beginning of the project. In my use of this matrix, shown below, I have modified it from the original used by Wysocki to add a category of projects in the lower left corner of the matrix. This will be discussed in more detail below.

The upper left quadrant of the Project Uncertainty Matrix is described as the Traditional project management approach. This is the set of conditions that many project management methodologies assume will exist on all projects; the requirements are fully and completely known at the beginning of the project and the methodology best suited to meet those requirements is known and understood by the project team. Many of the books and academic courses on project management also assume these conditions or they direct the project team not to proceed until these conditions exist. The upper right quadrant of the Project Uncertainty Matrix is described as the Adaptive project management approach. This is the condition of many projects, especially in the cases of product development projects and business improvement projects. These projects are initiated with a clear goal in mind. However, due to the nature of the work to be done within the project, the specific activities are not known, or the level of effort required to conduct some project activities is unknown. For example, the project may require software development. Seldom is software operating perfectly when first created. There is likely to be bugs that must my analyzed and fixed. The amount of time required for bug-fixing cannot be precisely estimated until the number of bugs is determined. The lower left quadrant of the Project Uncertainty Matrix is described as the Discovery project management approach. The application of this approach is much less frequent than the other approaches. In fact, Wysocki does not even acknowledge the existence of this approach. However, my experience has found that these conditions do occasionally exist. This approach is applicable when there is a defined project management process or methodology to be applied, but the end result of the project is unknown and unpredictable. The types of projects where I have seen this approach effectively applied are research-based projects. The lower right quadrant of the Project Uncertainty Matrix is described as the Extreme project management approach. Almost all projects find themselves in this situation at some point in time due to changes in stakeholders or requirements. Many projects start in this situation and never recover. An objective with the Extreme project management approach should be to migrate the project into either the Adaptive approach, the Discovery approach, or possibly even the Traditional approach as soon as practical. Extreme conditions are commonly caused by a "crisis" in the project. A change in business or project conditions leads to significant uncertainty in some aspect of the project goal or business result. This uncertainty in the goal introduces the need for the project team to establish a fundamentally new project plan. During this time of crisis, neither the goal or the required project activities are clearly defined. Even though everything about the project is unsettled, there are project management principles that can still be applied. These are the principles of the Extreme project management approach.

Traditional Project Management

Traditional projects are those where both the project goals and project activities are clearly defined at the begining of a project. When a project meets this set of assumptions, a detailed project plan can be established at the beginning of the project. That detailed plan identifies all of the tasks needed to achieve the clear project goal. In addition, the detailed plan includes the resource, often by name, who will do the activities and can realistically estimate how much effort the resource will require to do the work. Given the identification of the resource and the estimated effort required to do the work, the estimated budget and schedule for the project can be established. At this point a detailed plan exists and project risk management activities and project control activities can begin to monitor the implementation of the plan and ensure the successful completion of the project. In this approach, the project plan is the "controlling" document. Whenever questions about project activities or project progress arise, the plan determines the response. When a project team is fortunate enough to be working with a project that fits the criteria of Traditional project management they should certainly take advantage of that fact and plan the project in detail and control the project to the plan.

The major difficulty with this approach is that often the projects don't fit the set of assumptions that Traditional project management is based upon. When the goal is uncertain, or is in flux, or the necessary project activities are unknown, the application of a Traditional project management methodology leads to one of two problems. Either the project is excessively delayed in an attempt to gain enough information to fully define the goal and the required activities, which leads to missed opportunity and delayed strategy deployment. Or, a project plan is put in place that the project team knows is not correct, but they don't know with certainty what the deficiencies might be. This latter condition leads to cynicism about the value of project planning and project management among the entire team. In addition, the stakeholders and senior management may not realize the high level of uncertainty and risk inherent in the plan because they don't realize that fundamental assumptions about the project were untrue. That condition often leads to unrealistic assumptions by the stakeholders and disillusionment in the project management skills of the project team.

Adaptive Project Management

Adaptive projects are those with clearly defined goals but uncertain tasks and activities needed to achieve those goals. When project conditions meet the criteria of an Adaptive project, the methods of project management used for Traditional projects will not work well. A detailed list of activities, typically documented in a Work Breakdown Structure, can not be developed. Without this detailed list of tasks, a precise schedule, budget, and resource list can not be determined.

However, just because these detailed elements of project planning and control that are used in Traditional project management are not available, it does not mean that the project can not be managed at all. The approach that has proven to be successful with Adaptive projects is progressive elaboration, also known as "rolling wave planning and control." In this approach, a high-level project plan or outline is established based upon the major project deliverables, key milestones and project decisions that must be made to achieve the goal of the project - which is known and understood. this high level plan is the key to success and the project is managed based upon the high-level plan. Once the high-level plan is set, a detailed plan leading up to the first milestone or decision point is developed. This first stage of the project is approved and executed. As the first stage completes, a detailed plan leading to the next milestone or decision point is developed. This second stage plan builds on the results of the first stage. Many aspects of the project that were not known at the beginning of the project may now be clear, allowing the project management team to develop a realistic plan for the second stage. This process continues throughout the project from stage to stage until the project goal is achieved.

This approach to project management is more complex than the Traditional project management approach. However, when there are major risk items that will significantly influence the scope, schedule or budget of the project and these items are unpredictable and uncontrollable, this approach provides both the project management team and the business leadership with opportunities to control the project. When an activity takes longer - or shorter - than planned or a new activity is recognized as required in order to complete a project deliverable, the detailed plan is modified, but the high-level plan does not change. The project team still strives to achieve the milestones or decision points but they modify the approach used to get to that point. Every new stage is a decision to continue or cancel the project based upon what happened in the previous stage. If the decision is to continue, the new stage is an opportunity to shift the project scope and approach based upon the information learned with respect to the probability and impact of these major risks. This approach relies on the establishment a high-level plan consisting of major milestones and decision points. This is often called a stage-gate or toll-gate project management approach. Unless the high-level plan is established and the project team actively controls the project to reach those points, the project is likely to run amuck, resulting in massive overruns and delays.

Discovery Project Management

When a project meets the criteria for Discovery projects, the Traditional project management approach will not work. Key aspects of the goal can not be defined, therefore the scope, schedule and budget cannot be defined. However, what can be defined for this type of project is the set of detailed activities and interactions that will be used to generate and analyze data. A well-defined project approach is necessary for these projects to ensure that nothing is overlooked and that the data that is generated and analyzed has not been compromised. For these projects, a proposed methodology is developed and approved as the project plan. Decision points are then setup that are usually based upon calendar or budgetary events, such as quarterly reviews, end of the semester, or annual budget requests. At these decision points, the results of the project during the preceding project phase are reviewed and the senior leadership decides whether the project should be continued in its current approach, the approach should be changed, the project is cancelled, or the result is deemed a success and the technology is promoted onto a new project that is initiated to apply and realize the business benefit of the discovery.

This approach requires disciplined project management to ensure that the plan for each phase is followed. The pace of Discovery projects is typically limited by the level of resources that is being assigned to the project. The greater the amount of resources, the greater the amount of data and analysis that can be done. Decisions at the decision points are based upon the strategic needs of the business and the characteristics of the results achieved during the previous phase. Thomas Edison is quoted as saying, "Results! Why, man, I have gotten a lot of results. I know several thousand things that won't work." Discovery projects are often like that. The value of project management in these projects is to ensure that the effort is not executed in a random or haphazard manner. Also, clearly defined project budgets can be set and managed with this approach. A result of project control with this approach is the generation and control of project records, both technical and financial.

Extreme Project Management

A maxim of project management is that the project management team's responsibility is to control the project risk. Once a project enters the Extreme quadrant, there are many major undefined and unquantifiable risks. The project management team focuses the efforts of the Extreme project on defining, eliminating, reducing, or quantifying the risks. In fact, risk management is the organizing principle for the project during the time it is operating in the Extreme quadrant.

When operating in the Extremen mode, the project management team identifies tasks and activities that must be completed to gain insight and understanding about the risks and uncertainties within the project. These would include meetings with stakeholders, analysis by subject matter experts, and preliminary trials of possible ideas or approaches. Many times the result of one activity impacts the nature of the next activity as information becomes available, project options are excluded and new options are identified. While it is impossible to plan the overall project scope and activities in this environment, the activities for each day, week or shift can be planned; one day, week or shift at a time.

Not only ie there uncertainty in the tasks and activities, often there is also uncertainty in the human resources and budget needed for the project. To minimize the risk in Extreme projects, a dedicated team of subject matter experts should be assigned during the time the project is operating in the Extreme mode. Many companies refer to these as Tiger Teams or Action Teams. Due to the high degree of uncertainty in tasks and activities, there is also a great deal of uncertainty with respect to the overall project schedule. However, elements of uncertainty with respect to schedule can be minimized. This is done by ensuring all tasks are of a short duration so that progress can be continuously assessed. If the activity is inherently long, interim check points are established so that progress within the activity can be monitored. An additional element of uncertainty in scheduling is associated with the relationship between activities. As the scope is unfolding within the Extreme project, the relationship between activities may change. It becomes imperative for the project management team to be regularly assessing what activities are required and/or desired predecessors for upcoming tasks or activities and ensuring that those activities are completed.

By this time, what should be clear with respect to a project management approach for Extreme projects is that the project is planned and executed on a very short cycle, pulsing pattern by a dedicated team of subject matter experts. This group does the work within a project pulse, for example the work for one day. At the end of the day the project management team gathers and reviews the information and progress made. Based upon that review, a new set of tasks are planned for the next day and resources assigned to do those tasks. At the end of the next day the next assessment occurs and a plan for the next day is developed. Ultimately, the project team is able to resolve enough risk items so as to clarify the goal, the required activities or both and then transition the project into an Adaptive, Discovery, or Traditional approach.

The Extreme project management approach appears at first to be the antithesis of project management. There is no long term plan, there is no project baseline to use for control, and there is no estimate on total time, total cost, or final project result. However, the conditions that cause a project to transition into the Extreme mode are very real. In my experience, many if not most projects will face the Extreme condition at some time during the project, or with respect to some major aspect of the project. Therefore, it is necessary to have a project management methodology that both recognizes when Extreme conditions exist and how to manage the project through that time. Often we find that both the project teams and senior management recognize when a project enters the Extreme mode. For instance, if an industry downturn causes management to direct the team to reduce the project scope and change the project schedule to accommodate a 50% budget cut, everyone recognizes that the project is temporarily in an Extreme mode until a new baseline can be established and the project transitions back to Adaptive, Discovery, or Traditional.

Usually the problem is not one of recognizing that Extreme conditions now exist, rather it is changing the project management approach due to those Extreme conditions. Often we find project management teams and senior management trying to manage the project using a Traditional approach during Extreme conditions. This leads to frustration, mis-information, and poor decision-making. I have heard the rapid pulsing process approach described as micro-management. I am not surprised at the comment since this is micro-management. The project management team is responsible for managing risk. When a project transitions to the Extreme mode, virtually everything is a risk and therefore everything must be managed simultaneously. The project management team is responsible for resolving all of the risks and must stay aware of all them. A key to success when managing in this fashion is to ensure that the project pulsing is maintained and the redirection of the project that is set at each pulse is always driven by the major risks facing the project at that time.

Operating in this mode for a sustained time will exhaust the project management team and most of the project team members. In addition, senior management often becomes frustrated with the team since it is unable to provide an overall schedule, budget, or even a description of what the project will be able to deliver. When the project management team and senior management work together to clarify goals and activities and work together to reset project boundaries, the uncertainty of Extreme project management is minimized.

What Happens When You Use The Wrong Project Management Methodology

Over the years I have seen many methodologies for managing projects. Virtually all of them are effective - for a unique set of business and project conditions. Difficulties arise when a methodology that is not appropriate for the current set of business and project conditions is imposed upon an organization or project. When this happens I typically see one of three destructive organizational responses.

One typical response is that those involved with project management, either at the project or the portfolio level, quickly realize that the methodology does not fit the business and project conditions and choose to ignore the methodology. Unfortunately, even the project teams managing projects for which the methodology is a fit begin to ignore the methodology - since everyone else is - and no benefit from the methodology is realized. When this response occurs, the organization usually maintains the status quo on project performance, despite the improvement efforts associated with implementing the new methodology. Everyone continues to interact with projects in the way they have in the past, and the business's ability to improve its strategy implementation remains unchanged. This often leads to a very cynical view of project management systems and methodology in general, with many individuals in the organization thinking they don't work or at least they don't work "here."

A second response occurs when the methodology is imposed on the organization and compliance is required. This leads to a mixed response within the organization. For those projects and business conditions where the methodology does fit there is typically an improvement in several measures of project performance. In those cases, the project teams often become strong advocates of the use of the methodology. For those projects and business conditions where the methodology does not fit, major problems in project planning and execution are often created. Sometimes the methodology creates massive amounts of useless work addressing issues that do not apply on the project. Sometimes particular tools are required that do not help the project team deal with the unique project risk, but rather mask the risk creating larger problems once the risk finally comes to the forefront. Sometimes the methodology requires unnecessary reviews and meetings where there is no change in status to report and no decisions to be made. Other times the methodology does not ensure timely reviews or that timely decision making occurs. For those projects where the methodology does not "fit," it is resented by the project team. The overall result for the business often leads to loss of morale, dysfunctional behavior and inconsistent performance.

The third category of response we have seen is when an organization embraces the new methodology and uses it to both manage and screen projects. In this case, projects that don't fit the inherent business and project conditions assumed by the methodology are never started. This leads to several organizational responses. The responses include 1) a curtailment in what strategic options are considered, 2) a major effort to outsource the incompatible projects, or 3) the development of a "shadow" project management approach where the projects that don't fit the methodology are done behind the scenes until the project conditions can fit the methodology when they are then brought forward.

As an example, one company we have worked with implemented a new product development methodology that has led to this third category. Their methodology requires complete, clear, and fully supported product, market, and business specifications before any new product project can be initiated. This methodology is suitable when the new product is a derivative of existing products within existing markets. However, for next generation products and emerging markets the project specifications can not be completed because there is no data with which to define the detailed product or market requirements. To work around this problem, individuals in the business have numerous "shadow projects" underway to create enough data to write specifications that are required to introduce the project into the new product development project management methodology. These "shadow projects" are lengthy, under-resourced, and haphazard in focus. There is no direct management oversight of "shadow projects." Therefore there is limited coordination and prioritization between functions. For those products with next generation technology or emerging markets, much of the project activity is accomplished before a "real project" is approved. When that happens, the "real project" becomes a paperwork exercise. The project team uses the project management methodology to document all of the work that was conducted in the "shadow" mode. The result is that valuable resources and effort are expended on "shadow projects" that should be directed towards those that are approved and support strategy. And the effort conducted on approved projects is perceived as bureaucratic and redundant.

The solution to the problem of the wrong project management methodology is not to avoid having a project management methodology. That approach leads to poor project risk management and communication, and ultimately to failed projects and failed business strategy. The solution is to devise a methodology, or family of methodologies, that are appropriate for the "real world" of your business and projects. In a future article I will explore several of the frameworks for analyzing the business and project context that allow you to define a methodology. Each of these frameworks provides valuable insight into determining the characteristics of the project management tools, techniques, and processes that are well suited to a unique set of business and project conditions.