Author: Robin Hornby

Can You Collaborate? Part 2

 In this second article, Robin Hornby presents his case for a new way of managing contracted projects, and the essential collaborative practices for project managers.
Hear more about these ideas at ProjectWorld Vancouver Sept 14-17, 2015.

In the first part of this article, I wondered about a possible Collaborate-Compete spectrum of project manager (PM) behavior and what the implications are for PMs in professional services and their clients. Does a collaborative approach correlate with project efficiency and positive outcomes? Can the separate silos of client and vendor management be bridged to benefit the joint project? To meet a perceived shortfall of such methods in the commercial arena, I proposed a new five-phase methodology, Total Collaborative Procurement (TCP), with a three-level (Business, PM, and Work) architecture. At the business level, TCP embeds a number (estimated at 15 to 20) of collaborative practices of great importance to the concept, and in this second article I will introduce six of them.

Practices as Point Solutions

I can put forward these six core practices because detailed work has already been done (ref. Projects for Profit): they have evolved and practiced in various settings through my experience. They are designed to embed within TCP, however each practice is stand-alone and can be implemented as a point solution, if client and vendor agree. This means that the tools exist to begin collaboration now. Collaboration does not mean, by the way, that I do it and you approve it. We both work on it, and we both approve it. Furthermore, as these practices are designed to deal with complexity and perplexing project issues in a collaborative manner, they need not be restricted to the commercial world. They could be beneficially applied to large complex internal projects, particularly for sophisticated organizations that operate an internal economy.
These core practices address areas that can consistently go wrong, and where for some reason the parties find it hard to collaborate, perhaps from a misguided fear of divulging corporate secrets, betraying weaknesses, or eroding competitiveness. I have bracketed the practices into primary and secondary based on my assessment of potential positive impact if well implemented.

Primary Practices

The primary practices map to three of the famous ‘W’ questions: What, Who, and hoW. (The Why I shall leave to the sponsor and the When and Where can come later.)
1. Lifecycle Mapping. The very first step is to force integration and eliminate the silos. The solution recommended is to recognize the essential role of the project (aka application) lifecycle as the backbone of project integration. It will be used to integrate PM explicitly into the work of the project, using the four-function PM model Plan, Organize, Control and Lead. This model does not attempt to supplant the PMBOK®; it just creates a higher universal view to ensure common ground between client and vendor. In fact, the PMBOK® activities and deliverables can be used as a checklist during mapping. As illustrated, the chart will show the precise management activity supplied by both client and vendor, and map their management deliverables into the same phases of work as project deliverables. This is the most valuable of the six practices. It tells us exactly what the joint project is doing, and a bit of the who and the how.

rhornbyarticle2

2. Accountabilities Definition. The intent is to bring clarity to accountabilities. There are several techniques that can be used, but the RAM (Responsibility Assignment Matrix) chart based on the deliverables from Lifecycle Mapping gives the PM the extra precision and clarity needed. Most PMs are familiar with the tool, and it is possible that both vendor and client PMs will have developed their own chart. That, of course, is the problem. The true value of the RAM is when it is jointly developed in a proper working session, and issued as a project document signed off by both client and vendor. Here we have the how and the who.

3. Joint Resource Management. Resource constraints seem to bedevil most projects, and appear in risk registers so often it is almost business as usual. In the commercial world, the problem is exacerbated by the reluctance of the parties to communicate their plans and status. In this particular case, I do believe that clients would benefit from adopting some of the techniques employed by most vendors, namely utilization and availability tracking. Productive, periodic, joint resource meetings are then feasible. This covers who and some of the how.

Secondary Practices

I hesitate to label anything ‘secondary’, but in honest moments I will admit struggling through projects without really understanding risk, quality, and estimating, never mind collaborating with the client on such matters. But wouldn’t our projects be so much better if we did? Here are the next three of our core collaborative practices:

