Why you need to pay attention to customer experience

Why you need to pay attention to customer experience

Next        What to watch out for when researching and testing journeys

 

The chicken and egg question always fascinated me. When it comes to business models I find the same conundrum with customers and profits. Michael Porter once said that the purpose of a business is “to create value for customers”. Although we all assume it was inferred in there, he never bothered to mention profits.
The reality every business faces however it that creating value comes first and monetization follows.

1. Compare the debacle of the great Thatcherite privatisations to the often maligned success story of dot com.
In the UK we have a raft of privatised utilities who still have not “got it”, they still think in terms of Oligopoly, force, bullying, price rigging. They think and act like tax collectors. The total innovation from all of them over two decades could be written on the back of a credit card along with a full list of their happy loyal customers.
Amazon, ebay, Paypal, Google and many more have on the other hand built world beating businesses on the back of profitless customer satisfaction and only now are monetising these business models. They operate at P/Es up to 500 and have no shortage of investors.

The message is clear, the customer is king and until you can demonstrate value to them you don’t have a business model.
“ Sooner or later regardless how much cash you have stashed away, you will learn to create value for customers or fail.” We even see this law apply itself to dictatorships.

2. What is customer value and how can you create it?
The biggest possible blunder any business can make is to quantify customer value in terms of product features. I cringe when I see these neat spreadsheets listing product x competitior1, competitor2 etc and how well they score on each (in the marketing trainees opinion).
Customers buy an experience, even hard nosed corporate customers. That begins with the interaction with “People” in the supplier side, or “friendly” and human like ecommerce site and carries right through to anticipating delivery, opening the package, using it for the first time, bragging to friends, interacting with support and many more. Many of these are remarkably powerful influencers and even though supported at times by product features, most of the time they are a separate source of value, or indeed antagonism.
Next we return to the chicken and the egg.

3. Does customer experience exist without customer value and who foots the bill?
The problem here is thus: If you ask the customer how much extra they would pay for their phone to float up out of the box on a mechanism with a Jingle playing, be fully charged, sense the old phone and offer to copy the contacts and messages etc in a sweet voice, accept a voice answer. The customer might well offer a price that made this simply not feasible. However, when that same customer experiences it once, the likelihood is that she won’t want to be without it and when she hears her friends talking glowingly about it, it becomes a must-have at almost any price. Soon it is talked about and develops a cult status and then we have a brand value to take into account. That’s a whole new ball game.
I’m not suggesting we deliver high quality customer experience at all costs, I’m simply saying that you must understand the true value and what people do is far more revealing than what they say.

The point I’m making here is that sometimes you have to take a small hit to let customers realise what they value before it becomes indispensible to them. Henry Ford would have built a more comfortable horse carriage if he had asked the customer what to do. The distinction in marketing terms is between “True value” (product features) and perceived value ( How the customer sees it)
“There’s more than one way to ask the customer and more than one way to interpret the answer, if you listen with an open mind, sometimes you will be surprised pleasantly.”

4. We can’t have a discussion on customer experience without discussing the brand.
There are many definitions out there of a brand and I’ll leave that to those with little to do, for me the important point is that expectation which a customer carries as a result of the brand. That is what drives her through our door or to our site.
Let’s not gloss over the word “expectation”. Whether you are playing poker, editing movies, or doing magic tricks for your children, you will quickly realise that everyone, and that includes market researchers, sees what they expect to see, hears what they expect to hear and feels what they expect to feel. Most people could probably say yes to that statement glibly, but very few would appreciate the profound power of it.
In a previous blog I described the experiment when scientists used MRI brain scans to identify the increased satisfaction enjoyed by a coke drinker who had poured it from a branded can into a branded glass over that of another drinking it from a plain glass, all in stark contrast to the memorable testimonials of thousands who preferred Pepsi over coke when offered both in unmarked glasses and could only focus on taste.
Expectation is created in many ways, but primarily by the chatter of others and the perceived opinion of peers. That is the territory of Brand managers, Marketing people and Social Media experts.

The key Point here is that creating an expectation associated with your product is the most powerful way to create value for your customers and often the cheapest and mot certain way also.
“Innovation is critical, but don’t confine it to the engineers and inventors, the ultimate playing field is inside the customer’s head”

5. Customer Lifetime Value is not an old, or boring idea it has never been more relevant, or more critical.
One of the first things we tend to look at with a new product is a breakdown of the cost of product, cost of selling it and gross margin. The cost of selling a product usually surprises newcomers to the field.
In competitive markets with a lot of equal offerings a small price advantage can drive large sales increases so price is critical and it is driven primarily by cost. i.e you cant reduce price below a level that is profitable. In most markets price is sensitive and if it isn’t then investors are sensitive to margins, earnings and dividends. In all cases no business can indefinitely carry unnecessary cost and in a competitive market. Sooner or later the competition will do it and steal a march. Of course there are many pricing strategies and this is not a discussion on price
The money you spend on marketing and selling your product is critical to the success of your product, yet it comes under less scrutiny than any other budget apart from the CEOs expense account.
Let’s say you sell 1m units of a product at £100 retail. Your production cost is 20 and your marketing/selling costs are £30 operating costs are £40 and net profit is £10
That’s 100m t/o, 30m spent on selling 40m operating profit and 10m net profit

