Quality assurance on a project – let’s start with the basics

In principle, any organization that is conducting digital transformation, and related projects to implement various IT solutions, would want each of these solutions to meet the organization’s needs in terms of performance, functionality, growth potential, reliability, and maintenance efficiency. These needs are obvious, but as we know from many examples, there have been, and continue to be, many projects where the obvious needs have not been met. This happens for a variety of reasons but is mainly the result of smaller or larger mistakes made at various stages of the project.

Quality assurance (QA) comes to the rescue here. Quality assurance is a tool that supports a project in meeting the needs of the organization through the products of that project. There is a lot of talk about it, and probably most project teams will say that quality assurance is an important process in their project.

Unfortunately, activities in this area are usually limited to IT system testing. The work of planning tests, creating scenarios, implementing system testing, and handling the results, exhausts quality issues in many projects. Some vendors of large IT solutions even provide quality assurance tools, and they are usually limited just to test management support or test automation.

In our opinion, this approach is not so much wrong as very limited (technical) and in no way comprehensively supporting the success of the project, i.e. meeting requirements.

Let’s look again at the key aspects of an organization’s needs for a project product such as an implemented IT system, which are: performance, functionality, development potential, reliability, and maintenance efficiency. Typical testing will only help verify the functionality implemented in the system, and to some extent addresses reliability and performance.

But how do you ensure that the system primarily includes the functionality the organization needs? How do you ensure that the IT solution is ready/possible to develop? How to ensure that the designed and implemented system can be securely and cost-effectively maintained? To support these aspects, classic system testing is not enough on its own. This is why Quality Assurance is really a comprehensive approach to ensuring that requirements are met in all areas and at each stage of the project.

Quality Assurance is as much about well-prepared requirements as it is about properly conducted analytical workshops, and correct distribution of responsibilities in the projection, as it is about good test preparation.

This is the comprehensive approach we take, and I will talk about some of the basic principles of good quality assurance on a project in future posts. I will not duplicate book stories on how to implement QA in a project, or what are its phases, but will focus on specific challenges and issues on how to practically take care of quality on a project.

Quality assurance on the project – project preparation

During the project preparation phase/stage in general, we define the parameters of the project product, the business case, the WBS (Work Breakdown Structure), the organizational structure, etc., the inclusion of QA usually amounts to writing about this issue in the project definition document, that is, indicating that there will be QA procedures in the project and general information on what they consist of.

In my opinion, however, QA should already work in practice at this stage, that is, to ensure the proper quality of the products of this phase/stage of the project. I won’t waste readers’ time with formulas copied from project methodologies about quality assurance, instead, I will highlight some important practical issues related to quality assurance so that project preparation is conducive to ensuring that the project product meets the organization’s needs in terms of performance, functionality,  development potential, reliability, and maintenance efficiency, because that is what QA is about, after all.

The elements that are worth planning/verifying in the context of QA are many, here I will focus on three issues that are important in my opinion.

First of all, it is worth verifying the business case, that is, the element that actually defines the reason why the project is being implemented and indicates what value we want for our organization as a result of its implementation. As part of the quality assurance activity, it is worth verifying the basic parameters and features of the business case. Is it understood by the project parties? Is it related to the subject matter of the project? Is it really possible to assess the fulfillment of the business case by the project deliverables? In my opinion, the business case is the main pillar of the project, because it is what we should refer to when assessing the legitimacy of performing a task in the project. Thus, it is also worth checking from the QA perspective whether the justification is useful, i.e. whether we can use it in a situation when we need to resolve a dispute or have doubts about the scope of the project. It is a good idea to prepare a list of features that the business case should meet and examine in this context. It is worth remembering that all the time there is a huge number of projects where the business justification is either very generally written or very detailed, but in no way possible to be filled by the products of the project.

Another important element worth examining from a QA perspective is the specification of requirements for project deliverables. IT implementations are very interesting projects, where in practice we often forget to specify measurable parameters of the result we want to achieve. This is especially true for implementations of business-type solutions such as ERP, CRM, APS, etc. A lot is written about the organization of the project, acceptance, management procedures, etc., and one forgets to define a clear specification of what we want to obtain and verify that it is realistic to achieve. We put very complex acceptance procedures and penalties into the contract, but we don’t have a properly described scope of the features we want to receive, evaluate and test.

The other important aspect of project organization that is worth examining for quality is the division of responsibilities between the parties. It is crucial, of course, that it exists, but it is also important that it relates to the specific project we want to carry out. Very often the divisions of responsibility are simply copied from the methodology and in no way adapted to the actual project. In addition, often the division of responsibilities of the parties is inconsistent with, for example, the provisions in the contract, the project scope, or the WBS. Such basic verifications should definitely be done because a wrong assignment of responsibilities can be very detrimental to the project.

As I mentioned, these three aspects are not enough, it is also worth reviewing, for example, risk analysis, change management procedures, organizational structure, acceptance, and the project-defining documentation itself. For many of the readers, these recommendations will seem obvious, but practice shows that the obvious things are often implemented the most poorly. Perhaps it is routine that sometimes kills a project. Taking a qualitative approach to a project and verifying everything is often a key method for us to ensure project success.

Author: Bartłomiej Żak