Review

In the Review Phase, opportunities are generated by comparing capabilities and project priorities for the attributes.  The comparisons are summarized and ranked by an Opportunity Index (discussed at the end of this section).  Essentially, the higher the index, the better the opportunity for a beneficial collaboration based on the preliminary data.  The opportunities are then reviewed and placed (by each organization only) into one of three categories:

• Collaborative Project Opportunity (CPO):  the attribute is selected by any manager interested to go to discussion with the potential collaborators at other organizations invited to the ROADMAP Process. (Note that the attribute is selected based on its potential to generate projects.)
• Not Collaborative Project (NCP): the attribute is selected to go to discussion to discover the merits of potential projects derived from the attribute. However, the discussion and subsequent projects will be internal to the organization and not part of a collaborative effort.
• Dead Opportunity on Arrival (DOA): the attribute is rejected in terms of even being discussed for potential improvement projects.  A DOA happens by not selecting the attribute to as a CPO or NCP.  So by default, all attributes are DOA at the start or the Review Phase.

From the selections of Collaborative and Not Collaborative Projects, a roadmap will be created for each organization that will link into a collaborative Enterprise Roadmap. To each organization, the two roadmaps will jointly be viewed as a single, relatively seamless roadmap that includes the organization’s internal and collaborative projects.  Looking at the example in the figure, the roadmap for Division C includes 450 internal “Not Collaborative Projects” and 120 “Collaborative Project Opportunities” for a total of 570 projects.  In this example, the Collaborative Roadmap for the entire enterprise (Divisions A, B, C, D and E) has 255 collaborative projects.

Collaborative versus Not Collaborative Projects

Projects in the collaborative area can be seen by the other divisions; however, the information included is not detailed in terms of activities, durations of the activities, relationships between activities, resources assigned to the activities and other such traditional project information.  Developers of Collaborative Roadmaps should avoid getting caught in the minutia of project details.  The only current information shown for a collaborative project is the expected duration, the project manager or lead, the predecessor and successor relationships and the project charter information.

Once an organization agrees to discuss an attribute with potential collaborators, their Attribute Score is visible to the other organizations which also agree to discussion.  While in discussion, the discussants can set-up project proposals related to the attribute.  The proposals, also called charters, are then sent to the Agree Phase.

Opportunity Index
In the following figure, assume that managers from Division C are reviewing their opportunities for collaboration. 

Selecting Attributes for Collaborative Discussions

In the figure, the attributes are ranked from the highest Opportunity Index to the lowest.  In this case, “Attribute XPO” through “Attribute “WEI” tied with the largest calculated Opportunity Index.  Of these top opportunities, Division C’s management has decided to reveal its Attribute Scores for three of the top four opportunities as identified by the “X” mark in the CPO (Collaborative Project Opportunity) column.  The activity of deciding which opportunities organizations would like to discuss can be accomplished online or with a Roadmaps Institute™ Master serving as the intermediary between the organizations.  Either method protects attribute score information as much as possible until the parties have agreed to consider collaboration on the specific attribute.  Calculation of the Opportunity Index is presented in the Roadmap Process White Paper.

Opportunity

Attributes selected by checking the CPO or NCP boxes in the Review Phase become discussions in the Opportunity Phase.  In an online format, the discussions take the form of forums, which need very little facilitation.  In contrast, offline discussions are facilitated by a moderator.  Regardless of how the discussions are facilitated, a ranking of the discussions is helpful to focus efforts on the highest potential impact discussions.  The Collaborative Opportunity Index (COI) addresses this need.  Calculation of the COI is presented in the Roadmap Process White Paper. 

Discussion Recommendations
Whether potential projects are discussed face-to-face or online, several pre-defined steps that should occur within each discussion.  (In an online format, these steps can be automatically created as separate discussions for each project.)  Opportunity Discussion steps to develop project ideas from attributes are as follow:

1. Discovery: Discuss the opportunities to find either a:
        - Match between another organization’s capability and your need
        - Match of a common need (articulated as a project)
        - Match of a common capability to be further improved