Suppose you convinced 1% of your customers to recommend the product to a friend
Now your t/o is 101m selling and operating costs stay the same and net profit is 11m.
That’s a ten percent increase in earnings- a darling of the markets if you can repeat it.

Let’s say that you have a Million customers, every customer has to be replaced after 4 years and they pay £1000 a year for your product. That’s t/o of £1b
To maintain that t/o you have find 250,000 new customers at a cost of £1000 each
That’s £250m a year in marketing/selling costs.
Now suppose you are so nice to these customers that they stay for 5 years instead of 4

Now your costs are reduced to £200m a saving of £50m
if your net profits were, for arguments sake, £100m on £1b now they would be increased to 150m a 50% increase in earnings. What would that do for your stock?

These are simplified figures used to demonstrate a point, so lets not get into a investment analysis discussion. The message is clear:
“Treating your customers well enough to retain them a little longer can deliver huge dividends while enlisting them onto your salesforce is the next killer app and make no mistake about it.”
That means paying attention to the user journey long after the “order to pay “ stream has completed.

Requirements engineering strategy can make or break your project .

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists in isolation-what should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

If you’ve been reading my blogs on the subject of requirements, you will no doubt appreciate the level of importance I place on getting requirements right and then testing them before committing yourself to a contract or a technical specification.
Just in case you are thinking that this is in some way anti agile, then nothing could be further from the truth. Please read my blog on agile requirements engineering for a discussion on this topic.

Let’s take this opportunity to recap on why we do requirements. The simple fact is that once a development team start work on creating a technical specification, the till begins to ring up with costs and every time you make a change after this point more costs are added. The closer you are to rollout when you make the change, the greater the extra cost will be and that time phased increase is exponential, therefore the first purpose of requirements engineering is to contain costs and eliminate or reduce slippages.

The second purpose is to make sure that the end product delivers value by meeting the needs of the business precisely in order to meet or exceed the benefits targets set in the business case.

Getting requirements right therefore, is absolutely critical if you are to contain costs and deliver value

Developing a requirements engineering strategy

Each organisation and each project are different and requires a tailor made strategy for getting the requirements right by recognising, exploiting and working with the capabilities of the organisation.

To do this successfully, you will need a few things:

  1. A detailed analysis of the stakeholders involved in the as-is process in order to make interviewing efficient and thorough.
  2. A strong feel for the past experiences of the organisation in terms of successes or failures with software projects in terms of meeting business need and staying within budget and time constraints. This along with some tactful exploration of causes will give a strong steer about the current capabilities of the organisation to engage with a formal requirements process and to take seriously concepts like change control.
  3. A feel for the organisations ability to take on and successfully adapt change will help you decide whether and how far you might decide to upgrade their skills and attitudes to requirement engineering
  4. A good indicative plan that indicates the products to be created, their acceptance criteria, time scales for delivery and the amount of effort that will be needed from stakeholders.
  5. The understanding, agreement and total buy-in of key stakeholders to the proposed approach with full support in terms of making people and facilities available for the process

 

Stakeholder analysis for requirement engineering

Step one

Using RACI to identify stakeholders for the Requirements function.

In my blogs on business case techniques and models I discussed the importance involving the right stakeholders to gain buy-in and get a real picture of what success will look like.
In order to design the system, you will need a different type of stakeholder list, one that describes roles, responsibilities skills and communication. This list will give a clear view of where the knowledge skills and the responsibilities lie within the organisation and therefore point you at the right people to describe requirements and take responsibility for their quality. My favourite tool for achieving this is a well known HR instrument known as the RACI chart. Responsibilities Accountabilities, Consults, Informs and it provides a two dimensional view of a team that helps you quickly analyse the team for adequate skills, supervision, communication and quality control. It can be adjusted in form or emphasis to suit your precise needs, but the fundamental principal serves well in any circumstance straight out of the box.
Here’s an example;

RAACI example

The table above lists nominal roles across the top and Activities down the left, each cell is then marked with one or more of RACI to show who has what role in that activity.
The example is for a software development team, but if you were building a hospital it would list things like planner, builder, architect and activities like approve plans, complete design, etc.

A software project for a builders might involve, Construction director, surveyor, cost controller, quality controller etc and Liaise with clients, agree costs, sign off completion, etc.
Apart from being a huge benefit in helping to highlight the important stakeholders for your requirements process, the RACI chart also provides a quick but effective sanity check to make sure that your team is adequate and that there no duplications, conflicts or gaps.

Horizontal analysis of each task will quickly tell you whether there are sufficient doers and accountability exists and is in the right place.
Vertical analysis of roles will quickly highlight overworked, underworked, misplaced authority or responsibility and lack of or too much consultation and information.
Too much consultation stifles decision making and too little leads to dangerous decisions. Corporate culture can lead to busy bodies who don’t always follow through, or teflon in-trays. All of these issues need to be understood and ideally addressed ahead of system design, because the system will only perform as well as the people who use it.

