One of the most under-rated and demanding management jobs I’ve ever had was managing a QA organization.  Staffing a QA group is the ultimate in gray areas for managers trying to keep up with the ever changing demands of the business while maintaining the right level of cost efficiency. 

I came to the conclusion that unless one were working for a technology company that required having a dedicated QA function, it’s impossible to justify a QA organization made entirely up of FTEs.  The simple reason being is that most companies will look to cut at these types of functions when times get tight.

One the one side, you have the need to keep intellectual knowledge in the company from project to project.  On the other side, there is the need to support ongoing budget constraints.  So what we are ultimately talking about is the balance between contract labor and FTEs. 

What I’ve found is a mixed model of FTE and contract resources work the best.  There are a couple of ground rules that must be followed in this model:

• Projects MUST fund their own QA
• You as the QA manager develop and provide the processes, tools, and guidelines, the contract QA resources then work under your function to maintain independence
• Your FTEs are going to work with the contract resources to help them understand the constructs that they must work in
• As much as possible, leverage automated scripting for projects that can be used downstream with enhancements and bug fixes
• The FTE organization you build out then must be able to support enhancements and bug fixes that come along as a normal part of system maintenance

As referenced above, there will inevitably be downstream testing for bug fixes and enhancements.  To the extent possible, leverage automated regression scripting.  Rightfully so, no QA budget would exists for this type of testing so you will need to fulfill this testing with FTEs or contractors that you fund. 

So in addition to supporting the QA framework for projects, your FTEs (possibly supplemented with contractors) will be doing regression testing for break fix and enhancements.   You will need to justify those resources, and that will be driven by metrics.  Specifically, post production defects or production incidents. 

The higher number of incidents an application has after production release, the more changes that are typically needed to resolve the issues and shore up the application or its infrastructure.  This all then requires more validation (especially regression testing in the event of application changes), which in turn requires more resources.  I have found the need to tie metrics showing the post production defects and incidents as a way to fund those additional resources.  That funding then comes from either the application team or the business unit primarily responsible for the application, again tying the funding back to those metrics.