Failure to Communicate
It’s no secret that many IT projects fail to deliver their promised benefits.
Costs over run, delivery milestones slip and priority requirements are not addressed. Much has been written on the subject but fundamentally, in the oft repeated words from the 1967 film Cool Hand Luke, “What we’ve got here is failure to communicate.” It’s a failure to communicate between business stakeholders, project managers, business analysts, solution architects and the development team. All of these different stakeholders use a different vocabulary and view the world from different perspectives:
- Business stakeholders are the customers of the project. They own the requirements and they will use the system when it is delivered. Often they get frustrated because they feel like their needs have not been fully understood or completely addressed. They are wary of the compromises that IT projects often seem to enforce upon them.
- Project managers drive the project forwards. They focus on budget, time and quality but often miss the bigger picture understanding of what they are delivering and why. They need to approach things from a high level so struggle with understanding the details when required.
- Business analysts try to bridge the gap between the business stakeholders and the technical team. By eliciting and prioritising business needs from the business and then refactoring them in terms of functional and non-functional requirements, they provide the solution architects with a good understanding of the objectives of the solution.
- Business analysts often face challenges with representing the requirements accurately to the technical team.
- Solution architects and the technical team need to take the requirements and build an appropriate solution given costs and technical constraints. Often they need to explain how the solution components fit together so that the project manager can understand key dependencies and make decisions. Sometimes they suffer from a lack of clarity around requirements and become frustrated when a non-technical audience question their design.
All of these perspectives are valid, the challenge is helping the rest of the project team to understand your perspective of the project and to see how the different perspectives relate and are interdependent. We’ve personally experienced various flavours of these problems throughout our I.T. careers and so have come up with a solution. The solution is our application Hubscope which combines business analysis and solution architecture tools with techniques to help you bridge the gap between technology and the business on complex projects. Hubscope is a visualisation tool that represents all of the different stakeholder perspectives in a combined, interconnected way. It challenges individuals to move out of their subject matter domain and promotes systemic thinking.
‘One Project, One Objective, Different Perspectives,’ summarises our approach as we seek to remind everyone that they are all working to the same project objective but need to understand how their perspective on the project relates to, supports and depends upon others. Hubscope lets everyone in the team contribute their unique insights and combines them into a common objective that can be viewed from many different perspectives.