Once you have created this chart, the next thing is to create a list of names with contact information to place in each of the role areas. If the project is large and/or complex, there may be more than one name in each box and there may be further sifting to do in order to resolve any doubts.
Don’t be surprised to find skeletons in the cupboard and lack of agreement over who does what. If you uncover these issues, now is the time to discuss them at a high level and attempt to get them resolved ahead of requirement gathering.

Step Two
The second step is identify the Actors, the people and systems that carry out tasks as part of this process and the sources of all the skills, knowledge and decisions required to complete the process successfully. This will generally begin with the R people in your RACI chart and will usually expand to people who do the work with or for the R person. E.G. the R may be in your chart as the Technical architects for design, but on investigation, you may find a DBA, a SysAdmin and many others who play key roles and these people also need to be interviewed.
The actual actors may be more usefully broken down to specific skill sets or disciplines as opposed to specific roles. E.G you may have Document writer, Interviewer, modeller all of which are actors within the BA function. This approach gives a slightly more abstract approach that lends itself to reorganising roles for efficiencies, or to adapt to a new system.Never be tempted to accept the assurance that a supervisor can tell you the whole story and you don’t need to talk to her/his charges. If anything this should be seen with an element of suspicion and tactful verification is a good idea.

To better understand and communicate how the various roles influence the outcome of a process, it is sometimes useful to create a fishbone chart adapted slightly for the purpose. Here is how i like to create it:

Stakeholder fishbone chart

The fishbone can be made as complex as you need it to be in order to show all the influences on your new project. The thing that becomes apparent very quickly is that whether they are aware of it or not, most of your stakeholders rely on others for skills, support, knowhow, data, administration and other inputs that can potentially prevent the processes progressing and hence you need to know about it and to resolve, or risk manage it.
Your fishbone chart will immediately tell you who to talk to and by way of a bonus, it will very quickly highlight the areas of influence, both positive and negative when it comes to rolling out.

Organisational culture and requirements process maturity.

Once your target interviewees are lined up, your next step is to hold a number of short interviews and/or an interactive workshop to discuss past projects, how they went and how the organisation reacted at the time and now. Asking them what they felt went well and what went wrong will go a long way towards gauging what will go down well, or will meet with resistance in terms of methodology.
The aim is not to deliver the perfect project, by your standards, but to deliver the best you can within the capabilities and expectation of the clients.

The last critical aspect of this phase is to get a good feel for their favoured mode of communication within this area. Do they have requirements documentation that they worked with in the past? Are they comfortable working with it? Does technical documentation create silos that exclude valuable stakeholders to the benefit of technical people .

This aspect is vital, because the quality of decisions they make and their perception of you as a trusted adviser will be directly proportionate to your skill in communicating the concepts clearly to them. Not only that, but your ability to get their attention at all let alone hold it long enough to achieve a useful level of consultation will depend on not confusing or alienating them with technical or complex instruments of communication or use of unfamiliar jargon.

A clearly communicated strategy and indicative plan

Once you have gathered your information it is time to make some preliminary decisions about how to take it forward. How to collect information, how to verify your information and how to communicate back to stakeholders ahead of defining the requirements.

Identifying these tasks, the stakeholder and support staff needed and the order and dependencies of the work, it is time to add this to a simple Gantt chart that defines high level activities, high level milestones and products to be delivered.

Understanding, agreement and total buy-in.

If you have done your homework and worked in a consultative manner you will be very confident before presenting the plan, that it will be understood and supported and will be accepted by your stakeholders.
You should present:

  1. An introductory explanation of the approach with reasoning
  2. A list of products you propose to produce backed by a simple concise explanation of how and why and samples.
  3. A Gantt describing the timeframes and milestones.
  4. A simple, high level risk assessment
  5. An indication of the time commitments required of key stakeholders.

At the end of this you should answer questions and ask for their full support backed by a sign-off of the plan.

Ed Taaffe is a senior Consultant in Business Improvement through technology and Hi-tech Product management.

Reblog this post [with Zemanta]

The health warning attached to agile is nothing more, it’s not a reason to ignore agile thinking as a powerful tool.

As a manager who entered software engineering as the agile movement was gathering pace and returned to management in the systems world, I find it amusing when other disciplines jump on the bandwagon as it were. I also find it encouraging, but I would have serious concern if it were my business and here is why:

  1. Agile is not what journalists say it is

In much the same way that we probably misinterpret and ingratiate many movements,  Agile is credited with a lot of stuff that was never  though t of,  never intended and for the most part never happens.
A bunch of software engineers (several in several places) to decide how they could “take back control” of the software process in business.  They knew the power thy held in their hands, but could see more and more of it ebbing into middle and senior management determined to make them “blue collar”.  At the same time service businesses like IBM and Microsoft were looking for ways to reduce the paperwork and improve communication in the software transaction. The two things were married and produced a clever, but unruly child that requires careful monitoring and constant praise.  Agile was never a strategy, but a bun fight and it is far from over.

