By Robin Hornby
August 16, 2023
Collaborative working has become something of a buzzword. Every project would claim it is their intention. But more than good intentions are needed. In this fourth article, Robin investigates the illusive issue of business alignment, an essential step towards a collaborative goal. He determines the need for techniques to align project and business objectives and explores a structure to ensure proper business communication and control.
Introduction
Business alignment is not a well-defined term. Given the primacy of business goals, it implies the owner and provider know what each other are talking about, understand each other’s priorities, and can negotiate productively. In other words, good communication and complementary objectives. It’s not so easy, as experiences of communication failure demonstrate. One stands out because I learned so much from it. Our Australian client (I was with an international IT consultancy) had just signed the contract and I was meeting with the plain-spoken sponsor to discuss their quality requirements. After a laborious description of the options, he cut me off and said, “One of the reasons we hired your firm is you do a quality job. That’s right, isn’t it? So just get on with it”. One immediate lesson was don’t negotiate quality after the contract is signed. And the second? That was one of my preoccupations for the next few decades and forms a chapter in the reference text1.
The delivery of project benefits has also been fertile ground for poor communication and misalignment. Lack of effective cost control is another. The provider denies any responsibility for benefits and blames the owner for not declaring the scope, the level of complexity, and the need for quality. Meanwhile the owner blames the provider for negligence, incomplete analysis, and incompetence. An absence of business alignment may seem like an understatement in these scenarios.
Statement of Requirements
Business alignment requires two structures to connect provider and owner. The first is a method to link the objectives of the owner with the objectives of the provider. I am appalled at how few multi-million-dollar projects devote any significant effort to this linkage. The second is a meaningful framework for communication. Communication tends to occur on the provider’s terms, using the provider’s perspective, and ignores factors that allow the owner to assess real progress and apply business decision-making criteria.
Fundamentally, owner and provider do not speak the same language. The provider’s primary method to communicate their work is the project lifecycle (aka the application, or development lifecycle), usually expanded into a methodology. Providers have taken justifiable pride in developing this vital technique to deliver projects with increasing effectiveness. Methods have evolved from the earliest “let’s get coding”, through waterfall, fast track, iterative, spiral, prototyping, and agile lifecycles. Although essential for team communication and project management (PM), this framework is of interest to only a handful of Collaborative Stakeholders (CSHs), explained in the previous article, and means very little to the owner. Rather than educating the owner on project methods, which are forever changing, the provider’s work should be placed within a universal business framework to meet the following requirements:
- Supports a broader scope than simply building the product.
- Places business control in the hands of the owner.
- Responds to the owner’s custom reporting requirements.
- Recognizes the owner’s perspective is dominated by funding issues, level of risk, and the need to hold the provider accountable for commitments.
The prevailing project methodology may also be ‘tweaked’ to accommodate business needs such as milestones relevant to the owner, project success factors, and status of benefits, obligations, and commitments. A standard approach is also needed when responding to unexpected difficulties – status and options should be reported in language familiar to the owner.
A Framework for Business Alignment
The proposed solution is to use a simple, universal, unchanging business lifecycle to report the project. The graphic, Universal Business Lifecycle, shows an intuitive business view of a project. Though primarily a framework for communication, the lifecycle also forms a base for a systems approach to risk assessment and for appropriate CSH engagement.
- Project Materialization: This is an inherently complex and distinctive stage which gives birth to the project. It is driven by the owner and is concerned with project definition, feasibility, corporate approval, and provider selection. If the provider is to be outsourced using a procurement stage, vendor activities will follow a parallel track partially dovetailed with the owner. At current levels of PM maturity, it is unrealistic to envisage these stages as collaborative, though the reference text describes a future specification for joint practices.
- Project Delivery: Collaboration can now be specified as the project enters the common delivery stages of the lifecycle, defined as follows:
- Project Initiation: This stage starts when the project manager (the PM) is assigned and ends after the signing of the charter or contract, and when the initiation checklist is completed. This is a critical stage and the objective, in brief, is to set up the project for success. The PM, the sponsor and appointed CSHs determine when engagement is needed during the life of the project and obtain commitments. They agree on joint practices and procedures, specific accountabilities, and apply collaborative risk, quality, and resource planning models.
- Project Execution: Owner/provider collaboration plans made during initiation are now put into effect. This stage usually includes all phases of the project lifecycle, though contracted projects using the rolling wave may employ the business lifecycle to manage each contract (for one or two phases at a time). The objective is to ensure business control. Project status is jointly reviewed monthly, decision requests and deliverable approvals kept current, issues and changes analysed and resolved, and go/no-go data assessed in phase end reports. Project performance is reviewed, and a risk alert model implemented for joint feedback and control. This stage ends when approvals for planned deliverables of the included phases are granted or waived and, if it includes the final phase, when the project team has integrated these deliverables into a tested system.
- Project Completion: This stage places the nominally completed system into the owner’s hands for official system acceptance. A further series of tests may be required. Sign-off can be a difficult process, as it requires the owner to declare satisfaction with results and put this sentiment in writing. Several collaborative techniques can be used to help. Transition planning must also be a collaborative task. This plan specifies the owner/provider resources to accomplish decommissioning of replaced systems(s), installation tools, data conversion, training, new procedures, and other change management items. The checklist agreed at initiation officially records project completion.
- Project Assessment: Assessment is planned collaboratively and scheduled three months after go-live. The objective is to learn personally and institutionally from the project experience. Project and business objectives, and the effectiveness of the development and operational phases are evaluated. Recommendations address the system, the operations, and the development environment. This completes the final stage.
The business lifecycle is independent of the type of product, the industry, and the project lifecycle itself. It is quite distinct from PM and is really the foundation of a Delivery Organization.
Conclusion
The experienced reader might be wondering if use of a business lifecycle implies the rigours of a specific methodology. No, because the move to collaboration requires only general structures such as the business lifecycle, an extension of project roles such as the CSHs, and guidance on stage-by-stage techniques and activities. This is sufficient to create a Delivery Organization. My recent book, A Concise Guide to Project Collaboration1, provides a practical template for such an initiative. It is aimed at corporate managers, not just the PMs, and is designed for both in-house and vendor providers. Managers need to understand the concept and its benefits so they can give their authority for implementation to the PMs, who can use the template the book describes. Vendor firms, whose concern is the profitability of their projects and whose business needs are very precise, may refer to Commercial Delivery Methodology2 if formal methodology is of interest.
References
[1] Hornby, Robin. 2023. A Concise Guide to Project Collaboration: Building a Delivery Organization, Routledge (Focus Series). https://www.routledge.com/A-Concise-Guide-to-Project-Collaboration-Building-a-Delivery-Organization/Hornby/p/book/9781032435459
[2] Hornby, Robin. 2019. Commercial Delivery Methodology, TMI. https://play.google.com/store/books/details/Robin_Hornby_Commercial_Delivery_Methodology?id=Rbu9DwAAQBAJ
Robin Hornby has worked in Information Technology for over 40 years, taught project management at Mount Royal University for 12 years and maintained a consulting practice. He worked across Canada and internationally, was a long-time holder of the PMP designation, and presented frequently at PMI symposia. He pioneered many delivery management practices and is the author of four books. In this series of articles, Robin develops ideas found in his most recent book A Concise Guide to Project Collaboration. The series was first published in the PM World Journal.
Registration for International Project Management Day Online Conference is now open! Get IPM Day for only $69 now through September 1st! Register here.
Disclaimer: The ideas, views, and opinions expressed in this article are those of the author and do not necessarily reflect the views of International Institute for Learning or any entities they represent.
