Skip to main content

Author: Robert Wysocki

OUTSIDE THE BOX Forum: Hybrid Project Management Transformations Into the Digital Organization

The digital organization has brought on the need for a disruptive change in the processes and practices of project management.

No longer should we depend on out of the box Scrum, PRINCE2 or Waterfall Models. We don’t need models. We need flexibility, adaptability and creativity to successfully plan and manage today’s complex projects.

WHAT IS HYBRID PROJECT MANAGEMENT?

Organizations have spent years and lots of money designing project management models. Their inventories will include versions of the Waterfall Model along with one or more versions of Scrum, FDD, DSDM and perhaps other agile models. So, CMMI Maturity Level 2 seems well established but, according to Mulally, is seldom used. Assuming we have competent project managers, it is safe to assume they have found other alternatives than those provided by their organization and defined in the project management body of knowledge. Those alternatives are probably variations of what their organization has provided. These alternatives are not published but travel below the radar but it is safe to assume that these alternatives align with these three factors:

  • the behavioral and physical characteristics of the project
  • their cultural and organizational environment of projects
  • the external supply/demand markets for the deliverables

All three of these are dynamic. They can change at any time and in unexpected ways. When any one of the factors change, the specific project management approach designed by the HPMgr might also need to change. The objective is to maintain the alignment of the project management approach to the project in order to achieve maximum business value and minimization of the risk of project failure. In other words, projects are unique and so should the best fit model for managing them also be unique. After all, project management is nothing more than organized common sense – isn’t it? That is the basic principle underlying a hybrid approach and sets the stage for defining HPMgt.

WHAT IS THE HYBRID PROJECT MANAGEMENT FRAMEWORK TRANSFORMATION?

In order to achieve and maintain that alignment a robust HPMgt Framework must be defined. At the highest level of abstraction, a robust framework will have 3 phases:

  • Ideation Phase
  • Set-up Phase
  • Execution Phase

The dependency relationship among these three phases is shown in Figure 1.

wysocki 01082019aFigure 1. The HPM Framework

Ideation Phase

In this phase a definition of what the project is all about is developed. It begins with some type of request or mandate from a sponsor. Alternative approaches to the project are suggested and prioritized and a Business Case is developed. A short summary of the project approach is developed (such as a Charter Statement) which is used to gain approval and support for the project.


Advertisement
[widget id=”custom_html-68″]

Set-up Phase

In this phase a definition of how the project will be done is developed. It may include a specific project management model which may be an off-the-shelf, customized or unique model. In some cases, the vetted portfolio might be used to create the approach. The Set-up Phase will include a high-level plan with a budget, resource requirements and a schedule. That high-level plan might be subject to approval at an executive level.

Execution Phase

This phase executes the project management model that was designed for the project. In the most complex cases the learning and discovery that resulted from a previous iteration may require a revision of the Set-up Phase.

The Execution Phase has a feedback loop to the Set-up Phase which is unique among project management methodologies and requires some explanation. During the Client Review Step it may be discovered that changes to the solution require a review of how best to continue the project into the next cycle. That is an activity best done in the Set-up Phase.

SCOPE OF THE HPMgt FRAMEWORK

The above robust definition allows for several solutions. In fact, since a project is unique, the solution (a project management model) will also be unique. To be a useful framework the HPMgt Framework must support any project – from the very small and simple to the very large and most complex. At the highest level the Framework is defined by the Ideation, Set-up and Execution Phases. That defines the “WHAT” that must be done for every project. Within that robust structure we can define the “HOW” to do it. In defining that “HOW” the basic assumption is that the HPMgr is in charge and will define the “HOW” utilizing the vetted portfolio of tools, templates and processes. In using that vetted portfolio, the HPMgr can select and adapt items from the vetted portfolio to create an approach that aligns with the three factors that profile the project.