2. Breakdown: Transform the opportunities into actual project proposals. One attribute can break into many project proposals.  If more than one project proposal is to be created, then it is done through setting up another project.  All projects will link to the attribute that spawned the projects.  Maintaining each project’s association to the attribute is to facilitate will help update the organization’s Attribute Score the next time the organization is assessed.
3. Leadership: Elect one manager from each organization to each project proposal.  These managers serve as representatives for their organization. Next, decide which manager from the representatives will lead the project.  Finally, decide where the project will be hosted.
4. Value: Estimate the value of the project for each participating organization.  Then, discuss how the project can be made beneficial to all through sharing the rewards.  Guidelines for “Sharing the Rewards” of collaborative projects were established in the DESIGN Process through the Engagement Charter.  The guidelines for sharing were negotiated in the DESIGN Process to remove them as a point of contention later in this phase.
5. Hours:  The estimated number of hours that the project will take for each collaborating organization should have been included in the value estimation above.  If not, then rough estimates need to be developed in this discussion.  Estimates of management hours are needed because management hours are generally considered the key constraint (behind cost) in determining how many projects an organization can accept in a given period of time.  Also, required management hours are used to estimate the Project Value Index, which is used to rank projects for selection purposes.
6. Dependencies: Identify the relationships between projects in terms of both resource constraints and standard predecessor-successor dependencies.  Some projects must be completed before others can begin, others can be started independently.  Dependencies must be available to create the roadmap in the Develop Phase.
7. Placeholders: Create a Placeholder Milestone if a predecessor dependency exists outside the scope of collaborative projects.  Placeholders may be used if a known predecessor project is occurring outside of the collaboration, or if a constraint exists that must be removed before the project can begin.  Placeholder information must be available to link the Collaborative Roadmap to the hidden roadmaps within the collaborative organizations.  Placeholder Milestones are added in the Milestone Phase.
8. Agree: The lead manager develops a Project Charter using all of the information from the discussion points above.  The Project Charter, which is currently still just a proposal, is available in the Agree Phase to all organizations that are participating in the project.  Then, if participants so choose, discussion continues in the Opportunity Phase to ensure participants are truly in agreement regarding the contents of the Project Charter.

Project Set-up
A project proposal may be set-up at any time during a discussion. By default, whoever sets up the project proposal is the project’s lead manager.   Essentially, the Project Proposal is a charter that contains summaries of the information provided in the eight point list in the discussion.  Set-up of a project proposal does not mean the project has been accepted or authorized.  A proposal does not become an active project or part of the official roadmap until after the Authorize Phase.  This will be explained in greater detail in the Authorize Phase.

Project Return
Estimation of the Project’s Return in the Opportunity Phase requires a fundamental understanding of the goals and constraints of all organizations involved.  Ultimately, the calculation of the return will provide partial basis for project selection.  Project selection is the process of evaluating individual projects, or groups of projects, and then choosing to implement some set of them to achieve the organization’s objectives.  Project return calculated in this phase focuses on both the financial and non-financial results of projects. Project Evaluation Models are discussed in the Roadmap Process White Paper. 

 
Choosing an Evaluation Model
Selecting the type of model to aid the evaluation/selection process depends on the philosophy and wishes of management. Weighted scoring models are usually favored for three fundamental reasons.

1. They allow for the inclusion of all the multiple objectives of all organizations in the decision to undertake or reject a certain project
2. They are easily adaptable to changes in managerial philosophy as well as changes in the business environment
3. They do not suffer from the bias inherent in the profitability models that discount future cash flows by placing no emphasis on the time value of money

The use of any project selection model assumes that the decision-making procedure takes place in a reasonably rational organizational environment. By utilizing Saaty’s Analytic Hierarchy Process, some degree of rationality can be imposed to a sometimes irrational process (see T.S. Saaty, Decision for Leaders: The Analytic Hierarchy Process, Pittsburgh, University of Pittsburgh, 1990).  Also, although the accounting system is the richest source of information in any given organization, it should always be used with great care and understanding due to the inherent failures in accounting systems to track costs in an accurate and timely manner.

Project Value Index
Following the popularity of weighted scoring models, the Opportunity Phase employs the DR²IVE™ Project Value Index (PVI).  The PVI is the primary way that projects are ranked for selection within the ROADMAP and ROBUST Processes.  The PVI accounts for both the quantitative and qualitative returns from projects.  Also, PVI accounts for management time as the primary constraint on projects.

PVI is a DR²IVE™ specific form of weighted value analysis.  PVI was developed in response to the number one comment that visionaries wishing to develop roadmaps within their organizations, which is “We don’t have the time for our current projects, let alone taking on more!”  The reply is simple, “With DR²IVE™ you can yield greater returns using the same or less management hours currently spent on projects.”  Sketches of the Efficient Frontier to explain portfolio optimization and how DR²IVE™ can expand the frontier to the Robust Frontier may be needed to convince individuals in organizations that fail to see the value in DR²IVE™.  Calculation of the PVI is presented in the Roadmap Process White Paper.

