Skip to main content

Author: Robert Wysocki

OUTSIDE THE BOX Forum: Project Birth, Maturation and Death Process, Part 2 of 2

The project enters the maturation process on the first day it becomes an active project.

The successful conduct of a complex project is fraught with all sorts of challenges.

PT June24 1

Project Active

A selected project is active if it has received its funding authorization and is open for work. At this stage, the PM is authorized to proceed with the recruiting and assignment of team members, to prepare the final work schedule, and other activities associated with launching the project.

In a complex project environment the SMT needs to maintain control while being flexible and adaptive at the same time. Here are my suggestions for your consideration:

Understand the deliverable schedule and expect exception reports only. For myself reports such as

  • Everything is going according to plan.
  • There are some minor variances from plan but I have a get well plan in place that will bring the plan in compliance by the next report date. The details are attached for your information.
  • There are major variances from plan and I need help implementing a corrective action plan. The details are attached for your action.
  • The project is heading for failure and I do not have the authority or knowledge to restore the project to plan. The details are attached for your intervention.

Project Evaluated

The Evaluation Phase consists of determining which portfolio or portfolios the project is most closely aligned with. Three outcomes are possible from this evaluation:

  • The project is not aligned and is rejected out of hand.
  • The project is not aligned but revision and resubmission recommended.
  • The project is aligned.

Alignment is often a quantitative measure. Once the project is determined to be aligned the proposing parties should begin preparing a detailed plan. The plan will contain information like time, cost, and resource requirements that will help the portfolio manager make a final determination regarding the project support that will be needed from the portfolio.

Alignment is a complex task. The first decision the SMT needs to make is how to define the alignment process. Will you use a quantitative or qualitative metric? I’ll defer that discussion to Chapter 9: An Agile Portfolio Strategy. The next decision is alignment with respect to what – a specific portfolio, several portfolios, one or more strategic objectives? That is also discussed in Chapter 9 and a few models suggested.

Project Prioritized

All proposed projects for the portfolio will be ranked along with other projects proposed for the same portfolio. This is the final stage before the project is selected for the portfolio. If it is high enough in priority, it will be funded and included in the portfolio.

The big question for the SMT is what criterion should be used for developing that prioritized list? Among the quantitative metrics business value is the most popular choice in the complex project world although risk and return on investment have also been used.

While you could force one measure on all project proposals that might be too restrictive and force invalid conversions of success measures to a single metric, like bottom line dollars. So allowing any one of the three metrics defined in IRACIS to be used, the problem reduces to comparing projects across all three measures of business value.

Among the qualitative measures a variety of rules such as MoSCoW are in common use:
M = must do
S = should do
C = could do
W = will not do now

Variations of A, B, and C or 1, 2, and 3 are also common. I personally prefer and exclusively use MoSCoW. The major reason is that each category contains a descriptor.


Advertisement
[widget id=”custom_html-68″]

Project Selected

This is a temporary classification and assuming approval of the portfolio, this project will be supported. That support may come in the form of less time, money, and resources than were requested. In such cases a revised project plan and expected business value will be prepared.

It goes without saying that the request for money, time, and staff will always exceed what is available. To think otherwise is pure fantasy. The SMT is responsible for defining the model that drives how these selection decisions will be made. For example, for a given portfolio you could fully fund the first ten of the fifteen projects selected for that portfolio or you could partially fund the first twelve. Which decision will you take? Is there a business rule here or will the decision be subjective? And don’t forget that complex projects will only succeed in a creative environment. Does that creativity encompass the selection criteria? I would argue for your making room for some speculation but being heavy handed on accountability.

As a portfolio manager there are some traps awaiting you. You can easily force a PM into a no-win situation by maintaining the originally proposed deliverables but in less time, for less money or with fewer resources. Many PMs want their projects supported and will often agree to compromises that cannot be realistically attained. Be careful that you don’t force them into such positions. Once the level of support has been awarded require the PM to finalize the project plan and deliverables in line with the support provided and then negotiate from that position to a realistic closure. Now the project team can be held accountable for the results they agreed to deliver. If you base individual performance reviews on project performance, you will have created a motivating environment.

As the sponsoring executive you are responsible for achieving expected business value. You sold the expected business value of the project to your SMT colleagues and they deferred to your judgment. The project team is responsible for completing the project as defined by your office. The project team is not responsible for the business value. They may contribute to increased business value but the sponsor is responsible for achieving the expected business value.

Project Death Process

There are three ways that the project can move through the death process. It can be postponed, canceled or completed.

Project Postponed

An active project is postponed if its staff resources have been temporarily removed. Such projects must return to the pool of prioritized projects and be selected and its staff resources restored. The resources allocated to a postponed project are returned to the staffing category from which they originated to be reallocated to the next project in the queue of that project category.

Postponed indefinitely

The problem situation or business opportunity is no longer what it was when the project was first proposed. Unless that situation changes the project will die a slow death.

Paused

A project can be paused for some number of cycles due to a temporary condition and then resumed when the condition is no longer in play. These conditions include:

  • Higher priority projects require team resources for a few cycles for completion.
  • There is a temporary loss of resources to the portfolio.

Project Cancelled

An active project is canceled if it has failed to demonstrate planned progress toward its successful completion. Depending on the stage in which the project was cancelled, there may be unspent resources. If so, they are returned to the resource pool from which they originated. Those resources then become available for the next project in the prioritized queue of projects being held pending funding for that portfolio.

Project Completed

