Beware the Cookbook Approach! We hear this, but what does it mean?
Usually, it means the mistake of thinking something complicated can be reduced down to a simple set of steps, like a recipe in a cookbook. I've heard people say that the Scaled Agile Framework is guilty of the cookbook approach, as well as ITIL and other "best practice" guidance. Just follow the steps and success is guaranteed! (Of course, someone has to try to apply the guidance in this way; most bodies of knowledge have some caution against overly simplified approaches.)
The impatient always want a simple, recipe-only cookbook. They don't want to be bothered with principles, let alone history. The trouble is that many of life's interesting and valuable things are complex and no cookbook recipe is guaranteed to deliver success. Knowing principles is what enables creativity. If all you have are recipes, what happens when you don't have the right ingredients?
However, not all cookbooks are created equal. The accompanying image shows two cookbooks with vastly different approaches. The Betty Crocker's Cookbook is primarily a set of recipes. There is almost no discussion of why they work, the background of the food, the various classes of ingredients, the different cooking techniques employed, and so forth. You're left to mechanically follow the recipes (which is sometimes all you need).
The Joy of Cooking, in contrast, is grounded in fundamentals. Before a single recipe is given, it provides context on the food, its history, the various preparation techniques, quality criteria, even nutrition and just a little chemistry where appropriate. As the book focuses on principle and technique, you come away less limited to the precise recipes provided - the book also gives you the tools to adapt them.
As digital transformation accelerates, we need more, not less, attention to the principles and factors that gave rise to it and continue to drive it. That is what I have attempted to do in Managing Digital: Concepts and Techniques. It's intended to orient the student, or the mid-career professional, to the new digital economy. Rather than prescriptive guidance, it brings forward why things work the way they do. Why does Scrum work? What were its creators thinking when they invented it? Why is scaling hard? What influences led to the Scaled Agile Framework? Where does this idea of "governance" come from, and why won't it go away?
I'm especially proud of the book's evolutionary approach. Traditional approaches leave the student asking "but when and why did Operations become a solution to a problem? (Or Product Management, or Project Management, or what have you...). Education starts with respecting the student's journey, and I have found that dropping them cold into enterprise-scale discussions doesn't work. I am interested in talking with anyone thinking along similar lines.
Whether you're learning haute cuisine or high technology, understanding the principles is important. In learning digital, we can illustrate these principles effectively by thinking about how organizations grow.
I am teaching entry-level IT students at a Masters' level that ITIL and PMBOK (more generally, IT service management and project management) are often unnecessary and sometimes harmful. I have incorporated these perspectives into my survey text for digital management.
It's easy to find criticism of these delivery models, especially from Agile folks, but this criticism is often emotional and anecdotal and not helpful in terms of teaching. There is a legitimate question of "are we throwing out the baby with the bathwater"? The real question with these frameworks is, why do they exist? What are they trying to achieve? If we don't understand that, we'll continue struggling with these debates in the digital industry.
The first thing to understand with both IT service management and project management is that they are combinations of more fundamental practices and concerns:
One of my goals in designing a new survey textbook was to "drink my own champagne." I've been an architect and concerned with systems and service design in many forms. An educational experience is a service, requiring design. My first book, Architecture and Patterns for IT, was not providing the right experience. In thinking about a third version, I knew I had the problem of narrative, of learning progression. What was the right order of the material for my students?
I examined a lot of textbooks, and also drew on my knowledge of industry standards. I perceived two major narratives in these bodies of knowledge:
The "Stack" is how we teach technical topics. Algebra and trig before calculus; algorithms and data structures before applications. We also see it in architecture: business, data, applications, technology. The "Lifecycle" is how we structure guidance: plan, build, run. (It's also influential in software engineering programs, as distinct from computer science).
I wrote this book for my students at the University of St. Thomas in St. Paul, Minnesota, where I am teaching my graduate IT management survey course (SEIS664, IT Delivery) for the 7th semester in a row. I'd tried using my first book but found that the order of the material wasn't well suited for classroom use. St. Thomas is a teaching college and caters to students of all backgrounds, including those with no previous experience, those with non-technical undergraduate degrees, and those wanting to change careers. I have to educate a diverse student body, in terms of age, nationality, professional experience, and gender.
Flying back from the IT Service Management Forum meeting in Oslo (where I was honored to give an AM keynote), I watched The Intern. It stars Robert De Niro as Ben, a 70-year old widowed retiree whose boredom leads him to a job as a “senior intern” at an online fashion startup. The company has all the accoutrements: digital culture, an office masseuse, and a 24-year old CEO (Anne Hathaway as Jules) who rides a bike through the office.
It’s a charming, grown-up movie, easy to watch. At first I dreaded there would be a bunch of cheap age-related humor at Ben's expense. But he’s a savvy and emotionally intelligent dude with many years of business, and human, experience. He pays attention and doesn’t commit stupid faux pas. He is adaptable. He goes from a feature to a smart phone, updates his computer skills, and gets on Facebook.
And, as the movie progresses it’s clear that the important things are timeless, as in a scene where Ben takes pains to make someone else look good. It’s worth seeing the movie just for that short study in leadership.
Watching this account of generational contrast, leads me to this blog. As I look out across the digitally transforming landscape, I see millions of Bens, with the difference being they are in no position to retire. I also see underemployed millennials looking to get a foothold in the new digital economy, one of the bright spots in today’s job market.
And I see a large and complex educational system intended to help people of all ages develop the appropriate skills and capabilities to participate in this economy. We all pay for this system, through federal and state taxes, and tax revenues foregone in support of non-profit institutions.
I've been spending some time lately looking into the state of IT education. This system is more like Ben than Jules - it is also in need of some updates.
In January 2014, as an AT&T executive assigned to Target, I made the case I should attend the National Retail Federation’s big party (ahem, convention) in New York, at the Javits Center. I re-connected with the Association for Retail Technology Standards, and was envious of the success they’d achieved: a large booth on prime expo floor real estate, in the center of the action at the Javits Center, with satellite booths from Oracle and Teradata and others (who had their own big pavilions).
This shows the success of the ARTS leadership in promoting their standard as the basis of interoperability in the retail space. I’ve seen the ARTS data model; it’s enormous and comprehensive and continues to expand its reach as the basis for retail architecture. (My old boss at Target was a participant, as long ago as 2000. These things do take time.)
The governance model
This brings us to the governance question: how is the standard created and maintained?
Disclaimer: this post represents my personal views only.
Let’s confront some of the harder frequently asked questions about IT4IT.
"IT for the sake of IT”?
“Oh, you want IT for the sake of IT? What about IT for The Business?” is one initial reaction we hear.
Of course, the business is represented in IT4IT. The IT4IT architecture reflects throughout the fundamental business drivers that give rise to the need for IT services. One sees Portfolio and Demand, going on to Requirements, Service Level, Request, and so forth.
Like ALL brands, IT4IT™ has its limitations. In all honesty, we went round and round on the brand. My initial domain name ERP4IT had influenced the IT4IT choice, but would have been even more problematic.
Disclaimer: this post represents my personal views only.
I was in Edinburgh, Scotland this October for the official launch of the IT4IT standard by The Open Group. As a followup, I attended the HDI/IT Service Management Fusion conference in New Orleans a couple weeks later, where the Open Group booth had a constant flow of traffic.
As I watched Mary Jarrett of Shell's keynote on the IT4IT journey, I reflected that in some ways, this was the culmination of a journey I started with this blog, 12 years ago this fall.
I had begun with an initial interest in “ERP for IT.” However, this has never been a blog about ERP systems; rather, it started off questioning the lack of such systems for the domain of large-scale IT management. In other words, why was IT the barefoot cobbler's child in automating itself?
There's been a lot of water under the bridge since then, and as I deepened my understanding of the problems, I rebranded the blog as lean4it. But the premise continues: IT remains under-managed relative to peer functions, relying on emails, texts, spreadsheets, word of mouth and gut feel as opposed to data-driven systems.
And solving IT management problems has never been more pressing. Why? Two words: