dancingmango

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?

Documents, or rather words are the scourge of product design.  Because words can never convey the true meaning or emotion of what is really required.  All to often, software development projects are driven by the documentation - agile projects can be equally guilty of this- driven by words on paper (or card) that convey what the requirement is.  Issue #1. Developers don’t read!

Except for a few exceptions, software is all about a user interacting with a system in order to accomplish a goal.  Trying to describe that premise in terms of features and functionality is fundamentally flawed as it will be nested in the language of technical implementation, not in the user interaction.  “Find” becomes “search”, “buy” becomes “shopping cart”, “check” becomes “validation” and so on.  Issue #2. The desired outcomes become lost in a smog of technical jargon.   

Solution: Picture Driven Design.  Up front.  Yeah!  I’m all for up front design!  A picture tells a thousand words.  It has the power to remove ambiguities, clarify the vision, showing what the journey to realise outcomes look like.  Start with a day in the life of…  scribble out the flow, the user journey.  Nothing complicated, boxes and arrows.  Then scribble out what the user interface might look like.  Done.  That’s your up front design.  That’s your documentation.  That’s your scope.  What you do next is up to you, write loads of documents that describe it and produce the software in a waterfall way if you want.  I’d prefer you were more lean and adopted agile practices, but whatever you do, start with the picture.  I’m convinced it will save much pain later on.

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…

So you’ve run a workshop and generated ideas. There’s a list of points on the flipchart and diagrams on the whiteboard. What now? Write it all up in Word or commit the drawings to PowerPoint?

Stop! Ask yourself why you are doing this? Is it just to record the ideas, to socialise back to the group involved in the workshop? Creating PowerPoint slides is not always an inconsiderable effort. It takes time. That effort is waste.

Think of the purpose of what you are doing. Then take photographs of the flipcharts and whiteboard diagrams, paste them into PowerPoint, and think of how much time and effort you have just saved.

All too often the business thinks in terms of the “how” rather than the “what”. But why should they care how something is to be implemented? Why doesn’t the business state their requirements in terms of their desired outcomes? What is it that they want? Then, and only then should anybody think about the “how”.

Sadly, focusing upon the how rather than the what is a driving factor behind so much of the mediocrity in enterprise software. Rather than stating “what” (they want) in terms of their dreams and aspirations, the business express their requirements in terms of what they perceive IT can deliver. “What” could never be the design quality of Apple (visionary) because they believe the “how” (their IT team) is not Apple (mediocre). But wouldn’t your average developer rather be building something visionary than something mediocre?

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).

So the sensitive personal details of 25m people has been lost and there is a huge political furore over it.  Whose fault is it?  As far as I can see, (and this is my personal opinion,) blame must lie with IT, specifically the IT contractor and either the contract they work with or the perception of that contract.

The National Audit Office asked HM Customs and Excise for child benefit in “desensitized form”.  Sensitive details were specifically asked to be removed, ostensibly to make the file size smaller.  This would require a bespoke query to be run.  It was deemed too costly so it was assumed that a full extract of the data would do.  The fact that this was then burned to a CD, posted unregistered mail and lost is not the point (that is stupidity).  What is the point is the IT contract prohibits the business (in this case the governmental offices) to do their job properly.

What sort of contract demands extra payment for a simple database query for “NI numbers, child benefit numbers and children’s names in order to select a risk-based sample of cases to audit as part of anti-fraud work“?

Surely this is an extra request that an experienced database analyst could easily run in the course of a day?  If not you must ask why not - is it because the database is badly designed with nested tables and stored procedures and stuff that would make a decent DBA go eugchhh (I’ve seen that happen).  If this is the case, the IT contractor has done a bad job; if an electrician worked in your house and left a mess of an electrical installation, would you keep employing them, even if they were cheap?

