A great way to establish your software engineering processes, training, best practices, reports, and metrics is to build a center-of-excellence (CoE). When complete, a CoE is a team, or entity, that provides the leadership and governance in a focus area. Often the leadership is in the form of items such as, training, documentation, metrics, reporting.
Throughout my consulting career, I have come to find that a great way to establish your software engineering processes, training, best practices, reports, and metrics is to build a center-of-excellence (CoE). When complete, a CoE is a team, or entity, that provides the leadership and governance in a focus area. Often the leadership is in the form of items such as, training, documentation, metrics, reporting.
A CoE is a “buzz-wordy” name, but CoEs are very effective in making sure the projects are on the “right track,” risk is properly managed, and that you have what you need to be successful. A CoE is a group or body that supports a certain focus area through leadership, governance, best practices, and knowledge. I have helped build, or have been part of CoEs at several enterprises, and over and over I have seen how departments, firms, and groups with CoEs have a greater chance of success than those without.
Recently, I helped build a CoE at a large firm in which there was a rollout and configuration of an application lifecycle management (ALM) development tool in the context of establishing a global ALM. The rollout was targeted for the enterprise level, and yes, agile development was a line item in the CoE. Enterprise level projects are always challenging and fraught with technical, managerial, and emotional issues. Many project owners think their projects and/or processes are so unique that no enterprise standard could ever support them. My CoE project was no exception.
We found the key to a good CoE and process adaption was some foresight and forward thinking, on the part of the CoE leads. Good CoE leadership must, as much as possible, be promotedon the part of the extended technical team with simplicity with respect to the CoE practices and artifacts. Good CoE leads must also use a governance process to manage change, and to also address the needs of teams that may need more process items that are generally supported by the CoE. With respect to training, I believe in the train-the-trainer approach. The train-the-trainer approach allows clients to better manage training costs, and it allows the client’s own employees to apply sections of training to the business needs. This is the training approach we used at my recent building engagement. Train-the-trainer also allows the clients and CoE leads to deliver the product training and also design the training options, such as web-based training.
Our immediate strategy focused on teams that wanted to join our ALM CoE. Teams that want to be early adapters of things like CoEs, generally, are motivated, want to improve, and will better react to change. We used web conferences and networking to find these early adapter project teams. Since change is always hard, we used our foresight and reached out to project teams that thought their success was hindered by a process that was either too cumbersome, too manual, or just too much. Teams in this situation are receptive to CoEs, as the CoE provides expertise, subject matter experts (SMEs), and pathways to improvement and success.
As you would expect, these project teams enjoy the education, documents, best practices, and reports that are part of the CoE. Our CoE, as with most, provides knowledge support, product supports tips, and useful metrics, needed by struggling teams. Some of the useful metrics we designed into the CoE included “build health” and “defects-per-development” Iteration. Metrics such as these help teams improve quickly and support continuous improvement. When successful, CoE early adapters can be some of the CoEs greatest supporters.
We also targeted teams that either wanted or needed to