2.Fiiddling with KPIs is not changing anything.
 In my early days as a marketer I was taught that if you are not meeting KPIs, it is easier to fiddle with the KPI than change your behaviour. This is a fairly universal principal of business and nowhere is it more fitting that the world of software.” I want it and I want it now, but I am not sure what it is and couldn’t communicate it to you even if I did . In any case, what if it doesn’t work?”  I’ll claim you didn’t deliver and /or you didn’t do it right. That is the scenario driving software engineers to do away with specifications and contracts and make the product owner responsible. Unfortunately, what they didn’t spot until too late was that in doing this, they sold their souls and became blue collar again, but that’s another story.  Now they estimate in Tee-shirt-sizes and look upwards and to the left as they declare how many tee shirts they completed this month. If they don’t like the design they simply say it can’t be done or will cost too much. That is roughly where the tyre meets the road toady

3. A racehorse designed by a vet and an art student will make a very ugly camel at best

I was a product Manager for a few years, it is a natural progression for a marketer cum software engineer and I know some of the best around the globe. Some are redundant and others struggling. Why? Who needs professional when you have the seat of your pants? I am not suggesting that Agile teams with a nominated Product Owner can’t or don’t produce good stuff, simply that; successful products need a market sized opportunity, or it matters not how good they are, products need to meet an unmet need and to do it so that they are a more attractive proposition that their competitors and so forth.
What I am getting at is this; iPhones are successful because they were driven forward by a brilliant visionary who had the courage to show us what we are missing and make us love iPhones. Bill Gates did this for the PC. In an agile world neither of these products would have happened.
The iPhone would have been an ugly mishmash of half-finished features rushed out to an imaginary deadline and reflecting the current tastes of the Lead developer and the Product Owner, usually in that order.  I suspect the PC would have been a typewriter with a glass screen and a coffee holder.

  1. Lying in the water and thrashing your arms about is not swimming.
    Anybody who seriously wants to make a change for the better needs to start not with the technology, but with goals, develop strategies and work their way down to the details of how.  If that happens to be agile, wonderful, there is then a powerful chance that you will make it work.
  2. Beware the evangelists, many are trainee terrorists

Understanding the shortfalls of anything is the first sign of expertise and even love. Don’t fall for the preachers they have alternative motives. Somethings and some teams lend themselves well to agile, but not everything and worst of all, when a good agile team has been doing the same thing for a year or so, they are no longer agile, they are simply where they were before with slightly different rules and rituals.

  1. Agile is a state of mind not a book or a methodology and must be championed and driven form the top down by people who know what they are doing and why they are doing it.

The DNA of CHAOS. Why software projects, peace negotiations and football games all come up short on occasion and the true value proposition of agile

Why Business analysts, Product Owners, negotiators, political reformers, scientists and many others are doomed to repeat the same mistakes until they drown in in their failures.

  1. Most people in a work situation, and indeed in most situations, live in a consciousness that is deliberately falsified to reflect (a) what they believe is expected of them by peers, and (b) what the asker of a given question wants to hear. This is a conditioned response and nobody’s fault.  Terms like “Group Think” attempt to explain it, but none really explain the phenomenon well and the long version is just beyond our scope in this piece. Market researchers are trained to try and avoid it, Politicians and advertisers learn to harness it. If you have the role of finding out what  a business wants to do so you can get the software designed to support, it, you will be faced with the same  aggravated problem. Asking and listening simply won’t get the job done.
  2. For reasons I don’t claim to understand fully, most people have a favourite solution in their minds for most problems they are aware of. Expensive  housing – they may say; “Stop immigrants coming in”.  The call centres is too expensive and eating our profits- they may say; “ Close the call centre and let them use Twitter”. Always there is an obvious political, or financial gain for the responder from this solution. If it is a senior executive, or politician, there will be cleverly argued points and tables of figures that make her pet solution look like a no-brainer.
  3. Michael D Cohen  coined the phrase “Garbage Can Theory” to describe this phenomenon which permeates politics, business, the playground and just about every area of human life crippling every endeavour to improve our lot century after century. If you are trying to get your proposal through programme and investment boards, or trying to agree a solution closer the coal-face you will drown unless you understand this phenomenon and take steps to work with it.
  4. Many researchers and writers have agreed strongly that the human brain makes virtually all decisions in a matter of time between milliseconds and 1 to 3 seconds, but then spend enormous amounts of time and effort researching in order to prove their decision was correct. Most people are entirely unaware that they do so.  This of course is not news to Scientific researchers who often publish the theory before beginning on the research.  In the academic world where we have to start somewhere this can be a useful approach. Product managers and entrepreneurs also start with the theory and are difficult to budge even when wrong, yet these leaders are necessary to get something started at all.
  5. People are conditioned to follow a strong leader and will convince themselves of their support for any theory put forward by this leader. This is largely an extension of  point one, but worth being aware of all the same when venturing into any group to arrive at a shared view.

