The question I am frequently asked by Business Systems Analysts (BSA) is, "Why is getting Quality Management's approval of my requirements so difficult?" The answer could be many things; resource issues, lack of knowledge about the project, requirements quality, timing, etc. More often then not it has to do with lack of Quality Management (QM) involvement during initial requirement review sessions which creates a disconnect between BSA's expectation of what is testable and QM's expectation of the changes that are occurring.
Who is at fault? Everybody.
People tend to think of QM as a 'tack on' service that usually gets involved downstream of requirements development. I would like to challenge this thinking; Quality Management should be involved as early as feasibly possible on a project. They should not be thought of as solely testing requirements that are approved and handed down to them, but rather as counterparts to overall requirements quality.
If you involve QM as early as possible in the requirements review and approval process you will have better quality requirements, quicker approvals, more accurate test results, and team cohesion. How can all of these benefits be true just by including them earlier you ask? Let's take a look:
On many of my past projects I have worked with exceptional Quality Management team members who were subject matter experts (SME) on the particular system. As I drafted requirements I would send my QM lead what I had for review. I thought I was doing great, writing clear, concise, testable requirements, but my QM lead had differing opinions. BSAs and QM have certain requirement quality criterion that needs to be met in order to approve the requirements. These should be similar, but the way one interrupts them could lead to gaps. Long story short, they were able to add additional quality to my requirements by asking leading questions and validating that the requirements met the QM criteria. This usually meant more requirements which broke some of my existing requirements into specific elements. I appreciated the feedback because it allowed me to make quick and easy adjustments to the requirements. I wasn't past any milestone dates and the requirements had not been approved, meaning I didn't have to go through any change control or formal process to make these adjustments - win-win if you ask me. It was this initial review by QM that contributed to the overall quality of the requirements and final deliverable.
Involving QM throughout the requirements process will allow any questions or concerns to be mitigated prior to approvals. Quality Management will be able to do a formal review and sign off with less hindrance because they have been engaged throughout the requirement process.
More Accurate Test Results
The testing on the project will run smoother and have more accurate results because the team clearly understands the requirements and business needs. It is this understanding of what is actually driving the requirements that will allow for the creation of more detailed test cases. It is a lot easier to create testing scenarios when you have the full picture, not just a few lines of requirement text.
The more you include your project teams from different areas, the more they feel like they are part of an integrated team working towards the same goal. The more your QM team members know about the business needs the more effective they are in doing their job.
So, why not just wait till you are done then send it out for the formal review? Well you could, but that week the PM has in the project plan for requirements review and approvals may go right out the window if there are issues. Depending on the way your project/program is structured, if there are issues with approvals, milestones may need to be adjusted because requirements may have to be re-worked and therefore need to go through the approval cycle once again. If this occurs on the project the PM will typically need to submit a change control to adjust the dates, which could set the project back.
I have seen it and have done it myself, we work in a vacuum and only come up for air when we need approvals or questions answered. On your current project or your next, I challenge you to get your Quality Management counterparts involved early and reap the benefits.
If you take anything away from this, it should be - involve Quality Management as soon possible to avoid unnecessary requirement re-work, as well as project and approval delays.