Agree

In the Agree Phase, an Agreement Report is generated which lists projects that were set-up in the Opportunity Phase by their Project Value Index (PVI) rank.  The projects in the Agreement Report are either accepted or rejected by representatives of the organizations.  Usually a Master is in charge of logging the agreement on behalf of each organization, thus there is one central person overseeing the phase and communicating the needs and conclusions of the organization to the other organizations involved.

Both “Collaborative” and “Not Collaborative” projects selected in the Opportunity Phase are transferred into the Agreement Report.  Projects that are “Not Collaborative” still need to be agreed upon internally to move onto the next phase.  The threshold for “Not Collaborative” projects to move on is certainly lower than for “Collaborative” projects where two or more organizations must agree to move a project forward.

The Agree Phase is the first phase in the ROADMAP Process where step chart categorization is not provided.  Participants are encouraged to think in terms of optimization of all organizations involved as a whole instead of their own core competency silos.  In this phase, all project proposals start out as “rejected” since no one has formally agreed to the projects as proposed in the charters.

Agreement Report
A snapshot of a typical Agreement Report view is provided in the next figure.  The view given is from the perspective of Division C.  The view shown is essentially a blank template with no inputs.  The default view shows all projects for Division C as having a red circle icon, which means the project proposal is currently stopped like a car at a stoplight.

Template for Agreeing on Projects (Default View)

With the list above, managers from Division C can methodically go through the list and change the red stoplight icon to yellow or green to indicate that they have approved or agreed to the contents of each project charter or proposal.  Other organizations that have access to the project proposal will do the same with their views.  Once Division C and one other division has changed a specific project’s indicator to green, then the project is approved to move forward to the Develop Phase.

The color coding is important to understand.  Red means the project is not yet agreed upon by the organization involved.  In contrast, a green color means that the project charter is agreed upon by the organization involved.  A yellow color means the organization has questions regarding the project and that the charter must be revised.  Revisions to the charters can be accomplished by a return to the specific discussions in the Opportunity Phase that are directly related to the project.

The next figure presents a continuation of the previous figure.  In this figure we can see that Division C has reviewed the project charters and approved all of the projects listed.  Six of the projects have also been approved by the divisions that collaborated together in the Opportunity Phase to develop the project charters.  Two projects have requests to return to the discussion and revise the charter.  The request to revise for project IOP will not stop the project from moving forward to the Develop Phase since at least one organization (in this case three have done so) has already agreed to the charter with Division C.  The two projects shown with red circles are thus far rejected by Division B.  There are many possible reasons for the rejection.  For example, Division B may have not yet reviewed the charters.  If Division C really wants the rejected projects to be approved, then a manager from Division C should contact the manager that represented Division B in the discussion of the project in the Opportunity Phase.

Template for Agreeing on Projects (Completed View)

Projects agreed upon in the Agree Phase are transferred to the Develop Phase.

Develop

In the Develop Phase, project proposals that have been set-up in charters are now loaded into a Project Portfolio Management (PPM) system.  Although Project Portfolio Management and its subset systems of Program Management and Project Management can be accomplished on a small scale without the use of software specifically written to accomplish each system’s goals, the management of a manual system is highly discouraged.  Manual systems, such as using spreadsheets or crib sheets quickly become inefficient and require excessive levels of management time. Management time is expensive. The money is better spent on an actual software based system.

Project Portfolio Management
The easiest way to understand a PPM system is to think of it as a traditional Project Management (PM) system, except in the case of a PPM there are no activities, only projects.  In other words, the following is essentially true:

Projects (PPM View) = Activities (PM View)

In fact, the similarity in how the projects are managed in a PPM to how activities are managed within a PM is so strong that many organizations can simply use their PM system to mimic a system that is built from the ground up as a PPM system.

Roadmap Centralization
Even if all organizations involved in the ROADMAP Process have their own internal PPM system, there is still a need to have a neutral location to load projects that are common to two or more of the organization portfolios.  In other words, there is a location needed to centralize the dependency relationships, resources allocated, project durations and other data needed to develop, maintain and update Collaborative Roadmaps. (The term Collaborative Roadmap is used here as a more generic term for Enterprise Roadmap and Robust Roadmap™.)  There are essentially two choices to have a functioning centralized Collaborative Roadmap system as described.