The Project Support Office (PSO) for the HPMgr will be an adaptation of the typical Project Management Office (PMO). The PMO is usually seen as a standards and compliance organization. That won’t work in a HPMgt environment. The PSO is by definition a support organization. That support includes:

  • a vetted portfolio of tools, templates and processes
  • consultants to provide support at the request of the HPMgr.

This article has defined the starting point for HPMgt. Stay tuned for other articles to follow that will put some meat on the bones of the “HOW”.

NOTES
[Mulally, 2017] Mulally, Mark, 2017. All is not the same in the World of Project Management, ProjectManagement.com, 3/27/17
[Robins, 2016] Robins, David, 2016. Introduction to Hybrid project management methodology, (HTTPS://WWW.BINFIRE.COM/AUTHOR/DAVID/)
[Wysocki, 2019] Wysocki, Robert K., 2019. Effective Project Management: Traditional, Agile, Extreme, Hybrid, 8th Edition (John Wiley & Sons Publishers, forthcoming)

OUTSIDE THE BOX: Client as Project Manager

Having the client manage their project is obviously an extreme position but hear me out before you pass judgment.

Open your mind to the possibilities. If client ownership of the deliverables has been a problem or if a successful implementation of the deliverables is at risk, consider appointing the client as the Project Manager. No assumption is made about the client’s project management experience or expertise. The person who would have been the Project Manager will assume the role of Project Management Consultant to make sure that the client, with limited knowledge of managing projects, is kept pointed in the right direction and briefed on management actions and pending decisions. That appointment will promote ownership and assure implementation too. The client’s reputation is at stake and they won’t accept failure. This will be disruptive of current practices but it may offer some valuable benefits too. Oddly enough this has advantages that may offset the obvious disadvantages. And there will be a learning curve for all participants. This assignment is not the default decision in all cases. This also has long-term advantages but at the cost of the temporary short-term disadvantages. What better way could there be for having the client appreciate, sympathize with and learn how to manage the problems that arise in the conduct of effective project management?

In this article we take a more considered look at how such a disruptive decision might be taken.

Who is a Candidate for Becoming a Project Manager

There are a group of business analysts and end users who show an interest in the roles that a project manager executes and tend to be more involved in projects that impact their current roles and responsibilities. They may have even practiced some of these roles on projects they were involved in. In some cases, they get in the way with their level of involvement. These are the professionals that we want to recruit to become project managers. They could begin that program by being the co-manager (see Figure 1.) representing the product being developed by the project. Their involvement in the roles and responsibilities of the co-project manager on the process side can be used and developed with their project.

This model offers a good learning environment for the OPM. As a Product Co-Manager they are positioned to share their extensive project knowledge and practice and grow their process knowledge in project management under the watchful eye of the process co-manager.

wysocki 12102018a

Figure 1. The Co-Manager Project Management Model

For smaller, simpler projects in their functional area they can be put into the role of project manager with a professional project manager as mentor and consultant. Kind of like a co-project manager but with lesser project management responsibilities. They are like the teacher or mentor with a real project as their classroom and a single student – the product co-manager. The size of the team can vary from one to perhaps a dozen or so members. The project scope doesn’t go beyond the single business unit of the OPM.

Benefits of Client as the Project Manager

First, the client will have real ownership of the deliverables and will not let the project fail. The best solution will be implemented without issue. Second, the person who knows the most about the requirements is in charge of the project and so the best results will be obtained. Needs.


Advertisement
[widget id=”custom_html-68″]

Long Term Effects

The Project Support Office (PSO) will serve the Professional Project Manager (PPM) and the Occasional Project Manager (OPM) needs. The needs of these two very different types of project managers will be different needs. One uses project management as their professional attachment (the PPM). The other uses it as a support tool for some other professional area (marketing, finance, etc.) The PPM needs can be summarized as follows:

  • Software evaluations
  • PM Methodology development
  • Training development and delivery in advanced topics
  • Advanced process needs to fit a particular unique situation.

The needs of the OPM can be summarized as follows:

  • General project management methodology application support
  • Short training on how to use a basic concept
  • Consulting support on unique applications of established processes.

The Future Environment

As the OPM begins to look like the PPM project management will become a skill with distribution across the enterprise. It will be practiced by the OPM on projects of increasing complexity. The PPM will be working on projects of increasing complexity and not on the simpler projects. This is a trend that will be obvious across all functional business units.

At the organizational level project success will increase as projects are managed by those who have a closer relationship to the deliverables. These could be managers from the affected business unit(s) or business analysts from it. In both cases, the impact on project success will be positive.

While your goal is to implement a client as project manager model across the enterprise, that may not be possible. Your model is implemented in every business unit where there is one or more functional or business unit managers who are so positioned for growing into the project management community because of their aligned interests. They may have exercised similar practices in other projects or simply have contributed to the project management practices in previous projects. Another source will be those business analysts who have through prior involvement shown and demonstrated an interest. At the low end of the business unit management team might simply be managers who show an interest.

All in all, the organization will gain through an overall improvement in the practice of project management as well as an improvement in understanding project management and how it can contribute to the organization.

A Brainstorming Model for Collaborative Project Management Part 2 of 2

In Part 1 we developed the brainstorming model for collaborative project management.

In this final part we define the projects, prioritize them and choose the one to start the process and write the POS for the chosen project.

Define the ECPM Project or Projects

Whether you use the ECPM Brainstorming Process or some type of Feasibility Study approach you should have generated a few alternatives, and it is time to explore them in more depth in your search for the best alternative. There are several variables that you might use to profile each alternative project. Here are some suggestions:

  • Risk
  • Duration
  • Cost
  • Team size and skills
  • Expected business value

Analyze the Alternative Projects

The analysis of alternative projects examines their business value. The objective is to prioritize them and select the best. There are several approaches to analyzing the financial aspects of a project. While the sponsor should perform this analysis, it is often done by a project manager. The approaches I have chosen are easily understood and give enough insight into the financials of the project at this early stage in its life span.

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 financial analysis from the project manager as an attachment to the POS. At the time, they were my client and allocated 4 hours for the project manager to complete the financial analysis. Project managers are typically not professional financial analysts, and 4 hours is not much time. So, the resulting analysis will be cursory at best, but it does lend some information relevant to financial feasibility.

Following are types of financial analyses you may be asked to provide. Keep in mind that the project manager may not be a financial analyst, and requiring an in-depth financial analysis may be beyond their ability.

  • Cost and Benefit Analysis
  • Breakeven Analysis
  • Return on Investment
  • Cost-Benefit Ratio

For further details refer to (Wysocki, 2014a and Wysocki, 2014b).

Prioritize the Alternative Projects

The first tactical STEP in every portfolio management model involves prioritizing the projects that have been shown to be aligned with the portfolio strategy. Proposed projects are usually grouped into funding categories or aligned under Objectives, or under the Strategies that align under Objectives.

Each group defines a potential portfolio. When finished, each group will have a list of prioritized projects. Dozens of approaches could be used to establish that prioritization. Some are nonnumeric; others are numeric. Some approaches are very simple; others can be quite complex and involve multivariate analysis, goal programming, and other complex computer-based algorithms. My approach is to identify methods that can easily be implemented without any pre-requisite knowledge or experience, and which do not require a computer system for support, although sometimes a simple spreadsheet application can reduce the labor intensity of the process. This section describes the models commonly used for establishing priorities:

  • Forced ranking
  • Q-Sort
  • Must-Do, Should-Do, Postpone
  • Criteria weighting
  • Paired comparisons
  • Risk/benefit matrix

For details on each of these models see (Wysocki, 2014a and Wysocki, 2014b).


Advertisement
[widget id=”custom_html-68″]

Select the Project To Be Proposed

STEP 1 ends with the selection of a project to take into STEP 2. Several prioritization lists may have been created for the potential projects identified in the affinity packages. The decision will be based on both quantitative and qualitative data. In the final analysis, these data are guidelines for a decision that is first a good business decision. It would be unusual if all prioritized lists have the same project as highest priority, but it has happened. It is in keeping with the ECPM Brainstorming Model if more than one project were proposed. Let the best project survive the approval StageGate.

The Business Case is the foundation and referent for all project decisions in ECPM Framework projects. It maintains alignment of the project to the expected business value validated for the project.

Project IDEATION Phase STEP 2: Elicit Requirements

Many authors will use the term “Gather” with respect to building the list of requirements. That suggests the requirements are just laying around and waiting to be picked up and added to the requirements bucket. In complex projects, nothing could be farther from the truth. The term “Elicit.” suggests that requirements must be discovered and drawn out for documentation and addition to the list.

Project management thought leaders are of like mind in that requirements are rarely complete during project definition. Beyond the complexity and uncertainty the project is affected by the changing internal environment and external market dynamics. Managing a complex project is of course complex by definition but the challenge is further increased due to incomplete requirements. The situation is not hopeless and there are mitigation strategies that are available in the ECPM Framework during the Project IDEATION Phase.

Project IDEATION Phase STEP 3: Write A Project Overview Statement

A Project Overview Statement (POS) is the first formal document that describes the project idea at a high-level and is used for general distribution. It is written in the language of the business so that anyone who has the occasion to read it, will understand it. No “techie talk” allowed. It is only one page, so there isn’t an opportunity to say much other than a few basic pieces of information.

Definition of the Project Overview Statement

The POS is brief—one page is always sufficient. A POS basically summarizes the RBS. A POS template with an example is shown in Figure 2. The POS contains the following five sections::

  • A statement of the problem or opportunity (reason for doing the project).
  • A goal statement (what will generally be done).
  • A statement of the objectives (general statements of how it might be done).
  • The quantifiable business outcomes (what business value will be obtained).
  • General comments on risks, assumptions, and obstacles to success.

wysocki 12032018aFigure 2 A Typical POS Template with Example Data

After more than 50 years of managing projects, I can honestly say that I have always been able to write a one-page POS regardless of the scope of the project. Being able to write a one-page POS means that you really understand the project and can communicate it intelligently to senior management. Think of it as though it was the two minute elevator speech and you won’t go far astray. I’ve seen project initiation documents as large as 70 pages. I’m not sure who reads these, if anyone. If they do, do they really understand the project at the level of detail needed for granting approval to create the project plan? I doubt it! A document of that length may be of value to the development team but not to the sponsor and certainly not to the executive who will be approving it.

Seek StageGate #1 Approval

StageGate #1 is the senior management approval to proceed to the Project SET-UP Phase. Along with this approval is the release of the resources that will be needed for that phase. There is still a lot about this project that has to be defined before any version planning work can be done and one more approval STEP (StageGate #2) before the actual work of the project is authorized and budgeted by senior management.

There will be occasions when the POS is not approved. This usually means that the sponsor has not made a compelling argument for the business viability of their intended approach to the problem or opportunity. Despite the fact that the business need may be critical, the risk of failure is weighed against the expected business value of the solution. Expected business value may not justify the cost of the project. It does not mean that the project is not important to the executives, just that the approach chosen does not make good business sense. Some other approach is needed. The sponsoring business unit is invited to revise and resubmit the POS. Alternatively, the POS may be rejected without further consideration.

PUTTING IT ALL TOGETHER

In this article we described the ECPM Framework Brainstorming Process which spans STEP 1 of the IDEATION Phase. It is a robust process that will have application in several contexts.

In the IDEATION Phase we have brought an idea from a very informal statement of need or opportunity to a initial definition of one or more prioritized projects and finally to a choice of the initial project to be pursued. The IDEATION Phase is ended with a one page statement of that project that is forwarded for management approval. The IDEATION Phase includes the first three STEPs to defining a project and seeking the resources and authorization to proceed to the SET-UP Phase.

REFERENCES
Gray, Dave, Sunni Brown and James Macanufo (2010). Game Storming: A Playbook for Innovators, Rulebreakers, and Changemakers, O’Reilly Media, Inc.
Maul, June (2011). Developing A Business Case: Expert Solutions to Everyday Challenges, Harvard Business Review Press.
Project Management Institute, (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition, Project Management Institute, Inc.
Wysocki, Robert K. (2014a). Effective Project Management: Traditional, Agile, Extreme, 7th Edition, John Wiley & Sons, Inc.
Wysocki, Robert K. (2014b). Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing.
Framework for Dlivering Business Value, J. Ross Publishing.

A Brainstorming Model for Collaborative Project Management Part 1 of 2

Every Project is a response to a Project Mandate. The Mandate can arise from anywhere in the organization but is usually the result of a senior manager or sponsor bringing an unsolved problem or untapped business opportunity to the attention of the organization.

Underlying that mandate is the expectation, or even the insistence, that something be done. In response to that request, a team is commissioned to identify and prioritize a number of responses to that mandate. That can be of minor difficulty or a major STEP into the unknown and everything in between.

The ECPM Framework includes a comprehensive Brainstorming Process that handles the unique requirements for Project IDEATION. Project IDEATION begins with a short description of an unsolved business problem or untapped business opportunity and ends with a one page statement called the Project Overview Statement (POS) that will be proposed. To reach that proposed project a comprehensive brainstorming process has been designed for the ECPM Framework. That process takes the project team through the identification of ideas (the Divergent Phase) to the definition of affinity groups (the Emergent Phase) to a list of prioritized projects (the Convergent Phase) and finally to the one page statement of the project (the POS).

The major benefit of using the ECPM Brainstorming Process is that it is designed to foster early engagement by the Client. An unsolved problem or untapped business opportunity (the Project Mandate) starts the Project IDEATION Phase of the ECPM Framework using the language of the Client. The Brainstorming Process concludes with a prioritized list of projects that address the problem or opportunity. Business Cases accompany each prioritized project and are often used as the criteria for prioritizing the final choices of potential projects. The IDEATION Phase concludes with the creation of the POS of the ECPM Framework.

ECPM FRAMEWORK BRAINSTORMING PROCESS

The IDEATION Phase of the ECPM Framework is usually not part of the linear project life cycle as commonly understood. In fact, PMI has little to say about the Business Case and the elicitation of requirements in preparation for gaining project approval (PMI, 2013). More common practice is to begin the project life cycle with some form of project charter statement. The project has already been decided all that remains is its formal definition and planning. The ECPM Framework takes a more holistic approach. Including IDEATION in the ECPM project life cycle provides an understanding of how the project aligns with the business of the organization and its priority with respect to the generation of that business value. You will come to realize that it is a powerful tool for complex project management decision making that is shared only by PRINCE2 and the ECPM Framework. This uniqueness gives the ECPM Framework a powerful and far more effective capacity for successfully managing any type of project from inception to the end of the useful life of its deliverables. It is also a good segue into complex project portfolio management.

An ECPM project begins with a need to solve a critical yet unsolved problem, or to take advantage of an untapped business opportunity, but it can also begin with nothing more than knowledge that there is a problem or untapped business opportunity. Figure 1 highlights the three STEPs that are executed during the IDEATION Phase of a complex project. The approach discussed below is simple and intuitive. Once an idea is submitted: 1) a business case is developed; 2) high-level requirements are elicited; and, 3) a POS is prepared.

