Centers of excellence (CoEs), also known as competency centers, can be a powerful tool for an organization, but...
they can also become a bottleneck for projects, putting delivery dates at risk. Learn how to make sure that CoEs remain an effective means of managing technical risk, rather than being a source of risk themselves.
A center of excellence is frequently used when an organization needs to take on a new technology or skill and manage its adoption. I have personally been involved with centers of excellence focused on Java, .NET, SOA and BPM to name a few. While the organization may have had experts on any one of the given systems in each of these projects, they did not have any individuals who knew all the technologies involved.
A clear picture of the organization's end state after the CoE is established is the first step in long-term CoE success, but it is frequently forgotten.
Take a SOA CoE as an example. Initially, the CoE may consist of a single team that builds key services identified within projects. In the long run, however, that's not a sustainable model. A single team can't be responsible for all services that you will have in your portfolio. If the organization plans on embracing a technology or approach and expects that it will be part of nearly all projects going forward, then a holistic path to that end is required.
This brings up the second thing to keep in mind. Is the goal to build up competency in the organization, or to centralize a particular function? While the terms center of excellence and competency center are frequently used interchangeably, they actually imply two different approaches. The key word in the title of competency center is competency. Its purpose is to build competency. A CoE, however, uses the word center to imply centralize, as its goal is centralizing a particular function within an organization.
If the purpose is to build competency, then the desired organizational end state should be the elimination of the competency center. Why? Because the competency center's purpose is not to deliver projects, but to build skills within the organization.
Create a competency center when there is little competency in the new technology within the organization and there are no in-house resources to execute projects. In this situation, it may be necessary to use legacy approaches on new projects until you build up appropriate skills. Certainly, outside resources can be used, but building internal expertise is the end goal
Don't measure the success of your competency center solely by the number of projects using the new technology. Measure it by the number of staff members who have gone through the training and proven competency on projects. As the number of people who need to be trained starts to go down, the competency center can be dissolved as the transition to a center of excellence begins.
A CoE centralizes a particular function for the entire organization. Clearly, this has to be something that is a specialized discipline, and a function that a single team handles, rather than a function a wide number of people in the organization require. A technology CoE frequently calls for cross-organizational standardization where it doesn't cleanly fall into an existing organizational group. For example, many organizations have a centralized Project Management Office (PMO) function. In this case, organizations have made a decision that it is more important to have consistency in the practice of project management, rather than aligning project managers with the business domain of the projects. The risk with this approach is that organizations must all come to the PMO for a project manager and are now at risk of not getting one.
What helps mitigate this risk is that the PMO is typically also involved with the prioritization of the project portfolio. By not being part of any one organization that sources projects, PMO can remain impartial when it comes to the prioritization efforts. By managing the portfolio, the PMO can now manage its demand and ensure that the best PMs are allocated to the highest priority projects.
SOA can involve similar functions where the development of services is not centralized, but the CoE handles the governance activities to ensure consistency of approach. When using a COE to take on these cross-organizational issues, another approach can be to establish a cross-functional group to handle it. The risk here is that it's only the SOA CoE's responsibility when they all gather for the meeting; but when they walk out the door, they go back to their day-to-day organizational responsibilities. With this approach, find a way to ensure that required functions are provided, such as measuring the team's activities and potentially including CoE objectives within each individual's performance objectives.
To sum things up, take a competency center approach when you need to build up skills across a large part of your organization. The goal should always be to build up the necessary level of skill and then dissolve or dramatically shrink the competency center. Take a CoE approach when the requirements are a specialized skill with a relatively fixed demand; standardization of the practice is more important than the domain knowledge, depending upon where the practice will be applied; and when there's a need for centralized management or oversight across the entire organization.