00:14hello I'm Tom Hathaway I'm wearing my da
00:18hat so let's talk business analysis in
00:22this nugget I'd like to introduce you to
00:23a method for creating what we call a
00:25business problem backlog this is
00:28basically an agile approach to
00:30initiating business problem analysis it
00:33will help you figure out how to get a
00:35list of good potential problems and then
00:39later on we'll learn how to work the
00:41list to identify the real problem this
00:44technique will help you when you are the
00:46one wearing the BA hat if you're working
00:50on a project and don't know what
00:52business problem the project will solve
00:54you have no way of really knowing when
00:57you're done whether the project was
01:02worse you have only limited ability
01:05while you are on the project to decide
01:07whether it is moving in the right
01:11business problem analysis is a
01:13phenomenally powerful technique for
01:15ensuring that your project is the right
01:17project and that it is delivering the
01:23business problem analysis identifies the
01:25real problem related symptoms and
01:28creates a more complete list of
01:29requirements for your project from the
01:31beginning before you can do it however
01:34you need a list of potential quote
01:36problems unquote that the project might
01:41start by building a problem list
01:44as a prerequisite let's assume that
01:47someone presumably the project sponsor
01:49defined the project scope in some manner
01:52you need the project scope to get folks
01:55focused on what kinds of problems they
01:57should be identifying
02:00actually the project sponsored be a
02:01great first person to ask what problems
02:04this project will solve by simply
02:07documenting the answers you have
02:08initiated a problem list don't attempt
02:11to analyze their problems just yet
02:17once you have your sponsors answers the
02:19idea is to expand your problem list by
02:22getting input from all stakeholders on
02:24the project you might use email to
02:26solicit their business problems related
02:28to your project or have a meeting
02:30virtual or in person in which the group
02:33can present their answers
02:36ask each stakeholder that you identified
02:39what's wrong with the way the things
02:41work today your goal is to collect quote
02:45problems unquote from the different
02:48perspectives of identified stakeholders
02:50again ignore the urge to analyze until
02:53you have sufficient material to analyze
02:57on a related topic I highly recommend
03:00the meeting over email because the
03:02discussion around each other's perceived
03:04problems a is a great team-building
03:06exercise B generates additional quote
03:10problems unquote from other stakeholders
03:12and C presents ample opportunity to
03:16start to identify potential solutions to
03:20generally speaking there is no lack of
03:23the latter in a meeting you called
03:24specifically to discuss problems that's
03:27fine don't ignore the solutions capture
03:31them as someone presents them under no
03:33circumstances however should you assume
03:35or indicate that that solution might
03:38actually be what your project will
03:40deliver it's much too early in the
03:44a well-structured problem lists for each
03:48problem identified by a stakeholder one
03:51write it down as a complete sentence you
03:54want to minimize ambiguity by expressing
03:56the problem in a simple clear sentence
03:59get a concrete example or a clear
04:01definition so that everybody involved
04:04understands the problem as stated
04:07to get agreement with all involved
04:10parties that it is a problem from that
04:12stakeholders perspective agreement leads
04:15to co-ownership of the problem but
04:17sometimes getting agreement amongst a
04:19group of people is nearly impossible
04:22start by getting at least one person to
04:24agree then enlist that person to explain
04:26the issue to others this process
04:29achieves consensus if not outright
04:33if you cannot get agreement on a problem
04:35put it on an open issues list be aware
04:38that anything on the open issues list
04:41represents a potential risk factor to
04:43your project until the issue is resolved
04:46by the way the open issues list is a
04:48wonderful byproduct of the meeting
04:52three number of the problems will make
04:55your life a whole lot simpler by having
04:57an identifier for each problem for
05:00although your numbering the problems
05:02sequentially as you discover them the
05:05number becomes an identifier meaning you
05:07shouldn't change the number after the
05:09fact having a unique identifier for each
05:12captured problem will facilitate problem
05:14analysis and later relating business and
05:18stakeholder requirements back to the
05:26now that you have a baseline use your
05:28existing problem list to expand your
05:30list of stakeholders to make your
05:32problem list as complete as possible
05:35for each problem on your list ask who's
05:38interested in solving this problem the
05:41people most interested in solving this
05:43problem are probably the ones suffering
05:45from the effects other candidates are
05:48people or departments that could gain
05:50tangible or intangible benefits from a
05:55beyond the people who suffer from the
05:57effects of the problem aka the victims
05:59there are several potential groups with
06:01whom you should speak to understand the
06:03problem and potential solutions in
06:07people who don't have a problem with the
06:09way things are currently done and as a
06:11result are quite often unhappy if you
06:14want to change things
06:17special interest groups meaning people
06:19who might not care about whether you
06:21solve the problem but have the authority
06:23to mandate that it be solved a certain
06:26way ie a standards committee the legal
06:29department security audit just to name a
06:33including the members of these groups
06:35will help you define most if not all
06:37relevant stakeholders of your project
06:39that in turn will help you contain the
06:42ugly scope creep monster in later stages
06:44of the project mist stakeholders and
06:48unidentified problems are major
06:50contributors to scope creep because you
06:52need to add new requirements to solve
06:54the additional business problems since
06:57you're involving a wide range of
06:58stakeholders from the start the risk of
07:00eternally expanding requirements is much
07:05on a sidenote this approach will also
07:08lead to a more complete set of
07:09requirements because you're considering
07:12the needs of many stakeholders from the
07:15it is an iterative process as soon as
07:18you identify new stakeholders in your
07:19project find out what problems these
07:22stakeholders perceive repeat step one
07:25above to add the new problems to your
07:27original problem list and continue
07:29numbering them sequentially
07:32if new insights lead you to modify
07:34captured problems make sure that
07:36everyone not only the newly identified
07:38stakeholders agrees with the
07:43now do you have a problem list you're
07:45ready to do business problem analysis
07:47and that's the content of a different