wysicki 11262018aaFigure 1: ECPM Framework IDEATION Phase STEP 1

Few project management books discuss the decision processes and practices over the entire project life span. A complex project is a dynamic entity that changes for all sorts of reasons, both predictable and unpredictable, and for that reason the best management approach will also be dynamic and change along with the changing project conditions that arise. This places several challenges on the sponsor, the project manager, the client manager, the client team, and the development team. They must be constantly vigilant and ready to embrace change. The purpose of these changes is to maintain alignment between the changing nature of the project and how it is managed. The IDEATION Phase provides that checkpoint during the project EXECUTION Phase. The goal of the ECPM Framework is to deliver maximum business value with respect to the strategic plan of the organization.

Project IDEATION Phase STEP 1: Develop the ECPM Business Case

Most project management methodologies start with the project as given, and proceed from there. Those methodologies often start with writing the POS or an equivalent short statement of the project. The ECPM Framework is not like other project management methodologies. The ECPM Framework is a holistic framework and embraces the entire project life span. That begins with the very roots of a possible project—with an idea where a problem or an unmet need is identified and analyzed for business feasibility. STEP 1 ends with the identification of a specific project as described in the POS.

What Is an ECPM Business Case?

A business case is a document that identifies an unmet need, and provides evidence and justification for initiating or continuing a project investment to address that need. An ECPM business case typically includes:

  • A statement of a critical need and the overall justification for a project to address that need
  • A description of the product, process, or service that the project will deliver
  • How the project aligns with the business strategy
  • A financial analysis comparing alternative project ideas
  • A prioritization of the alternatives and the preferred option
  • The scope of the project and its deliverables
  • The incremental business value that will result.

