Listening To The Needs Of Business Owners

Kate Carruthers

Ark Group Conference Communicating Web Capabilities

& Limitations16 May 2008, Sydney

We technologists are often being asked to deliver things that are impossible given the constraints within which we must deliver them. Delivery of web solutions is one such area.

The problem begins with business people who have some ideas about what they want, but who do not understand the technical domain sufficiently to understand how expensive or complex those wants are to fulfil.

May 2008© Kate Carruthers 2

Some of the issues include: understanding the real business requirements; finding effective ways to listen to the needs of business owners; helping business people understand trade-off options to meet client and end-user needs; how to move beyond egos and agendas to the real issues; and how to clarify business requirements to meet expectations.

Another important thing we need to achieve is how to explain the advantages and disadvantages of requested web projects. In the short time available I will attempt to address these issues.


Except when you are building it for someone else


Building software is a

relatively easy process that is

only complicated by the involvement

of people.

Main Entry: mis·com·mu·ni·ca·tion Pronunciation: \ˌmis-kə-ˌmyü-nə-ˈkā-shən\ Function: noun

Meaning: failure to communicate clearly

Source: Merriam-Webster Online


Miscommunication is at the root of all problems between technologists, business owners and end users. Very often one party is from Mars and the other is from Venus, or even Pluto.

We often go into discussions as if we are all working from a common basis of understanding. But the truth is very different. Each party bring to the conversation a different perspective, set of expectations and base of experience and knowledge. This makes for a challenging mix to manage. It also makes it challenge to keep everyone happy.


… more on this later

“Annual income twenty pounds, annual expenditure nineteen & six, result happiness. Annual income twenty pounds, annual expenditure twenty pounds ought & six, result misery.”

Charles Dickens


The dog house is a great example

Easy to build a dog house

More challenging to build a sky scraper


Business owners neither know nor care about all of this complexity.

Like all of us they want what they want when they want it for the budget they have available.

Also many people today have built some software themselves, perhaps at home or at university.

This means that they have a perception that it is not that difficult.


Steve McConnell has written about this problem and characterises it in terms of building a dog house:◦ “People who have written a few small programs in college

sometimes think that writing large, professional programs is the same kind of work-only on a larger scale. It is not the same kind of work. I can build a beautiful doghouse in my backyard in a few hours. It might even take first prize at the county fair's doghouse competition. But that does not imply that I have the expertise to build a skyscraper. The skyscraper project requires an entirely more sophisticated kind of expertise. The difference in complexity between student programs and professional programs can be just as great, and non-professional programmers -underestimate the difference in required expertise at their own peril.” (McConnell, 1996)


Some of the important issues we have to deal with include: software is not always simple to build; integration with existing systems can be a challenge; we often have legacy spaghetti code; and new code can be just as complicated to build, deploy and maintain.

It is our job to be able to explain the difference between building a dog house and a skyscraper to business people. But firstly it is our job to understand what they really want and need. Bearing in mind that wants and needs are not necessarily the same thing.


Complexity adds risk

What if you need to make changes in many places?

What if there are many interfaces?



What if the changes need to made at all levels in the system?



Even worse what if those changes need to happen across 4 different systems including one with an external supplier?


Web System

Billing System

CRMSystem

ExtSupplierSystems

Sometimes a seemingly simple request from a business owner can actually require a series of complex and risky changes. I’ve often had someone ask if we can change just one little thing on a web screen. ◦ The request might actually require a web front end developer,

API developer, database developer and a tester and take them each a minimum of one day to complete. Assuming a base rate of $1,000 per day per resource, that one day of duration is actually four effort days and thus a minimum cost of $4,000.

Often the business owner does not get to have a discussion regarding how this cost aligns with their wants and needs.


Do people always hear what we mean?

AVOID:◦ Jargon◦ Special language◦ Technical terms

USE:◦ Plain English◦ Visual aids◦ Relate to business plans◦ Business language


Business systems tend towards complexity

Business people do not know or understand how much effort or cost is required to fulfil their desires


Business people do not have a mental map upon which to plot the combination of their desired functionality and designs and the effort, cost and complexity of achieving them. It is up to us to explain to them the trade-offs required. There are many ways to deconstruct this, some of the key criteria are:• Novelty of the desired solution• Complexity of the requirements & the technical environment

into which it will be deployed• Ability to re-use existing applications and code• Degree to which the desired solution has to connect to legacy

spaghetti code


Business people generally want to build the cheapest solution that meets their business needs, they often do not have visibility of TCO.

We need to develop culturally appropriate ways to explain these issues to business people.


The challenge is to tease them apart

A need is: Something you must have Something you can't do

without

A want is: Something you would like

to have Not necessary, but would

be a good thing to have


One of the big challenges we face in delivering solutions to business owners is truly understanding their wants and needs and the difference between the two.

This is where we return to the idea expressed by Charles Dickens about needs v. wants and budget. If the business owner wants a highly complex project with novel functionality (a.k.a. a Ferrari) but only has budget for a simple project that reuses existing functionality (the a.k.a. Nissan Micra) then it is time for the discussion on needs v. wants.


