When IT professionals … heck, let’s not limit this to the land of IT; when professionals of any and all stripes hear someone say “All you gotta do,” we cringe.
My co-author Dave Kaiser and I decided to do more than cringe. We wrote There’s No Such Thing as an IT Project as a counterbalance to a particularly unfortunate branch of the all-you-gotta-do tree.
That’s the branch that focuses on making organizational change happen. Listing offenders would be ungraceful, tedious, and would generate a compendium of titles that would become stale within weeks.
The problem with all-you-gotta-doism is that it doesn’t work but is pernicious: “All you gotta do” books aren’t entirely wrong. They describe something you gotta do. The problem is that they pretend something that’s complex isn’t.
When someone ignores complexity, they compromise their ability to make the complex entity they’re oversimplifying different tomorrow than it was yesterday. And no matter how you look at an organization it’s complicated. You might, for example, look at it from the perspective of:
Business architecture, which consists of five internal dimensions (people, process, technology, structure, and culture) and five external dimensions (customers, products, pricing, marketplace, and messaging). Or …
Business functions, of which there are more than 300, even if you limit your drill-down to three levels, and that count ignores their interconnections: Each business function receives inputs from other business functions and delivers its outputs to yet another group of business functions. One more:
Business model, a description of the levers management can pull and buttons it can push to make profitable sales happen. Even simplistic business models track at least 20 factors and their interconnections.
In Leading IT I made the case that leading isn’t hard the way neurosurgery is hard. It’s hard the way digging a ditch is hard.
In No IT Projects, Dave and I make the case that achieving intentional business change is both — it’s hard because it’s intrinsically complicated and it’s hard because there’s a lot of actual work involved in making it happen.
Much of the hard work is complicated work, too. Dave and I break it down to:
- Culture change
- Changing the conversation between IT and the rest of the business
- Fixing Agile
- Building an operations-level business/IT partnership
- Business change governance
- Establishing IT-led strategy
- A quick look at the seven disciplines needed to make change happen: leadership, business design, technical architecture management, applications support, organizational change management, implementation logistics, and project management.
It’s enough to make your head explode.
Which doesn’t mean it’s impossible. It means business leaders need to approach intentional business change the same way they approach running the company as it is: If they try to stuff into their heads everything that has to happen so the company can sell and deliver products to its customers they’ll fail, and fail with a near-terminal migraine in the process.
That’s why organizations have org charts — or, rather, why organizations organize. The org chart shows how they’re organized; it’s that they’re organized that makes a bunch of people an organization and not an aimless mob.
CEOs put organizations together the way they do specifically because nobody can keep track of everything that has to happen to sell and deliver products, not to mention getting paid for them.
In an effective organization, while nobody can know everything that has to happen, someone knows each thing that has to happen and enough about the rest to, if you’ll forgive the turn of phrase, keep the joint running.
That’s also true for intentional business change: nobody can understand what has to happen in enough detail to make it all happen. But with the right team, organized well and effectively led, someone will know each thing that has to happen, and can recognize when collaboration with another team member is called for. If Dave and I did our job, No IT Projects will help you and your change team put it all together.
Organizational change is both complicated and hard work. Changing an industry is, if not harder, at least more unlikely, and beyond helping business change leaders, that’s what we’re trying to do with this book: Change how an industry … management consulting … approaches everything about the interconnections between IT and the rest of the business.
We recognize we lack access to and influence over most of the buttons and levers needed for success. What we’re hoping is that those leading organizational change … you … and anyone who finds this book useful … also you? … will start the broader conversation.
I’m curious as to where one could see this list of 300 business functions?
Sorry … the version I use is my employer’s proprietary IP.
Very interesting stuff! – BTW what are the 300 functions that every business performs?
You mention that in your book you break down “achieving intentional business change” into seven areas. Some of those sound like they would have to happen for each project, like culture change, and the seven disciplines listed in the last bullet point.
But others sound like they might only have to be addressed once, and then use that established process or relationship for each subsequent project. I’m referring to areas like “fixing Agile” and “building a business ops/IT partnership”.
Is that correct, or does Agile need fixing again for every project? It might be that it could use tweaking for each one…
Or maybe I should just read the book, huh 🙂
Well, sure, you should read the book! Which doesn’t mean I’ll ignore your question until I do.
Think of the book (and the underlying ideas from it) as a set of capabilities the organization has to master to become adept at intentional change. So you only need to fix Agile once for it to be useful for all future change efforts. The same is true of culture, sorta … establish a no-IT-projects-oriented culture (including such niceties as jettisoning the tiresome IT-as-supplier-to-internal-customers perspective … and the changed culture supports every future change effort.
Does that help?
I have another question that’s finally occurred to me after all the talk about “No IT Projects” – i.e., they’re all business-change projects. Does the converse also hold true, that’s there’s no business-change project that doesn’t involve IT?
Very good question. I’d say the converse holds mostly but not universally true. It’s certainly possible to define and accomplish some business changes without needing any new or changed information technology. But in this day and age of pervasive IT, I think the large majority of change efforts can’t happen without some associated information technology.