KISSing Complexity Goodbye
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!
One of the recurring themes I heard from presenters and attendees alike was the challenge in demonstrating the value of business analysis and related activities to their organization, particularly with business architecture initiatives. I think part of the challenge lies in trying to use big, elaborate frameworks to describe anything and everything within an organization. Sometimes we think we’ve developed the ultimate map of our organizations, but it just serves to confuse our audience when we try and have a conversation with them. It can be hard to explain, much less understand.
Complexity – the conversation killer Watch video here
Instead of trying to have every possible model and view of our organizations, why not focus on using what is effective and relevant for our audience and eliminate the rest. One of the primary purposes of modeling is to facilitate a shared vision of the present and/or the future, which supports informed decision making and improves change outcomes. The more complex we make the model the harder it is for all stakeholders, from executives to front line staff to solution experts, to get on the same page.
Every organization is different, so no one set of models is appropriate for everyone. Here is a sample of the types of models I usually use as a starting point with clients:
- People: Org charts and stakeholder/actor/persona matrices
- Capabilities/Processes: (Non-compliant) BPMN diagrams
- Information: Entity-relationship diagrams, sometimes data flow diagrams, business rules catalogue
- Technology: Systems catalogue mapped to the information each system manages and the processes it supports
- Requirements: Text, diagrams, mockups/prototypes
This is the starting point that I use for everything from developing business cases to assessing solution performance. These are by no means the only models that can be used to maintain and communicate this information; it’s all about finding what works best with your stakeholders to achieve that shared vision and reduce the noise in your conversations.
So, what part of your business analysis practice do you consider overly complex? What challenges do you encounter due to the complexity? What can you do to simplify or eliminate items that are not having their desired effect?
Don’t forget to leave your comments below.