These Five forces combined thwart just about every effort to form a good business strategy with technology in mind, agree a solution and still be in agreement when the solution is completed to specification even a few months later, let alone after a year or more. Waterfall and other methods of managing the software delivery process all rely on a simplistic view that if you gather enough requirements from users and stakeholders, you can then haggle over priority and build the killer solution to solve everyone’s problems. In reality, there is rarely any agreement, there is even less concern over business outcomes and near- total focus on the many garbage can solutions. Nothing this project could deliver is ever likely to meet the satisfaction of more than a small proportion of stakeholders, the others are always going to be loud in their dissatisfaction and only by sheer luck is their ever going to be serious business benefit.  This project, however well the techies perform will be added to the list of “failures” and the cause will be placed at the CIO’s door. Failure to focus on goals Developers and technical architects are driven by developing exciting new toys. That is their package in the garbage can. Techies ultimately want and are entitled to, clear definitions of what they must build.  They then build and test precisely what you asked for and give it to you working  very well. Few people would try to argue with that, let alone succeed.  The problem is that what you asked for does not always address the problem you needed solved and in fairness the developer or indeed the CIO is not to blame. There is one technique that all accomplished negotiators agree on whether brokering peace in a war zone or negotiating a business contract. YOU MUST KEEP THEM FOCUSED ON GOALS NOT SOLUTIONS! If you don’t, the garbage can will take over.
One cause  of the problem is not using the effective solutions we already have,
The need to focus on goals rather than solutions is not  new to the software industry by the way.  MSP, Prince2 and TOGAF are frameworks I am personally very familiar with, all of which, when used correctly, focus on outcomes required, the solutions that will best deliver those outcomes and the details of each solution, in that order. BABOK and the ISEB framework for business analysis also follow these same principals and are very clear about it. The problem is that few people make any attempt to use their training effectively, the training is rushed and focused only on answering multiple choice questions to gain a certificate and of course the majority of people involved in the business have no training at all. This same scenario, by the way, applies equally to Scrum. Scrum solves some of the problem Scrum attempts to alleviate the problem in a different way and with a similar level of success. Scrum is invented and owned by the technical community as a direct response to these issues plus the difficulty of communicating the complexity of technology with business people. The Scrum team wants only to be given an unambiguous requirement so they can do what they studied for, build great software. They place the onus on the business to appoint, or work with a Product Owner who will be seconded to their team and take all responsibility for the definition of the Product/System.   Communication issues are solved by very short Sprints of just two weeks typically and using prototypes and working software to describe things to the product owner in place of documents. Initially this arrangement solves the problems for the Scrum team, there is no ambiguity about what they must build, they do as much work as the Product Owner wants and stop when he is satisfied. There is no room for dissatisfaction with the IT team. Likewise for the Product Owner, if he is unsure, he can build something , test it on real world scenarios and then make adjustments until it delivers the right outcomes or scrap it altogether.
Inspect and adapt solves problems with lack of knowledge, but also masks others Scrum tries to tackle the strategic questions by replacing strategic decisions and documents with Inspect and adapt. For online products and for certain internal systems, this works extremely well because you can build the minimum, get it working and in use, learn from success or failure and add a little more, remove some, or start again. The risks are lower, failures are smaller and less expensive and the problems with groupthink, daydreaming and garbage cans are alleviated by an early sobering splash of cold reality that comes with release of a Minimal Viable Product. What is often wrong with this approach and fatally dangerous, is the lack of a strategic layer to the thinking process. Inspect and adapt is a close cousin of the OODA loop as defined by Colonel John Boyd. The principal is very simple that in a dynamic environment, he who has the most clear view of the situation always wins given a reasonable ability to make decisions.  Pilots flying inferior jets were seen to consistently win dogfights  because they had a better view from the cockpit and could make better decisions faster.  Developing OODA  (Observe, Orientate, Decide, Act ) and teaching it to pilots made significant improvements over giving them a detailed instruction, or a faster Jet because as the military have always recognised, in the field, the operative has superior knowledge in the heat of battle and must have the right level of autonomy and confidence to decide and act. No military  has ever cut loose a person, or team, or unmanned drone to inspect and adapt and just stay out there. There has to be a clear goal, a Definition of Done, Principals that guide it in the field and a strategy for completing the mission. Then Inspect and Adapt comes into play and in the same way that the human brain itself learns,  the actions  in the field can feed all the way back to sometimes cause a change in strategy or even a revision in Principals, but  actors in the field DO NOT  GO AWOL. Principals and strategy come first and Inspect and Adapt is a response to exceptions , it is not the  plan.

The real reason why Agile/Scrum is winning friends in the world of software and gaining attention beyond these confines

