Listening To The Needs Of Business Owners
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Listening To The Needs Of Business Owners

  • 1,853 views
Uploaded on

Ark Group Conference Sydney 16 May 2008

Ark Group Conference Sydney 16 May 2008

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,853
On Slideshare
1,853
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
76
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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. Some of the issues that we face in building software for business people include: understanding their real 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. This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Australia license http://creativecommons.org/licenses/by-nc-sa/2.5/au/

Transcript

  • 1. Kate Carruthers Ark Group Conference Communicating Web Capabilities & Limitations 16 May 2008, Sydney
  • 2.
    • 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
  • 3.
    • 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.
    May 2008 © Kate Carruthers
  • 4.
    • Except when you are building it for someone else
    May 2008 © Kate Carruthers Building software is a relatively easy process that is only complicated by the involvement of people.
  • 5.
    • 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
    May 2008 © Kate Carruthers
  • 6.
    • 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.
    May 2008 © Kate Carruthers
  • 7.
    • … 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
    May 2008 © Kate Carruthers
  • 8.
    • The dog house is a great example
    • Easy to build a dog house
    • More challenging to build a sky scraper
    May 2008 © Kate Carruthers
  • 9.
    • 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.
    May 2008 © Kate Carruthers
  • 10.
    • 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)
    May 2008 © Kate Carruthers
  • 11.
    • 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.
    May 2008 © Kate Carruthers
  • 12.
    • Complexity adds risk
    • What if you need to make changes in many places?
    • What if there are many interfaces?
    May 2008 © Kate Carruthers
  • 13.
    • Complexity adds risk
    • What if the changes need to made at all levels in the system?
    May 2008 © Kate Carruthers
  • 14.
    • Complexity adds risk
    • Even worse what if those changes need to happen across 4 different systems including one with an external supplier?
    May 2008 © Kate Carruthers Web System Billing System CRM System Ext Supplier Systems
  • 15.
    • 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.
    May 2008 © Kate Carruthers
  • 16.
    • Do people always hear what we mean?
    • AVOID:
      • Jargon
      • Special language
      • Technical terms
    • USE:
      • Plain English
      • Visual aids
      • Relate to business plans
      • Business language
    May 2008 © Kate Carruthers
  • 17.
    • Business systems tend towards complexity
    • Business people do not know or understand how much effort or cost is required to fulfil their desires
    May 2008 © Kate Carruthers
  • 18.
    • 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
    May 2008 © Kate Carruthers
  • 19.
    • 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.
    May 2008 © Kate Carruthers
  • 20.
    • 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
    May 2008 © Kate Carruthers
  • 21.
    • 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.
    May 2008 © Kate Carruthers
  • 22.
    • 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.
    May 2008 © Kate Carruthers
  • 23.
    • How do you break the news?
    • … a dumb idea?
    • … technically difficult ?
    • … really expensive?
    • … totally impossible?
    May 2008 © Kate Carruthers
  • 24.
    • Make the implicit explicit
    • Needs
    • Wants
    • Constraints
    • Conjectures
    • Assumptions
    May 2008 © Kate Carruthers
  • 25.
    • 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.
    May 2008 © Kate Carruthers
  • 26.
    • 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 …
    May 2008 © Kate Carruthers
  • 27.
    • 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.
    May 2008 © Kate Carruthers
  • 28. May 2008 © Kate Carruthers
  • 29.
    • The only way is to listen
    • Respect
    • Trust
    • Objective
    • Clear
    • Purpose
    May 2008 © Kate Carruthers
  • 30.
    • 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).
    May 2008 © Kate Carruthers
  • 31.
    • Objectify
    • Use visual tools
    • Recap continually
    • Clarify
    • Simplify
    • Don’t take things personally
    May 2008 © Kate Carruthers
  • 32.
    • 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.
    May 2008 © Kate Carruthers
  • 33.
    • These are just for inspiration
    May 2008 © Kate Carruthers
  • 34.
    • 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.
    May 2008 © Kate Carruthers
  • 35. May 2008 © Kate Carruthers RULES You only have 100 points total. You can allocate them between options but it cannot total more than 100 points. Example 0 100 0 100 0 100 0 100 Cost Quality Schedule Scope
  • 36.
    • 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.
    May 2008 © Kate Carruthers Example
  • 37.
    • 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.
  • 38.
    • Marketing manager writes web brief
    • Web team reviews brief
    • Joint requirements workshops
    • Agree scope & budget, appoint project manager
    • Create Information Architecture, wireframes, web design
    • Build & unit test website
    • User acceptance testing
    • Launch
    Example
  • 39.
    • 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)
    May 2008 © Kate Carruthers Example
  • 40.
    • 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?
    May 2008 © Kate Carruthers Example
  • 41. Web Design Web Development Web Templating & CMS Backend – database & applications Graphic Design Backend Front-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
  • 42.
    • Result = happy business people
    • Use plain language
    • Visual tools help to frame conversations
    • Be transparent & open
    • Take time to explain issues
    May 2008 © Kate Carruthers
  • 43.
    • 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
    May 2008 © Kate Carruthers