Leverage, Business Benefit and Mutual Understanding

As a developer, one of my concerns is that the time I’m using on something has real business benefit.

The term business benefit is just short hand for saying will it enhance our income, reputation and future viability. Enhancing either of the latter can only enhance the former.

How do I know what will benefit the business – both short and long term?

Can I rely on intuition? I doubt it.

The best source is solid feedback, systematically obtained from as many clients as is practical. This is can complex and tricky; an awful lot of it is subjective, difficult to capture accurately and may not even be offered in full.

Some responders may decide not to state the genuine reasons for a negative view. They may feel it’s impolite, not had time to consider it fully, other pressures may be at work or they simply haven’t had sufficient training in the product.

Is there a next best then? Possibly – I’m a believer in client involvement and I also think *depth of sale is critical for any non-trivial software solution.

The premise of specialised software is to provide a natural solution for a specific area of business. This requires deep understanding of this business, its language and its primary concerns – this is why client involvement is critical.

Eric Evans in his book on Domain Driven Design tackles this subject head on.

The depth of sale is critical because from here, the relationship has to grow into a deeper mutual understanding – what do they need and expect also how does this evolve as their knowledge grows.

Initially, the emphasis is on the developer to understand and use the language of the client’s world. Later, the client learns what the developer can really bring to their business and, **if the process is done well, actually use the developers knowledge to create new possibilities for the business.

This becomes more mutual as the developer gains expertise as his or her skill will be to synthesize a number of models of what the client needs. The developer is really looking for the greatest leverage points that benefit the clients’ business; what is the most effective intervention that can be gained with the new software?

I highly recommend Chapter 6 of Thinking in Systems for a brief discussion on leverage points – as developers the higher up the list we can help clients intervene, the greater the value of our solution. These points are something for a later blog, so please stay tuned!

In a previous blog I detail the idea of informed client feedback where, with context, a client can easily realise new possibilities that make a huge difference to the simple day to day operation of their business. This can only come from educated context – if you didn’t know this feature existed, you won’t build on it mentally to come up with a new one.

One piece of software I work with captures a seemingly trivial piece of information every time a note is made-this information is used with immense effect elsewhere in other features. One of which saved a client a large amount of hassle. This client would never have guessed that such a feature would have helped them.

As developers our job isn’t just writing code – that’s just the mechanics. Our job is to help our clients create new possibilities for the future of their business.

If we enable them to succeed in ways they may not have even conceived of, prior to our work, we also succeed.

*Depth of sale quite simply means educate effectively in order to allow clients to make a fully informed sale. Here I have to give credit to Andy Dent of http://www.innovit.co.uk/ for introducing this idea to me years ago in the context of school IT strategy.

** It doesn’t mean the client has to learn to code, but it is beneficial for them to gain an overview of the thought process and analytic skills used by the developer; this way they can ask better questions. This is a virtuous cycle of positive feedback because better feedback means better understanding expressed in the software that means more possibilities and even more feedback and so on… There is a reverse of this of course, an exercise I’ll leave to the reader!

Gathering Requirements

Do you like people? More specifically do you like meeting clients? What do I mean?

And why the developer SHOULD be doing these meetings, not someone else.

Recently I sat with a number of senior managers and directors for a particular group. Not one of them has any interest in what happens deep under the hood when we are talking software. They are interested in making their work easier and more accurate. The session is part criticism and issues, not just positive feedback.

I conduct the meeting in a simple way. A few coloured pens, a hard back plain A4 notebook and a question. “Is it ok if I sit and listen to your questions in turn, make notes and then work out some answers with you?”

Some folks take longer than others to voice their specific issues but everything is written down and I take care to ensure that everyone is able to see what I note and how I *understand them. Repetition is common; I request clarification until I’m sure. About halfway through, the main issues that people have wanted to get off their chest are written down. Everything from here on is refinement.

I take a look at the points and begin with the ones that seem the most pressing, based on the way they are expressed and how important the issue is in the wider context of what they are doing. Then start working out possibilities.
This is the fun bit. Sometimes it’s easy to think users don’t know what they want; often this is partway true. However, this is a limited view. The reality is, given the opportunity, users have a damned fine idea of what they want – they often don’t quite realise it yet.

