Quality assurance: feeling unloved...

Nowadays, quality assurance is present in many of our activities. It is used to reduce the number of non-compliant products and accordingly secure production in accordance with specifications and initial scheduling. 

In the IT world, it applies to 2 levels: projects and software.   At project level, quality assurance is used to guarantee that the life-cycle is properly complied with, and that milestone achievement criteria (validation of deliverables) are properly met. This is a process-based approach. This approach is based on check-lists.  At software level, it's compliance with development standards that is checked, particularly coverage of requirements with tests. This is a product-based approach. It is often based on software such as Sonar and ALM.  The key stakeholder in these activities is the Quality Assurance Manager, or QAM. 

 

Wanted: Quality Assurance Manager (QAM)

Although this activity is diversified (project portfolio management) and cross-disciplinary (coverage of all IT and even business activities), there are few candidates for the position of QAM.  What's behind this aversion to quality assurance? Is it because this activity is lumped together with auditing or seen as a repressive activity? Is it because it's a support activity?   Undoubtedly a bit of both! Unfortunately, these views are over-simplistic.      Actually, though QA activities can be lumped in with auditing, this is only part of the job.  

 

Quality Assurance Manager, a key role, central to projects

The QAM has many roles:  

  • The QAM is a coach. They advise the Project Manager on project organisation (allocation, Agile, waterfall), as well as risk identification and the related resolution plan.  
  • They are also a facilitator. In fact, as a networker, they will be able to liaise between the Project Manager and project contributors: Architects, Portfolio Manager, Security Engineers, etc. In addition their work allows the Project Manager to save time (access time) and  gain clarification of the definition of needs. 
  • The project management methodology is not fixed. It changes based on feedback from the projects themselves, new auditing themes (GDPR, Continuity, etc.), etc. The QAM then creates new templates, new bodies and new processes. And as methodology writing is not a solo effort, the QAM then takes on the role of leader at the workshops held to draw them up.       
  • Last but not least: the QAM is the cornerstone of Project Manager upskilling. They train PMs on the applicable methodology during collegiate sessions and/or briefly share new information at face-to-face meetings with Project Managers.

In short, it's a position offering no time to get bored. It offers the Project Manager the chance to move from managing to overseeing projects, progressing from a "limited" challenge (single project) to a "comprehensive" challenge (multiple projects). From my point of view as a former PM, it's an opportunity to take a step back in your career, i.e. switching from "doing" to "helping to do". It's an ambitious objective but a highly attractive proposition!