4. Joint Risk Management. The challenge is to bridge the difference in risk perception between the vendor and the client. The vendor PM will tend to assume an analytical posture and start drafting a risk register with only sketchy information available (and the salesperson will just consider it an annoyance). On the client side, unfortunately, the likely attitude is that risk is something they don’t have to worry about as it is to be downloaded onto the vendor! The most effective way to get everyone on the same page is to use two new collaborative models evolved from risk factor and risk indicator checklists. The Risk Factor model gives an actionable risk assessment for the project at an early phase of TCP, and the Risk Alert model provide an objective readout (usually as Red, Yellow, or Green) for the critical performance areas during project execution.

5. Quality Target Development. Quality is difficult at the best of times, more so in most commercial relationships. Both parties are comfortable dealing in subjective terms – vendors will talk about the objective of “customer satisfaction”; clients will talk about the need for everything to “work the way we want”. To resolve this conundrum using a collaborative approach, these are the techniques I recommend. First, we need a framework that moves subjective expressions of future states to objective measures that represent agreed project targets. Next, we need to use uncomplicated (intuitive) models to establish project norms that will best meet quality objectives. Finally, we do need a QMS (Quality Management System), though not necessarily ISO9000. I call the proposed design a Basic QMS.

6. Estimate Counseling. My theme is collaboration and the reader might be wondering – how on earth can we collaborate on this topic and still operate in a fair and competitive environment? The main counsel for both parties is to avoid wedge issues that cause inefficiency, lead to inaccurate estimates, and benefit no one. Seven significant wedge issues have been identified to-date. A wedge issue drives the client (the requirements and the budget) and the vendor (the solution and the estimate) further apart for no good reason, and to the detriment of getting a good proposal.

Success Factors and Benefits

There are challenges, of course, when it comes to implementing collaborative procurement, so some critical success factors need to be defined and put in place. Both parties must be prepared to adopt a joint approach to the project and discard silo mentalities. There will be joint documents, developed in joint working sessions, and information must be shared openly. Initial organizational trust and an assured mutual understanding of TCP protocols will be needed and could require a system of registration for certified client/vendor TCP users, administered by a trusted third party.

The culture of some organizations may not always be comfortable with these prerequisites, so there will be no point in them pursuing TCP. That’s OK. It won’t be for everyone.
But for those who can work within a collaborative framework, I believe the rewards will be substantial. Using the practices as point solutions provides an easy, low-risk entry point. I am convinced collaboration can co-exist with competition. And I am further convinced that collaboration means better outcomes and a win-win. I also believe there is a national productivity issue at stake here! Collaboration means more projects can be completed per year, for less unit cost.

Feedback

The ideas presented in parts 1 and 2 of this article may, if taken into development, provide some reason for commercial projects to improve either in efficiency, in outcomes for stakeholders, or in the equanimity of the project managers. What do you think? Are the ideas presented within feasible? I need feedback and would welcome your comments below, or by email to [email protected], or by question and comment at the ProjectWorld Vancouver Conference.

References

Hornby, Robin (2013). Projects for Profit: An insider’s guide to delivering projects and getting paid. Calgary, Canada: Tempest Management Inc.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author.

Speaker Spotlight: Can You Collaborate?

In this article, Robin Hornby presents his case for a new way of managing contracted projects and introduces the concept of a collaborative lifecycle.
Hear more about these ideas at ProjectWorld Vancouver Sept 14-17, 2015.

There are many behavioural models out there (the Keirsey Four Temperaments, Myers-Briggs, Social Style Profile, Lumina Spark, and Marston DISC® model among others), but I am not aware of any that explicitly sort us on the axis of Collaborate-Compete. I suspect there is a bit of collaborate and compete in all project managers though most will fall on one side or the other. Recently I have been wondering what the implications are for PMs in professional services and their clients. How does the Collaborate-Compete preference reflect the organizational approach to contracted projects? Is there a correlation with project efficiency and positive outcomes?

The Marketplace

The project marketplace seems like the antithesis of collaboration. Commercial free-for-all, regulatory and procurement policy constraints, zero-sum contracting terms, arm’s length stakeholders, hidden communication channels, project delivery under commercial pressures, as well as the usual quota of technical and project management issues creates a complex project environment. It’s certainly competitive but can be time wasting and frustrating. Surely there must be a better way, and that ‘better way’ increases in importance as the boom in project outsourcing over the past 20 years continues. 

