Bob Sutton has an interesting post on the limits of expertise: I have already told you more than 125% of what I know. As he points out:
I think that those of us who are alleged to have expertise in certain topics can easily fall into this trap as we try to be helpful to others, and rather than stopping and realizing that we are beyond our expertise, we just keep saying more and more about things we know less and less about.
Bob is talking about journalism, but there’s a similar problem with the business-IT relationship. IT often forgets that subject matter experts don’t always have the answers needed; at least, not yet. Sometimes the subject matter experts need time to convert tacit knowledge —knowledge they know but which they can’t write down, or which they even struggle to explain — into a form which we can consume. Or they might even need time among themselves to create the knowledge together.
I’ve seen more than a few projects come unstuck because they didn’t understand that capturing knowledge is a journey you need to take with the business. The team continually returned to the business for more detail — asking for bullet pointed requirements or stories in a format that IT can easily consume — an approach which often fails, even if you have an embedded SME (à la Agile). (How many agile products have burnt out this customer representative with an overwhelming volume of detailed questions which the representative struggles to answer? Or transformation programmes which try to get the business to predict what they’ll need in a couple of years time, only to find out that they couldn’t predict that far into the future.) Sometimes the business just doesn’t know the answer, or can’t communicate it via our IT artefacts. They’ve already told us 125% of what they know.
We need to provide the business with a little help. This might involve iteration — showing them an early version to see “is what you meant”. It might mean deploying initial functionality into production quickly, and then building on the deployed solution. Or it might involve talking about the the things the business cares about — tasks, decisions, and points of variation, in the case of capturing a workflow — so that they can focus on the outcome they are driving too, leaving IT to worrying about how it might be implemented.
Today, we’re focused on leveraging the synergies between business and technology, rather than simply automating existing business processes. New technologies enable new business models which were not possible before. The business can see the opportunities but doesn’t know what’s possible. IT knows what’s possible, but can’t see the opportunities. Companies that understand this blur the line between business and IT, getting the two groups to work together, on the same side of the table, to identify and exploit these synergies. These companies — such as Zappos, P&G and Vanguard — identify and exploit new revenue streams which are unavailable to their peers.
What’s interesting about these companies is that they seem to have realised that building out their IT estate is a journey that IT and business need to take together, rather than a simple matter of IT asking business what they want.
Hi PEG,
The stories you mention need to be developed iteratively and interactively both Top-Down and Bottom-Up. As you say it is a journey and all the stakeholders needs to understand the key stages and outcomes. Unfortunately, requirements long laundry lists and ‘we-do-it-this-way-constraints’ clouds understanding (of change purpose and needed outcomes). These also fuel the125% antipattern to which you refer.
I had recent experience of a business not understanding that capturing knowledge is a journey. The result was a deeper and deeper dive into detail with conflicting views on the destination (business outcomes) and the mode of travel (RFP vendors). This was most evident in the approach to procurement which swung wildly between precisely-spec’d-product & risk-lives-with–buyer approach – or loosely-defined-service & risk-lives-with-supplier. It did seem that the more detail we dealt with, the more ‘requirements’ became a matter of unsubstantiated opinion rather than fact.
My observation is that too much detail too soon, can be a very dangerous and can lead to the sort of bureaucratic over-specification that bogs down any change initiative. This often starts with the buyer’s premise that we need to contract to functional detail to make sure we get what we asked for from the vendor. Sadly, this can end in much wasted time and money and, perhaps worse, damaged relationships and de-motivated staff. To paraphrase a Chinese proverb: Be careful what you ask for – and the detail you go to.
Would business change projects might benefit from seeing the value of well-considered abstraction and follow the principle of requirements simplification?
If your interested in some ideas that are developing this area follow/search the #storyb4br tag on Twitter.
Nigel.
Nice related war story Nigel. That’s kind of where my next post headed. I think part of the problem is that each side of the engagement isn’t thinking about how to make the other successful. From your example, the business is flipping between pushing the risk onto the supplier, or taking the risk on themselves; the focus is on the process, SLAs, and their own risk, forgetting the need for both companies to be successful if the relationship is to work.
This traditional “quality and price” approach used to work when we were buying widgets, but it doesn’t work with the complex products and services that we’re delivering today. I’m not sure simplification can help, as the real problem is the both parties rushed to the solution rather than trying to under what was the problem that they were trying to solve together. The end result, they started making stuff up, as the didn’t and couldn’t know the detail.
The challenge here is to understand what you really need to do.
On simplification: Perhaps I should’ve used ‘De-clutter’. It isn’t always possible to simplify the problem/opportunity, but I do think it is possible to remove unwanted noise during the process of discovery of what’s really needed.
I do also believe it is possible to convey complex information simply. Maps, stories and storyboards help us share complex ideas simply and help us get to what’s really needed.
Simplifying the complex with a map:
http://www.nycsubway.org/img/maps/system_1972.jpg
Agreed. My favorite text on this is Scott McCloud’s Understanding Comics.
Funny you should mention Scott McCloud – I blogged a while back http://servicefab.blogspot.com/2009/03/serious-about-play-and-comics.html after seeing his and Stuart Brown’s TED videos (lined from my blog). Their videos are well worth the time investment IMO.
n.
Go to the source young man, go to the source. The book is always much better than the film 🙂