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.
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.
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.
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.
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@example.com, or by question and comment at the ProjectWorld Vancouver Conference.
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.