Delivery Silos

Strangely, many clients seem to regard procurement as coming to an end when the vendor has been selected and contracted, rather than when the product is delivered and accepted. Perhaps this complements the concept of risk transference associated with fixed-price contracts. Another cause might be the emergence of two (or more) silos of activity – client team(s) and vendor teams(s) – whose management interactions are limited and formal, with occasionally an unhealthy dependence on the vendor’s expertise for anything but the basics. A vendor can unwittingly encourage this, accepting a client’s lack of rigour on status reporting and resource allocation. (Unbelievably, I have had clients tell me in no uncertain terms that they don’t want to waste their time and money on status meetings.) On the other side of the fence, I have heard vendor PMs wish that the client would sign off the requirements so we could get back to the office and build the product! None of this sounds like collaboration. Unfortunately, there is no accepted framework that supports a collaborative approach through all the phases of project proposal and delivery, and it is my vision to address that.

The Case for Methodology

I believe that without formalization, just like standard project management, attempts to improve the record of project contracting will be sporadic, temporary, and based on heroic measures by rare combinations of exceptional people. The proposed formalization is Total Collaborative Procurement (TCP). Using the qualifier ‘Total’ reminds us that successful procurement is more than selecting a qualified vendor. We must include the entire delivery cycle and forget about the idea that all risk and problems are delegated to the vendor. Projects are always a joint endeavour.

What might be the requirements for such a methodology? I have identified twelve; foremost of these are a business focus and an executive role over PM and the work itself. It must be low in documentation demands and adopt a checklist approach. It must assume a delegation of business decision-making to PMs. It cannot be detailed and process-driven. I am suggesting a structure of collaborative practices within a commonly accepted joint business lifecycle.

Shown in the diagram below is a three level architecture that fits these requirements. It offers a starting point for TCP development. The work level emphasizes the use of a project lifecycle (it can be any – Waterfall or Agile), but is essential for the key practice of Lifecycle Mapping. The PM level is based on the functions (not processes) of project management – Plan, Organize, Control, and Lead (POCL). The new business level is an amalgam of the existing buyer procurement lifecycle (ref. PMBOK®), and the best-practice vendor lifecycle (ref. Projects for Profit). This comprises five as yet unnamed phases, home to a probable total of 15-20 practices.

 rhornbyarticle1

Note that the diagram illustrates how the TCP includes delivery in Phase 4 by acting as a ‘wrapper’ for the execution of the contract agreed in Phase 3. In the example shown, the contract is for a big bang project including all project phases. An alternative rolling wave approach would entail two or more cycles of the TCP.

Benefits of the Framework

Senior client and vendor managers concerned with successful procurement, delivery, and closure will now have a defined and consistent basis upon which to conduct their business and shared interest in the project. This contributes to optimization of contract design, more open, efficient conduct of the project, and builds a foundation for the development of trust between the parties.

The contemplation of PM as a four-function model fits extremely well into the demands of the commercial world. No one disputes the need for knowledge of standard processes as found in the PMBOK®, but POCL provides a highly relevant skills and training model as well as permitting clarity of integration of PM with the project lifecycle. Lifecycle Mapping, as I call this technique, is the first of six collaborative practices I will discuss in the second part of this article, as well as some of the challenges of implementation.

Feedback

There is a methods vacuum in the commercial arena, and unless this initiative, or something similar, is taken into development, I can’t see any reason for commercial projects to improve either in efficiency, in outcomes for stakeholders, or in the equanimity of the project managers. What do you think? Are the ideas presented feasible? I need feedback and would welcome your comments below, or by email to [email protected], or by question and comment at the ProjectWorld Vancouver Conference.

References

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author.
Hornby, Robin (2013).

Projects for Profit: An insider’s guide to delivering projects and getting paid. Calgary, Canada: Tempest Management Inc.