There are several models and processes that could be used to develop the business case. I have adapted the model developed by (Maul, 2011) to accommodate the range of projects in the ECPM Framework.

The ECPM Framework Brainstorming Process

Figure 1 includes the brainstorming process that drives the development of the Business Case beginning with a Project Mandate that is a call to action to solve a critical problem or exploit an untapped opportunity. The typical brainstorming process and mapped it across the IDEATION Phase. Figure 1 is the ECPM Framework adaptation of a Game Design Model originally developed by (Gray et al, 2010).

The ECPM Brainstorming Model consists of four parts:

  • Definition of the problem or business opportunity
  • Divergent Phase
  • Emergent Phase
  • Convergent Phase

Advertisement
[widget id=”custom_html-68″]

Definition of the problem or business opportunity

ECPM is designed so that an idea can originate anywhere and be submitted by anyone in the organization. The person proposing the idea must get the endorsement and support of a manager, who will often become the sponsor. This is the first STEP in the process of developing a business case. A sponsor (usually an executive from the client organization who will fund the project) makes a request of senior management to undertake a project to solve a mission critical problem, or take advantage of a significant yet untapped business opportunity. Whether it be a problem or an opportunity, the organization is presented with a major challenge. The challenge arises from the fact that the problem has remained unsolved despite any prior attempts at resolution and it is unclear how to take advantage of the untapped business opportunity. That uncertainty is a fundamental characteristic of complex projects.