1. The first is a system where projects in the Collaborative Roadmaps are electronically linked to projects in the proprietary systems of each organization.  As you might imagine, such a system requires a large investment in information technology systems and infallible firewall protections.
2. The other alternative is the one chosen for the Develop Phase.  A centralized location is used to temporarily house the projects so that the roadmaps can be jointly developed.  Linkages to the PPM systems of the participating organizations are modeled, but they are manually managed using Placeholder Milestones (see the description in the Milestone Phase).   The Placeholder Milestone alternative is clean, simple and protects the proprietary systems and data of the participating organizations.

Roadmaps Planning Tool
Under development at the Roadmaps Institute™ is a tool called the Roadmaps Planning Tool or RPT.  The Roadmaps Planning Tool is used to develop Collaborative Roadmaps using projects loaded (or electronically transferred) from the Agree Phase.  The RPT serves as a centralized location used to temporarily or permanently house the roadmap.  After completion of the Collaborative Roadmap for the organizations involved, the organizations will collectively have the choice to move the Project Portfolio to an external Project Portfolio Management system at one of the organizations.  This decision may make sense for a collaborative group that has been brought together by a “prime” or large company that clearly serves in the leadership role for the collaboration.  In a collaboration that resembles more of a peer situation, the organizations may prefer that the Collaborative Roadmaps be maintained within the RPT as an independent third-party location.  Regardless of the choice, the RPT is accessible both within the DR²IVE™ Software System while the ROADMAP Process is occurring and externally after the ROADMAP Process is complete and the Collaborative Roadmap is actually being used.  

The RPT is intentionally kept simple so the learning curve for participants is simple and the only required education is in the Fundamentals of Project Management.   Knowledge of the fundamentals of project management will enable a manager to quickly grasp how a Project Portfolio can be managed similarly to a single project.  Once again, projects in a roadmap are treated similarly to activities within a single project.  The unit of analysis is essentially identical.

In the Roadmap Planning Tool (RPT), projects are loaded for each organization as either Collaborative Projects or Not Collaborative Projects.  Within the two categories, the projects may be subcategorized by the step chart and attribute from which the projects originated.  The reason for this is that the likelihood of a dependency between two projects is higher if both came derived by attributes in the same chart.  Beyond the information on the organizations involved and value estimation, only the most fundamental information is loaded for each project into the project management software.

Milestone

In the Milestone Phase, two types of milestones are added.  The first are Program Management Milestones that identify significant completion points in roadmaps for groups of projects.  These are called Collaborative Milestones in the Collaborative Roadmap.  The second type of milestone is the Roadmap Placeholder Milestone, which was discussed earlier in the Review Phase. The reason for discussion of Placeholder Milestones in the Review Phase was to alleviate concerns about sharing information between organizations.  Placeholder Milestones work very well in protecting internal programs from external entities by revealing only information required for the proper sequencing of projects.  For a discussion on Placeholder Milestones, see the Roadmap Process White Paper.

Authorize

Up to this point, the Enterprise Roadmap has not been authorized by upper management.  The phases leading to the Authorize Phase should have been monitored and tacitly approved by upper management of each organization.  Some explicit approval also had to occur through acceptance of the outputs of the processes and phases.  For example, upper management had to approve the budgeted hours and costs for each engagement created in the DESIGN Process.  In addition, upper management should have received various reports such as the SCORE Report, Registrar Report, Opportunity Report and Agreement Report.  The Authorize Phase may be the first time upper management will see the projects networked together in a roadmap, but it should not be the first time that the projects have been seen.

Authorization is accomplished using a similar template (or interface if online) to the one presented in the Agree Phase.  In addition, some charters for large projects will need signatures.  The main difference in this phase versus the Agree Phase is the projects accepted are now included in the budget for the year they are planned to start.

Proceed

At this point, each organization has the option to load the projects from the roadmap into their organization’s information technology system. The difference is that the projects in the roadmap are formally approved and the roadmap is ready to proceed or start. Since the information on each project is basic, the upload should be simple. A copy and paste may be all that is needed if the system at the organization uses a tabular format for adding projects and the fields match up properly. Otherwise, a single export file can be generated from Roadmap Planning Tool and uploaded to the target system.