By Robin Hornby
October 18, 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 sixth article, Robin presents a business focused architecture for projects, and supplementary models designed to promote collaboration. This establishes a framework for implementing a Delivery Organization.
Introduction
Previous articles in this series have probed specific requirements believed essential in the quest to create a truly collaborative approach to corporate projects. In many cases, solutions were also described. I now want to take a top-down approach to the problem and place solutions within a business focused architecture which in turn suggests models that can be used to develop a transformed environment.
This discussion naturally reads like a description of a project management (PM) implementation, and it does indeed use PM concepts. It is, however, a framework for the business management of project delivery and most likely is accompanied by corporate cultural change. The change requires organizational adjustments, discussed in the third article Organize to Collaborate, but also changes to work patterns, behaviors, and attitudes. The final article will recognise these issues as part of the general implementation to bring about a collaborative environment.
An Architecture for Collaboration
Our architectural model recognizes three distinct project domains to consider when applying collaborative thinking. This has been absent from traditional project frameworks, and the different domains have consequently been muddled together. This lack of clarity has hindered project development, severely impacting the ability of the business to understand, influence, and control the appropriate elements of the project. The diagram, Business Focused Architecture, is taken from the reference, A Concise Guide to Project Collaboration1, and provides the necessary anchor.
The three domains are Business Management, Project Management, and Project Work. Let’s examine each of these domains:
(1) Business Management is the lens through which senior management considers the project. It must be clearly defined, meet the owner’s need, and offer a worthwhile and scheduled return on investment. The project’s compliance with these demands must be tracked and understood through all stages. Finally, the owner should be able to discern whether business expectations have been met. Collaboration places the onus on the provider to nominate and adhere to a framework friendly to the owner. If the provider is a vendor, then the framework must account for the differing business views of the owner and the vendor.
(2) Project Management is naturally a provider’s responsibility but is usually a shared concern of owners/providers. Collaboration requires that the same view is held by owners, in-house, and vendor providers. Thus, our model must operate at the highest level of abstraction to achieve universality and eliminate erroneous views of PM (e.g., as a sequential set of management phases), or overly complex and potentially inconsistent views (e.g., in-house standards, PMBOK®, PRINCE2®, etc.). Desirable details (taken from these standards) can then be reviewed, the value assessed, and selected by the collaborating project managers under a universal umbrella.
(3) Project Work is by definition, a provider’s responsibility. The work is usually guided by the use of a methodology determined by the provider as suitable for the project. Collaboration demands all providers share a common understanding of the visible elements of the methodology, including the nominated Collaborative Stakeholders, as explained in the third article.
Models to Support the Architecture
The three domains of the architecture are invariant. I believe that each of the embedded domain models are just as essential. The domain models are directly reinforced by implementable auxiliary models and techniques.
Domain Models
- A Universal Business Lifecycle: Note that a discarded option for the model of business management was to extend and embellish the project lifecycle to meet business needs. For various reasons, I decided this option was impractical, though providers should always consider minor ‘tweaks’ to their usual methodology to add business intelligibility during execution. The preferred solution is something new – a universal business lifecycle. This offers the best chance to fully align owner and provider and was described in the fourth article, Align with the Business.
- A Universal Model for Project Management (PM): The confusion and time-wasting debate over competing methodologies is avoidable. A watertight definition of PM was proposed in the series introduction, which gives us a solution. PM can be universally defined as four functions – Plan, Organize, Control, and Lead (POCL). These are easily recognized and invoked repetitively and pragmatically as required. During initiation, the numerous deliverables, processes, tools, and techniques provided by PM can be assessed, agreed by all parties, and integrated into the POCL model.
- A Common Project Lifecycle: The most visible component of managing project work is the project lifecycle, and this is clearly where a common understanding of the work is most important. The illustration of the project work domain shows only one project lifecycle out of many in common usage, such as waterfall, iterative, and agile. Thus, a universal project lifecycle is unrealistic, and we must settle for the idea of selecting the preferred option at project initiation and ensuring it is commonly understood. Note that the business view of project work is entirely contained in the execution stage. This forces clarity by separating activities properly belonging in other stages of the business lifecycle from the technical work of delivering a project.
These models may be interpreted as three pillars. They support actionable, auxiliary models that advance the goal of responsible collaboration.
Auxiliary Models
This is where the action is. A sample selection of these auxiliary models and techniques is listed below:
- Shared Administrative PM Decisions: Essential PM decisions and responsibility assignments previously made by the project manager in isolation.
- Owner/Provider Balance: Balanced procedures for joint owner/provider deliverables.
- RAA Balance: The Responsibility/Accountability/Authority model applied to the project manager, ccollaborative stakeholders, and team assignments.
- Team Structure Options: Common structures based on project integration needs.
- Business Risk Lifecycle: Systematic risk analysis fitted to the business lifecycle.
- New Project Model: A new foundation for project analysis which expands the triple constraint without the complexity of PMBOK® or PRINCE2®.
- Project Quality Models: Derived from the new project model to facilitate objective setting, task optimization, deliverable acceptance, and project trade-offs.
- Owner/Provider QMS: Simplified Quality Management System to guarantee provider adherence to owner-approved quality specifications.
Conclusion
Frameworks and models influence how complex problems are analyzed and provide direction for our solutions. This ensures adherence to the objectives deemed important. In this case, they pave the road to responsible collaboration, proper project integration, and owner/provider alignment within an environment favorable to control by business management.
Success with this innovative architecture requires rethinking or sometimes repackaging many established PM approaches and techniques. They are, with some exceptions, not brand new but adaptations of existing elements or a change in emphasis. They are prerequisites for the realization of a Delivery Organization.
I was impelled to write my recent book, A Concise Guide to Project Collaboration1, to meet the need for a practical template that operates within this business architecture. It is aimed at corporate managers, not just project manager. Corporate managers need to understand the concept and its benefits. Then they must give their authority for implementation to the project managers, who will need a description of the techniques and methods.
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
Robin Hornby
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.
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.