Maybe however it would not have incurred a cost and this was just the perception;  “we must not… run additional scans/filters that may incur a cost to the department”.  If this was case it suggests a breakdown in the relationship between the business and IT, with tendency towards the  confrontational and transactional rather than co-operation and partnership.

Organisations that outsource their IT often fail to realise what the true costs are.  Anything outside the terms of the contract is a change request.  It is not unusual for the request itself to incur a cost (someone has to write the documentation, specifiy the design, estimate the effort) before a line of code is written.  (At one organisation I worked with that had outsourced their IT function, I was told that to add some basic client-side field validation to a single field on an application form on their website was likely to cost in the region of £60k).  The business starts to believe that everything costs and IT becomes a hindrance and a vicious cycle commences.

How could things have worked differently?  Let’s say the HMRC IT department was run on more lean/ agile lines.  With agile it embraces change.  The request comes in (let’s assume such requests are not regular occurances) and in the morning stand-up the BA describes the request and asks the developers for its feasibility in a word.  Someone says “yes, I ran a simiar querry last month, it’ll take me ten minutes”.  (In reality double or treble that estimate), but it will not have an imact on the developers ability to get thier prioritised work completed.  Alternatively the developers say “given the database structure we have inherited that’s a  lot of effort” or the project manager says “another request?!  pritoritise it like the others!” and it is prioritised in the weekly iteration planning meeting (pushing something else out) and then it gets done.

My hope is that when the inevitable investigation takes place, they don’t just look at the policies and procedures, but also at the underlying structure of the way that IT is managed.

Call it a pattern, a heuristic or a rule of thumb. A fundamental one of those to ensuring usability is consistency. This may be external consistency - for something behaves in the software in a similar way elsewhere. A good example might be the ‘x’ button in the top right hand side of an open window. It is universally a call to action to close the window. If the designer created a button labelled “C”, and placed it on the left hand side this would result in confusion. It is not consistent with the users’ expectations from using other applications. The second type of consistency is internal - do things behave in a consistent manner throughout the application? This may be both in behaviours (e.g. buttons with the same titles perform the same action), and in look and feel - a website has a visual identity and coherence, assuring a continuity of experience.

There may be examples of where internal consistency is not possible. For example a brochureware site that uses a third party for fulfilment or payment. Paypal is a good example of this - the user is taken out of the shopping experience and into a paypal experience. This can be successful if there is clear signposting and use of the paypal imagery on the shopping site to assure the user.

So what happens when you have a large, legacy website that you acknowledge to be pretty poor in the usability front and want to introduce new functionality, or want to rebuild it. If you play the consistency card too strongly you may continue to be consistent with the old design and behaviours. This begs the question, is it better to introduce something that is internally inconsistent, but fundamentally better? This becomes even more an issue when you look to rebuilding your site in an incremental fashion.

As an information architect I can help you design your site architecture - the look and feel, navigation structure, user journeys etc., but this will probably be in its entirety. To build this new site will take time, and assumes a “big bang” whereby a completely new site will be (re)launched. Yet there are probably business imperatives to fix specific areas. If we build in an incremental fashion, and take the agile approach of focussing upon delivering business value, we are not going to have a fully redesigned site to go live with. We are probably going to have (for a short while at least), some parts of the site that are new and some that are old.

Going back to my original question, we can either build this to be consistent with the old site, or do something tangentially better. If we do the later it will probably be significantly inconsistent from other parts of the site, or the original parts of the site. It is in this scenario that I am inclined to throw away the consistency pattern. You may have internal inconsistency if you have a clear roadmap to throwing the old and the new functionality / design is proven to be usable, accessible and intuitive. With this the case, the interaction behaviour and visual identity of the new functionality must become the benchmark to which future functionality is consistent with. And you must clearly signpost to the user what is going on; customers will generally be forgiving if they understand that the changes are in their interests.

It sounds clichéd and old hat, but it is true. Truer now than ever before; the web is an enabler for new ideas. It provides you with the tools for disruptive innovation. Sadly for too many organisations it has become a hindrance.