A project is completed if it has met all of its objectives and delivered acceptable business value. Even if it hasn’t met all of its objectives the decision may be to call the current solution acceptable and hence the project complete. Recall that the complex project environment is one where the final solution is not known at project launch and the solution attained may compromise some of the deliverables and hence delivered business value may be less than planned business value but yet acceptable to the SMT.

Putting It All Together

Every organization needs to define its own version of this birth and death process. Having done that the organization and the SMT can track the number of projects in each category. This is especially important in establishing the contents of each portfolio. Of specific interest will be the Project Prioritization category and the staffing of selected projects. Prioritization includes new projects, continuing projects, and postponed projects. Defining the rules for prioritization is not as easy as you might think. The three categories of projects are to be prioritized in a single list and they are very different types of projects.

OUTSIDE THE BOX Forum: Project Birth, Maturation and Death Process, Part 1 of 2

With over 40 years of project management experience I can’t help but conclude that despite the fact that projects are supposed to be finite efforts,

there are some projects that will never die. After a while they take on a life of their own even though no one remembers why the project is being done. It has become institutional. With the exception of those projects all projects follow a cycle of birth, maturation, and death just like any biological process or product life cycle. Up to the time of their birth (a.k.a. approval) projects are in a planning phase when the decision to undertake the project is made. Throughout their maturation phase (a.k.a. execution) projects are subject to change due mostly to random events whose likelihood was hopefully anticipated and planned but whose occurrence cannot be predicted. For all complex projects that maturation process includes the discovery, learning, and integration of functions and features into the solution. At some point in time the solution is deemed complete for the time and cost invested. The end of the project signals its death when the deliverables are produced and the project is completed successfully or acceptable deliverables are not produced and the project fails. Project success is measured by the deliverables having produced acceptable business value.

This is all well and good but the realities are often quite different. Are there active projects in your organization that are active only because their sponsor had the power and leverage to get them approved? If there ever was a valid business reason for the project, it is long since disappeared but the project hasn’t. Terminating a project is difficult especially because of the impact on the sponsor and the reputation of the client.

Declaring a project a failure and then terminating it is often not as clear a decision as one might think. Failure is a temporal decision. Take for example the case of the sticky note. The project that produced the glue was declared a failure because the glue did not have the physical properties needed. The project results sat on the shelf for over 7 years until an application for the glue was identified – result the Post-It Note. So one man’s failure may be another man’s success. If the project was to cure melanoma and instead delivered a successful tanning lotion that totally prevented sunburn, was the project a success or a failure? I mention this to you so that you will be cautious because in the complex project world failure is very difficult to define.

For the SMT each phase in the project life cycle requires continuous monitoring, adjustment, and stage-gate approval. These are described below. Figure 7.1 identifies the changing status of a project as it moves through the portfolio management life cycle. The portfolio management life cycle process is described in Chapter 8. For now it is sufficient to know that there are eight different stages that a project may be in during the portfolio life cycle. These are briefly described below as they align with each of the three phases in the project birth, maturation, and death processes.

PT June24

Figure 1: The project birth, maturation and death life cycle     

Project Birth Process

The project birth process begins with an idea and ends when the idea becomes an approved and funded project attached to the appropriate portfolio.

Project Proposed

All projects begin with an idea to address an existing problem or take advantage of a new business opportunity. It is the responsibility of the proposer or their staff to provide business validation that the proposed project makes good business sense.

The proposed project is documented with a one page Project Overview Statement (POS) and submitted to the appropriate portfolio to be evaluated regarding its alignment to the portfolio strategy and its suitability for support. The POS originated at Texas Instruments as part of its new product research and development process. I started using it in 1963 while an employee at Texas Instruments and have continuously adapted it to the project proposal process that I also developed. It is invaluable. The POS is a five-part document that contains:

Problem or Opportunity Statement

Every organization has a collection of known problems and untapped business opportunities. Several attempts to alleviate part of or the entire problem may have already been made but the problem persists. The POS gives proposers a way to relate their idea to a known problem and to offer a full or partial solution. If the problem is serious enough and if the proposed solution is feasible, further action will be taken. In this case, senior managers will request a more detailed solution plan from the requestor.

Untapped business opportunities abound. Technology fuels that. A statement that speaks to exploiting technology in order to improve an existing product or develop an entirely new one will certainly get the attention of the SMT.

Whichever the reason for the problem or opportunity statement, it must be written in the language of the business because it will be read by executives like you. So no techie talk allowed unless everyone who might have a reason for reading the POS speaks techie talk.

Project Goal

The second section of the POS states the goal of the project—what you intend to do to address the problem or opportunity identified in the first section of the POS. The purpose of the goal statement is to get the SMT to value the idea enough to read on. In other words, you should think enough of the idea to conclude that it warrants further attention and consideration. Several POSs might be submitted that propose projects addressing the same issue.

A project has one goal. The goal gives purpose and direction to the project. At a very high level, it defines the final deliverable or outcome of the project in clear terms so that everyone understands what is to be accomplished. The goal statement will be used as a continual point of reference for any questions that arise regarding the project’s scope or purpose.

Just like the problem or opportunity statement, the goal statement is short and to the point. The goal statement does not include any information that might commit the project to dates or deliverables that are not practical. Remember that you do not have much detail about the project at this point.

Project Objectives

The third section of the POS describes the project objectives. Think of objective statements as a more detailed version of the goal statement. The purpose of objective statements is to clarify the exact boundaries of the goal statement and define the boundaries or the scope of your project. In fact, the objective statements you write for a specific goal statement are nothing more than a decomposition of the goal statement into a set of necessary and sufficient objective statements. That is, every objective must be accomplished in order to reach the goal, and no objective is superfluous.