It is important to frame this conversation in ways that the business owner can connect to their existing mental map (Kitchin, 1994).

This is where the use of visual tools to frame the conversation become helpful.

A number of simple tools are shown later.


How do you break the news?

… a dumb idea?

… technically difficult ?

… really expensive?

… totally impossible?


Make the implicit explicit

Needs Wants Constraints Conjectures Assumptions


It has been estimated that conversational “speech is produced at a rate of about 2.5 words per second, often in noisy environments and with less than-perfect articulation.” (Krauss, 2002)

This means that the spoken word is probably one of the more inefficient ways to communicate with the business owner. Especially when you consider that, given the dearth of meeting rooms, the meeting will likely be held in a noisy coffee shop.


Thus there are a few things that are absolutely essential, especially if there is bad news to share.

First of all it is imperative that we tease out all of the implicit requirements.

See the following example …


For example, where the business person explains their requirements and it all looking nice and simple. But they finish off with the throwaway line that “and we’d like that to email us if it does not work”.

Thus with this implicit requirement, it is now possible that your simple project requires scheduling functionality, an email gateway, error checking for transmission, etc. A small project just got a whole lot bigger.


The only way is to listen

Respect Trust Objective Clear Purpose


Trust can only be build on a foundation of respect. An important way to signify respect is to listen to what

the other person has to say. But a trust based relationship must be two-way. Therefore you must be respected and listened to as

well. All of this takes time, and it is a good investment (especially if you will be working together in the long term).


Objectify Use visual tools Recap continually Clarify Simplify Don’t take things personally


One important way that we can account for emotions is to help people to objectify matters relating to the project.

We can do this by using visual tools; recap information regularly; seek clarification and check for understanding.

Make the effort to simplify things and above all don’t take things personally. Emotions often run hot during a project since people’s careers and lives are involved.


These are just for inspiration


I will share a few simple tools that I use to obtain clarity from business owners and also to ensure that they have clarity about what I can do for them.

You are welcome to take these and modify them for non-commercial purposes, I simply ask that you share any good stuff back into the community.

These examples are mostly web development based, but they could easily be used for other kinds of development too.



0 100

0 100

0 100

0 100

Cost

Quality

Schedule

Scope

RULESYou only have 100 points total. You can allocate them between options but it

cannot total more than 100 points.

Example

This is an example of a tool that I use to facilitate discussions with business owners about what they are willing to trade-off to meet their business needs.

For example, if quality is 100 points then this means that they are negotiable on each of the other elements.

It really helps people to focus on what is important and you can come back to this later and use it to frame difficult discussions.


Example

Know the purpose of the website:◦ Business viewpoint◦ Consumer viewpoint

Clearly identify your target audiences Set S.M.A.R.T. goals, e.g. audience reach, level of

engagement, dwell time on site Define metrics for success Ensure you write great content specifically for web

Example

I use this as a simple introduction for the business so that they understand some of the things I will ask them to contribute to the success of the web project. It leads nicely into the engagement model and project team charter.

1. Marketing manager writes web brief2. Web team reviews brief3. Joint requirements workshops4. Agree scope & budget, appoint project manager5. Create Information Architecture, wireframes, web

design6. Build & unit test website7. User acceptance testing8. Launch

Example

Problem & goal Project Sponsor Project Team Leader Project Director Project Team Members Key Deliverables Critical Milestones Critical Success Factors Stakeholders Who Must Be Involved Constraints (People/Money/Time)


Example

Out Of Scope How Project Will Be Measured How Team Will Be Measured When The Team Must Check With Sponsor When The Team Has Full Authority To Act When The Sponsor Has The Right To Veto Who Else Has The Right To Veto Decisions? Is There Anyone Else Who Must Be Consulted For

Decisions?


Example

Web Design

Web Development

Web Templating & CMS

Backend – database & applications

Graphic Design

Bac

ken

dF

ront

-end

• Conceptual design – brand alignment, colour schemes, key visual elements (creative agencies), fonts & style guides

• Translates graphic design into web medium

• Site architecture, wireframes, process & workflows, functional specifications, HTML prototyping

• Web functional design/development for interactive front end elements, e.g. AJAX, JavaScript, HTML

•Web template design/development

• Integration with web functional elements & backend elements

• Backend functional design/development for database and application elements, e.g. customer database, API, integration, etc.

Business brief• Business brief – site objectives, positioning, audience, functionality desired, business requirements specification

Example

Result = happy business people

Use plain language Visual tools help to frame

conversations Be transparent & open Take time to explain issues


McConnell, S. (1996) “Response to Wilson: Teach Programming Principles, Not "Tools and Tips“, IEEE Computational Science and Engineering

R. M. Kitchin (1994). "Cognitive Maps: What Are They and Why Study Them?". Journal of Environmental Psychology 14: 1-19.

Krauss, R.M. (2002). The psychology of verbal communication. In, N. Smelser & P. Baltes (eds.), International Encyclopaedia of the Social and Behavioural Sciences. London: Elsevier

These slides are available on www.slideshare.net/carruthk


Listening To The Needs Of Business Owners

Business

Transcript of Listening To The Needs Of Business Owners