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.
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.
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.