A recurring theme with many organisations is the length of time it takes to take an idea to market. Especially in retail financial services, where you would expect lead times to be short it is not unusual for innovations to take a year to implement. This seems crazy, it’s not as if there is a physical product to manufactured.

So where are the hold ups? More often than not, they are rooted in the organisational structure. Innovative products often cross business boundaries; whilst customers only see the a single brand, different product teams only see what they are responsible for. They have own objectives that often conflict with other parts of the business; gaining agreement and consensus across all parties can often be a time consuming and painful experience that slows and often kills innovation.

Then there is the technology. Changes to systems have to be scheduled (along with every other request). Unproven ideas are put to the back of the queue. The business starts to perceive IT as a hindrance rather than an enabler and lines of conflict are drawn up.

Channel is the next hurdle to cross. Typically a face to face channel or telephony will be easiest, but getting something on the web? Now a new area of the business needs to be involved, the Internet Channel Team who interface between the business and IT. They’ve got to design web pages, get the creative done, produce requirements for technology to build (and schedule into deployment for which the dates are even further into the future), do usability testing… Long lead times are inevitable.

And then, before the innovation sees the light of day, someone new comes in to rationalise the product portfolio, the innovation doesn’t quite fit in with their new priorities and it is quietly ditched. This half hearted attempt at innovation has taken a year, cost in excess of a million and has come to nothing.

There has to be a better way.

There is. Do things at speed. You can start by sticking some amphetamines into ideation phase. Someone’s got an idea; identify who has a vested interest in it succeeding (or failing) and get them into a room to thrash it out. This doesn’t need to take long. Workshops are best limited to 90 minutes at a time (after that people get Blackberry withdrawal symptoms and loose interest). But if all the stakeholders are geographically dispersed, a structured day’s off-site might be the best solution. Avoid letting people dial in or video conference, this is one meeting where people have to be there in physical presence. Also avoid having too many people in the room, especially when forming ideas (there is a trade-off between having the right people and too many people to make the process unmanageable). Start with the users, the customers, the people whose lives will be changed by the idea. Scribble out personas -describe who they are, what their goals are, the perceptions of your company, of technology. Print out pictures of people that represent the personas, rip out photos from magazines, anything to bring them to life. As the idea takes shape, turn it into pictures. Draw out the customer experience. What would the persona do at each stage. Far better to do this than write it down in a document that can be open to interpretation. Illustrate the touch points. What does technology need to do. (Can we be pragmatic and use roller skate implementation rather than getting bogged down in an integration quagmire?)

Now is where it gets interesting. There once was a time when you would need to invest time and money into producing a heavyweight business model and business case for the innovation. You still need a business case, but at this stage it probably doesn’t need to be too robust; make some basic assumptions then test it. All too often business cases are built on flaky assumptions; build something quick, test it and get real data to build your models on. Again, this is about doing things at speed; a couple of weeks after the first workshop there is no reason why a small team of developers can’t be actually building something to bring the idea to life. So the team is using Ruby on Rails to build a proof of concept. There may be disquiet that this doesn’t fit into the current technology stack - doesn’t matter, it is a proof of concept. Six weeks later the proof of concept is done. It is not a static, prototype that demonstrates linear page flows, it is fully featured and fully functional. It can be usability tested (but more likely you were doing that on wire frames alongside the build). What then? In two months you’ve taken your idea and turned it into something tangible.

Why not put it into the market for real. Whilst IT might not want this Ruby “thing” on their stack, that doesn’t mean it isn’t possible and can’t be done. Large organisations have a testing ground of consumers inside a secure environment - their staff. Use them to beta pilot the idea? Friendly customers are delighted to be part of product development - put it out to a small and selected group of customers, and have some smoke and mirrors processes to handle fulfilment. The objective is to prove the viability of the idea, get data to make informed decisions and make your collective mind up quickly. To fail fast or succeed cheaply.