When to break down your QA Management Project into multiple smaller projects

Development Organizations are in constant change.

A change in the Product Marketing strategy may lead to splitting the development baseline into individual and separate products, or the growth in sales of a product may even support the decision to split an Organization in to separate Business Units.
Opposing change is like trying to stand in the way of Evolution, it may take longer to achieve it but at the end of the day Change will take place (and hope you don’t share the fate the Dinosaurs).

A question that arises as part of Organizational and Structural changes within an R&D (Development and Testing) group is when should we split our Issue and Test Management System into independent environments?

There is no text-book answer. There are Pros & Cons to having one large-concentrated project and/or many individual-smaller ones; and the decision should be made for each case separately.

QA management project - Environments

Having one large and concentrated project has multiple advantages:

1. A single place of work for everyone assures you are always looking at the correct set data.

2. When working with one environment you can migrate and share data between projects, for example a bug that is detected in one project can be assigned to a separate team for fixing and handling.

3. When all your data sits in one place you have the ability to aggregate and compare the information from all projects in order to get comprehensive reports (specially valuable to Higher Management)

4. Lastly, one centralized project makes it easier to implement and enforce a unified working process and methodology.

On the other hand, having a project with lots of unrelated data has its disadvantages:

1. When you have tons of data in your environment it is harder to easily find the information you require to work.

2. If you need to force a system to serve the needs of many teams it will automatically be optimal to none of them, as it needs to accommodate many more constraints than if it was to serve a single or a smaller number of teams.

3. My personal favorite (and you may disagree with my psychosis), having individual projects allows you to start fresh as many times as you want. I always enjoy the opportunity to “clean the desk” and leave behind all the mistakes of the past, looking at the future with a new and fresh perspective.

In order to take a practical approach, you need to review what are the individual needs of your organization and make a decision for yourself (with your respective stakeholders, obviously!). Over the years I realized that 2 main criteria usually help me decide what path to take: The level of Data Sharing, and the Incompatibility of the Processes.

1. If separate projects have important amounts of shared information (i.e. Issues that flow between Teams, Tests that are reused between Projects, etc) you should try to keep them under a single Management System.

2. If the working processes of the teams (dictated by external constraints, the nature of the project or even cultural differences) are too incompatible you should try to separate the systems into individual environments that will serve the needs of each team.

These are only rules of thumb and they need to be reviewed together with the rest of your Organization’s individual (and sometimes singular) constraints, but 8 times out of 10 they will be your main guiding points.

I could not finish this article without referring to some of the most common WRONG REASONS why some Organizations decide to split their working environment into individual projects:

1. Geographical dispersion of the teams.
This used to be a limitation in the past, and is still a real limitation for some Platforms in the market today (that continue using the wrong technological approach). But today there are enough platforms designed and developed in order to work seamlessly for distributed teams regardless where they sit around the world (if you are looking for one of these systems you can check QuackTest out).

2. Amount of data in the system.
If you have too much data in your system you should think about
(a) making some order and archiving (or erasing) the stuff you don’t need,
(b) working with a system that can help you accommodate the amount of information you need to manage.

To summarize, when an Organization changes you need to make sure your infrastructure still suits its needs.
Having said that you should not jump into breaking down your project without understanding if this is the right move for you. Take into account that it is very easy to break a system down into 2 or more instances, but it is extremely difficult (some would say close to impossible) to merge 2 or more systems into one.

About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.

One Response to When to break down your QA Management Project into multiple smaller projects

  1. Ido Schacham October 27, 2008 at 12:12 pm #

    Interesting, thanks.

Leave a Reply

As of May 2022, the blog has moved to PractiTest's main website. To keep following our posts go there.