A Business Analysis Centre of Excellence (CoE) can be an effective means of improving the way business analysis is performed, resulting in better business outcomes from successful projects and operational support initiatives. It often begins with an ambitious training program, followed by a distribution of templates and instilling the best practices. Some CoEs are successful, but all too often the CoE is disbanded after a couple of years of disappointing results. Having been involved with dozens of CoEs with different companies, I’ve observed some of the most common mistakes and how to avoid them.
1. Failure to Engage the Right Stakeholders
Many CoEs successfully inform executives about the CoE’s reason for existence, and they also let the BAs know what is expected of them. However, few BA CoEs meet the needs of the other key stakeholders. These stakeholders have their own priorities and challenges, and may not have time to worry about better business analysis. Take the time to understand their needs, and to help them make the necessary transitions.
I saw the following series of snippets in a LinkedIn discussion on the Agile ALM tool Rally. Bear with me as you read through them to get the context for our discussion…
I have a serious case of "I want to get back to JIRA Agile".
My latest challenge with Rally is to find the best and most true way of dealing with unfinished stories at the end of a sprint.
Story: I as a ScrumMaster want to move 3 unfinished stories from Sprint 1 to Sprint 2 gracefully so that the team will have these stories in the next sprint without falsifying the velocity of Sprint 2 or the backlog and not creating any more overhead for the ScrumMaster.
- Total backlog story points stays true
- Velocity of previous sprint stays true (commitment is reflected accurately)
- It's not adding a huge amount of overhead on the ScrumMaster or the person doing it
- It doesn't need a custom app for doing this
As I was reviewing the presentations from this year’s Building Business Capability conference, I kept running into slides that looked like the graphic below to describe frameworks which model how organizations operate (the details have been left intentionally blank to protect the innocent):
The Everything Framework
In this one example there was no less than 13 different model components and 25 relationships defined!