Don’t be fooled into thinking that you don’t need to do any design when you adopt Agile. Agile development strives to deliver business value early and often, focusing on getting working software to market as soon as possible rather than dwelling in documentation and ‘analysis paralysis’. But let’s be clear, “business value” and “working software” are not the same thing. You can quite easily get something into production that fails to generate revenue, decrease costs or whatever other yardstick you use for ‘value’. What differentiates the two of them is design. I don’t mean big up front design that details all the features and provides a concrete spec, I mean a design vision that articulates what the product goals are and a roadmap for getting there. And what is a design vision? A short statement of intent is a good place to start, and soon after a user interface mocked up in pen and ink. It is cheap and easy and helps bridge the path from idea to execution.
One of the problems with IT development is that it is tactical and piecemeal in its approach. Functionality is added in response to competitor or broader market activity. Expect to see an increasing number of brands doing something ‘social’ (and tactical) on the web, but don’t expect these new initiatives to be (strategic) seamlessly integrated into the existing digital channel offering.
This piecemeal approach extends to larger initiatives as well. In refreshing the website or developing new digital channels such as mobile and TV, IT will typically build out features and functionality prioritised upon their perceived individual business value regardless of what the sum value of the proposed release is. (Focusing all your effort of building functionality that delivers to your bottom line will seldom be as successful as you predict if it is not supported by features that meet the customers needs).
So when it comes to thinking about new features and functionality, where’s the best place to start? I’d suggest collaboratively, thinking around the customer. Collaboration is important to ensure that everyone starts with the same vision. It needs to be shared it with the broader audience, the product teams, IT; anyone whose day to life life will be touched by the project when it starts. I’d argue that you cannot start this soon enough. You don’t need to spend time doing analysis, interviewing all stakeholders individually, coming up with a document that is circulated and reviewed and re-written (with all the delays and waste that such a process incurs). Start the process getting all those stakeholders off-site for an afternoon and get the thoughts out on the table.
Commence with a presentation that introduces thinking in terms of customers and customer journeys. The below SlideShare presentation does this for the airline industry, addressing a new customer experience across channels. I acknowledge that it is pretty simple and doesn’t touch on half the ideas that airline executives may have. That is the point, it is just enough to get people thinking about different customer types and their touchpoints without getting bogged down in detail. This is what we want the participants of the off-site to share.
Once we’ve been through the presentation we break out into small groups a, each taking an individual customer (or persona) and build up a story; a day in the life of… (It is important not to forget the internal users of the system). These breakouts last 15-20 minutes with ten minutes for the team to play back their findings. As they build out a richer picture of the customer interactions they are asked to sketch out what the user interfaces may look like. The process is rapid, intense and iterative, but always focussing upon the customer journey; how will the customer realise their goals. When the teams tell their stories an analyst captures the essence of the requirements on index cards. The final exercise is to lay all these cards on the table and ask the team to group them into similar areas then prioritise them according to their perceived importance. In an afternoon you will have achieved four things. Firstly, you will have captured a vision for the new product in less than a day, with all stakeholders understanding not only the vision itself, but also the process that developed it and the concerns and issues that different parts of the business have with it. Secondly you will have an initial prioritised roadmap for its development. This will change, but it is a good strawman to circulate. Thirdly you will have introduced all the stakeholders together – projects succeed or fail based upon the strength of relationships and getting people engaged from the start will go a long way to creating shared ownership. And finally you will have generated energy, engagement and traction; to do the business case and to get the project started, recognising that just one part of the business having a vision is not going to bring it to the life that they dream.
“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.
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
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
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”.
One of the things that bugs me in IT development is that the business is too often referred to as “the customer”. “Customer” implies a transactional relationship. A customer purchases from a seller; there is little incentive for any meaningful relationship as it will ultimately come down to price. The buyer wants to pay as little as possible, the seller wants to charge as much as possible.
All to often IT is seen as a cost centre rather than a driver of business innovation and profit. Maintaining the transactional language to describe the relationship between IT and the business helps perpetuate this. We need to stop thinking of the Business as our customer. Instead of “customer” we should look to other professional services for our metaphor.
Professions that involve a more personal, relationship driven approach to their business use “client” rather than “customer”. Whilst retail banking has customers, wealth management talks about clients. I think it is a subtle but important difference. The relationship between IT and the business should not be seen as transactional, it is more consultative in its approach. Structuring our relationship as consultant-client is a small but important first step to redressing the perception of IT as a commodity.
It’s budgeting time with many organisations putting together their budets for 2009. In the current climate IT is an easy target for cutting costs. Stories such as “no new non-core projects till 2010” and “no project that can’t demonstrate a postive ROI in 12 months” are abound. There is a risk that only focusing upon projects that keep the lights on will do longer term damage to the company. Seth Godin writes:
Wealth is created by productivity. Productive communities generate more of value.
Productivity comes from innovation.
Innovation comes from investment and change.
Annual budgeting cycles combined with inflexible development approaches preclude real innovation. It is hard to justify any cost, especially untested products that brings a burden of risk to the organisation.
There are two solutions that go hand in hand. Agile software development enables IT to release value from production earlier and more often than waterfall development. Rather than significant sunk cost in risky product innovation, it removes waste from the process and focuses upon delivery of working software that is of value to the business, taking the product to market at the earliest possible time.
This is a challenge to the annual budgeting charade where line item projects compete for guessed amounts in return for notional value. (IT put crude guesses – not even estimates- against even cruder descriptions of required features from the business). A better model would be to take that of the venture capitalist, with different rounds of funding. Rather than allocating specific funds to specific projects, far better to ring fence budget for ‘product innovation’. Within this pool of cash projects compete with each other with a pitch for seed funding. Those that are successful go straight into agile development with sufficient funding for a first release (say three to four months). Getting to production (and to market- internal or external) will validate further funding or equally enable the business to make an informed decision and kill the idea – fail fast, fast cheap.
Recently I was told of a Blue Chip company whose IT organisation, in the guise of cost cutting, has recently disbanded its QA function. From now on, testing will be conducted by the developers themselves. Since when have developers relished the role of testing? It is inevitable that this cost cutting solution will end up costing the organisation more than it saves.
At the end of last summer I was working with a bank on their on-line retail banking strategy. During a workshop with representatives from their mortgage business they made it clear that they saw the biggest sector for growth in 2008 was the buy-to-let market. I left the workshop shaking my head, were they not reading the same newspapers I was? Even then I didn’t need a crystal ball to tell them that they were putting their eggs into the wrong basket.
Clearing out old paperwork, I came across a document describing the technology strategy for a blue chip organisation that I’d worked with in the past.
There is a guiding principle that is being applied to product technology selection that says we do not follow a ‘best-of-breed’ approach, but rather select a major technology leader (IBM) and ride their product development cycle. This means we explicitly seek and accept the “80% solution” rather than trying to optimise for each and every possible requirement. [We are] emphatic on this point. What this means in practice is that, following the selection of IBM WebSphere Application Server… add-on functionality should be sought from the IBM WebSphere family of products first. Shortcomings will be made explicit in order that we can escalate with IBM, and influence their product strategy.
No rationale was given for their preference for going with a single vendor rather than a best of breed solution, but talk to developers who have used best of breed products and the above mentioned vendor product and they will almost certainly come down on the side of the “best of breed” (that is why they are best).
During the dot-com boom I worked with bank who were developing a WAP mobile banking platform. Trouble was it could only be accessed via a Nokia 7110 (the first mobile phone with a WAP browser), the experience sucked – “Worthless Application Protocol” and the market penetration was never going to reach beyond the most hard-core (and GUI-patient) of early adopters.
At the time the same bank was intent on closing as many branches as possible – branch banking was considered unprofitable; on-line was the way forward… yet several years later I was back in the same bank helping them with their in-branch customer experience.
We all must have examples of times when we have shaken our heads and asked of others do they really know what do are doing? Whose interests are their decisions in aid of? You may not be able to do anything proactive about it at the time, but the question is, what can you learn from these encounters and how can you use them to teach others in the future.
In the current market conditions the easy and obvious thing to do when turning to cost cutting is to wield the knife heavily on IT. New projects get culled, recruitment freezes and contractors get laid off as IT spend shrinks. This is a knee-jerk reaction and rarely in the long term interests of the oganisation. Surely the current market downturn should be seen as an opportunity to invest in IT, use the slack period to improve processes when they are not stressed, and get ready for the upswing when the economy turns.
We recently completed writing a response to an RFP. It weighed in at just under 100 pages with almost 34,000 words. OK, so there was a lot of copying and pasting going on, but that is not an insignificant amount of effort. Multiply that by the number of suppliers who were invited to respond; add the time taken for the client to produce the RFP itself, then review responses and answer questions and it is clear that RFPs consumes a lot of everybody’s time. With the winner taking all, that is a lot of wasted effort. But hold! That is only the first stage! The list of suppliers is whittled down and a beauty parade follows. Yet more effort is spent by two or three vendors turning their word document into a bunch of PowerPoint slides. A favoured supplier is identified and a process of negotiation follows, based upon estimates and what little information the supplier knows. Finally the supplier is selected, inevitably their are surprises on both sides when the engagement starts.
So the RFP process is a standard (but inefficient) way of doing business. What if it was done a different way?
One of the more significant decisions you make in your life (if you have children) is where you will send them to school. It is not a decision you make lightly as it will have a major influence on how your child grows up in the world. In the UK the government provides data (league tables) but this can only tell you so much; there is more to education that the statistics tell (which are historical and do not necessarily reflect the current reality your child is going to face). You will probably ask around – seek the wisdom of the crowd. Undoubtedly the community can identify good schools and bad schools. But the best judge of a school is to go there, to look around, to meet the teachers, to see the children. Do you trust the leadership of the head? Would you be happy for this person to teach your child, would you like your child to play in this playground, (and more importantly) grow up with these children?
So why not apply this thinking when looking for a supplier to build you an application? At the end of the day, projects succeed on personalities and relationships. Will the vendor get on with the buyer? The RFP tells you little about that. What if the RFP process was like seeking a school for your child? What if you had a project open day where you welcomed suppliers in, got to meet them, and maybe even got them to compete against each other.
What if you had three intense days when the business, IT and prospective invited suppliers come together to define the project and complete against each other in teams to come up with the “best” solution.
What if you provide the suppliers with details of what you are looking to achieve and request a basic qualifier – company details, profitability etc (the stuff that goes on every RFP) and a list of clients they have built similar products for (not exceeding one page of A4 per client). And for costings you ask them to provide you with their proposed rate card.
What if you then invite all suppliers to a large venue with a space for everyone to gather, and break out areas for the individual suppliers to work in. You start with background and presentations from the business and from IT. You tell the story of what you want, the vision, a description of the current technology, constraints, assumptions, known risks, integration points, etc. You provide some initial direction as a large group, but then breakout into supplier teams, interspersing each team with your people – from IT and the business. You provide technology (access to your systems, whatever is needed) and domain expertise. What happens next is up to the suppliers. They then have two days to impress.
What if at the end of each day each supplier presents their output to the whole group. The following morning you outline what you like of the outputs and ask the teams to take that as input to work on. Then at the end of the last day each vendor puts in an anonymous sealed envelope with their estimate (resources required to build the application). Can this triangulation technique be any less accurate than the estimate given on the back of several pages specification in an RPP?
If we accept that IT projects are about people, implemented by people, then the benefit of this approach is that you get to work with the supplier and experience the relationship first hand, rather than through documents and practiced PowerPoint presentations. And for the supplier it reduces the time taken to respond and will be more enjoyable for those involved. After all, don’t people prefer to do rather than write about what they do?
The usual approach for a Business Analyst is to start with the ‘as is’ situation and then model a ‘to be’ solution. In understanding a problem, defining the as-is situation can take a number of weeks if not months. Once the current technology, process and working practice are understood, the BA begins to define the solution. Inevitably this solution is based upon what has been learned during the as-is analysis, thus the majority of their time is spent dwelling in the current reality rather than what could be.
Where is the value in that? Where is the value in modelling a solution that is based upon that the current way of working? What can you really learn about the business intent from the current as-is process? A process that is based upon technical decisions, practical constraints and inherent complexity that were made at the time the software was built (in the enterprise world that was an average of 7.2 years ago), and hasn’t technology moved on since then? By specifiying a system in terms of the curent reality the BA is missing a trick, and in the process is failing to add the value that the developement opportunity offers. Indeed the BA is probably destroying value with over complex specifications that do not get down to the heart of the business need.
If Business analysts really want to create value, rather than dwelling in the past they should start with the “to-be” vision. What are the desired outcomes of the application? What should it do? (Not how should it do it). Challenge existing assumptions, ignore perceived limitations and start with ‘blue-sky’ thinking. What would we really like the application to do? What are the customer / user goals and how can the application most eficiently (and delightfully) achieve these. Think about the what, not the how. Unlike the usual pattern of analysis, spend most of the time in the ‘to be’ world, only visiting the as-is to ask questions and confirm assumptions.
But that is only the first step of the BA creating value rather than destroying it. Why not go further and question the fundamental business model. Rather than replace an old system with a new one, is it possible to reinvent the business itself?
Let’s take an example. The client’s core business was data. They supplied that data to their customers through an old and cumbersome desktop application. They employed a service team to visit customers and install the system. Data updates were sent via CD-ROM. Their initial requirement was to maintain the desktop application. The steer was to rebuild its functionality in an updated architecture (only one person in the company really understood how it worked, so updates were infrequent and key-man depecncy was a real concern to the business) develop a new local database and provide the ability to download batch data updates via the web.
The business analysis could easily capture requirements based upon this vision, yet they would be doing the client a diservice. It would be possible to design and build a new desk-top aplication that woud be installed by the service team. The technology would be better, database querries would be faster and customer attrtion would be slowed. But it would be missing a trick. The desktop application that IT wanted to rebuild was not where the value was. The value was in the data.
Understanding what clients actually wanted and how they used the data (they used the desktop application to mine the data then copied and pasted into excel) it was possible to begin to challenge the existing assumptions. The desktop app had charting and graphing functionality – why rebuild that when Microsoft do rather a good job of that with a product called Excel. The requirements slowly changed into the ability for clients to pull data into excel via a web service. It now would be possible to charge for data usage enabling creative new packages to be offered to different customers. Previously customers had requested for changes to calculations and models to be implemented on updates for the desktop application. Now the business started thinking about building a community where customers could create and share excel models and calculations on community website. IT was helping the business create new value, setting aside the current reality and entering a domain of new possibilities.
The business analyst moved on from being a requirements taker to a change agent. This was possible only with the mind-shift away from paying lip-service to the way the current application worked and thinking in terms of what and what if.
I’m a strong proponent of engaging the customer in all stages of the design process. But sometimes you need to be careful with what they say and not always believe their first answer.
Ask the customer “what do you want” and the chances are you will get an answer that is rooted in their experiences and expectations. Not what they really want.
“I want an intranet portal“.
No, you don’t. You want a place where your employees can share files and documents.
“I want a google search appliance“.
No you don’t. You want to be able to find documents quickly and efficiently.
Worse is when vendors try and force products onto the customer…
“You want an integrated BI toolset“.
No they don’t. What they really want is to be able to pull some specific data from a legacy application into an excel spreadsheet and insert a graph into a word document.
OK, so it is easy to say that, but how to follow though? How do you actually get the customer to create a vision of what they really want? Well I’d start by not asking them that question. Get them to articulate what their goals are. Then try to understand in what context they will try to accomplish those goals? Think in terms of customer journeys and value outcomes over features. Think about the what, not the how. Start with the “to-be” vision rather than dwelling in the “as-is” quagmire, indeed use a system obituary to kill the as-is thinking. Use visual tools to model your ideas. And don’t get bogged down in detail.
I’ll write more about this in the future…