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.