A representative from the development organization is assigned to work with the client sponsor. In keeping with the principles underlying the ECPM Framework, this individual from the development organization will become one of the co-project managers, and someone from the sponsor’s business unit (the client) will become the other co-project manager (Wysocki, 2014b). That could be the sponsor or a responsible business analyst, but it usually is a line manager from the affected business unit(s). Whoever is chosen, they must represent the sponsor’s interests and have decision making authority for the business unit(s) they represent. These co-managers are equally responsible for the project from inception through completion (i.e., the project life span).

Divergent Phase

The purpose of the Divergent Phase is to elicit as many ideas as the brainstorming group can produce. No evaluation is done at the time, except for clarification. The more ideas that can be generated, the better the final result. No idea is too extreme to be rejected. One idea might not be used, but it may be the catalyst for other ideas. The best way to start the Divergent Phase is with a brainstorming session. What is presented here is a variant of the familiar brainstorming session that most people will be familiar with. This variant is far broader and comprehensive than you may have experienced so far:

BRAINSTORMING GROUP OPERATING RULE:
When a group member puts an idea on the table for consideration, they surrender ownership of the idea. It becomes the property of the entire group. It no longer makes any difference where the idea came from, and that should not even be part of any later discussions regarding the idea.

  • Assemble any individuals, whether they are team members, consultants, or others, who may have some knowledge of the problem or business opportunity area. A team of 8-12 should be sufficient. They don’t need to be experts. In fact, it may be better if they are not experts. You need people to think creatively and outside of the box. They may not be aware of any risks associated with their ideas, and that is good at this early stage. Experts tend to think inside the box and focus on why something can’t be done, rather than on why it should be done. How it will be done is a decision better left to the SET-UP and EXECUTION Phases.
  • The session begins with everyone recording an idea, reading it to the brainstorming group, and placing it on the table face up so everyone can see it. No discussion (except clarification) is permitted. Silence and pauses are fine. This allows any group member to think about the suggestions that have been submitted, and what they have heard and seen, and maybe that will spur another idea. Families of ideas can be generated like those shown linked together in Figure 2.1.
  • After all the ideas are on the table, and no new ideas seem to be forthcoming from the brainstorming group, the Divergent Phase is declared closed by the facilitator. A Divergent Phase can be completed in less than two hours.

