Before defining the architect’s contribution to the management of the project, it is first necessary to clarify the division of responsibilities between the role of the architect and the role of the project manager, the two roles possibly being embodied by the same person or by different people.
There are different scenarios and these differences, according to the companies, even according to the different projects within the same company, generate a lot of confusion with potential overlapping of activities and responsibilities or, conversely, non-embodied responsibilities. To define the responsibilities of the different stakeholders, we will use here the acronyms of the RACI (Responsible, Accountant, Consulted and Informed) to which we will give the meaning R = Director, A = Approver or Responsible, C = Consulted, I = Informed.
It should be noted that this sharing of responsibility between the architect and the project manager must be defined over the entire duration of the project (and not only in the design phase) and may change according to the phase of the project. It is therefore important to remember that the activities and responsibilities of the architect must continue throughout the life cycle.
Finally, note that in the project phases where the activity of the architect is reduced, the role of the architect can be entrusted to another member of the team.
A clear distribution of the perimeter between the project manager and the architect is essential to ensure the success of the project and should not be satisfied with the implicit.
The architect is in charge at least of defining the architecture of the system i.e. of creating the black box and white box architecture of his system, modeling the system and the value chains in the architecture, proposing, justifying and choosing competing architectures, evaluating architectures in maturity and in compliance with priority needs, managing interfaces, carrying out impact analyses, validating and verifying the system.
The project manager, on the other hand, manages the costs, risks and deadlines of the project.
In terms of achieving the project’s Quality, Performance, Cost and Time objectives, the architect is responsible (“Responsible” within the meaning of the RACI) for the Quality and Performance objectives allocated to him (considering the Cost and Deadline), while the project manager is responsible (“Accountable” in the sense of the RACI) of the Cost and Deadline objectives allocated to him (taking into account the constraints of Quality and Performance).
If it is impossible to achieve the Quality and Performance objectives with the Cost and Time constraints, then the question arises of who arbitrates. Since the project manager is responsible (possibly by delegation) for the overall QCDP of the project, it is either he who has this power of arbitration, or a higher authority.
In any case, it is important to clearly identify this authority from the start of the project.
Nota:
We’re talking about roles here, not players. It should be kept in mind that there may be cases where:
- The person who carries the role of architect also carries the Cost and Time objectives (on a sub-scope for example). This player then also plays the role of project manager for this subscope.
- The person who carries the role of the project manager also carries the Quality and Performance aspects (on a specific phase of the project or on a renewal project or called “business as usual”). This player then also plays the role of architect.
Among the main pitfalls are:
- Roles not clearly explained: who is responsible for what activity and what objective? By whom and how are arbitrations made?
- The problem of bandwidth, i.e., the burden on stakeholders who cannot ensure all the activities and responsibilities incumbent on them;
- Failure to explain the results of the arbitration;
- Decision-making that goes beyond the framework of project delegation (e.g. degradation of the quality of the product which has an impact on the image of the company and/or its activity);
- Confusions between role and title which can generate ambiguities (e.g. an architect who would have a role of developer on a project);
- Project managers who historically bear technical responsibility for projects, which can complicate the establishment of a new architectural profession. System project managers often make architectural choices without being aware of them, which induces risks/costs that have not been studied and anticipated (for example: choice of subcontractors on purely financial aspects, without taking account of the technical evaluations).
Here are some good practices to consider:
- Roles must be clarified at the beginning of the project as well as at any organizational change;
- Arbitrations must be explained on the different phases of the project (it can be a simple report or more precisely a detailed file justifying the choices);
- The organization must be adapted (what is the responsibility of the architect) according to the complexity of the component/subsystem as well as the complexity of the reporting (KPIs & models). Often the sectoral or organizational context determines the choice of a sharing of responsibility between the architect and the project manager;
- In addition to the clarification of roles, it is recommended to set up training on the profession of architect for the stakeholders of the project.
We have compiled here several verbatim statements from project managers or system architects from different companies, which echo this necessary distinction of roles:
“ To ensure the role of architect throughout the life of the project, we have appointed an integration and test manager who de facto assumes the role of architect after the study phase of the project;
“ In the context of large projects, we have batch managers who are project managers and architects who have delegated QCDP objectives within their scope and are managed by the manager above;
“ On a small project, we have a technical manager who acts as an architect;
“ We opt for a distribution of roles according to the projects and the profile of the resources available at the time of the launch of the project, with 3 key roles identified and embodied:
• The system project manager (in charge of managing the cost, deadline, schedule)
• The system architect (in charge of design, definition of the solution and technical choices meeting the customer’s needs)
• An IVVQ manager (focused on the downstream part of the V cycle). He ensures that what is delivered conforms to what was specified“ In small projects, the project manager can also have the role of architect: he takes care of the specifications with a system engineer, who is then the technical manager. In larger projects, a role of technical manager vis-à-vis the client can also be defined: it is then an architect involved in the ascending flow of the V cycle.
“ We have an organization where the roles are much more compartmentalized with:
• A program manager who carries the QCDP of the program
• A project design authority, technical manager on the project vis-à-vis the client
• A system architect, internal technical manager during the design phases
• A system engineering manager, responsible for carrying out system engineering activities on the project
• A verification and validation integration manager in charge of integration and V&V activities“ We have an organization where the size and the important deadline of the projects require a sharing of the technical responsibilities between technical managers and an architect. Technical managers are responsible for batches (corresponding to batches of business studies on a product scope). The batch manager is responsible for carrying out the technical studies on his batch (e.g. mechanical sizing notes) and ensures the budgetary monitoring of his activities. These are supports for the architect. The architect is responsible for the performance of the product, and unlike the technical manager, he has no budgetary aspect to manage. It should be noted that this distribution was intended to overcome historical problems where the solution, budget and planning responsibilities were carried by the same role without success: there was either a treatment of technical problems to the detriment of cost and time aspects, or, on the contrary, a focus on cost and time to the detriment of technique. The establishment of separate responsibility for product performance has made it possible to establish a healthier balance between these different aspects to be considered on projects and to strengthen the concern for compliance of the final product.
Your comments will be considered by the members of the Cercle at the next monthly meeting.