There is an age old debate about who's responsible for quality in software. Some people have quality teams, others dedicate quality to testing.
The rational unified process (RUP v2002) says, "A common misconception is that quality is owned by, or is the responsibility of, one group. This myth is often perpetuated by creating a group, sometimes called quality assurance other names include test, quality control, and quality engineering and giving them the charter and the responsibility for quality is, and should be, the responsibility of everyone. Achieving quality must be integral to almost all process activities, instead of a separate discipline, thereby making everyone responsible for the quality of the products (or artifacts) they produce and for the implementation of the process in which they are involved." It goes on to say that the project manager should ultimately own and be responsible for quality.
For processes and tools, I find that ownership is an area that is different every time I see it in most project teams or organizations. I've seen it evident in small teams owned by individuals who are good at learning the details of specific packages and how they work. They do this as a part-time job, being a mentor and tool smith besides doing their normal role of developing or testing. It's all about who you have on the team, how best you share the load and are able to help each other. Use the best skills of the people to the best advantage.
On larger teams, where ownership tends to be shared by teams of people, I've seen the process owned by architecture. I've also seen the process owned by quality management or project management. In many cases configuration management actually tends to run the many of the process and tools.
The reason this becomes frustrating is because I often go into projects as a consultant to help them define their processes and tools, only to find that I am not given admin rights to R&D on tool configurations, or change existing tools attributes, etc. In large projects, often only the helpdesk get enough rights to configure many of the tools used by the developers. Typically they don't know how to install them, let alone properly configure them. By this I don't mean CM tools as, fortunately, build and CM is very close to development, so managers realize that they need to employ the right people deal with these issues and give them the correct admin level rights. It's more the requirements management, change management, UML modeling, or test tools that fall into this category.
By and large I find this not very well defined or thought out in many large teams. The RUP has made an excellent start at describing this by defining an environment discipline that has the roles of a process engineer, tool smith and systems admin. It does not seem to get into much detail when it comes to larger organizations where production/operations tend to own, and want to make highly secure, all environments including the development environment (to the point where developers can't even make any changes).
How has your team dealt with this problem or overcome it in some well-structured way? To keep it in context, let us know how large your team is. I have some thoughts to share on how this could be organized if you are having similar problems.
