I have been involved in or close to about ten re-structurings of test and QA organizations, including the split of the late and great AT&T and Lucent and most recently as part of the HP / Compaq merger. These include centralizing, decentralizing, and downsizing (sometimes euphemistically called rightsizing) test groups, in industries ranging from insurance to retailing to pharmaceuticals. I have found that the industry does not matter too much but the objectives behind the change do. I know a firm, prominent in web services, which has just appointed a senior test architect to help rationalize and possibly synthesize their scattered, disparate test labs. In another example, a bank had acquired several others and was running multiple incompatible banking applications with similar functionality and on the same mix of mainframe and client/server hardware platforms.
Negative behaviors which are common in many re-structurings, not just test teams, include jockeying for position and turf battles, which tend to be more pronounced the more senior one is in management, but happen to non-manager professionals too; lower morale as people understandably speculate on their futures; and lower productivity with much time given over to gossip. If your situation is typical, you can expect a certain amount of shifts in direction, indecision, false moves and undoing of prior agreements as part of your re-structuring.
Change also brings opportunity. Business school professors have written about the concept of organizational stability (inertia) being unfrozen for a period of fluidity and creative experimentation, before settling into the new order of things – the new inertia. People with promise can become assistant vice presidents overnight, while other apparently equally qualified people are left behind. The difference is the initiative they displayed and the willingness to speak up for themselves.
A test-specific consideration in decentralizing: will the testers lose their sense of solidarity and mutual support, and feel individually left “hanging in the wind”, cut off from their fellow testers in the land of the developers and users?
Some test-specific considerations in centralizing, posed as questions:
(1) What will be the impact on the various development teams and user groups? Which ones if any will feel a loss of service? Which will feel that they have gotten a pest off their backs?
(2) Where is the centralization likely to help improve the effectiveness of testing and improve system quality? Where are these likely to decline, if anywhere?
(3) Will any test policies and practices be changed, and if so what will be the impact on the on-going test efforts?
(4) Will some test tools be abandoned? If so, what re-automation or conversion of existing automated test case libraries be required? Who will do it?
(5) Who frankly is going to win or lose with this change? Who had I better be nice too> What new opportunities may open up for me? If I had my druthers, what would be my ideal job in the new order of things?
There probably are other significant aspects which I have not thought to mention, so hopefully others will jump in.
Re: Centralizing Testing
I'm not quite sure if you're looking for additional considerations or answers/discussion of the points you've already brought up.
In my experience, decentralization is more likely to negatively impact the overall quality of systems than centralization. It is also more traumatic for the tester.
When centralized, service to development teams and user groups normally improves, although they may, at first resent loss of their "personal" tester. The tester themselves may be relieved, however. The resentment can be handled by assigning their accustomed resource to their project (at least at first); if the tester wants OFF of the project, they can also use the opportunity to get a backup trained. Service improves because testing personnel have better support, can utilize the talent of other team members, and can have backup for their own work duties. Often the availability of tools, training, and personnel improves.
If not handled properly, centralization may decrease the information flow from the development organization to the test analyst. This, in turn, can decrease test effectiveness.
Test policies and practices will probably be changed for some groups; normally such changes are not implemented for projects currently under test. This is a good thing; it allows the newly formed centralized group to insinuate itself more gradually into the project flow.
If the company uses multiple test tools for each little group, the QA/QC manager will need to evaluate overall effectiveness and determine which tools to keep, which to abandon, and formulate a plan for conversion/re-automation of existing scripts. In a large company, with scattered test assets, this effort can ultimately save the company significant money in license fees.
Often test personnel are excited by the change, because it opens a whole world of possibilities in terms of career. With a centralized group, division of personnel according to experience level and specialization becomes possible. Career paths can be established and it may be possible to establish lead positions. In a decentralized situation, this is not as likely. Every project team might have it's "QA Analyst", but they're pretty much on the same level, doing the same things. In addition, a centralized group can leverage each others' talent and experience. I've also found that testing staff appreciate having others to talk to that understand their work and a manager that understands and supports their goals.
I think everyone eventually wins with this change. The biggest problems for the newly formed group are going to be related to politics and the ugliest job is going to be that of the manager/director of the group. I think it's important that the head of the QA group be at the same level (or above) that of the highest level development manager. If there's a Director of IT, there needs to be a Director of QA/QC. Otherwise, the newly formed group will have difficulty getting support and cooperation from the development organization. In addition, without the visible, definite support of upper management, the group may survive, but it is often a constant, losing battle. In addition, a great deal of the manager/director's job will probably be education of those that do not understand the field.
A few considerations that also need to be considered are that a major evaluation of all existing processes, procedures, and templates will have to occur; reengineering will probably be necessary. Even if the environment utilizes agile technologies, some standardization in approach is going to be necessary. Space will have to be found for staff and equipment/labs standardized. Libraries (of test data, tests, templates, and procedures) will have to be centralized. Staff will have to be interviewed, assessed, possibly trained, and placed where most effective. A budget will have to be created, justified, and maintained.
And I suggest you be nice to everybody (!) , but I believe development will feel the most like "losers". The kickback can range from mild to truly hideous, but there's always kickback. It's a good idea to prepare upper management for this inevitable conflict, so they recognize it for what it is and respond appropriately. Establishing a QA/QC group is one of the most difficult organizational changes a company can make (again, due to politics), but if the group is supported by upper management, the flying shrapnel normally goes away within a few months. In fact, as the testing process becomes routine, most development staff forget that they ever opposed it; it actually makes their jobs easier. I believe it's the perceived "lack of control" over what gets tested and communicated to others that causes most of the problems. In other words, fear. This can be alleviated somewhat through professional ethics (everyone is measured using the same yardstick), and by helping/accommodating development staff wherever possible (without affecting the overall quality of the AUT). In the situations I've experienced, the user, production, operations, and marketing groups are normally supportive of QA/QC intiatives.
I think the "ideal job" question would depend on the individual. I'd want to head up the organization. Earlier in my career, one of the best jobs I ever had was as a lead for a really outstanding QA manager. I know some people that get the most gratification as TQAs (technical quality analysts), setting up and maintaining labs, running performance/load/stress tests, installing and maintaining tools, managing dbs, etc.
Looks like I've written a book, but I've just scratched the surface. I found the "inertia" statement interesting. I think most people find some comfort in some level of stability (particularly in the area of organization), but appreciate some fluidity and experimentation in terms of executing their jobs.
I'm sure others have a great deal to contribute; I've set up 9 or 10 QA/QC organizations from scratch. Thus far, I've found centralization efforts occur in larger companies that have had some major quality issues in production.