Nature doesn’t like a vacuum. It rushes to fill the void. Silences are similar. They are uncomfortable. They urge someone to break them. A good negotiator, a good sales person, a good facilitator knows how to handle silence, to feel comfortable with it. The first step is becoming conscious and aware of the silence. The next step is to actively resist the temptation to fill it. And the final step is to enjoy the silence and use it to your advantage.
The Observer magazine has a feature titled “This much I know“. It takes an interview with a celebrity who “share the lessons life has taught them” and distills it down into a number of key statements. There is probably some milage in this as an innovation game to play when you are looking for ideas and insights, hopes and fears from a newly formed team.
Ask team members to write statements “this much I know” on post-it notes with Sharpies (because you can’t write many words like that) and see what you get.
For structure you may consider using different coloured post-its to represent PEST themes: Political, Social, Environmental and Technical, or how about CRIT:
So for example…
Acme.com recently redesigned their website. The forums and twitter were full of positive comments (C)
People will pay for content. It’s just got to be priced right, relevant and timely to them and easy to pay (R)
Getting things done here is a nightmare. The process to get approval for any new project is designed to be hard (I)
We’ve got problems with our CMS. Our license is due to expire and the vendor is trying to get us to upgrade. We don’t know what to do (T)
Getting these ideas on the wall will help participants articulate their thoughts and provide a framework for understanding the current reality and mining for new ideas and opportunities.
Innovation games are a great way of engaging stakeholders, getting them to collaborate and think creatively around solutions to problems. Here are a few I’ve recently used. Introducing a persona helps focus the attention.
What happens if?
Ask participants to construct a back story for the persona. What have they done in the last year. Describe each touch point they have had with your brand or product. Now introduce a crisis moment. Lost a job, got a terminal illness, won the lottery. What happens? How does the experience with each touch point change?
Build a widget
Again, give the group a persona to help focus their attention. Now give them half an hour to build a widget that would solve a problem the persona has. Give them paper, post-its sharpies, coloured pencils. This is agile right. Now present back – They get two minutes to provide the context, pitch the product. Then one minute to demonstrate how the widget works. Open the widget to questions. How will it work….
You’re all crooks
<Insert your industry> are crooks. What new laws would you introduce to clean up their act? (OK, this feels uncomfortable but it may help get people thinking about how consumers perceive the industry and how the customer experience could be improved. For example you are crooks because you hide details in small print, introduce a new law on transparency. What would that mean you would change?)
Kill the sacred cows
Every business has sacred cows or elephants in the room; things that are done because they’ve always been done, not to be challenged, considered immune from criticism or are too risky or dangerous to change. Ask participants to identify these, putting them on post-it notes. Now imagine that they no-longer exist. What could you do now that you couldn’t do when the sacred cows were in place?
Litter bins on the street aren’t the most interesting of objects. The design is pretty standard, with variations on a couple of themes – cylindrical or rectangle and colour being the primary tool of differentiation.
“To throw rubbish in the bin instead of onto the floor shouldn’t really be so hard. Many people still fail to do so. Can we get more people to throw rubbish into the bin, rather than onto the ground”
One answer is to make it more fun. Check out The FunTheory for other ways of improving mundane products by making them fun.
Now think about that mundane product of yours. Maybe it is your on-line retail bank. It is getting tired and it is time for a technology refresh. You’re going through a process of capturing requirements. How about playing an innovation game, but base it on the concept of fun. What could you introduce to your product that would make people smile? What would make people laugh? OK, so after a while the bin would no longer be fun. What makes it fun is the element of surprise. Again, what could you drop into the product that would surprise people. What would a ‘fun’ internet bank look like? Focus on fun and surprise and you might uncover a nugget of inspiration that will make the final product.
Let’s assume that you are not bought into the whole agile thing. That doesn’t mean you can’t look at your IT organisation and identify waste and fat in the process. How long does it take from the business having an idea and requesting IT to build something to the developers actually starting to code?
This seems to be common: The initial ‘idea’ is fed into the PMO team, it is documented with a high level scope, rough business case and napkin estimate of +/- 100%. Elapsed time (i.e. the time from the first email or conversation requesting the requirement through to the initial scope document being circulated and approved): two weeks, value added time (i.e. the time actually spent thinking, doing or deciding); two hours. The project, having gained approval in principle, is then prioritised. Some organisations actively monitor thier project protfolio, others do it annually, with the business having to put in project requests when the budgets are set. Mid-cycle and the project is unlikely to take off.
Let’s assume PMO agree the value of the project, next step is high level design. Analysts capture high level requirements, ascertain what the business really wants and refine the business case further. IT puts some high level estimates against the requirements, with a +/- 80% confidence. Elapsed time: eight weeks. Value added time two weeks. With a refined business case to take to PMO or the steering commitee all that has changed now is that we have some more detail and a guess on what it might cost. We are ten weeks down the road and we still have not made a decision whether the project will commence. This due dilligence is notionally about reducing risk and keeping costs in check, but in reality, what value has been added?
Now it is time for detailed design. Another (elapsed time) eight weeks of analysis, drilling down into the requirements. Documentation follows workshops, only now the specification is no longer speaking the language of the business. Use cases, UML, it’s all getting slightly technical and the business are not really sure what they are reviewing. Let’s call it another couple of weeks of actual value that is added.
Eighteen weeks elapsed time, countless meetings, momentum and still no decision on whether project will start, let alone a line of code being written. But the business case is really taking shape and IT have got the estimates down to a 20% confidence limit.
The project gets the go-ahead, but it is not yet time to start coding. Technical design needs to take place, four weeks of architects architecting and documenting the spec. Six months has elapsed (of which maybe a month was actually doing stuff that positively contributed to the success of the delivery) and finally the developers start writing code.
What value did that six months deliver? Requirements, design, business and estimates. Yet we all know that the requirements will change, and with that the business case. The estimates will be way out, but we’ll justify the process of estimation because they would have been right it the requirements hadn’t change during the build…
Knocking the process is easy. What’s the alternative? Start with a burning desire to release something of value at the earliest responsible moment. Get the business in the same room as the analysts and the architects and get them to articulate their vision. Use personas and more importantly scenarios and customer journeys to drive out the business vision. Ask the analyst to capture the business intents on index cards. Lots of whiteboarding, visualisation and pictures to inform the thinking. Don’t dwell on the detail, this is about capturing the intent of the system, what are the desired outcomes that it will deliver, how will it impact the lives of all the people who will touch it. Next step is to prioritise these outcomes. Collate these into the minimum set that would make a coherent and compelling product that you could go to market with. For the business case make basic assumptions on the revenue that this feature set will deliver (or what costs it will save) and ask the architects and developers in the room to do some high level estimates. The whole process should take no more than a week (you could get a first cut done in a couple of days) and there is your initial business case. If we accept that estimates are little better than guesses and things will change anyway, if we have an initial realisable goal that we have demonstrated will deliver value, why not go straight into development. By actually ‘doing’ you will minimise risks that you can only predict on paper, and value will be delivered so much quicker, indeed you should be able to have something to market, generating revenue in the same timescales that you otherwise spent planning and analysing. And if you still want to do waterfall, you’ve got a smaller number of requirements to analyse and design for, again, delivering value sooner.
“For you who have had the experience, no explanation is necessary. For you who have not, none is possible.”
I’m going to attribute that saying to Ram Dass, a Harvard professor who via psychedelic experiences ended up a spiritual teacher in the Eastern Tradition.
The problem with too much software/web design is that it is produced by people who have just not had the experience, or do not see the experience as relevant to their organisation or domain. They just don’t “get it”.
(“For you who have an apple product, no explanation is necessary, for you who have not, none is possible?” Cue “it’s an enterprise application we’re buiding, not a ****ing iPhone”).
If we want to build memorable and compelling products, we need to focus upon the experience. To dwell on the feature list or functional requirements is to build mediocrity. Nothing wrong with mediocrity if you don’t want to delight your customers or increase the performance of your workforce. Without considering experience you will miss innovation and added value.
So how to focus upon experience? Get your team to undertake different tasks to get under the skin of what customers go through.
Telco product?
Spend time in a retail outlet and watch different customers buy phones
Go into all the phone shops on the high street and ask the rep “hello, I want a mobile phone”. Suspend all your knowledge about phones and tariffs. How do they sell?
Leave your blackberry at home for a day (how dies it feel? How does it change what you do?)
Download instruction manuals from different phones from manufacturers websites
Travel product?
Go into a travel agents and ask for a holiday “somewhere hot and cheap in February”
Credit card product?
Ask to borrow money from someone you don’t know (how does it feel?)
Apply for a credit card at another bank
Collect all the Credit Card / loan direct mail and emails that you and you get sent over a week, photo / scan all the credit card advertisements you see in a week
Go into a car sales room and look to buy a car on credit
Supermarket product?
Get behind the till for a day (In the UK, at least a few years ago, all senior executives in both Tesco and Sainsburys spent time in the stores over the Christmas period)
Ask a shop assistant to help you find an obscure product that is not in stock
Go into a store with a shopping list and a single bank note, (no credit cards)
Go to the pharmacy when it is busy and ask to buy the morning after pill
Extend your team
Bring in representatives from completely unrelated parts of the business to participate in brainstorming sessions. Building a “youth” social networking website? Get someone from legal or corporate finance to join in. (Get’s you thinking along the lines of extreme characters – here and here [pdf]). Working on a complex exotic financial instruments? Get a few PAs to join in. You may learn something (that your product is too complicated and even you can’t explain what it really is).
I’m sure you can come up with better exercises. The object is that with this collection of experiences and related emotions new ideas can be brought to the table. They can offer insights from another, different perspective, providing more chance of business innovation being realised. More importantly, if you have an emotional attachment to the product you are building through real experience, you are more likely to build a better product that will fullfil the needs of and goals of the target audience in the way they want. The day your enterprise application team all have iPhones will be the day you start building better enterprise applications. For them, no explanation will be necessary. They’ll just “get it”.
Starting a meeting or workshop with new people will almost certainly commence with introductions. Usually I will ask participants to say not only who they are and what department they are from, but also why they think they are at the meeting. If someone is not sure, or says “because my boss told me to attend” there might be an issue.
Last week I attended a workshop run by a couple of our developers from China. Because paired programming is a fundamental practice to what we do, they asked the participants to do paired introductions. Participants paired, were offered a minute to talk to each other and then introduce their colleague. Because the team already knew each other, they didn’t need the minute to prepare. As each participant introduced his colleague, he emphasised the persons strengths and good points. At the end of the introductions there was a tremendously positive vibe in the room which set the meeting up for success. It might have taken a little longer than just doing the straight introductions, but the value was clear; get people to introduce their colleagues – it breaks the ice, promotes the positive (and as a facilitator gives you another hook by which to remember people).
You’re running a workshop and the group have come up with a bunch of new propositions. You want them to vote on which ones to take forward to the next stage. Or maybe you’ve identified a bunch of functionality and features and you want the group to prioritise what they’d like to see built first. What question you ask the group next is critical to the answer you will get.
You need to frame the question appropriately and make it clear to the group the criteria by which they are making their vote…
Do they need to be thinking about “do-ability”, the ease to implement, or do they need to be focussed upon the innovation and the idea itself. Should they be considering the cost to implement, time to market, return on investment, or should they be thinking about the art of the possible; the “blue sky”; the destination, regardless of the journey to get there.
Which line of thinking they should use will depend upon where you are in the process. Get them thinking about practicalities of implementation too early and you are likely to dilute the vision. Too late in the process and you will have candidate propositions or features that by their complexity or uncertainty will never the light of day.
So two tips. Before you ask the group to vote, or to prioritise, clarify the objectives and the critiera by which they are to decide. Maybe ask them to assume a ‘persona’ and vote in the way they’d expect the persona to vote, for example a customer will have different priorities to a developer. Whose vote is it anyway?
And after they have made their vote make sure you manage the group’s expectations. Don’t let them leave the room thinking what they’ve decided upon is final and binding. It rarely is.
Talking about workshop icebreakers with Prashant and here’s an idea: participants write their own tombstone or obituary. “Here lies Jack. A life spent comparing numbers on an excel spreadsheet”…. You could even use Tombstone Generator to bring them to life:
Hmmmm, maybe not the strongest icebreaker (indeed it could kill your workshop before you’ve even started… If you don’t consider cultural sensitivities you could receive some rather blank looks, if your audience doesn’t have a dry sense of humour or doesn’t “get it” you’ll be in trouble…)
So maybe it won’t work so well with people, but how about systems? If you are looking to understand the current system landscape, why not ask the participants in your workshop to list out all the systems they can think of and ask them to write the inscriptions that would appear on the tombstone.
For example…
+
Customer System RIP
1997-2007
Dearly beloved wife of Position System and bastard child of Excel spreadsheet (1991-date).
Threw tantrums and refused to give the right answers when it really mattered
Grew bloated in size due to unwanted change requests
Lost self worth due to non-business value changes
(Died in the loving hands of Indian Outsourcing Company)
She will not be missed
+
Here Lies Position Reconciliation Spreadsheet
1991-2007
Father of Every Conceivable Problem
A real handful to manage but usually got there in the end
Local resident of Sarah’s Desktop, he never got out much
Prone to occasional lapses of judgement that were rumoured to cost the bank millions
He has gone to a better place (recycle bin)
And why restrict this to the current state. It could be a useful exercise in understanding what benefits a new system could be remembered for…
+
Here lies New System
2007-2017
Saviour of the Back Office
Banished reconciliation breaks to history
Defeated the multi-headed Legacy Dragon, bringing peace and harmony to the Ops team
A single voice of truth
Beautiful to look at, easy to get on with, she gave such joy to customers and added such value to the business
Without her Ops can no longer function
There once was a time that international development was all about big capital projects, building dams and the likes. Times change, now the focus is on eliminating poverty; DFID “focus [their] aid on the poorest countries and those most in need”. There is a realisation that those big projects did very little to address poverty, indeed they kept countries poor forcing them into debt (read Confessions of an Economic Hit Man for a cynical view of this). And besides, dam projects are rarely successful and before you know it they silt up.
A focus on reducing poverty requires a new approach. It requires an understanding of the root problems, it means spending time with the poor to understand their circumstances to be able to create appropriate and sustainable solutions rather than prescribed programmes that develop and maintain a dependency culture.
There are parallels here with the IT industry. Much of the IT game remains focussed upon those big projects. Software dams that can be launched with great fanfare but do little sustainable good to those most in need. The customer.
Before I wound up in IT I worked in international development. My PhD. “Ergonomics tool and methods for use in Industrially Developing Countries” was based on working with farmers in Sub Saharan Africa, looking at how technology is transferred and how it can be made more appropriate, sustainable and usable. Many of the tools and techniques I used in the bush I apply with the corporations I work with today. These came under the umbrella of “Participatory Technology Development” and “Participatory Rural Appraisal”.
Rather than the delivering the white elephants of expensive machinery that you see littered around Africa, Participatory Technology Development is an approach for developing simple low cost innovative solutions that have the ownership of the community who work with researchers to build them. The PTD framework starts with gaining a shared understanding problems and opportunities. This is followed by defining priority problems then experimentation. Experimentation is collaborative with options derived from indigenous knowledge and support from the researchers experience and expertise. The farmers own the experiments and the results. This leads to the next step of the framework; sharing the results with farmer led extension. (Traditionally dissemination of agricultural advice is done by agricultural extension officers – government employees who despite their best intentions preach too the farmers, sharing centrally defined agricultural advice rather than the more appropriate, locally developed technologies that the farming community have developed themselves). The final step to the process is the researchers withdrawing, leaving the community with the capacity to continue the process of change.
(Sounding like agile?)
If PTD is a framework, then PRA is a basket of tools and techniques that can be used to support it. These can be broken down into nine categories:
Are you building a Software Dam? Or are you focussing your aid on those most in need? PTD and PRA are approaches that have developed to help introduce appropriate, sustainable improvements to the life and wellbeing of subsistence farmers. Much of their content can be transferred to IT projects, helping introduce appropriate, sustainable improvements to the life and wellbeing of customers / users.