Adam Niewęgłowski, the Head of PMO at SPOC recently gave a speech at the PMPIADA event in Poznan.
Adam took the 3rd place prize in the speaking competition talking about the importance of Quality Management in Project Management. – Read a short interview with Adam here.
When referencing Quality in relation to IT Project Management, many people will jump to the ‘testing’ of a solution. Something developed by a software development team.
Quality Management stands for much more than this. It is the act of overseeing all activities required to maintain a level of quality and excellence.
Still, an issue with this approach is that the terms themselves are subjective. One person’s definition of Quality will differ from the next.
The levels of quality must be relevant to the project and those who it’s serving.
A Summary of the speech: Quality Management – I Like Quality by Adam Niewęgłowski
Before starting a project it’s important to really understand –
- The objective of the project
- The people involved
- What is going to be developed and delivered
A framework that covers these points well is Simon Sinek’s Golden Circle. This focuses on the Why, How and What questions.
Why Are we Developing this Solution?
Every project is going to have a customer. A customer can be one person or a number of people; such as a department within a business. To determine the ‘Why’ for the project, we need to understand the customer’s requirements, as customer’s satisfaction is the main goal here.
We can use:
- Brainstorming sessions
- Target Groups
- Surveys and Statistics
As some of the many techniques to elicit the requirements.
Before you gather the requirements, you still need to understand the real Why! Taking an empathetic approach will help to do this.
What is it like to be in the shoes of the customer? How do they feel about the problem they’re trying to overcome? Analysing and asking probing questions will allow you to get deeper to the real issue.
How can we Translate Requirements into Objective Measures?
Going through this process, you will hear many points relating to the way the product should work or run. These usually fall into the Non-Functional Requirements list. Frequently they are intangible and difficult to measure.
A good example – ‘I would like the new system to be intuitive’ With only this level of detail, it would be impossible to satisfy the request. How do you determine if it’s intuitive? To do this we can convert the requirements into precise statements.
With a simpler example, if a customer asked a Builder – ‘I would like you to build me a big house’ Could the builder understand what they expect?
It would be much easier if the builder followed up with several questions to see ‘how’ the customer determines big.
- Would you like a house 120m2 – 140m2 or a 300m2 – 375m2?
- Shall it have 2 or 3 floors?
With similar questioning, the builder can finally define that they are to build a house 125m2 across 2 floors with a tolerance level of +/- .5m2
Once the project team defines the requirements in this quantitative way, the respective quality checks can be determined and prepared.
What will we do to make sure we are delivering a product of expected quality?
Now we have defined Why we are running the project and How we will measure the quality. What will you do maintain the quality throughout the project?
In terms of cost of quality, the easiest way to answer this is –
‘Spend as much money as is needed to provide a product of required quality, but not more than the expected benefits related to the quality process’
For example, you could decide to use Automated Testing if you’re developing a complex system. One that has many possible process flows and requires a lot of regression testing, could be a good candidate.
If you’re only creating a simple portal with two paths for the user to follow, will Automated Testing be necessary and provide additional value? Probably not.
Therefore, during the ‘What’ analysis, we also define –
- What will be done to test, and if testing will meet expected quality standards?
- The way we can maintain steady QM? (searching for anomalies, root cause analysis, looking for test result data correlations etc.)
- How can we look to make additional improvements to the quality process? (Focusing on 20% of the most important things to be dealt with first, avoiding waste in the process, following the PDCA cycle for continuous improvement etc.)
Continual Service Improvement Cycle to Improve Quality Management
Answering these points will also allow you to control the risk relating to the project. I.e. What will be the impact if – you only test once at the end of the project? Rather than smaller chunks of testing throughout?
A Parting Comment
Remember that Quality Management can be expensive. In contrast, it will typically be less than an unsuccessful product. A product that doesn’t meet the expectations and the ‘Good Quality Measures’ of the customers, or the factual evidence of poor product quality – can have severe consequences!
If you would like to find out about the tools that can support the techniques mentioned, please get in touch.