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

Stakeholders and Priorities

Expand Messages
  • Ann Dillon
    The project I m working on has two broadly defined user groups: 1. Viewers - those that just want to look at information quickly and easily, and 2. Doers -
    Message 1 of 5 , Aug 5, 2004
      The project I'm working on has two broadly defined user groups:
      1. Viewers - those that just want to look at information quickly
      and easily, and
      2. 'Doers' - those that want to enter or manipulate the information.

      In general, the numbers of 'doers' are the highest, most are domain
      experts, most require heads-down data entry efficiency, and more
      than 50% are slated to retire within the next five years - so the
      focus of the UI design might shift from 'easy-to-use' to 'easy-to-
      learn'.

      In contrast, the 'viewers' are generally the decision-makers and are
      often the most vocal. While some of the goals of the two groups
      overlap, many are in conflict. For example, the viewers want to see
      the big picture, the doers just want to get the information entered
      and move on to the next task.

      After reading Martha Lindeman's posts with great interest, I have
      some questions?
      1. If the goals of the user groups are different, and the business
      management team has been unable to prioritize the importance of
      these goals ("They're both equally important!"), how large of a
      project risk is this?
      2. If it is critical to get these groups prioritized, does anyone
      have any suggestions re: helping the business team to understand the
      importance of doing so? I'm having problems communicating that even
      if one user group has priority over others, that doesn't mean that
      we will ignore the needs of the other group, just that in a tie, one
      group has to 'win'.
      3. Am I too concerned with getting the user groups' needs
      prioritized by the business side? I try to pick my battles, and if
      this one isn't as important as I think it is - I'd be happy to drop
      it. :)

      Thanks in advance for any suggestions!
      --Ann
    • William Pietri
      ... That depends on how important those groups are to the success of the project. But generally, I consider inability to prioritize a major risk factor. ... It
      Message 2 of 5 , Aug 5, 2004
        On Thu, 2004-08-05 at 13:37, Ann Dillon wrote:
        >
        > 1. If the goals of the user groups are different, and the business
        > management team has been unable to prioritize the importance of
        > these goals ("They're both equally important!"), how large of a
        > project risk is this?

        That depends on how important those groups are to the success of the
        project. But generally, I consider inability to prioritize a major risk
        factor.

        > 2. If it is critical to get these groups prioritized, does anyone
        > have any suggestions re: helping the business team to understand the
        > importance of doing so? I'm having problems communicating that even
        > if one user group has priority over others, that doesn't mean that
        > we will ignore the needs of the other group, just that in a tie, one
        > group has to 'win'.

        It may not even be the case that one group has to always win. There are
        other possible outcomes. E.g., for a given feature, you make an
        interface for each group of users. Or that one group wins on interfaces
        that matter to them more, but let the other group win the rest of the
        time.

        Were you in an XP shop, where developers produce a certain number of
        points of development each week, I'd suggest you just allocate points to
        a representative of each group and then let them pay for what they want.
        If they can compromise on shared features, then they get more for their
        money. Where they can't, they get what they pay for.

        On my current project, we don't have different reps, but the product
        manager spends a lot of effort carefully balancing which users groups
        get attention when. To make it clearer, our story cards are colored by
        which audience a feature addresses; that way at a glance we can see
        patterns in who gets the goods.


        > 3. Am I too concerned with getting the user groups' needs
        > prioritized by the business side? I try to pick my battles, and if
        > this one isn't as important as I think it is - I'd be happy to drop
        > it. :)

        All of the truly awful projects I have been on were ones where the suits
        just refused to make hard decisions. Technical people should not be left
        to resolve what are really political issues; it generally ends up with
        everybody being mad at them.

        William
      • Charlie Trainor
        ... First, reframe the question, from which group has higher priority (a very political question, with no real answer) to which part of the system should we
        Message 3 of 5 , Aug 6, 2004
          RE: [agile-usability] Stakeholders and Priorities

          Ann Dillon wrote:
          >
          > The project I'm working on has two broadly defined user groups:
          >  1. Viewers - those that just want to look at information quickly
          > and easily, and
          >  2. 'Doers' - those that want to enter or manipulate the information.
          ...
          > 2. If it is critical to get these groups prioritized, does anyone
          > have any suggestions re: helping the business team to understand the
          > importance of doing so? I'm having problems communicating that even
          > if one user group has priority over others, that doesn't mean that
          > we will ignore the needs of the other group, just that in a tie, one
          > group has to 'win'.

          First, reframe the question, from "which group has higher priority"
          (a very political question, with no real answer) to "which part of
          the system should we work on first".

          The answer, ultimately, depends on where the team's effort will make the
          biggest difference to the overall goal for the project - looking more
          globally than the interests of individual groups.  You have a
          responsibility to help the business team by estimating the impact of
          poor usability in particular areas of the system on the overall project
          goals.  If you can't give them some indication of this, don't expect
          them to be able to prioritize in a vacuum.  But if you can, then you
          can (in all conscience) refuse to do any work until they decide what
          you should work on first.

          It sounds like, in your case, the first priority is to ensure the "doers"
          have a usable system to enter the data, since (I presume) the "viewers"
          can't benefit if the data is bad or nonexistent.  If you agree, you should
          feel free to point this out to the business team.

          - Charlie

        • Ann Dillon
          Thanks for the tips - especially the re-framed question. Coming up with the questions that can get the answers we need without putting people on the defensive
          Message 4 of 5 , Aug 6, 2004
            Thanks for the tips - especially the re-framed question. Coming up
            with the questions that can get the answers we need without putting
            people on the defensive or starting unnecessary political battles is
            an area in which I'm trying to enhance my skills!

            > First, reframe the question, from "which group has higher
            priority" (a very political question, with no real answer) to "which
            part of the system should we work on first".
            >
            > The answer, ultimately, depends on where the team's effort will
            make the
            > biggest difference to the overall goal for the project - looking
            more
            > globally than the interests of individual groups. You have a
            > responsibility to help the business team by estimating the impact
            of
            > poor usability in particular areas of the system on the overall
            project
            > goals. If you can't give them some indication of this, don't
            expect
            > them to be able to prioritize in a vacuum. But if you can, then
            you
            > can (in all conscience) refuse to do any work until they decide
            what
            > you should work on first.
            >
            > It sounds like, in your case, the first priority is to ensure
            the "doers"
            > have a usable system to enter the data, since (I presume)
            the "viewers"
            > can't benefit if the data is bad or nonexistent. If you agree,
            you should
            > feel free to point this out to the business team.
            >
            > - Charlie
          • Martha Lindeman
            Ann, 1. The project is very high risk because no one is willing to take responsibility for making hard choices. If the business management will not do it at
            Message 5 of 5 , Aug 6, 2004
              Ann,

              1. The project is very high risk because no one is willing to take
              responsibility for making hard choices. If the business management will
              not do it at this point in the project for issues that can be clearly
              defined, the risk will get higher and higher as the consequences get
              potentially more harmful and the issues less clear!

              2. Because "Priority" is an emotional trigger word, sometimes people
              will answer the question, "Which of these would you like for me to do
              first?" even when they will not "set priorities." Also, based on your
              description, it sounds to me as if you could discuss the issue in terms
              of 'level of information' rather than in terms of priorities that
              trigger a sense of pitting users against users. For example, the
              hands-down doers need detailed displays for original data entry. Other
              doers may need the same level of info for, perhaps, reviewing,
              approving, or other similar tasks. The viewers need higher-level
              summary info for decision-making. Sometimes it is quicker to design
              and code two displays (one for data entry and one that just prints the
              already entered data with an Approved button) than it is to resolve the
              differences between the groups so that one display will suffice.

              Martha

              >Message: 1
              > Date: Thu, 05 Aug 2004 20:37:36 -0000
              > From: "Ann Dillon" <Ann.Dillon@...>
              >Subject: Stakeholders and Priorities
              >
              >The project I'm working on has two broadly defined user groups:
              > 1. Viewers - those that just want to look at information quickly
              >and easily, and
              > 2. 'Doers' - those that want to enter or manipulate the information.
              >
              >In general, the numbers of 'doers' are the highest, most are domain
              >experts, most require heads-down data entry efficiency, and more
              >than 50% are slated to retire within the next five years - so the
              >focus of the UI design might shift from 'easy-to-use' to 'easy-to-
              >learn'.
              >
              >In contrast, the 'viewers' are generally the decision-makers and are
              >often the most vocal. While some of the goals of the two groups
              >overlap, many are in conflict. For example, the viewers want to see
              >the big picture, the doers just want to get the information entered
              >and move on to the next task.
              >
              >After reading Martha Lindeman's posts with great interest, I have
              >some questions?
              >1. If the goals of the user groups are different, and the business
              >management team has been unable to prioritize the importance of
              >these goals ("They're both equally important!"), how large of a
              >project risk is this?
              >2. If it is critical to get these groups prioritized, does anyone
              >have any suggestions re: helping the business team to understand the
              >importance of doing so? I'm having problems communicating that even
              >if one user group has priority over others, that doesn't mean that
              >we will ignore the needs of the other group, just that in a tie, one
              >group has to 'win'.
              >3. Am I too concerned with getting the user groups' needs
              >prioritized by the business side? I try to pick my battles, and if
              >this one isn't as important as I think it is - I'd be happy to drop
              >it. :)
              >
              >Thanks in advance for any suggestions!
              >--Ann
              >
              >
              >
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.