“Bridger” A person who acts as go between or translator between the management of a business and it’s IT department or IT partners.
The background
Since the arrival of computers in the enterprise there has been an unfortunate and counterproductive power struggle between IT departments and other areas of the business.
IT professionals share a great deal with other professions such as law and medicine in that they have their own impenetrable language, they are critically important to their clients and they simply can not be substituted with amateurs.
The difference between IT and other professions is that systems and IT tools, especially systems are right at the heart of the every day operations of the business and a fundamental part of every aspect of the business operations.
Naturally it is a source of very serious concern for business that such a critical function as IT is managed by people who are more often than not detached from the business functions and often lack very much understanding or training in business issues.
The key problems faced by a Bridger
Problem one – The Business versus the IT department.
In order to create and maintain a competitive advantage for the enterprise it is essential to combine deep understanding of the business, enlightened leadership and a thorough grasp of what IT can achieve.
The business leadership are custodians of business strategy and direction and as a result, hold the deep understanding of the business.
The IT department or partners hold the deep knowledge of how existing systems work, the impact of changes to them and what new technology is capable of.
Almost without exception, the two areas create and maintain their own plans and strategies in isolation and believe at some level that they can exist successfully in silos. This standoff when it occurs to any degree, is destructive and robs industry of billions annually in lost opportunities and wastage, mostly surfaced as failed projects.
How the Bridger can help
In the short term, a Bridger can mediate between IT and the business translating between IT and Business language and negotiating win/win agreements.
In particular the business needs to understand impacts and costs of sudden demands for change on the IT infrastructure. Risk must also be instinctively understood.
The IT department needs understand clearly the real life drivers that have potential to place unwanted demands in their inbox unexpectedly. Speaking both languages and understanding the underlying problems on both sides makes the Bridger ideally paced to forge this understanding.
In the medium to long term, a Bridger can help forge an understanding by helping to establish sustainable frameworks that see joint plans and strategies developed by the business and IT jointly to forge new partnerships in place of the silos or misunderstandings.
Problem 2 – Business analysts are trained in IT
The most important element of every software project is what it delivers to the business. How clever the technology is, whether it was delivered a little early or late or slightly under or over budget, are all relatively unimportant in the grand scheme of things, but if the system fails to deliver value to the business, it will be a costly failure.
Whether or not the system delivers value is down to understanding the needs of the business now and in the future, optimising processes for automation and implementing the accompanying cultural change to make it work. These are all business and people centric skills.
This critical job normally falls to a business analyst, but there lies the problem.
With a very few exceptions, business analysts are not trained in business analysis or indeed in any other business discipline. The majority are programmers who went down the analysis route and see their role as designing systems and working with IT delivery. In recent years some have been emerging from universities with degrees in business analysis, but even then they are quickly sucked into the existing culture and still lack the business knowledge to understand the issues and the gravitas to engage senior management.
It’s hardly surprising then that there are frustrations, communication difficulties and disappointments as the enterprise attempts to manage its it investments.
The alternative to this business analyst route is when the business, in exasperation appoints someone from the business to gather requirements. This is an even bigger mistake because the non-it person has no idea how to extract or record requirements or how to communicate them to IT people and especially he/she has little chance of monitoring the accuracy or quality of the deliverable.
Another very common error seen more and more in recent times is to react to this problem by appointing a non-IT trained Project Manager to deal with the business and systems sides of the project. While business stakeholders may enjoy better communication in the short-run, their holiday is generally short lived as this strategy lets IT off the hook and leads to a catalogue of poor decisions and a high proportion of failed software projects.
Government in particular are guilty of this mistake as they place too much trust in partners and maintain little, or often no internal skills and knowhow to oversee these huge projects.
How the Bridger can help
The Bridger is by nature a business person and by training a technical expert with the ability to explore, understand and improve processes as well as the training to explain and present them to the IT department, or to work in tandem with the IT department making sure that they get the business viewpoint right.
This approach ensures that the business goals are represented by the new proposed system and the level of change is understood and accepted by users so that a system can be designed and implemented with confidence.
Problem 3 – Stakeholders, Users and Technologists, the tradeoffs.
Stakeholders (define here as the people providing the investment and expecting the rewards in productivity) are all powerful within the project team and all things considered, this is how it should be.
Users, even for an in-house system, are still key. Unless you understand their needs and serve them, the system will not deliver value.
Technologists are the people who know how to deliver on your needs and to make it reliable. Nobody notices them when everything is running smoothly, only when it goes wrong so you can’t do it without their help and goodwill.
When it comes to defining the final feature set set of a system, stakeholders will have a detached and uninformed view of what happens on the shop floor and will want to dictate how the system should be. If they get all own their way it will almost certainly be a disaster.
Users will resist change and will not want any new system so their feedback important as though it is must be understood in context and then interpreted at the right level to deliver achievable changes.
IT will want to dictate the system based on what fits comfortably with that they already have and will have no empathy with users or stakeholders.
How the Bridger can help
The Bridger can help by forging and maintaining the right flows of communication between IT, Users and Business so that ultimately the Business gets what they want through ensuring that IT works with the User to maximise process and pitch cultural changes at a level that is achievable and lends itself to a successful implementation.
Ed Taaffe
(Hardcover) This book presents a top-down appcraoh to define an information system architecture at the enterprise level. It begins with a short presentation of the Zachman Framework that is used as the basic tool to analyse enterprise architecture. A first part is then devoted to present appcraohes used to express the strategy. A second part describes the techniques used to translate the strategic goals at the information system level with data and process modelling. Finally, a third part discusses current technologies and products involved to integrate applications and deploy the enterprise architecture. A CD-ROM is provided with the book. It contains problems and solutions to apply the concepts presented in the book, products information and some modelling tools.Clive Finkelstein is a founding father of Information Engineering and he continues to apply its principles. The goal is to help large organisations to manage their complex information systems. Being strategic doesn’t imply always multi-years projects. The book states that the enterprise architecture portfolio plan for a large company can be created in 8-12 weeks. It also recommends 2 days workshops to define sub-systems that have a 3 months delivery objective. Many examples are provided in the book.This book is recommended for people that are managing applications or portfolios of applications at the enterprise level. It provides also valuable knowledge for business analysts/architects with a detailed examination of the data and process modelling activities and the definition of coherent and autonomous sub-systems. The book has close to 500 pages of dense material, but each chapter could be used separately according to your needs.