​​​​​“The art of governance does not consist of making desirable what is possible. It consists in making possible all that is desirable”
Cardinal François Marty
Agility:
What is governance?
Governance is the system and set of rules that govern any area of activity. Applied to the project, governance guarantees the structure, organization and quality of the project.
The objectives of project governance include:
- Establish a clear and consensual vision of how the project will work.
- Ensure constant monitoring of the smooth running of project activities.
- Facilitate decision-making in line with events.
- Organize meetings involving all
stakeholders
. - Ensure a smooth and transparent flow of information.
The Essential Components of Governance
These components are defined at the beginning of the project by the project manager, the project manager or the project/program director, and are validated with the client who is also a stakeholder.
They are usually detailed at least in the Project Plan and ideally in a Quality Assurance Plan (QAP), including:
- The organization of the project
- Roles and responsibilities
- Governance bodies
- Tooling and mechanisms
- Processes and rules
1. Project organization
Bringing people together to achieve the same objective within the framework of a project requires taking into account both individual skills and the interdependencies between them (business, operational, hierarchical, etc.). This is the challenge of project organization.
It is based on two principles:
A-Profiles:
It is a question of selecting the most relevant and available profiles to join the project team.
This process starts with the pre-sales phase with the theoretical identification of the skills and levels of experience required to carry out the project.
The staffing process then consists of matching the desired profile with the most suitable person available.
In the description of governance, the actors are usually not mentioned by name, as they may change subsequently.
B-Team structure:
This involves graphically representing the team structure in the form of an organizational chart, including management levels (functional and/or hierarchical).
The functions of the members of the project team are specified, as well as their names, their full-time equivalent (FTE) occupancy rate and their geographical locations in the case of a distributed team. This representation makes it possible to verify the overall coherence of the system.
2. Roles and Responsibilities
At the start of a project, it is necessary to define the roles and responsibilities of the actors, internal and external, for each process and activity.
Two actions are required:
- Describe the missions and prerogatives of each key profile.
- Establish a granular RACI matrix.
A. Description of Key Profiles
The description of the key profiles is summarized and explicitly in the Project Plan and/or the Quality Assurance Plan (QAP).
Here’s an example, Release Manager:
- Coordinating, planning and managing release cycles with Project Managers.
- Coordination of content and publishing efforts based on the backlog.
- Relationship management and coordination of work between distributed teams.
- Contribution to the understanding of the impacts of branches and code mergers.
- Manage code branches (scope, version numbering, tags, etc.).
- Development of deployment and implementation plans.
Risk management
and resolution of issues affecting the scope, timing, and quality of publications.- Deploy code to different environments.
- Coordination of production activities.
- Maintenance of a publication repository and management of key information.
B. The RACI Matrix
In the RACI matrix, each letter has a specific meaning. This meaning may vary depending on whether RACI is used in English or French.
Also, under certain circumstances, additional letters may be added (S for Support, V for Validator, S for Signatory, Z for Zorro 😉).
The matrix lists the activities and tasks of the project, and for each one it indicates the involvement of the actors by the corresponding letters.
To avoid any ambiguity, it is important to always recall the meaning of each letter in the context of the project in question (legend). A common definition is:
3. Governance bodies
A. The Committees:
Committees are project control structures, bringing together representatives of the various
stakeholders
.
The composition of the project committees varies from the most operational to the most strategic, thus corresponding to a scale ranging from the most detailed to the most global, with a decreasing frequency of meetings.
The most common regular committees include:
Ad hoc committees, aligned with the key stages of the project, are also set up:
In addition:
- Internal instances of preparation upstream of client instances, such as ProCo (Project Committee) preceding SteerCo (Steering Committee)
- Contextual bodies, such as handover committees, innovation committees, or change committees, related to the processes established on the project.
- Exceptional bodies, such as crisis committees, provided for as part of the processes but set up on an ad hoc basis to manage critical situations.
- Rituals specific to the operational methodology:
daily scrum
,
sprint planning
,
sprint review
,
sprint retrospective
for
the Agile method
, for example.
B. SideLines of Committees
At the beginning of the project: the Project Plan (PP) and, ideally, the Quality Assurance Plan (QAP), detail the governance bodies that will punctuate the life cycle of the project.
For each instance, the standard agenda is specified,
the objectives, the mandatory and optional participants per
stakeholder
, the indicative duration and frequency, the modalities (face-to-face and/or remote via the tool), as well as the entry and exit elements (supports, associated deadlines, validation principles).
These elements are validated by the client at the start of the project.
Upstream of each planned meeting:
the project manager prepares and shares the committee’s agenda with the participants.
In some cases, particularly with regard to the project leader on the client side, the presentation material can also be shared upstream to allow everyone to prepare for it; The discussions will then focus on the key points during the meeting.
At the end of each instance:
to ensure the traceability of the decisions and actions taken during the meeting, a report (CR) is sent by the project manager to all participants.
This report is sent within 48 to 72 hours of the meeting, in accordance with the terms and conditions set out in the Project Plan or QAP.
In addition, each participant has a set amount of time to react; After this period, the content of the report is considered to have been accepted by all.
4.Tooling and mechanisms
To supervise and manage the project in an optimal way, the use of appropriate tools is essential. The project team must collaborate on similar tools that promote the fluid flow of information:
- project management software,
- file sharing space,
- dashboards,
- standardized exchange formats, etc.
The choice of tools involves both the internal team and the client, as their use is linked to control and reporting mechanisms aimed at measuring progress and ensuring the smooth running of the project.
With this in mind, it is best to avoid duplication of tools, data, or formats as much as possible.
For example, using a customer ticketing tool instead of Jira is conceivable, but this should not compromise best practices for measuring
KPIs
such as those practiced with the
Eazy BI
module.
Similarly, using Slack instead of Teams can deprive the project team of the ability to exchange data asynchronously, which is essential for traceability and prioritization of information.
Finally, the incompatibility between tools can be an obstacle in daily life that is best anticipated.
5. Processes and rules
In the interests of transparency and efficiency, the most common processes and rules can be defined at the start of the project.
The latter, once validated by the client, will have the force of law during the project. This is why accuracy in their description and operability are essential factors: care should be taken to apply the WWWWHHW method for each one (What, Who, Where, When, How, How much, Why).
Here are some of the most common examples:
- Onboarding process.
- Ramp-up/ramp-down management.
- Deliverable validation process.
- Change management process.
- Escalation process.
- Data security and privacy rules.
- Ordering and invoicing process.
- Document naming rules.
- Back-up principles.
Governance is not an option
The definition of governance is therefore an essential prerequisite of the project and its scope should not be underestimated.
In the event of difficulties, several components of governance, such as the roles and responsibilities of
stakeholders
, can be helpful as they can be challenged with the client.
This approach is applicable to all types of projects, regardless of their methodology or the nature of the engagement.
Governance is not set in stone
Defined in the early stages of the project, governance remains dynamic and adaptable throughout the process.
Based on a set of best practices, often derived from experience, and on assumptions about the best way to manage a specific project, governance is not inherently perfect.
It is essential to regularly question this governance and integrate it into a continuous improvement process.
Governance is inclusive
Governance involves
all stakeholders in the
project: the client, as the main sponsor, as well as the various entities of its organization involved (IT, Business, etc.), third parties (contributors or suppliers), as well as the service provider.
All these entities work together according to common rules established within the framework of governance. Any decision by the client to deviate from these principles, in particular by the desire to compartmentalize the project, is recorded and traced.
0 Comments