This is a 4-minute read that makes the case for a disciplined approach to selling and delivering a contracted project. This is a vendor responsibility, and a stepping-stone to the long-term goal of client/vendor collaboration that Robin believes is the key to real gains in productivity and project success rates.
In this post I am returning to the main focus of the series – the business management of IT projects. Previous posts discussed how to make a sound bid decision, how to respond to RFPs, how to model risk, and most recently presented a top-down view of the commercial environment which serves as preamble to today’s topic.
The common thread that emerges from these analyses is the need for a formal approach to guide the business through the multiple issues that arise, and so lift vendor performance to a new level. Namely, a comprehensive roadmap through all phases of the sales and delivery lifecycle, with clarity on what should be done and by whom. This practice is . . . methodology! There, I’ve said it. But please don’t go away just yet. I hope to persuade you that the pros outweigh the cons, outline some of the key components, and introduce one example of an available solution.
The advantages of methodology
Almost all projects of any complexity profess adherence to one of many methodologies (waterfall, iterative, or agile) each with their own project lifecycle. And most PMs would claim to follow the guidance of PMBOK(R) or PRINCE2(R) methods of management. Then my question is, why do business managers ignore the need for frameworks to guide sales and delivery processes? The well-known benefits of repeatability, quality of work, and predictability (for planning) would also be supplemented by a new ability of vendor management to understand the risks they are entertaining and control the degree of commitment they are accepting.
But methodologies do have a reputation for inflexibility and paper-work that threatens to erode productivity benefits. The more creative members of our profession also believe they are stifled by road maps and would rather roam free. In the business world, objections are sometimes voiced by sales executives who claim that the time required to engage in formal methods takes away from vital sales effort. I concede that the best practices described in this series reference, Commercial Project Management, do not require methodology, but I do believe that the added context and procedural detail make it worthwhile.
Start with a Big Picture
So, if we believe that vendor business management benefits from methodology, a good starting point is to analyze the framework, or architecture, that describes the commercial environment. Vendor projects exist in this environment, and if we want to get serious about controlling it (and making a profit), then we need an architecture that integrates the different views of the project – the project lifecycle generally seen by the client and team members, the project management view, the vendor’s business view, and the client’s procurement perspective. In my experience, working with existing standards on a contracted project is an exercise in frustration because there is no recognition of the need to integrate these views, nor any discernible support for the vendor.
I used this architecture as a roadmap for Commercial Project Management, focussing primarily on the six vendor best practices, and avoiding the challenge of a full methodology. That challenge is now my goal, using the architecture to ensure proper integration. Vendor methodology is not a means to manage the project, nor to sequence the phases of project work, but to ensure sales are accomplished consistent with the probability of delivery success, and that delivery is managed with the intention of making a profit. It is the consummate best practice.
Managing the business of projects
What I am really proposing is a means of managing the business of a project vendor. The framework for this effort is the five-phase business lifecycle, or vendor lifecycle (they are synonymous). Unlike other elements of the architecture, this need not especially concern the client as it is operated by the vendor’s delivery manager and deals with risk, commitment, and vendor business decisions. It’s a very good model for examining the business of moving from bid/no bid to contract award to project sign-off; the three most significant events for the vendor. It also provides a platform for the collection of valuable project data that can be used by an executive to profitably manage the vendor’s portfolio of projects.
With the lifecycle now defined, each phase can be developed in terms of goal, objectives, exit criteria, deployment flowchart, practices and processes, documents and deliverables. An array of techniques, checklists, models, and templates can be specified for each phase to be employed as needed.
Takeaway
Every successful technical development uses methodology. The project vendor can benefit from this established fact by adopting a methodology for their own complex task of selling and delivering a technical project. Of course, this is only a prerequisite for success, not a guarantee. Success in professional services depends on many other factors, including some elements closely related to methodologies such as policy, roles and responsibilities, and delegation of authority.
Although a disciplined approach by vendors in their use of methodology will improve matters, the ultimate goal must be the viable integration of the vendor lifecycle with procurement. And this, of course, is totally dependent upon client collaboration and future initiatives driven by the project management profession, procurement, and professional services.
But the vendor community can act today. If you are interested in examining and working with an example of such a methodology, there is a download available from Google Books. The reference is the Commercial Delivery Methodology. I would welcome feedback on this topic, especially from readers in the professional services business.