Identifying Success Criteria

The fourth section of the POS answers the question, “Why do we want to do this project?” It is the measurable business value that will result from doing this project. It sells the project to the SMT.

Whatever criteria are used, they must answer the question, “What must happen for us and the client to say the project was a success?” The COS will contain the beginnings of a statement of success criteria. Phrased another way, success criteria form a statement of doneness. It is also a statement of the business value to be achieved; therefore, it provides a basis for senior management to authorize the PM and the client to do detailed planning. It is essential that the criteria be quantifiable and measurable, and, if possible, expressed in terms of business value. Remember that the proposer is trying to sell their idea to the SMT.

No matter how you define success criteria, they all reduce to one of the following three types:

Increase revenue—As a part of the success criteria, the increase should be measured in hard dollars or as a percentage of a specific revenue number.

Avoid costs—Again, this criterion can be stated as a hard-dollar amount or a percentage of some specific cost. Be careful here because oftentimes a cost reduction means staff reductions. Staff reductions do not mean the shifting of resources to other places in the organization. Moving staff from one area to another is not a cost reduction.

Improve service—Here the metric is more difficult to define. It’s usually some percentage of improvement in client satisfaction or a reduction in the frequency or type of client complaints.

These criteria are often recognized by the name “IRACIS.”

The best choice for success criteria is to state clearly the bottom-line impact of the project. This is expressed in terms such as increased margins, higher net revenues, reduced turnaround time, improved productivity, a reduced cost of manufacturing or sales, and so on. This is the criteria on which the SMT will approve the project for further consideration and funding.

The SMT should look at the project’s success criteria and assign business value to the project. In the absence of other criteria, this will be the basis for the decision about whether to commit resources to complete the detailed plan or not.


Advertisement
[widget id=”custom_html-68″]

Assumptions, Risks, and Obstacles

The fifth and final section of the POS identifies any factors that can affect the outcome of the project and that should gain your attention as a member of the SMT. These factors can affect deliverables, the realization of the success criteria, the ability of the project team to complete the project as planned, and any other environmental or organizational conditions that are relevant to the project. The proposer wants to share anything that can go wrong and that the SMT might be able to favorably impact.

The project manager uses the assumptions, risks, and obstacles section to alert the SMT to any factors that may interfere with the project work or compromise the contribution that the project can make to the organization. The SMT may be able to neutralize the impact of these factors. Conversely, the project manager should include in the project plan whatever contingencies can help reduce the probable impact and its effect on project success.

Do not assume that everyone knows what the risks and perils to the project will be. Planning is a process of discovery about the project itself as well as any hidden perils that may cause embarrassment for the team. Document them and discuss them.

Attachments

Even though I strongly recommend a one-page POS, some business processes call for a longer document. As part of their initial approval of the resources to do detailed project planning, the SMT may want some measure of the economic value of the proposed project. They recognize that many of the estimates are little more than an order-of-magnitude guess, but they will nevertheless ask for this information. I have seen the following two types of analyses requested frequently:

  • Risk analysis
  • Financial analysis

The following sections briefly discuss these analysis types.

Risk Analysis

In my experience, risk analysis is the most frequently used attachment to the POS. In some cases, this analysis is a very cursory treatment. In others, it is a mathematically rigorous exercise. Many business-decision models depend on quantifying risks, the expected loss if the risk materializes, and the probability that the risk will occur. All of these are quantified, and the resulting analysis guides management in its project-approval decisions.

In high-technology industries, risk analysis is becoming the rule rather than the exception. Formal procedures are established as part of the initial definition of a project and continue throughout the life of the project. These analyses typically contain the identification of risk factors, the likelihood of their occurrence, the damage they will cause, and containment actions to reduce their likelihood or their potential damage. The cost of the containment program is compared with the expected loss as a basis for deciding which containment strategies to put in place.

Financial Analyses

Some organizations require a preliminary financial analysis of the project before granting approval to perform the detailed planning. Although such analyses are very rough because not enough information is known about the project at this time, they will offer a tripwire for project-planning approval. In some instances, they also offer criteria for prioritizing all of the POS documents that senior management will be reviewing. At one time, IBM required a cursory financial analysis from the PM as part of the POS submission. Following are brief descriptions of the types of financial analyses you may be asked to provide.

Feasibility Studies

The methodology to conduct a feasibility study is remarkably similar to the problem-solving method (or scientific method, if you prefer). It involves the following steps:

  1. Clearly define the problem.
  2. Describe the boundary of the problem—that is, what is in the problem scope and what is outside the problem scope.
  3. Define the features and functions of a good solution.
  4. Identify alternative solutions.
  5. Rank alternative solutions.
  6. State the recommendations along with the rationale for the choice.
  7. Provide a rough estimate of the timetable and expected costs.

The PM will be asked to provide the feasibility study when senior management wants to review the thinking that led to the proposed solution. A thoroughly researched solution can help build your credibility as the project manager.

Cost and Benefit Analyses

These analyses are always difficult to do because you need to include intangible benefits in the decision process. As mentioned earlier in the chapter, things such as improved client satisfaction cannot be easily quantified. You could argue that improved client satisfaction reduces client turnover, which in turn increases revenues, but how do you put a number on that? In many cases, senior management will take these inferences into account, but they still want to see hard-dollar comparisons. Opt for the direct and measurable benefits to compare against the cost of doing the project and the cost of operating the new process. If the benefits outweigh the costs over the expected life of the project deliverables, senior management may be willing to support the project.