How does this change? They become aware of possibilities through daily use. Before you had Microsoft Word, did you know you would want auto save, spelling correction or even mail merge?

Before you had GPS in a car, did you know you might need to save favourite places? Search by postcode OR part address? Auto traffic alerts?

Why not? You’d not had a reason to consider the possibility.

Every feature in software has the potential to generate dozens of requirements, new things that people realise are important.

A great requirements meeting is not passive. You don’t sit there with a “customer is right” attitude. You don’t send out a verbal or written survey and hope for results.

You have to get in there and communicate. Encourage their debate and criticism, hell, if they are passionate enough to be somewhat hostile, it can be even better (said with intense caution!). Why? Because they care enough about the needs the software is supposed to meet to gift you with their time, attention and emotion on the subject.

The response to intense criticism should have an attitude of “make me understand and here are some possibilities”.
Ignore how you are going to do it under the hood, forget limitations of technology-the client doesn’t care ultimately about this part-they have **expectations and it’s your job to figure out how to manage AND meet those expectations. Often these are out of reach or possibly on the surface of it, unreasonable. They didn’t think that was the case when they formed them. From their perspective, it’s obvious and natural that feature X should happen “like this” or “look like that”.
My own experience taught me that clients, who are not technical but know their world well, may actually translate a paper based process into a literal screen version of that paper. This isn’t wrong but it can be a weak metaphor and metaphors are the real translation tool for producing real world work from a computer.

When clients discuss their needs, they are translating things that matter in their day to day work. A good developer translates the entire context of their work into something that gives the client this leverage. To give this leverage, it is rarely good enough to simply provide a computer equivalent of what they would otherwise hand write.

A case in point: There is a specific type of reading that is required very regularly, for multiple individuals. The original client request was for a blank sheet-a template-of the form that could be printed and filled in or written on when back at the computer. The form was a periodic set of values per person for a day.

On examination, I gave him the following story: “What if you staff can walk into a room with ANY suitable phone, tap it and see the person in front of them on the phone. From this point on, every single tap could be a reading being recorded. The process takes no longer than the physical act of getting the correct reading and writing it down; it may even be quicker as writing by hand takes a minute. Then the phone is put away, forgotten, whilst the real work is being done. The results end up directly in the persons files from which reports and forms can be generated.”
When the notion was laid out, the client realised I understood the work they were doing and why. I understood his world and had taken the trouble to look beyond the surface impression of the stated need.

This idea was far more welcome than the original paper template idea. The idea uses no more technology than most staff are used to-a mobile phone or indeed for many, a tablet. In addition, many people understand the use of a sat nav, so a phone knowing where it is in a building is a natural leap.

Metaphor is all that a client has when handling a computer. Get this wrong and your software is sunk. We click, swiped, pinch & shrink; open/close and many others. We don’t “0101101”.

Why does anyone bring a computer into the equation? Because they want leverage over their work; they want to it faster, have it be more accurate, more secure, more consistent and far more convenient thus giving them more time to do their real work.

It would be easy for me to get distracted by the programming specifics only; however, I truly believe a really good developer is literate, articulate and keen on understanding their client. They may well engage 50% of their attention to the specifics of their toolkits – frameworks, methodologies, platforms, but the other 50% is on domain expertise of their clientele. If you write software for doctors, you should know common doctor terminology, processes and concerns; understand their job-stopping short of actually being able to do it – this is the ideal of course.

*How you understand something, deep down, defines everything you can reason about it. If you get a subject by rules alone then everything you think of is bounded by the rules not by the principle that underlies those rules. If you understand client need X in a literal sense, you may be limited your solutions deeply to this understand. If, you understand the drive and context for need X you may find a much richer structure upon which to base your new solutions. You job is open up these possibilities, only after understanding the requirements properly.

** Managing expectations is a whole skill in its own right. This is down to how you sold the product in the first place – if the sun, moon and stars were promised, you have a long way to go back tracking in later meetings. On the other hand, if you sold your product on a fairly limited premise then trained your clients well and were consistently receptive when they need help, you shouldn’t get wild expectations-most of the time.