Loading ...
Sorry, an error occurred while loading the content.
 

Business Goals

Expand Messages
  • Desilets, Alain
    One thing I have learned from attending Jeff Patton s tutorials, is that before you even think about users, you need to think about the Business Goals that the
    Message 1 of 7 , Apr 4, 2006
      One thing I have learned from attending Jeff Patton's tutorials, is that before you even think about users, you need to think about the Business Goals that the software is supposed to achieve. Business Goals are usually goals of the people who are paying you to write the software, and they may differ from the goals of the people who will be using it.

      For example, for a system that helps agents in a call center, a Business Goal might be:

      "Decrease the average length of a call by 2%."

      The concept of Business Goals is pretty simple to grasp, and it seems that defining them for a particular system would be a pretty lightweight thing to do. Yet, this idea does not seem to have been explictly articulated and stated by people like Larry Constantine and Alan Cooper.

      Can people point me to references on how one might go about gathering information about Business Goals?

      Alain Désilets, MASc
      Agent de recherches/Research Officer
      Institut de technologie de l'information du CNRC /
      NRC Institute for Information Technology

      alain.desilets@...
      Tél/Tel (613) 990-2813
      Facsimile/télécopieur: (613) 952-7151

      Conseil national de recherches Canada, M50, 1200 chemin Montréal,
      Ottawa (Ontario) K1A 0R6
      National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
      K1A 0R6

      Gouvernement du Canada | Government of Canada
    • Lada Gorlenko
      ... I posted this a few months ago to the IxDA Discuss list... In my group, we try to run two workshops with a client at the beginning of each engagement: -
      Message 2 of 7 , Apr 4, 2006
        > Can people point me to references on how one might go about
        > gathering information about Business Goals?

        I posted this a few months ago to the IxDA Discuss list...

        In my group, we try to run two workshops with a client at the
        beginning of each engagement:
        - Business Usability Needs (BUN) and
        - Roles and Goals (R&G).

        BUN participants are decision makers and stakeholders in the client
        organisation. At the workshop, we identify a prioritised list of
        distinct business goals (1-3 year outlook), where success of each goal
        is tied to the changes of human behaviour. For example, for a
        financial client these goals may be increased cross-sales of financial
        products through branches, increased uptake of customer self-service
        operations, etc.

        For each goal, we define the business benefit, constraints to success
        and target audiences. For each audience, we identify the audience
        value proposition, success metrics, audience inhibitors, mechanisms
        for change, and key usability goals.

        Usability goals are the differentiators that define our design
        direction. They describe the most important qualities of the system
        and set design priorities. Different systems (or even similar systems
        for different clients) will have different profile of usability goals,
        depending on the client's business goals and target audiences.

        Currently, we work with a set of 10 usability goals, from which we ask
        a client to identify up to three critical goals. For example, our set
        includes:
        - Adoption rate (increased usage of a discretionary system);
        - Efficiency (increased human performance, such as speed and
        productivity);
        - Compliance (reduced legal liability);
        - Appeal (increased emotional response to a design).

        Business goals, together with usability goals, give us a pretty good
        picture of business requirements.

        R&G workshop involves both stakeholders and "power users" of the
        target system. The goal of the workshop is to identify a list of
        distinct audience roles with an interest in the system (one level
        below target audiences identified previously). For each role, we
        describe demographic profile, education, experience, social, business,
        economic factors, as well as personal and professional goals. For each
        goal, we then define key tasks, identify enablers and inhibitors, and
        describe physical and social context of use.

        Typically, both workshops are conducted by the same two people who will
        later lead user research and product design activities. Both workshops
        address different requirements, but tie them together efficiently.

        Lada
      • Larry Constantine
        Alain wrote ... Good point. It so light weight that it is easily lost as we try to be more disciplined and comprehensive. Actually Lucy and I used to
        Message 3 of 7 , Apr 4, 2006
          Alain wrote

          > The concept of Business Goals is pretty simple to grasp, and it seems that
          > defining them for a particular system would be a pretty lightweight thing
          > to do. Yet, this idea does not seem to have been explictly articulated and
          > stated by people like Larry Constantine and Alan Cooper.

          Good point. It' so light weight that it is easily lost as we try to be more
          "disciplined" and "comprehensive." Actually Lucy and I used to begin with
          the "essential purposes" of a system/project but gradually shifted focus to
          understanding users and tasks.

          Back to basics!

          (We actually do bring in business goals in terms of prioritizing user roles
          and tasks, but nothing like the clarity of spelling it out up front.)

          --Larry
        • Jeff Patton
          To pipe in, this is where I found the techniques of Usage Centered Design so helpful - in particular the concept of focal user roles and focal tasks. The
          Message 4 of 7 , Apr 4, 2006

            To pipe in, this is where I found the techniques of Usage Centered Design so helpful – in particular the concept of focal user roles and focal tasks.  The questions I ask to identify focal roles and tasks [which I sure I learned from Larry & Lucy] where “of these user roles, which are critical to the success of this software.”

             

            Critical is a funny thing. 

             

            One of my gripes about agile approaches is this silly notion of prioritizing user stories by business value.  In most Agile contexts I’ve participated in it usually boils down to a subjective judgment on the part of stakeholders – or possibly a squeaky-wheel decision – story prioritized high to satisfy the most vocal user constituency.

             

            Prioritization happens against a backdrop of some business goals.  And, oddly I find that on many agile projects those goals aren’t articulated – at all.  They’re often considered obvious, until you attempt to write them down.  A few hours of discussion later, you’ll see how not-obvious they were.

             

            And my wise friend Alistair Cockburn always reminds me that software is always written for at least two people – the one behind the keyboard, and the one who paid for the software to be built.  He doesn’t say it exactly that way, but the point is that software needs to both satisfy the user, and guarantee the interest of some stakeholders.  

             

            I promise I’ll come to a conclusion here eventually.

             

            Prioritization of user stories happens against a backdrop of an understanding of user goals, and business goals.  It was from Larry & Lucy that I first learned the value of simple models that encapsulate my understanding.  To model business goals lately I’ve been using an approach my friend Julias pointed me to: GQM – short for goal question metric.  [Google around and you’ll find lots of references including a pricy Forrester Research report and an somewhat expensive book.]  Basically, if you have a business goal, ask “how would you know you were reaching this goal?”  Poke the goal long enough with questions and you’ll realize it’s either a dumb goal, or it’ll mutate into one that has some metrics that will help you understand how the goal is being reached.  A collection of goals with metrics makes up my business goal model.  The list is prioritized – or rather there are focal goals.  To understand users I’ll build both user role models and task models.  I’ll then ask stakeholder using the backdrop of the goal model to identify focal roles and tasks.  It’s much easier to identify the users the software needs to satisfy with the goal model visible.  I’ve found it makes the whole process go smoother.

             

            Finally, when if comes down to prioritizing small bits of the system under development written up in user stories, knowing what user the story serves, what task that user is engaged in, and what business goal the story is in support of helps immensely.  Arguments about priority dissipate quickly with these models that distill our understanding.  

             

            To bind in with Larry’s earlier post – “the abuse of usage,” usability testing is an important thing.  But it’s a part of a much bigger thing.  I suggest to people that they let lots of crappy, buggy, semi-usable software ship.  I do it myself.  The trick is knowing when we can get away with it and when we can’t.  Again, it boils down to these sorts of models and the guidance they give.  Don’t skimp on parts of the software used for focal users engaged in focal tasks that by definition – because they’re focal – are critical to the business goals of the software.  But for not so focal users engaged in infrequent tasks, barely sufficient is the rule.  I’ve met many usability people that look for usability at any cost.  That’s just not practical – not with my money or my customer’s money.  Sometimes usability testing overstates the concerns of the person behind the keyboard and understates the concerns of the stakeholders who paid for the software. 

             

            End rant. 

             

            This is a long message to Alain saying “take a look at GQM stuff” – apply it to business goals and see what happens.  ;-)

             

            Thanks,

             

            -Jeff

             


            From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Larry Constantine
            Sent: Tuesday, April 04, 2006 3:20 PM
            To: agile-usability@yahoogroups.com
            Subject: RE: [agile-usability] Business Goals

             

            Alain wrote

            > The concept of Business Goals is pretty simple to grasp, and it seems that
            > defining them for a particular system would be a pretty lightweight thing
            > to do. Yet, this idea does not seem to have been explictly articulated and
            > stated by people like Larry Constantine and Alan Cooper.

            Good point. It' so light weight that it is easily lost as we try to be more
            "disciplined" and "comprehensive." Actually Lucy and I used to begin with
            the "essential purposes" of a system/project but gradually shifted focus to
            understanding users and tasks.

            Back to basics!

            (We actually do bring in business goals in terms of prioritizing user roles
            and tasks, but nothing like the clarity of spelling it out up front.)

            --Larry



          • Desilets, Alain
            Prioritization of user stories happens against a backdrop of an understanding of user goals, and business goals. It was from Larry & Lucy that I first learned
            Message 5 of 7 , Apr 5, 2006
              Message
              Prioritization of user stories happens against a backdrop of an understanding of user goals, and business goals.  It was from Larry & Lucy that I first learned the value of simple models that encapsulate my understanding.  To model business goals lately I’ve been using an approach my friend Julias pointed me to: GQM – short for goal question metric.  [Google around and you’ll find lots of references including a pricy Forrester Research report and an somewhat expensive book.]  Basically, if you have a business goal, ask “how would you know you were reaching this goal?”  Poke the goal long enough with questions and you’ll realize it’s either a dumb goal, or it’ll mutate into one that has some metrics that will help you understand how the goal is being reached.  A collection of goals with metrics makes up my business goal model.  The list is prioritized – or rather there are focal goals.  To understand users I’ll build both user role models and task models.  I’ll then ask stakeholder using the backdrop of the goal model to identify focal roles and tasks.  It’s much easier to identify the users the software needs to satisfy with the goal model visible.  I’ve found it makes the whole process go smoother. 
               
              -- Alain:
              Question for you. Do you work on defining the Business Goals BEFORE defining User Roles and User Tasks, or AFTER? In your paper "What Goes Up Must Come Down", you seem to be saying that high level kite-and-above level goals (which are more or less equivalent to Business Goals) should at least be partially distilled based on knowlege about the lower level goals (although as you point out, it is best to work in both top-down and bottom-up directions). But to me, Business Goals is the one thing that I believe CAN be articulated mostly upfront, and I tend to favour that approach (although I tend to favour a "middle-out" approach for lower level details).
              ---- 

               

              Again, it boils down to these sorts of models and the guidance they give.  Don’t skimp on parts of the software used for focal users engaged in focal tasks that by definition – because they’re focal – are critical to the business goals of the software.  But for not so focal users engaged in infrequent tasks, barely sufficient is the rule.  I’ve met many usability people that look for usability at any cost.  That’s just not practical – not with my money or my customer’s money.  Sometimes usability testing overstates the concerns of the person behind the keyboard and understates the concerns of the stakeholders who paid for the software.   

               

              -- Alain:

              The converse is of course also true. Agilist sometimes pay too much attention to the concerns of the "Gold Owner" (the person who pays for development), without realising in order to achieve that person's Business Goals, you HAVE to pay a lot of attention to the people behind the keyboard (or at least the focal ones).

               

              In my view, this gold customer-centric vs user-centric difference is the main source of misunderstanding between the Agile and Usability community, and the work that you (Jeff) are doing goes a long way towards bringing those two perspective together.

              ----

            • Jeff Patton
              ... I often come into a project late - after it s started. Lately I often come in to do a bit of rescue work on the user interactions. In those situations
              Message 6 of 7 , Apr 5, 2006
                --- In agile-usability@yahoogroups.com, "Desilets, Alain"
                <alain.desilets@...> wrote:

                > -- Alain:
                > Question for you. Do you work on defining the Business Goals BEFORE
                > defining User Roles and User Tasks, or AFTER? In your paper "What Goes
                > Up Must Come Down", you seem to be saying that high level kite-and-above
                > level goals (which are more or less equivalent to Business Goals) should
                > at least be partially distilled based on knowlege about the lower level
                > goals (although as you point out, it is best to work in both top-down
                > and bottom-up directions). But to me, Business Goals is the one thing
                > that I believe CAN be articulated mostly upfront, and I tend to favour
                > that approach (although I tend to favour a "middle-out" approach for
                > lower level details).
                > ----

                I often come into a project late - after it's started. Lately I often
                come in to do a bit of "rescue" work on the user interactions. In
                those situations there's often an absence of business goals, or a set
                of ambiguous business goals that don't seem well connected to the
                users and scope chosen. So, I'll work bottom up to reconstruct a goal
                model from what I observe people actually building. Then review my
                observations about the business goals I see being pursued based on
                what people are actually doing. When coming in late to a project I
                might prefer to spend a bit of time with stakeholders on business
                goals first, but this sort of work is often seen as regressive -
                everyone already believes they know what the goals are. "Just get to
                work on this UI stuff! That's where we need the help." Not until I
                point out deviation from goals does rewinding and discussing a more
                concise goal model become important.

                In a greefield situation I put together goals first. But I always
                move up and down validating users and activities we choose to support
                with goals we hope to achieve. Doing this uncovers both missing users
                and tasks, and missing business goals.

                I try to avoid waterfall head - by that I mean only moving down from
                high level to lower level, insisting high level models are complete
                before moving on to lower levels, and always assuming what what done
                in a higher level phase was correct. Levarage agile feedback loops to
                validate and further refine these higher level models.

                > -- Alain:
                > The converse is of course also true. Agilist sometimes pay too
                > much attention to the concerns of the "Gold Owner" (the person who pays
                > for development), without realising in order to achieve that person's
                > Business Goals, you HAVE to pay a lot of attention to the people behind
                > the keyboard (or at least the focal ones).

                Where agilists might fall down is in the creation of these mezzenine
                level models - things like goal models, user models, task models, etc.
                All this stuff starts to smell of big design up front to some agile
                people. The thing to remember is that it's not the model that
                represents waterfall thinking, it's the way be build and work with the
                model that makes in waterfallish - and potentially risk.

                I look at user stories like leaves on a tree. I'll try to build
                simple models that start to give form to the tree - a trunk, branches,
                then finally leaves. Unfortunately in a lot of agile projects all
                that exists are user stories. Sort of like pulling all the leaves off
                the tree, cutting down and chopping up the tree, then handing you the
                leaves in a leaf bag. This leaf-bag-style story backlog is a common
                agile project smell. I spend a fair bit of time forensically
                reconstructing mezzenine level model from the leaf-bag-o-details found
                in a story backlog. Everyone's often surprised at the tree they're
                actually building - the users, tasks, and business goals they really
                chose to support.

                Thanks Alain for keeping this discussion going.

                Opinions anyone? Is anyone out there working on an agile project
                where goals seem ambiguously defined? Does this cause problems
                prioritizing and detailing user stories? Actually scratch agile from
                the previous sentances. Agile development certainly doesn't have a
                corner in the ambiguous goals market.

                -Jeff
              • Jeff Patton
                Forgot to say something - see below... ... pays ... What I didn t bring out above is that the creation of these models helps the gold owner more effectively
                Message 7 of 7 , Apr 5, 2006
                  Forgot to say something - see below...

                  --- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@...> wrote:
                  > > The converse is of course also true. Agilist sometimes pay too
                  > > much attention to the concerns of the "Gold Owner" (the person who
                  pays
                  > > for development)...

                  > Where agilists might fall down is in the creation of these mezzenine
                  > level models - things like goal models, user models, task models, etc.

                  What I didn't bring out above is that the creation of these models
                  helps the "gold owner" more effectively stear the project, and makes
                  the direction the project is being steared in more visible to the
                  whole team. Without them, the decisions the "gold owner" make often
                  seem arbitrary and subjective - at times even to themselves. These
                  sorts of models are quick to create, useful tools. I'll assert that
                  as a development team we're not serving our "gold owners" well if we
                  don't help them with things like this.

                  -Jeff
                Your message has been successfully submitted and would be delivered to recipients shortly.