I say Agile/Scrum because when most people speak of agile they are really referring  to Scrum. However Scrum has encompassed much from other Agile implementations and definitely does not hold the sole franchise on Agile methods. The first problem Scrum had to address was the great chasm between Business leaders and Technology leaders.  Various versions of the same solution see the business seconding someone to the Scrum team, or colocation of business and technical people working on the same project. This is a perennial problem sometimes referred to as silos and secondment or colocation of cross discipline teams is a useful technique that helps, but doesn’t alone solve the problems. In the case of Scrum it forces the business into making decisions for better or for worse and living or dying by them. That helps techies to get on with building stuff, but it doesn’t, of itself, help the business much with getting the strategy right. I.E they produce more stuff, but don’t necessarily solve more problems. The next problem Scrum had to address is helping the business in dealing with the unknown. The speed of change is much greater in the past few decades driven by the fast pace of disruptive technology. Organisations are faced with problems they can’t analyse easily and therefore can’t solve. They also find that when they know the problem, they don’t have an obvious solution. This is the situation Scrum was designed for in its entirety. A Scrum team can make a best guess and very quickly get a potential solution in front of customers, Inspect and Adapt and return quickly with an improved effort until the right solution is reached by trial and error and then it can be built upon until it reaches its optimum scale. The biggest problem addressed by Scrum and that one that is causing all the excitement is the almost  total  lack of leadership throughout modern businesses (the past 10 years). Few would lament the passing of the great Command and Control organisations, but with them went whatever semblance of leadership we had in organisations. In the Flat organisation leadership in name is often cited, but leadership in deed is sometimes frowned upon or even punished. In the 80s and 90s business leaders bullishly wrote books about leadership and motivation. These were charismatic people with an instinct for what made others tick.   Kenneth Blanchard, Peter  Drucker, Stephen R Covey and their like gave us the ideas and the passion to change things and build things. We somehow lost this passion and insight in the transition.  Scrum is a beacon in the dark, because it values people and their interactions over trails of evidence. It values achievement over promises and it values self-improvement  and job satisfaction. Here and there Scrum teams are springing up that capture attention by their high productivity and ingenuity and win the envy of their colleagues for their enthusiasm and Joie de vivre.  People who see a good Scrum team in action want to be part of it or learn how to make that happen in their business.  That is the real reason why the buzz of excitement continues and why Scrum experts are being invited into other areas of business.

The true DNA of an agile project (exploding the myths)

Ignore the new vocabulary and you’ll find nothing new in the concepts.

If you have heard me pour scorn over some of the claims made for agile, you may be surprised to know that I’m an agile practitioner with some considerable experience and not at all adverse to the approach.  That said, I always repeat the words of my agile mentor Keith Richards (no not him silly) when I asked the obvious silly question. He said ” It’s horses for courses.  When you turn up for training we assume a certain level of education, intelligence and experience”.

OK so what is the big noise about. Well the underlying promise of agile emerged back in the seventies soon after the first Standish report when some of the industry leaders cooked up an alternative to the waterfall way of wasting money.
The theory and indeed the practice is totally valid when followed with a level of honesty.  You tell me how much you can spend, or how long you have and I’ll guarantee you a working system.
Note the difference from waterfall where you have two options: fix both budget and time and have a failure nine times out of ten, or fix  just one and reduce the odds by 2/3.(MSF).

Agile delivers on the promise when billed honestly and executed  honestly.
Here’s the metaphor.  Say you meet with your co-directors and agree that right now the thing that will  accelerate you to your goals is an very large extra table  in the boardroom with a tiny door and spiral staircase and you have only £n  to spend, or n months to deliver it. I will discuss your needs at length, then I will come back with a proposal that looks like this.

The minimum required to make this work is a top and thee legs. You don’t need four to make a table work, though I agree it would be nice.  It can’t be bought and even the top has to be constructed on site.
The legs are standard things and fundamental so I will order three of these and have them delivered.
We will start making prototypes using scrap wood  for legs and sticking planks together until we have a table that is just stable enough and functional enough to meet your needs.

This we are confident we can achieve within your constraints, if we have extra time or budget, which I expect we will have, we can add a fourth leg, or smooth it over, or add a coat of varnish. You can decide when the time comes, which is more important. That’s it. No miracles, no free lunches, just less pontification, more action and a product that is fit for purpose, if not always entirely pretty.

 When you wouldn’t use agile.

You would never use it to build a space shuttle. That type of project requires a right first time approach.  I shouldn’t joke about a tragedy like that. There can never be a serious consequence of getting it wrong first time. You shouldn’t use it unless you are bought in fully to the three legged table, if your mind is set on four, stick to what you know. If you are buying in the team either as contractors or a service company, it is risky, because highly competent  people is a prerequisite.
If your main motivation is to be involved on a day to day basis as opposed to making a decision up front. It is poison, keep away.

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists onin isolation-whwat should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

What would you like sir?

Countless reports on the reasons for project failures in the software industry point heavily towards poor requirements as a source of the problem. It isn’t too hard to see why that might be. After all if you hope to get exactly what you want, you are going to have to spell it out in some detail.

How many times have all of us left a restaurant disappointed because we misinterpreted what a dish consisted of, or had a bad experience ?

Ordering what you want in a restaurant where they speak your language is relatively low risk. There is a risk of misinterpretation and there is a risk of a poorly executed dish, a meal that arrives after a very long wait, or a nuisance at the next table making you uncomfortable.

If you want to give yourself a strong chance of being satisfied with your meal, first you will need to be aware of all these contributors and make your choices with this in mind.
Taking this approach might help you avoid the family from hell at the next table, the dish that isn’t what you expected etc and if it doesn’t work out you are at least in a strong position to seek recompense.

Software is much more complex than food and like a restaurant meal there are more concerns than simply  the ingredients. In an ideal world you would be dealing with a professional who could interpret your tastes, avoid the poorer restaurants and order on your behalf.
This is the main purpose of the Business analysis and product  development body of knowledge.

It gives you the option of working with trusted professionals that can help you achieve what you had hoped for and keep your costs down.

Product versus System.