Emergent Phase

The purpose of the Emergent Phase is to collect and consolidate the brainstormed ideas into packages of similar ideas (i.e., affinity packages) as a prelude to defining specific action items:

  • Discuss the ideas that have been submitted. Try to combine ideas, or revise ideas based on each member’s perspective. Ideas are grouped into affinity groups, or packages of similar ideas, if you prefer. Some ideas may not be similar enough to be placed in a package. Don’t discard any ideas. They might have value that has not yet been recognized.
  • In time, primitive solutions will begin to emerge from these packages. Don’t rush this process, and by all means test each idea with an open mind. Remember that you are looking for a solution that no individual could identify, but that you hope the group is able to identify through their collective efforts. There is a synergy that comes from a well-run Emergent Phase.
  • An Emergent Phase can be completed in 2-3 hours, but don’t cut it short if it is still producing good affinity packages.

Convergent Phase

The purpose of the Convergent Phase is to use the affinity groups or packages as the foundation for projects, and perhaps group similar packages into projects, and then to analyze, prioritize, and finally select the project to be proposed. Referring to Figure 2.1, the Convergent Phase consists of these activities:

  • Define the ECPM project or projects (P1 through P4).
  • Analyze (P1 and P2 become P5) and prioritize alternatives (P5, P3, P4).
  • Select the first project to be proposed (P3).