Breakeven Analysis

This is a timeline that shows the cumulative cost of the project against the cumulative revenue or savings from the project. At each point where the cumulative revenue or savings line crosses the cumulative cost line, the project will recoup its costs. Usually senior management looks for an elapsed time less than some threshold number. If the project meets that deadline date, it may be worthy of support. Targeted breakeven dates are getting shorter because of more frequent changes in the business and its markets.

Return on Investment

The ROI analyzes the total costs as compared with the increased revenue that will accrue over the life of the project deliverables. Here senior management finds a common basis for comparing one project against another. They look for the high ROI projects or the projects that at least meet some minimum ROI.

A project that does not meet the alignment criteria may be either rejected out of hand or returned to the proposing party for revision and resubmission. Projects that are returned for revision generally need minor revision and following the suggested revisions should meet the alignment criteria.

These four financial analyses are common. Their purpose is to help the financial analysts determine the risk versus reward for the proposed project.

As a member of the SMT you have the power of rank at your disposal. So my first caution to you is don’t abuse your power by forcing your project idea into the portfolio. Staff below you in the organization has a difficult time saying no or pushing back on your idea. If your idea is valid from an expected business value perspective, sell it on its own merits not on the power of your office. Clogging the process with frivolous ideas is a waste of time and resources and just adds confusion to a challenging portfolio management process.

OUTSIDE THE BOX Forum:A Practical Project-based Model of the Enterprise, Part 4 of 4

Who are the Participants in the EPMM?

Across the 6 phases of the EPMM several managers and professionals will be involved. This section defines these participants and gives examples of typical position titles.

Line of Business (LOB) Managers or Directors

This is a collective manager type. There are no positions named “LOB Manager”. A LOB is a Manager or Director of a business unit that directly produces business value, usually but not always financial. An LOB Manager or Director has responsibility for a product, process or service that uses resources to directly interacts with customers or clients to produce business value. 

Functional Managers

This is a collective manager type. There are no positions named “Functional Manager”. Some functional managers are resource managers. The key differentiator is whether they manage resources directly or use resources to produce business value. So, for example the Director of Marketing is a functional manager. They use the Data Warehouse (a resource) to produce a marketing plan which generates business value through increasing sales. On the other hand, the Director of Human Resources is a resource because they directly manages the human resource. One might argue that they could also be a functional manager if they manage a professional development program which produces a skill and competency inventory that is aligned with the project, program and portfolio needs of the enterprise. If we think at the role level the apparent conflict is easily resolved. In the role of managing the human resource they are a resource manager. In the role of managing the professional development program, they are a functional manager.

Resource Managers