Few people stop to consider the difference between developing products and developing systems for a private audience and will often approach both in exactly the same way, but although there is a lot in common, there are also critical differences.
1. The first and most important difference is the fact that a system will be rolled out to desktops ot devices and the organisation will train users and tell them to get on with it, whereas a product will be launched into a marketplace who have to be attracted to explore the product and then persuaded to purchase it.

  1. A system will largely be rolled out into a controlled technical environment whereas a product will be at the mercy every conceivable version of operating system and technical environment.

  2. A product must breakeven quickly, deliver a profit in the long tail and exit gracefully before it becomes a liability.

The first of these is one of the more telling differences for our purposes because it requires an entirely different approach to understanding requirements  and defining outcomes and it introduces a whole new level of financial constraints.

When developing a product, the Analyst/Product manager  is often working with a user advocate  or product forum to define the desired functionality and get requirements down on paper in the same way as with a system.

A better process will run Alpha and Beta releases with early adapters in order to learn about how users react to it and make critical changes that improve it’s chances. In an Agile world the Product Owner will release an MVP (Minimum Viable Product) and perhaps then an MMP (Marketable)
All the time the success or failure of a product rests on the likelihood of the user base receiving it will, perceiving a persuasive benefit and viewing it as value for money.
The project manager delivering a system on the other hand has the luxury of rolling out a system and only worrying about complaints that threaten it’s ability to deliver.

The project manager can learn a lot from the product manager in terms of delivering a well received output and maintaining good communications with stakeholders.

Innovation as opposed to state of the art

Projects that involve a level of innovation either in terms of process or the technology to drive it will require a different approach and a strong element of prototyping both as proof of concept and as a way of communicating to users a blue skies concept, will generally be the better approach leading to a point where requirements and scope can be nailed down and the process of delivering it can get under way.

Complex domain knowledge

Another situation requiring a different approach to requirements is the one that involves extreme complexity in a domain outside the scope of the analysts, project managers or technical staff.

Let’s say for example that we are building software to manage extremely complex trend analysis for  forex traders and only a small number of skilled individuals understand the underlying mathematics.

To get a product manger or analyst to a sufficient level of understanding could take years and it would still be a second best option. The best option is a totally agile approach whereby the statistician the analyst and the developer all sit together and build prototypes without the statistician ever needing to understand the underlying code and architecture, or the programmers and analyst ever understanding the fine detail of Monte Carlo analyses etc being used to construct models.
In this situation the requirements are written after the code has been written and unit tested and it’s purpose is to support maintenance and future development processes.

COTS versus Development

The biggest area of effort by a long shot is the purchase and implementation of COTS (Commercial Off The Shelf) software systems.

Right form early days in the industry, there was a realisation of the need for reuse of software and many of the various efforts that came and went have been sold to us on the basis of promoting re-use. In reality precious little is developed in Com or reusable classes and SOA is still not that widely used.
The theory that once you had created a “customer object” you didn’t ever need to do it again, just never caught on, but COTS systems did and today there is very little development of end to end systems outside of software houses that develop products.  Nobody builds their own CRM, or ERP, etc, because it makes no sense when you can buy it straight out of the box at a fraction of the cost. Bill Gates freely admits that he ran the business on SAP using his own products to integrate where he needed the extra flexibility.

The issues with COTS however are that businesses are all keen to differentiate their offerings and this adds to the variety of processes and business models in operation which in turn means that many of these all encompassing systems are a compromise rather than a solution and require a lot of integration and customisation in order to make them deliver benefits.

There has never been to my knowledge, any attention given to the needs of these systems. The most common problem I have encountered is people from the business assuming that you don’t need the normal skills to deal with this because it is in the box and it is like buying a lawnmower,  you bring it home and tell “the IT boys” to plug it in.

In reality this is a very dangerous mistake and pitfalls are as follows:

  • You are reading wooly,  warm and friendly descriptions of what the system will do, but no detail about how it gets there. All COTS is sold with a “Caveat Emptor” clause and unless somebody knows all the details of what it must do and whether it actually does, then you will end up with a very expensive system that just is not suitable.
  • The complexity and risk attached to integrating COTS systems with other systems can sometimes make them almost as expensive as starting form scratch.
  • The impact of the COTS systems on your infrastructure and on other critical systems can be devastating unless it is properly understood.

The job of procuring COTS software is  complex and tricky and it can often be a struggle to convince business stakeholders of the need for detailed requirements, detailed investigations, complex questionnaires, proofs of concept, and a range of testing before making the system live on a production environment.
The size and complexity of this area is such that it could not be addressed in this series, but suffice to say that all the rules about requirement apply equally and there are a number of new concerns to be addesses.

Requirements, tests, training, help files – the connection?

Part one What would you like sir

Part two Requirements,tests, training, help files

Part three Why no project exists onin isolation-whwat should be done

Part four Business rules, Process rules, Process, Data, different viewpoints

Part five Testing requirements is not optional

Part six Requirements strategy can make or break your project

 Really! – Have you seen this new stuff? 

This could easily have been Mick Jagger and Keith Richards after their first successful gig. In the modern world, it is more likely to be a hard working CTO talking to a COO about his systems needs.

