A seasoned CIO of a large multinational once remarked: “All of these vendors keep telling me that IT must be aligned with the needs of ‘the business’, as if I just had one customer. "The reality is that I am constantly refereeing in squabbles over budgets, resources and priorities between the heads of the eight divisions I …
Define 'The Business'
In the last company at which I worked as a developer, "The Business" came to be understood for what it really meant: the rich-but-inept middle-manager who had (we later found out) ploughed a tonne of money into the company at an early stage and could therefore not be fired, despite how utterly useless she was.
Getting work signed off by 'The Business' was a euphemism, because it would have sounded unprofessional to say that "E doesn't like that today."
Can't think of a title
Been there, done that, got the t-shirt. Several times.
The last contract I worked on, we were meant to consolidate systems between different businesses, moving some legacy stuff to some strategic stuff. We halted the project and changed tack twice in a month because the business couldn't decide which was more important and it all came down to which of the business owners could shout the loudest. It eventually all got scrapped when they ran out of budget (having spent a good portion of it arguing between themselves and leaving the IT staff to read El Reg all day for lack of anything to do).
The contract before that was more a case of the business being unable to define their requirements. E.g. we were in a meeting with them, 10 business owners around the table saying "we absolutely need functionality X" so we asked: "please define X" and got 11 different answers.
I also had the case of the business owner going "it's not difficult, you just have plug a server in a rack somewhere and put that software on it!" So we asked what he wanted us to do when the system went down, how quickly he wanted his data back, what would happen if the software he had only seen a demo of didn't actually do what it said on the tin, etc.
Generally speaking, I find that differences between requirements from different departments are not necessarily the issue, they can usually get reconciled with a bit of patience. The main issues I face are:
- prioritisation: what department in the business get their problems solved first?
- decision making: business unable to make a decision on a critical issue and trying to defer that decision to IT (and then of course blaming IT if it doesn't prove optimal)
- severely under-estimating the time and effort it takes to deliver a stable, maintainable, usable and secure solution and then discarding IT's advice in that respect based on the fact that everybody* knows that it can't take that long to deliver what they need
The last issue can generally be mitigated by IT asking the right questions and showing that they are definitely not trying to put spanners in the work but are genuinely trying to deliver something that won't be a nightmare to maintain. The first two tend to be completely outside of IT's control and are a direct consequence of poor management in business. If anybody can suggest what can be done from an IT point of view to mitigate those, I'd be grateful.
*everybody: the person saying it and every other person who has exactly the same view of the world
AC to protect the innocent (and the guilty)
Is there any such thing as "IT"?
Especially in larger organizations, there isn't a single "IT" to orient in line "The Business" any more than there's only one "The Business" to orient with. There's the CIO office, with overarching responsibility for establishing standards and security, but doesn't actually run hardware or software. There's the networks group that runs the comms infrastructure and can theoretically shut anything off at the direction of the CIO office, but also claims that individual machines and unsactioned software pose a risk to their infrastructure. There's the mail team that want to be able to deliver everything that comes in, and the mailbox team that doesn't want them to. There's web server folks tapping their bandwidth meters, and the design team that never seem to have the same configurations as the web servers do. There's the Accounting folks that never want ANYTHING changed, and if you have to change it, only do so in February, May, August, or November, and the Marketing department that never talks to any of the above and instead hire their own programmers that set up ad hoc boxes all over the place running who knows what applications that all somehow become essential to actually selling the products. And every one of those groups has eight different "Businesses" to please, and two of the eight are other IT groups, competing with them for budget.
"IT Governance" is an unfortunate term - it presupposes that business process owners should actually be interested in the technologies for their own sake. They shouldn't be primarily interested in technologies - they should concentrate on making their business processes cheaper/faster/smoother/more robust. The technologies are just means to those ends.
What should matter to business is information, not technologies, so what we really need is Information Governance, not IT Governance. Concentrating on the "IT" causes the technologies to become both the driving force and the bone of contention while the business processes are often left to languish. There is indeed such a thing as "the Business" - we've just got into the habit of ignoring it in favour of a techie-led culture of change for the sake of change. The results are all around us - gross inefficiency, poor returns on IT investment and a landscape littered with failed IT projects.
Dealing With "The Business"
Excellent article hitting on one of the Big Issues in the IT world today. May I (relatively) humbly submit my two penn'orth from the perspective of a management consultant with many years on both sides of the fence (IT bloke and also CEO of multinational corp) and also experience on the real dark side - viz. corporate lawyer?
Practical tips and techniques as follows:
1. Hit hard at the top of the organisation with issues that will register with non tech senior managers: specifically "do you understand what this fannying around is costing us? here are the numbers... " (obviously you need to get the data together to work up the argument - but that should not be too hard). If you do not have the balls or communication skills to do this without losing your job then maybe its time to move on (sorry to be harsh, but that's the reality)
2. Depending on the nature of the problem (and the structure of the organisation), build a strategic alliance with the legal department (assuming there is one - if not, move to point 3). Educate them regarding the risks of not getting (whatever the issue is) sorted out, and get them thinking about the potential liabilities arising. Exec teams / boards generally do not listen to IT people - but they sure as hell sit up and take notice when the General Counsel announces a potential liability. Over the last few years, this has provided me with more traction in "dysfunctional" organisations than any other approach.
3. Ensure that all communications (reports, presentations, chats over a beer etc.) with exec management avoid any technical jargon. Keep the focus on stuff they relate to - viz. bottom line, share price, and legal exposures. Nothing else counts. I recently did a presentation on IT strategy to the board of a major financial services company; the first question was "what is an application?" The guy who asked it would make or break any IT investment decision - and he would break anything he did not personally understand; a sobering thought.
4. Rebrand the "IT Department" as the "Information Systems Department". Sounds trite, but works wonders from personal experience. Non digital native board members (i.e. most directors) still think of "IT" as blokes wandering around with screw drivers fixing broken PC's. The concept of "information assets" (and the linkage between IT and the delivery, stewardship and improvement of information) has not dawned on them. A rebranding (and consequent discussion of the underlying reasons) flushes out a lot of issues.
5. Develop and document an "IT Strategy" which has the stated intent of providing a framework for analysing IT investment decisions (i.e. the sub plot is "if it's part of the agreed strategy, you really need to agree this spend..."). This process will be painful, but the pain is worth it as it forces business unit stakeholders to "put up or shut up".
6. Do not regard IT Governance as "fancy". It is as central to a contemporary organisation as a cash flow analysis. You might decide (from a presentational perspective) to call it something different, but the concepts are key to sorting out these types of issues. Invoke what competitors are doing (most directors want to keep up with the Jones's, even if they have no idea why the Jones's are doing what they are doing).
Hope that helps.
- Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
- Samsung Galaxy S5 fingerprint scanner hacked in just 4 DAYS
- Did a date calculation bug just cost hard-up Co-op Bank £110m?
- Feast your PUNY eyes on highest resolution phone display EVER
- Wall St's DROOLING as Twitter GULPS DOWN analytics firm Gnip