This is a collective manager type. There are no positions named “Resource Manager”. Anyone in the organization who has total and direct stewardship responsibility over a resource that has business value.  It includes those functional managers with responsibility for resources that have business value (for example, Human Resource managers (human assets); financial managers, (financial assets); sales, marketing and public relations managers, (intangible assets); IT and engineering managers, (IP and knowledge assets) and plant or equipment managers, who have stewardship over and manage the physical assets of an organization. Depending on the specific circumstances, these people are often those who, in their role function as project SPONSORS. They have decision making authority over where the assets under their charge are deployed to create expected business value. A less comprehensive set or resources was introduced in earlier editions of Effective Project Management, 6th edition (EPM6e) and can be consulted for further discussions that are out of scope for this article.

Strategy Portfolio Managers

These could be any of the above. The Strategies are established as part of the Strategic Planning Process and their managers assigned at that time. They constitute a Strategy Team whose major responsibility is to assure the delivery of expected business value through the effective use of resources across all Strategy Portfolios. 

Project Managers

The project manager is the critical supporting participant who takes the resources delegated to him or her by a Strategy Manager and utilizes those resources to produce a project deliverable which hopefully will achieve the strategic objectives defined by the project sponsor. That could come in several forms: 
  • New product development or improvement
  • Process design or improvement
  • Service enhancement
So, the project manager facilitates the process of change and manages the risk of achieving that change. They are the enablers of the projects in a Strategy Portfolio.

Business analyst

It is important to distinguish between two types of Business Analysts. They can be generalists or specialists.
I’m a firm believer in complex projects having a team comprised of both specialists and generalists. The argument in support of the generalist is that they have the ability and skills to keep options open and may see solution details that would otherwise be missed.  The specialist is constrained to their span of knowledge and experiences and can easily miss a clue about the undiscovered parts of the solution. The argument in support of the specialist is that only they can know if a suggested approach will work in the environment they represent. The generalist would not be able to make that call. 
We know that the project manager (PM) takes the lead in managing the process for defining and solving the problem and the business analyst (BA) takes the lead in solving the problem and installing the deliverables. If you hold to this, then it is obvious that both the PM and the BA are involved in the project from beginning to end. This brings up a discussion of the role of generalists and/or specialists on the project. Calling the PM a generalist and the BA the specialist is too simplistic and usually not correct. A detailed discussion of generalists versus specialists is beyond the scope of this brief article but a few observations with respect to their roles on a project are within scope.
These five professional manager groups interact throughout the entire life span of the Strategy Portfolios from birth to death. In later chapters we will expand on each of these three manager-types and discuss their roles and interactions between and among one another.

What is the Enterprise Project RASCI Matrix?

The RASCI Matrix identifies the relationship between individuals and the major processes, phases or steps of an effort. In our case we link responsibilities of the 3 major managers and 3 support professionals to the 6 phases of the EPMM. Figure 1.8 is an operational RASCI Matrix. 
Robert Wysocki June 10 1.jpg
Figure 1.8: EPMM RASCI Matrix

Complex Project Profiling

For our discussion of complex projects I reference a recent book by Kathleen B. Hass (2009, “Managing Complex Projects: A New Model,” Vienna, VA: Management Concepts, ISBN 978-1-56726-233-9). 
There is no simple accepted definition of a complex project. The best we have to offer are some of its characteristics from the proceedings of the 2008 NASA Project Management Challenge Conference (Mulenburg, Jerry, “What Does Complexity Have to do With It? Complexity and the Management of Projects,” 2008): 
Details: number of variables and interfaces
Ambiguity: lack of awareness of events and causality
Uncertainty: inability to pre-evaluate actions
Unpredictability: inability to know what will happen
Dynamics: rapid rate of change
Social Structure: numbers and types of interactions.”
 

Advertisement
[widget id=”custom_html-68″]

Complex projects are filled with uncertainty and unexpected change. Complexity, uncertainty, and the pace of the project all contribute positively to project risk. Risk increases as any of these three variables increases. In most cases these projects are trying to find solutions to critical problems whose solutions have evaded even the most creative professionals. These projects can also be seeking to take advantage of heretofore untapped business opportunities without a clear path as to how to do that. If organizations are to be successful in this environment they must:
  • employ management processes that are flexible;
  • empower the client and the project team;
  • provide an open environment in which creativity can flourish;
  • base decisions on what is best for adding business value, and
  • avoid encumbering project managers with non-value added work. 
These are significant challenges because they require senior managers to step outside of their comfort zone and embrace frequent change and high risk. 
The first bit of business for you as a member of the SMT is to understand the project environment within which your project, program, and portfolio managers and their teams must work and within that environment the challenges you will face in establishing and supporting an effective project management environment. The needs of that environment have changed dramatically in the last 15 years especially with respect to the tools, templates, and processes that support it. The result is confusion and the introduction of yet another silver bullet every Tuesday. Those silver bullets appear very enticing but let me make it clear that there are no silver bullets now nor have there ever been. There are strategies and you are going to learn them from this book but they will require work on your part in order to implement them and continuing attention from your office for them to become and remain effective in your organization. The reactions of my client organizations as they attempt to support complex project management is predictable. I offer you what I have learned over the years.
Let me try to put this in a context that relates directly to the SMT. A recent worldwide survey (IBM, 2010, “Capitalizing on Complexity: Insights from the Global Chief Executive Officer Study” GBE03297-USEN-00) conducted by IBM from September 2009 through January 2010 reported that over half of the 1541 executives from the 60 countries that they interviewed admitted that they were not prepared to support the complex and uncertain environment in which they were forced to conduct business and they didn’t know what to do about it. If that isn’t a wake-up call to action, I don’t know what is.
The following quote from that IBM report highlights the efforts of standout organizations to manage complexity. Their efforts provide a roadmap for us.
“The effects of rising complexity call for CEOs and their teams to lead with bold creativity; connect with customers in imaginative ways, and design their operations for speed and flexibility to position their organizations for twenty-first century success. To capitalize on complexity, CEOs:
Embody creative leadership.
CEOs now realize that creativity trumps other leadership characteristics. Creative leaders are comfortable with ambiguity and experimentation. To connect with and inspire a new generation, they lead and interact in entirely new ways.
Reinvent customer relationships.
Customers have never had so much information or so many options. CEOs are making “getting connected” to customers their highest priority to better predict and provide customers with what they really want.
Build operational dexterity.
CEOs are mastering complexity in countless ways. They are redesigning operating strategies for ultimate speed and flexibility. They embed complexity that creates value in elegantly simple products, services and customer interactions.”
The messages from this survey are clear and validate the goal of this book. The solution offered herein is a logical approach to mitigating the complexity problem that over half of the CEOs interviewed admitted having. Which half of the population do you align with? If you want to prepare yourself to handle complexity, this book is mandatory reading and prepares you to take action. If you are a standout organization, congratulations but you should still read this book because in these pages you will find some gems to help you stay on top of changing complexity and uncertainty. 
There was a time when you may have distanced yourself from projects. Your feeling was that projects were operational level activities and of little importance to someone at your management level. In the past 20 years you’ve probably rethought that position and now see projects as investments and part of a portfolio that has an investment strategy. You may in fact be the manager that determines that strategy. For that reason you are challenged to do what you can to maximize the return on investment (ROI) to your organization from the projects you recommend for the portfolio and that you support directly. How you have responded to this situation depends on your roles and responsibilities with respect to the project, the project teams, and the portfolio. You may have primary responsibility for supporting or managing project managers or have a role supporting those who do have primary responsibility for supporting or managing project managers. In any case, this book offers you the advice you will need to help you and your organization succeed.
The business environment has changed significantly in the last 20 years and has ushered in new project management challenges that the old ways simply cannot support. Business as usual with respect to projects no longer works and may have never worked. Contemporary projects are projects of high complexity and great uncertainty and you must deal with them under those conditions. All of the simple projects have been done! Specifically, 
  • Complex project managers need the confidence and support of their management
  • Complex project teams must be empowered so they can be successful
  • Complex project portfolios must be aligned with staff resources
  • Complex projects are unique and so are their management approaches
  • Complex projects are high-risk projects
  • Complex projects require a creative approach to discovering solutions
  • Complex project require meaningful client involvement
  • Complex projects require flexible support services
In the pages that follow you will see just how you can and must positively impact all of these challenges. So let’s get started with a brief introduction to the complex project environment. Understanding that environment is the foundation on which you will be able to build your support strategy.
Kathleen B. Hass (2009, Managing Complex Projects: A New Model, Vienna, VA: Management Concepts, ISBN 978-1-56726-233-0) offers the most in depth treatment of complexity that we have. She describes complexity in terms of:
  • Time, Cost, and Size
  • Team Composition and Performance
  • Urgency and Flexibility of Cost, Time, and Scope
  • Clarity of Problem, Opportunity, and Solution
  • Requirements Volatility and Risk
  • Strategic Importance, Political Implications, Multiple Stakeholders
  • Level of Organizational Change
  • Risks, Dependencies, and External Constraints
  • Level of IT Complexity
In a paper written shortly after her book was published (Presented at the 2010 PMI Global Congress Proceedings, Washington, DC) she updates the complexity definition with a four-point scale (Independent Projects, Moderately Complex Projects, Highly Complex Projects, and Highly Complex Programs) and displays the values for a specific project in the form of a spider chart. Figure 1.10 is a hypothetical example adapted from her updated definition and published with her permission.

OUTSIDE THE BOX Forum:A Practical Project-based Model of the Enterprise

The Enterprise Project Management Model (EPMM)

At a very high level of abstraction the EPMM can be reduced to 5 simple questions by adapting the Graham-Englund Project Selection Model (Graham, Robert and Randall Englund, 1997. Creating an Environment for Successful Projects, San Francisco, CA: Jossey Bass),  as shown in Figure 1.4  below and introduced in Effective Project Man 

 PM June3 1

Figure 1.4: Adapting the Graham-Englund Selection Model to the EPMM

The Graham-Englund Selection Model is an intuitive model and derives directly from Figure 1.4. It gives a very simple introduction to the EPMM and relates to the EPMM as follows:

  • What projects should we do? This decision follows from the Market Opportunities. 
  • What projects can we do? This decision follows from the Enterprise Capacity.
  • What projects will we do? The Strategic Alignment Model defines these in terms of the Tactics identified in Figure 1.2. The decision on portfolio contents must include all portfolios because they are interdependent by virtue of their resource requirements and schedule availabilities.
  • Will the portfolios be balanced? Balance is in the eyes of the beholder. There are two points of balance in a portfolio.

The first is with respect to the business strategy and there are several models that might apply (See EPM6e Chapter 14: Project Portfolio Management Process.).

The second is with respect to resource capacity, especially the human resource inventory of skills and competencies. If every portfolio requires senior level project professionals, what do you do with the lower level project professionals. Alignment of supply and demand across all resource types is a critical component of the EPMM. As Strategy Managers balance staffing needs of their projects against available resources a common practice is to replace “A Team” players with “B Team” or even “C Team” players. EPM6e has a lot more to say on these compromises.

  • How are the portfolios performing? Projects are included in a Strategy Portfolio because they expect to deliver acceptable business value to the Strategy Portfolio. Each project’s performance is continuously assessed against that expectation. At regular intervals Strategy Portfolio reviews are conducted. Under performing projects may be revised or terminated and its resources assigned to a replacement project.

To achieve the Business Strategy and Strategic Plan of the enterprise requires a comprehensive process that I will call an Enterprise Project Management Model (EPMM). As defined below we will come to realize that it is an interlocking and interdependent collection of processes involving several different managers from C-level executives to department managers and several different support professionals.

There are two views of the EPMM that will help put projects into proper perspective. The project level process flow diagram is described in Figure 1.5 and the process flow diagram of the Strategy Portfolios. 

PM June3 2

Figure 1.5: EPMM – A  Portfolio-level EPMM Process Flow Diagram

The history and development of the EPMM begins in the early 1960s. I was a newly minted system engineer enjoying my first real job at Texas Instruments in Dallas, Texas. I was exposed to the annual planning process called TI/OST. That process has evolved over the years and is still monitored by the Harvard Business School (reference?). The learning opportunities it afforded me are reflected in much of my project management publications and the EPMM as well.

The EPMM takes the Strategic Alignment Model described in EPM6e and puts it in the context of the enterprise. Figures 1.5 gave a high-level view of the EPMM. This offers a fresh perspective on how projects, programs and portfolios arise and how they are in fact interdependent due to the fact that they draw from a finite and dependent set of resources. That elevates decision making to the highest levels of the enterprise.

The Vision, Mission and Objectives statements drive the specification of Strategies to be implemented over the strategic planning horizon through the submission and selection of Tactics aligned to those Strategies. Six phases trace the life span of a project, program or portfolio – from birth to maturation to death. Below is a snapshot of each phase.

COLLECT Phase

The net to collect these ideas must caste a wide berth across the enterprise. This is both a top-down and a bottom-up effort. The top-down effort is guided by the resource, functional and LOB managers. The bottom-up effort is to support a process that encourages anyone in the enterprise to submit their ideas to their appropriate managers. At this point every idea is a good idea and the process used to gather these ideas must facilitate ideas coming from anywhere in the enterprise. The ideas that form this initial set are discussed and vetted by C-level and other senior level resource and operations managers through a collaborative model. All of the ideas are submitted using a one page document called a Project Overview Statement (POS). Comments and observation are added to each POS and then forwarded to the ANALYZE Phase.


Advertisement
[widget id=”custom_html-68″]

ANALYZE Phase

The successful execution of this phase depends on input from the appropriate business analysts. Their analysis will collect more detailed intelligence on each of the ideas for the purpose of reducing the set to a much smaller set of feasible ideas. In the process of doing this analysis more detailed information on each feasible idea will be appended to each POS. These amplified documents are forwarded to the SELECT Phase. One of the critical activities in the ANALYZE Phase is the alignment of Feasible Ideas to Strategies. There are two processes for completing this activity.

PROJECT Scope Phases

The Project Scope Phases are repeated for each Strategy. The next three phases (SELECT, INITIATE and EXECUTE) bound project management as we know it. The interesting feature of the EPMM is the positioning of the choice of best fit project management life cycle (PMLC) within the INITIATE Phase. The process for making that best fit decision is portrayed in Figure 1.6 below.

SELECT Phase

The first step in the SELECT Phase is to prioritize the feasible ideas that came out of the ANALYZE Phase. There are several ways to do that depending on the needs. From that prioritized list choosing the Best Idea is a complex process. First of all, we are not just picking just one project. We will pick the best from among a short prioritized list that is aligned with a “bucket” that includes projects that are aligned with a Goal and one or more of its Strategies. At this level we are picking a portfolio that spans all of the buckets and are constrained by the applicable set of resources. A further complicating factor is that many of the resources are finite and more than one resource is needed for any feasible idea. In that sense, resources are not independent from one another and that complicates the choice of  Best Idea. So in effect what we have is a machine with lots of moving and dependent parts.

INITIATE Phase

The INITIATE Phase begins with the preparation and sponsor’s approval of the project plan. The INITIATE Phase begins with a process to choose the best fit PMLC Model for each project in the Strategy Portfolio (Figure 1.6). These plans are then consolidated into a single portfolio and final decisions are made about the final portfolio and the resource availability dependent schedule. To accommodate as many of these projects as possible, adjustments to project schedules might be needed to accommodate resource availability.

PM June3 3

Figure 1-6: A Robust EPMM Process for Choosing the Best Fit PMLC

EXECUTE Phase

Producing the deliverables according to the requirements can be straightforward (traditional projects) or risky and very challenging from a management perspective (complex projects). In the final analysis, the sponsor has to decide if the expected business value can be realized. Maybe yes; maybe no. If yes, everyone is satisfied and the deliverables can be installed. If no, any number of further actions might be approved.

DEPLOY Phase

The deliverables are put in operational status according to one of several implementation strategies and the deliverables are monitored for compliance during a warranty period before full responsibility is transferred to a resource or operations manager. Actual business value delivered is tracked against expected business value.

OUTSIDE THE BOX Forum: A Practical Project-based Model of the Enterprise

The purpose of this first of four articles is to set the stage for the life cycle of projects, programs and portfolios within the enterprise.

It introduces a model called the Enterprise-level Project Management Model (EPMM). To date articles on project management assume the existence of a project with little discussion of where that project comes from; the business validation and expected business value; why there is even a project and how to manage it within the constraints of the enterprise. In effect projects are treated as if they were islands independent of external constraints and factors. Nothing could be farther from the truth! Imbedding the project into an enterprise context introduces a number of factors external to the project that impact the project management life cycle (PMLC). Many of those factors are related to resource capacity and schedule availability. This article sets the stage for the Enterprise Project Management Model (EPMM). It encompasses these factors as well as others and the attendant management decisions that arise.

The origins of the EPMM date from the 1960s. The Objective/Strategy/Tactic Process was in its embryonic stage at that time and in use at Texas Instruments in its Corporate Research & Development Division in Dallas, Texas.

The Business Environment

The Business Environment is fickle, somewhat unpredictable and continuously changing. In the past 60 years it has been heavily influenced by the relentless march of technology and the intrusion of the internet into all aspects of our economic and social lives.

Business is global

Outsourcing dominates the support service businesses (call centers and help desks, for example) and software development (I am constantly plagued by Indian-based businesses looking for software development contracts). The US is trending towards becoming a knowledge-based economy and suffered the loss of many jobs that will never return. The number of displaced workers continues to grow as businesses struggle to recoup their market positions. You may not sell in the international markets but your competitors sell in your markets and your business decisions are forced to take on an international perspective.

Success goes to the creative and courageous

Those who can envision products and services put themselves at great risk. The early entrants into social media applications are testimonials to that success. But the secret is more than a matter of creativity. The business idea must include barriers to entry or an unknown software developer will replicate your idea and from his dining room table in Mumbai will set up a competitor business and your business will be in harm’s way. So the business environment is one of high speed and high change with technology and the internet as the driving force. On the positive side, the world is your market. Place has no place in the marketing mix! It is obvious that an EPMM is a critical success factor (CSF) in the 21st century marketplace.

The Business Environment – A View from the Top

Figure 1-1 illustrates the business environment from the highest level. Processing it and making it your own is fundamental to our discussion of projects, programs and portfolios in the proper context of the enterprise. It takes a village to effectively manage the Enterprise Project Management Model (EPMM) and generate sustainable business value. Defining that village and how each of its citizens interact and depend upon one another is critical to the success of the EPMM. This is a critical element in this book.

  Robert Wysocki Apr29

Figure 1-1: The Business Environment

Market Opportunities

With that understanding of the continuous changes in the Business Environment, Market Opportunities will come and go. If you can’t seize the opportunity immediately, someone somewhere on the planet will! The opportunities will be internal (problem solving and process improvement, for example) and external (new product, service and processes for meeting the needs of an expanded customer base, for example). Taking advantage of these opportunities requires a culture characterized by openness and creativity and business practice managers that are not afraid to take reasonable business risks. Windows of opportunity open and close sometimes without warning (due to the introduction of new technologies, for example). Projects that thrive in this risky environment are complex projects and require solid collaborative efforts between business managers at all levels and project managers as the enablers of business ideas.


Advertisement
[widget id=”custom_html-68″]

Enterprise Capacity

Clearly Enterprise Capacity is the driver of any strategic model. So any Tactic that relates to the creation or maintenance of Enterprise Capacity will be a strategic project. Capacity is defined at the resource level and was first discussed in EPM1e. When we elevate the discussion to the enterprise level, resources take on a different perspective and become an enabling factor and a constraining factor. Management decisions regarding Resource Capacity are complex and challenging due to the number of dependent factors.

Market Opportunities can only be exploited within the capacity of the Enterprise to support them. The Business Environment is in a constant state of flux so Market Opportunities will come and go. Any of those opportunities can be exploited if and only if Enterprise Capacity adjusts to align with those opportunities. One of the big questions for senior management is how to spend enterprise resources and how to adjust that allocation as Strategy Portfolio performance occurs.

The reference here is to the resources that are available for allocation to projects. In a multi-year planning horizon resource capacity might be upgraded or increased through projects, programs or portfolios designed for the purpose of expanding or enhancing enterprise capacity to more effectively align to and to support attainment of the Objectives defined in the Strategic Plan.

Resources and resource types (financial, physical, human, information and intangible) are defined later in this chapter. As stated above resource capacity, availability and the interdependencies among those resources is both a constraining factor and an enabling factor. As a constraining factor what the enterprise should do is limited by what the enterprise can do and finally leads to what the enterprise will do. As a counter measure to the constraining factor the enterprise needs to assure the alignment of not only resource supply but also resource availability against the business demands for those resources. So resource capacity is a dynamic tool that can be adjusted as a deliverable from the planning exercises. Expanding or enhancing resources will reduce the schedule contention between resources but that is a business decision that arises during the fulfillment of the Strategic Plan.

As an enabling factor resource managers collaborate with functional business managers and LOB managers to creatively solve problems and enable the exploitation of new business opportunities. These collaborative efforts result in the commissioning of projects, programs and portfolios to project managers who function as the enablers.

The constraining factor and the enabling factor and their implications at the enterprise level will dominate our discussion and development of the EPMM across all chapters.

Objectives

The integration of Objectives/Strategies/Tactics (OST) into a system is an embodiment of the Strategic Planning Process (SPP). OST has its roots in the emerging product planning processes developed and used by Texas Instruments in its Corporate Research & Engineering Division in the early 1960s. TI/OST required one quarter each year for the development of the strategic plan. The objective of the planning exercise was to identify 200 feasible new product ideas. The expectation is that the result would be bringing a handful of new products to market. At that time I was a systems engineer at Texas Instruments and benefited immensely from my understanding and use of their planning systems. I have taken the TI/OST processes and practices and brought them up to current standards and expectations and imbedded them into the EPMM. The EPMM is a game-changer for project managers and is presented here for the first time.

Objectives are generated at the highest levels of enterprise management as a direction-setting guide for those who will suggest Tactics for reaching the Objectives of the enterprise. In effect, the enterprise knows where it is (its current state) and knows where it would like to be (its desired end state). The missing ingredient is how to get there? Strategies and their aligned Tactics describe that journey. As Figure 1-1 clearly shows, those Tactics are defined through a collection of projects, programs and portfolios.

Strategies

Strategies are the guide for proposing Tactics and are the short-term variables in the SPP.

Each Strategy has a Strategy Manager. They are assigned as part of the SPP and manage their Strategy until all projects in their Strategy Portfolio are completed. The responsibilities of a Strategy Manager include:

  • Strategy Portfolio planning and management
  • Monitor portfolio performance and content in order to maximum expected business value contributions from their portfolio
  • Adjusting project scope and schedules to accommodate resource capacity and availability
  • Monitor portfolio performance and adjust resource allocation to assure maximal business value to the enterprise.
  • Negotiating resource requirements and utilization among all Strategy Managers

The relationship between Objectives, Strategies and Tactics can be complex and create interdependencies due to resource capacities and dependencies among and between resources. At the Objective/Strategy level the following apply:

Tactics

These will be offered in the form of potential project, program or portfolio ideas to be carried out within the planning horizon (3 or 5 years is common). Tactics are ideas for products, services or processes submitted to the EPMM in the form of one page documents called Project Overview Statements (POS). (The POS was first introduced in 1995 in EPM1e and has matured to its present form.). The extent to which a Tactic aligns with the Strategies of the enterprise is an important factor in any prioritization exercise of the proposed Tactics. The strength of that alignment and other factors (like risk and expected incremental business value) are the basis for decisions on which Tactics will be prioritized and approved. These projects, programs and portfolios represent the Tactics that convert available resources into incremental business value.

Tactics turn into approved projects, programs and portfolios. These are constrained as shown in the Scope Triangle which occupies the center of the Business Climate in Figure 1-1. It is a critical graphic that must be fully understood as it has several applications across the life of a project, program and portfolio. We will see those applications at the enterprise-level in this book. For a comprehensive discussion of the Scope Triangle and its application at the project level see EPM6e.