Systems are not like any other purchase. You can go to a tailor today and he will do almost the identical things that a tailor did for Julius Ceaser.  You can call an architect and his approach will differ little from that of Hiram Abif apart from the time taken to produce drawings.  When it comes to systems though, it is more like medicine. Patients differ, you only hear what they tell you and you don’t really understand anything you have not personally experienced, you have to tease it out using your instinct and experience and play the numbers game.

There are techniques for flushing out the problems and verifying them and for getting the medicine accepted, but ultimately every doctor likes to deal with life threatening situations. If he succeeds for whatever reason, he’s a hero and if not, well, he did his best.
Apart from a lucky few, most of us in the software industry have to earn a living by delivering value in the real world through cost savings, or competitive advantage and that’s a tall order.
It calls for a mixture of calculated risk taking and good fall back positions and it requires an insight that combines real understanding of the business domain with leading edge technological ability. It doesn’t matter whether this is done by a committee or a genius as long as it gets done

The requirements challenge

So how do you meet a business person, listen to his/her needs and six, nine or thirty six months later get a well done, thank you response?

There isn’t a really good answer to this. If it is six months, you are in with a chance. If it is nine you are still in there, at thirty six, the likelihood is that before you deliver this, a much better solution will have been invented, or the problem will have been replaced by a new one.

There is a considerable number of methodologies out there, most of them geared up to coax you into paying for expensive training courses and few aimed at really bridging the divide between what a business needs and what technology can deliver with reasonable reliability.   A methodology that really works has to be able to understand business needs, translate it into process and match this with the best possible technical solution.

Defining the problem

This is not as simple as it sounds. If you read my business case blogs, you will probably remember the way I recommend tying corporate objectives in a direct and accountable way to the benefits delivered by the business case.  That makes perfect sense of course, because a good business sets a plan and then works to deliver on it.
There are other scenarios however that need to be taken into account, this example will hopefully help to illustrate the point.
Suppose we approach an Amazon tribe still living in the traditional way, tell them that we would like to give them some gifts and ask them about the problems they would most like to solve and the things that might give them the most satisfaction.  Problems and exciters. The likelihood is that having seen bright steel machetes amongst the crew, they might suggest a steel spear to make fishing more productive. We might then suggest that rather than give them a spear, we can give them a monofilament net. This way they can catch enough for the whole tribe in an hour instead of having to fish all day.Here we have seen a classic example of the two cardinal sins of analysis:

 1.       Asking a question that the object of the question can’t possibly be expected to answer well.

2.       Answering with a solution rather than a problem.

The interviewee in this example can’t be expected to know how to manage this process, so the entire responsibility lies with the interviewer. By the way, that includes the many occasions when the interviewee believes she knows exactly what she wants and is driving.
The responsibility of the analyst extends to making sure that the interviewee has explored and understood the problem and has a sufficient understanding of it and of the desired outcomes to start either designing or verifying the solution.
I include verifying here, because an increasing number of business people believe themselves to be tech wizards and arrive with fait accomplis and a budget wanting a technically trained fellow to make her vision happen.  In these cases, instead of designing a solution, the analyst goes through a process of verifying the problem, the requirements and the solution.  If these three don’t match and the sponsor doesn’t see it then it is up to the individual analyst’s conscience  and professional intergityas to what he/she should do next.

In Summary

In this part we have talked about three key issues:

1.       The unique challenge facing a systems professional in getting to the real problem before starting on the solution.

2.       Educating the client about possibilities in order to truly understand what the problem is.

3.       Tempering the part time inventor with a little pragmatism without dampening his/her enthusiasm.

The next part will get much deeper into the language and culture of requirements and and discuss different methods of achieving a reliable result.
 

 

 

 

Reblog this post [with Zemanta]

Business analysts: a bridge between IT and business

 Role of business analysts
Business analysts intervene at the project management stage in information technology. Working with the project manager, their role is specifically to analyze business requirements before the start of a project. Their work involves identifying, defining, analyzing then documenting the underlying needs of a project. They guarantee the compliance of a project with business requirements and help determine which projects have priority.
The work of business analysts differs from that of traditional information systems analysts because they focus exclusively on the benefits of the project for the company’s business. It is also different than that of project managers and functional analysts because their role is to show what the product will be required to do, and not how it will do it. The analysis of needs is carried out with no commitment toward a specific product.

 Read more >>

 

Business Analysts Bridge the Business Gap

A dramatic change is taking place in the way businesses operate, and the business analyst is leading the charge.

The business analyst (or business process analyst) is the vital link between business executives and IT staff, translating business goals into IT requirements and communicating the requirements to IT. That’s no small matter. According to research firm Meta Group, “Poor requirements gathering, analysis and management are directly responsible for 70 to 80 percent of project failures.”

Until recently, IT requirements typically originated in the IT department. In some companies they still do. When IT is not given clearly defined business expectations, not surprisingly it develops solutions that fail to meet expectations. By improving communication between business stakeholders and developers in IT, the business analyst reduces costs and delays.

This article by By Charlie Orosz of Boston University discusses the change in focus as business analysts seek to bridge the gap from the business to IT as opposed to the other way around.