Tuesday, 25 August 2015 10:09

Speaker Spotlight: Can You Collaborate?

Written by

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 tmi@telus.net, 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.

Read 4131 times
Robin Hornby

Following his degree in Engineering, Robin’s career began in the UK as a systems engineer. Moving to Canada in 1977, he worked in the telecommunications sector before joining an international IT consulting firm, and embarking on his project management career, rising to become national delivery manager for a major US software vendor. Robin set up his own consulting company in 1997, taught project management at Mount Royal University for ten years, and consults to private clients. He is a long-time member of PMI, holds their PMP designation, and has presented frequently at their annual symposia. 
Robin is the author of Ten Commandments of Project Management and Projects for Profit.

Latest from Robin Hornby

© ProjectTimes.com 2017

macgregor logo white web