Chapter 6 - The Accountability versus Ownership Paradox
Stewardship is at the core of this paradox: the business owns its information systems, but the IT department is held accountable for them. As such, technology executives have responsibility without authority, which is the perfect recipe for scapegoat stew.
A sardonic CIO commented that "There are only two types of projects, business successes and IT failures."
Having to deal with systems into which the IT department had little input in choosing is the present problem, and having little ability to influence the future choices ensures they do not have the power to address the problem. They can push the business, but it's likened to pushing a rope. The business will invariably arrive at an ultimatum of "do as we say or we will seek an external vendor," and they have the budget authority to back their threats.
In some instances, the IT department is brought into the planning process for "the last mile," which puts them in the position to either accept bad decisions, or gain the reputation of a naysayer and an obstructionist.
The author notes that there is a plethora of literature and lectures about how IT can partner with the business, yet many companies maintain the schism. She asks, "Why, after all this time, is this still the case?"
(EN: The answers that follow overlook the obvious: it is a power struggle in which IT executives seek to take power, and sometimes a lot more than they should, away from their peers. Most books and seminars, including this very one, are written as tactical manuals for the IT department to manipulate and wheedle, consolidating authority to themselves to provide technical solutions that they like, but which may not suit the needs of the business. Even when the advice is well-meaning and properly restrained, is application has been less than productive, and the motives of the IT department are suspect. After years of trying to kick in the front door, they wonder why the intended victims of their foiled attempts don't invite them inside now that they are asking politely. They just don't get that people, unlike machines, do not forget a thousand errors when you finally get the code right.)
One reason the author offers instead is that It is a young profession that has not had time to mature as others have. Another alternate is that IT projects became much more complex and integrated than they used to be: the IT department isn't merely setting up a warehouse for customer data, much like an empty warehouse. But today, IT departments are automating tasks that govern how the data is entered and accessed in the system.
Don't Mistake Governance for Shared Accountability
The prime directive of most IT departments is to ensure the security and stability of the company's technology resources - which is a valid goal, but one that leads them to be obstructive: the most secure and stable system is one on which no software is installed, no employee ever uses. Better still, disconnect it from the network, unplug it, and lock it in a vault.
With this in mind, governance means saying "no" to a lot of things, and using a committee means that there is no single person who can be approached and reasoned with. It also means that decisions become political, currying favor with the right people to gain their permission to do what clearly needs to be done.
While governance cannot be abandoned, it should be restructured. Do the analysis, and have some frank discussions, to identify specific people who are responsible, so that there is clarity and accountability.
There is also the need to dial back on the amount of influence IT seeks to have by means of governance. The general concern, which is supported by past behavior, is that governance committees tend to delve in much deeper than is required to ensure stability and security. If the IT department is to have input into business initiatives, it needs to be through other mechanisms and much earlier.
This may also be a case where the strengths of technically savvy employees become weaknesses: they are very good at delving into details and laying out processes, and often take the same approach when they are given any perspective into the business operations. Said another way, fussiness and micromanagement are part of their DNA, as is a complete lack of people skills to know when it is acceptable to do so.
At a minimum, rules of engagement should be defined in any project where multiple departments are involved, to define responsibilities and authority that promote collaboration rather than struggling for control.
The author also indicates that it is also a common practice for businesses to completely drop a project on the IT department and expect it to run it, without their input. An actual quote from an IT executive is given: "I explained to them that just because IT is a part of the project, it does not mean that IT should run it. Suppose you have a problem with your car, and I'm a chemical engineer. There are certainly chemicals in your car. Does that mean that I should fix it?" (EN: Given that level of snottiness and condescension, is it any wonder he's got a bad relationship?)
The various organizational and procedural measures have limited ability to be effective if there is not an "honest, simple agreement" in place at the beginning. Remember, too, that IT people like to hack things, and can be just as inventive at subverting organizational rules and processes to get what they want from the system. Collaboration is an attitude that cannot be forced.
There's also the suggestion that IT employees need to learn social networking, in the analog sense. What is said across the table in a formal meeting is part of the story, and you have to establish individual relationships and listen to informal connections to learn the rest of the story.
In extreme cases, hiring a third-party project manager can be useful: this person is a newcomer and does not carry the baggage of past relationships, and may find it easier to establish positive relationships because he is not starting in the hole. Such a person may still seem to be aligned with the side that selected and hired him, but that is less to his detriment than being a long-standing member of one camp or the other.
Another contributing factor is that the right people are often not involved in the decision: project coordination is delegated to lesser mortals and the executives in other parts of the business get information through channels and out of date. Having them in the room, or at least ensuring they are briefed routinely, helps ensure they are aware and participating.
Once CIO has taken the extreme position of completely abolishing governance structures. They were originally put into place because technology is expensive and CEOs think a committee is the best way to keep an eye on it. But given that technology expenditures are watched by the various departments whose budgets pay them, they are often a redundant measure that is obstructive in their very existence.
Let the Business Lead
It's suggested that when large programs are led entirely by IT, they are almost certain to fail. Ultimately, it is not the quality of a technical solution, but its adoption and use by the business that creates value.
One CIO speaks of delivering a major project related to CRM: they wrote thorough requirements, delivered it on time and budget, and provided excellent capabilities. And then, it got "something like a two percent adoption rate." It turns out all that the VP of sales operations wanted was a tool that enabled his subordinates to enter sales information to be rolled up into a report. The CRM was complete overkill because IT delivered what it thought the business ought to want, rather than what they really needed. Which is to say, the business need was completely ignored.
To go a step further, consider that the "choosers" of a system are often not the users of it. So whether it is an IT or business manager, it is likely that the solution will not be appropriate to the needs of the users because their input was never considered in the requirements process.
Another fine example of CIO attitude is comparing getting businesses to lead a project is "like getting my daughters to do the laundry ... they won't lift a finger." (EN: Again, the condescending attitude of IT who characterizes their business partners as bratty children shows a consummate lack of respect and a failure to consider whether their own behavior might be to blame.)
Unfortunately, businesses do not often send their best people to work with the IT department. "The business will give you a mediocre but reliable person who has never rocked any boats," or it may be that the least productive and competent of their staff are sent to work with IT because their absence will not impact the business operations. Your challenge is in finding a way to influence this decision to get a strong player from the business team.
In addition to getting a strong business leader, who is respected by their colleagues and "plugged into the user base," that person will need to be supported rather than subverted. Also, you have to resign yourself to the fact that they, rather than the IT department, will likely get most of the credit when the project is a success. When the business hires you to build a mobile application that results in a huge bump in sales, you shouldn't expect to be featured in the company newsletter for having built it - especially if the entire thing was their idea, and all you did was build it.
And likely, that's the nature of the job you accepted: the secretary who types a letter is not its author, nor is the technology department who implemented a solution an innovator. There are very limited situations in which you can rightly claim to have been more than a sidekick.
Lead the Business
The author comes out with a condescending metaphor of her own: that working with business partners is likened to parenting a teenager: "When is it best that you drive the car and when do you allow your new teenage driver to take the wheel?" (EN: Aside of condescending, this also completely ignores the balance of power - the business owns the car, and has been driving it for decades or centuries before IT wanted to take over the wheel. If there's any paternalism, anyone "letting" someone else drive, the business is in the position of power, and IT would do well to remember that.)
One CIO comments that he feels "my job is to lead my IT organization in teaching business leaders ... we educate them ... it is our responsibility to teach while we are executing and to bring the business along." (EN: Ditto.)
One of them actually seems to understand her role, from a personal experience in which she hired an architect to help remodel her house. "I couldn't just hand him a page ripped out of a magazine" but needed to describe to hum what she wanted so he could build it. Then, in working with the general contractor, she had occasions where things didn't go as planned, and "he had to pause and explain the problem to me and we had to talk through options."
Another issue is that CIOs have a bias for action - they want to meet deadlines and have the appearance of turning work out quickly. Unfortunately, this often pits them in the position of dragging their business partners forward faster than they care to move and, ultimately, to earn a reputation for doing bad work quickly. Not only should the IT department slow down, but it should also refuse to start work until leaders from the relevant parts of the business are assigned and engaged.
Another issue is transparency in charging the business for IT. The author suggests that one of the most common complaints from the business is that IT is an enormous expense, but they never see where the money goes. The technology department is "a black box that no one can understand," and as such they have a hard time accepting that their money is being well spent. Trust in the relationship, and a willingness to partner rather than contend, depend on greater transparency.
A common approach to costing is a service model: the IT department has only a small budget, but draws revenue by being "paid" from other budgets, with each department paying for the services. In these instances, it is especially important to be transparent in communicating prices and charges for services. One IT executive suggests that their services to business are communicated via a rate card that fits on one sheet of paper, clearly indicating the cost of services. In such instances, it is also important to benchmark internal costs against external costs to give business a sense that they are getting good value.