We have worked on a number of organizational transformation projects to mature business analysis and agile practices, whether through centers of excellence, centers of practice, or maturity initiatives. Looking back at all of these initiatives, I can say there is one absolute requirement for success in these projects – executive management must believe in and support the effort. When executives aren’t supportive, then in all cases, funding eventually is cut. I recently wrote a post on the projectmanagement.com business analysis blog – “Business Analysis and Successful Outcomes” about how to gain executive support. The underlying theme here is that executives have to believe there is an opportunity or problem that is big enough to address. And that opportunity or problem has to be quantified in some way, usually with dollars.

Justifications for COEs – the ugly, the bad, and the good

I’ve heard many different justifications for COE-type projects. Here are some of the ugly or just bad ones, though ironically these are also the most common rationale!

1. My teams lack the use of consistent practices and don’t produce consistent deliverables….consistency, consistency, consistency! The thing is, consistency isn’t actually valuable in and of itself. Consistently just feels good – it’s neat and orderly. However, if we can deliver successful outcomes using inconsistent practices, we would! So this justification assumes that consistency leads to better project results. If that’s the case, then lets dig into the assumption and ask “what’s wrong with the current results” to find our real motivation to improve.
2. I need to grow my team’s skills. But do you really? How do you know they aren’t at their peak performance level? The real question to ask is “what is the thing you are seeing that tells you they could do better if they had better skills?” Likely the real issue is that the projects the team works on are failing! So can we find out what that underlying issue causing those projects to fail? In solving the issue, no doubt we’ll grow the team’s skills, but that’s not the reason to do this.
3. We have poor quality requirements. That very well may be the case, and it might actually be causing a real problem – but how do poor quality requirements manifest as a problem? Is it rework from development or lots of defects, both of which are costly? Is it that the business doesn’t get what they wanted, which is even more costly? Requirements are just a means to an end, so making them “good quality” isn’t really an end goal. It’s important we understand the real organizational issue that occurs from poor requirements.

Here are a few good justifications for a COE program:

1. 100% of projects quantify what successful outcomes are and 80% of those projects achieve them. Then we can develop an approach through a COE program to make sure outcomes are defined and used to prioritize work, so that the projects achieve them.
2. We are wasting $30M a year in IT spend because 30% of projects don’t ever deliver and 25% that deliver don’t meet the business’s needs. Again, if we align our methodologies to canceling unnecessary projects and aligning the rest to deliver the business needs, then we can ensure the projects are successful and the COE too.
3. Deliver products to market 33% faster to open up $20M a year to invest towards other initiatives. This is a great example of why organizations move to agile – to deliver better products faster. So use the outcome target to make sure that the agile practices actually deliver 33% faster. Again, you can use a COE or some other organizational transformation effort to roll out those new approaches.

One key to all of these is that once you understand the desired outcome for a COE effort, you actually do have to measure it along the way too. This is good though – because if you aren’t achieving or on track to achieve the outcomes, then you can make a change! That’s just useful information to tell you something has to change or you will fail.

The Conflict

But wait – therein lies the rub. Notice that what I’ve been saying so far is we need to define or understand target outcomes for our COE effort to retain executive support. And also notice that the 3 good examples of COE outcomes are all related to the actual projects in the organization delivering outcomes too. But, this is the problem…the very thing that can help justify COEs is to measure project outcomes in the organization and unfortunately, the executives might not want you to expose their projects outcome success rate. So the thing that will retain executive support is the very thing that they might not want you to know about!

To further state the problem, many executives make emotional choices about which projects to run and what to build in those projects. In some cases, they have data backing for their decisions, but usually they don’t. They are using intuition or experiences. The COE efforts will roll out approaches that will measure outcome success on projects, and consequently will start to build the data repository for executives. However, that data might not support the executives’ emotions, preferences, or intuitions about what to build or not.

What Do We Do?

Knowing outcomes, be it for a COE or for an individual project affected by one, are definitely key to actually being successful. You can’t achieve the target outcomes if you don’t know what they are! So, we know we need to do this. The best approach is to actually get your executives to understand why they are important and support you measuring them. You might preface the argument by explaining that the findings will likely show some projects in the past were the wrong ones or unsuccessful, but the findings will more importantly offer solid ground to grow from going forward so that doesn’t happen again. So bottom line is, you have to define and measure outcomes and executives *should* be excited about that. But you might also need to use some strong leadership and influence skills to help them see that!