For product guidance visit

For product guidance visit

For product guidance visit

How Invotra is ensuring quality in project delivery

Invotra provides intranet services on a SaaS (Software-as-a-Service) basis. This means that most updates to our product, whether they are new features, improvements or bug fixes, are managed within the context of our bi-weekly release cycle.

I previously described our approach to maintaining quality in our releases here.

However, some of the functional changes we implement do not readily fit into our standard release cycle.

This can typically be the case for:

  • larger functional changes, which take longer than the 2-weeks development cycle of our releases

  • functionality commissioned by customers, which might require more in-depth customer testing, possibly with specialist teams

  • functionality which significantly changes the technology stack that we’re using and needs to be worked on in separate environments to avoid affecting the releases until it’s fully developed

These are managed and implemented separately as projects and are delivered when ready.

In early 2020, we took a good look at our practices to see how we could further improve quality in our project delivery.

What does quality mean in the context of project delivery ?

Each project, whether in IT or any other sector ultimately seeks to deliver the following:

  • What the customer wants (*);

  • When they want it;

  • For the amount of money that they’re expecting/prepared to pay (i.e. the solution delivered is value for money).

Delivering project quality is ensuring the success of those 3 criteria.

(*) Customer can be understood here as either external or internal to Invotra, depending on the project. The same processes will apply in both cases.

What are we doing in 2020 to drive quality into project delivery?

We’re introducing a Quality Contract to drive and monitor quality throughout the lifespan of each project

This contract binds all teams and functions involved in project delivery into an agreed set of principles and practices that have been recognised as necessary to ensure the quality of the project delivery.

These principles and practices are being defined and agreed in collaboration with all department leads involved in project delivery as well as the Invotra board and management team.

The Quality Contract is then communicated to all team members and used throughout the lifespan of projects to ensure that quality is at the core of all that we do.

We’re creating a new function of Technical Quality Lead

Traditionally in Invotra, quality has been the responsibility of all, monitored by team or department leads.

While that responsibility is of course still here, the Technical Quality Lead function is designed to break up silos and improve collaboration between the different teams involved in technical delivery, in particular development, devops and architecture.

The Technical Quality Lead:

  • takes an overall view of all technical delivery departments to drive coherent principles, champions improvements to processes, practices and tools that will improve the overall quality of technical delivery

  • helps coordinate investigation and efforts to solve issues that span more than one team or department.

We’re splitting Internal and External Project Management into 2 separate roles

Until now in Invotra, all projects have been managed by a single project manager.

While this approach has benefits in terms of ensuring that what is communicated to the teams reflect accurately what is being communicated to and from the customer, it does present some challenges which led us to split the role into the following functions:

  • The Internal Project Manager focuses on managing the Invotra teams to lead the delivery of the project

  • The External Project Manager focuses on the relationship and communication with the customer, from contract negotiations to customer involvement in testing the solution.

Here are some of the reason why we chose to split those two functions:

Different skills are involved in each of these functions, which means the best person to lead the internal delivery might not be the same as the best person to lead contract negotiation or the same as the best person to take decisions on what the finished product should look like and how it should behave.

For larger projects, each of these areas requires full-time involvement, making it extremely difficult for one person to successfully do everything that is needed for the success of the project.

What practices and processes are needed ?

So, what are some of the practices and processes that need to be in place for projects to deliver quality?

  • Defined and agreed project scope

This includes functional scope, timelines and budget. 

This needs to be agreed both internally and with the customer, so that it provides a point of reference throughout the delivery that can be used to ensure that all that is required is delivered, but that there is no scope creep. 

  • Roles and responsibilities defined and agreed with all involved

We are now using a RACI matrix on each project to define who is responsible, accountable, consulted and informed for each distinct activity on the project. 

This is a living document that is updated throughout the life of the project to reflect role or resource changes and is used as reference throughout the project, especially when project decisions have to be taken or know who should be dealing with arising issues. 

  • Processes defined, known by all and applied… Even when they seem (a little) too bureaucratic

Of course, we all know that developers want to write code, business analysts and designers want to think about how those new cool features and designs, etc, etc …… 

However, some of the things that might look like administrative details when compared to getting the specification or code written up, or the new functionality tested, are actually vital to the good health and quality of the project. 

Things, for example, like abiding by defined rules on configuration management, knowing how we are planning to release a particular project (what are the different phases that are required for each change, which team is involved, and when is each change going to which environment), how each team member/team notifies that a piece of work is complete and needs to go to the next stage, logging the time spent working on each task of the project.

They are absolutely essential to get sorted from the beginning. 

Having them in place (and followed religiously by all) means the project manager can assess the state of the project at a glance, that everyone knows what needs to happen next for a given piece of work, and in the long run, saves the whole project hours of communication that would otherwise need to happen to figure out what is where, who is doing what and how things are actually going.

Clearly, this also has to be balanced with effective project delivery, or you risk your project taking far longer or costing far more than it should.  Nobody wants to fill-in a 15 page root cause analysis document for changing one particular spelling in code!

  • Regular reviews of all aspects of the project

A project doesn’t exist in a vacuum. It has been commissioned by a customer (possibly internal to the organisation, possibly not), and has a variety of stakeholders, from each department lead who is lending resources to the project, to the management or board of the company, who watches the success of the project. 

In order to ensure that the project will deliver on its entire scope (functional, time and budget), a mechanism of regular reviews has to be in place. 

Reviews need to take place at all levels, and help to decide/highlight to the project team, customer and other stakeholders: 

  • Whether the project is on track;

  • Whether the current approach is working or should be changed;

  • Flag any issues or risks to the project delivery as early as they’re known.

The frequency of reviews and who is involved may vary from project to project. 

Here are some of the regular reviews that are in place on projects run by Invotra: 

  • Daily stand-up call with all direct project team;

  • Sprint retrospective with all direct project team;

  • Weekly review of the project with senior management;

  • Governance meeting with project management team and board members. 

In summary, we’re drawing on our experience of managing projects to implement an approach to project delivery that is putting quality at the core of everything we do, relying equally on our principles and practices and the expertise and professionalism of our teams.