The Convergent Phase is the first time that projects begin to take shape. Even though a single project is chosen, the list still can have residual value if the chosen project does not appear to be delivering business value. You may want to come back to this list for another pick.

PUTTING IT ALL TOGETHER

In the IDEATION Phase we have brought an idea from a very informal statement of need or opportunity to a initial definition of one or more prioritized projects and finally to a choice of the initial project to be pursued. The IDEATION Phase is ended with a one page statement of that project that is forwarded for management approval. The IDEATION Phase includes the first three STEPs to defining a project and seeking the resources and authorization to proceed to the SET-UP Phase.

REFERENCES
Gray, Dave, Sunni Brown and James Macanufo (2010). Game Storming: A Playbook for Innovators, Rulebreakers, and Changemakers, O’Reilly Media, Inc.
Maul, June (2011). Developing A Business Case: Expert Solutions to Everyday Challenges, Harvard Business Review Press.
Project Management Institute, (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition, Project Management Institute, Inc.
Wysocki, Robert K. (2014a). Effective Project Management: Traditional, Agile, Extreme, 7th Edition, John Wiley & Sons, Inc.
Wysocki, Robert K. (2014b). Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing.

OUTSIDE THE BOX Forum: What is Collaborative Project Management?

A project is a finite effort to move the organization from its current state to a desired end state.

The presumption is that there is some deficiency or shortcoming that results in unacceptable outcomes. So, the project’s purpose is to generate incremental business value. That business value is usually measured in increased revenue (IR) or avoided costs (AC) but might also be measured in improved service (IS). IRACIS is the acronym that describes this business value.

So, how should this project be configured and managed in order to achieve the changed state? There are many ways to do this but everyone of them should have characteristics that model collaboration among those who can contribute to the project and its successful outcome. In this article we are going to discuss that reality under the name of Collaborative Project Management (CPM). The Hybrid Project Landscape is adaptive and flexible and is therefore the ideal framework for supporting CPM.

THE COLLABORATIVE PROJECT TEAM

Our discussion of collaboration must begin with a definition and explanation of the collaborative project team. First of all, it is not like any project team you will have encountered before. Figure 1 is a generic structure of the collaborative project team. This team structure departs from the traditional project team in that it has two project managers: a Process Co-Manager and a Product Co-manager. This is certainly viewed as a disruptive structure by the traditionalists.
It has two project managers. One is the process co-manager whose major responsibility is the management processes that drive the project. The other is the product co-manager whose responsibility is the deliverables that the management processes produce. But further to that, they share equally in the authority and responsibility for the project.

For collaboration to be successful it must be holistic. We already know that the process team must collaborate but so also must the product team. And finally, collaboration must include cross-team collaboration. The cross-team collaboration is the most challenging because it takes both teams out of their comfort zones.

The Process and Product Co-Managers

These two managers equally share the responsibility and authority of the project but from different perspectives. Both roles will take the typical project manager and product manager outside of their comfort zones. But it is that equal sharing of authority and responsibility that puts a collaborative project environment over the top.

The Process Co-Manager is the analog of the traditional project manager but from a broader perspective. In addition to satisfying the project management requirements they must also satisfy the product requirements at the same time. The product co-manager will assure that that happens. Their constant attention to the needs of the product is different than most typical project situations.


Advertisement
[widget id=”custom_html-68″]

The Product Co-Manager represents the entire user group. If that happens to be a single, homogeneous user group that should be very straightforward. But that will be the exception rather than the rule. That could be deployed through several client team leaders – one for each user group. This will often put the Product Co-Manager in a negotiating position as they try to meet the needs of different user groups. The Business Analysts become a critical resource for these negotiations.

wysocki 11202018a
Figure 1: The Collaborative Project Team

The Process Team

The ProcessTeam is on the left side of Figure 1. The Business Systems Engineer is a small team of specialists whose services will be needed throughout the project. They might work independently of one another or even as a small cooperative team. Their expertise spans the relevant business processes and they will offer changes and improvements to support the Engineers. These developers could be organized into several independent groups who work on the advice os a single business systems engineer.

The Product Team

The Product Team is on the right side of Figure 1. The Business Systems Analyst can be the most complex team as it focuses across the entire user group of a product or service. For a simple product that user group might be one person or a homogeneous group of users. For a complex service it might be a cross-section of a supply chain with different teams for different process steps. For a simple product that user group might be one person or a homogeneous group of users. For a complex service it might be a cross-section of a supply chain with different types of users with different or even conflicting needs.

How to Establish a Collaborative Environment

Just as a Hybrid Project Environment could be established either top down or bottom up so also could a Collaborative Project Team be established in the same way. My preference is for a bottom up approach. The major business reason for a bottom up approach is to generate business value ASAP. A separate business unit could be put in place for the new business opportunity. It should be independent of the entire enterprise.

Benefits of a Collaborative Environment

A true Collaborative Environment is rare but emerging in many organizations. It is rare because it requires a project team structure across the enterprise rather than the normal functional structure. That team structure is emerging in many organizations.

With an enterprise-wide project team structure in place the following can take place:

  • Every project will have been reviewed to recruit team members with specific contributions to be considered,
  • No project will be denied the benefits of the organizations’ expertise,
  • Every project will deliver the maximum benefits to the organization.

The project structure obviously is one model for delivering maximum business value to the organization but its full implementation is a futures benefit. The hybrid project management approach is a way to get there.