00:04now let's talk about tactical business
00:07analysis remember tactical business
00:09analysis is where you have a project
00:11defined and now you try to go out and
00:13try to get the nitty-gritty details
00:15about what the project is going to do
00:16what the application is going to do what
00:18the people with are going to be doing
00:20with the application and things like
00:22that this is where you're going to be
00:24talking to a thundering herd of
00:25stakeholders and you need to figure out
00:27who are all of the people that are going
00:28to be involved in the project and what
00:30do you need to ask them in order to get
00:32their requirements this is the core work
00:34that most people who have the title
00:36business analyst or junior business
00:38analysts actually start with you're
00:40really looking at the project and you're
00:41trying to assess the time money value
00:44perspectives so that there is a balance
00:46of the resources required the money
00:48that's invested and the value that the
00:50company is going to be getting out of it
00:52your job now is to do hardcore analysis
00:55if you are thinking about the connection
00:56framework this is where things in the
00:58complicated domain really fit well
01:00because you can do analysis you can
01:02break things apart look at the details
01:05and out of the details figure out what
01:07is it exactly that we need to do in
01:08order to satisfy the customer and of
01:11course this is where we deal with change
01:12in the tactical business analysis level
01:15change is rampant and that's why we have
01:17philosophies such as agile and lean and
01:20methodologies like Kanban and scrum in
01:22order to deal with ongoing change
01:24throughout the project the outcome out
01:27of street act achill business analysis
01:29is going to be stakeholder requirements
01:30if you're in a conventional project or
01:32features and/or user stories if you're
01:35in a lean or agile project fundamentally
01:38given today's technology we'd maintained
01:40that user stories are a phenomenal tool
01:43a phenomenal structure for expressing
01:46stakeholder requirements regardless of
01:48what philosophy yard following whether
01:50it's waterfall agile or lean I think
01:53because the user story gives you the who
01:55the what and the why answers very early
01:59on they're a phenomenal tool for
02:01analyzing or for looking at and
02:03expressing stakeholder requirements at
02:05any level of detail so what kind of
02:07techniques do we use in tactical
02:09business analysis well our old friend
02:11problem analysis is still there this
02:13time however we're looking
02:14at a lower level of detail looking at
02:16individual problems as opposed to the
02:18problems that affect the entire
02:19organization and when you start talking
02:22through the people in the trenches
02:23people doing the real work you're gonna
02:25find a lot of problems that the higher
02:28levels had not thought about didn't
02:29identify as problems because they are
02:31not involved with them at that level
02:33you're also going to be using things
02:34like process modeling and analysis
02:36you're gonna drop pictures going to draw
02:37diagrams of how the business process
02:40works how the flow is how you get from A
02:42to B and what information is exchanged
02:45between the individual steps of the
02:47process interviews and workshops or in
02:49the world of agile conversations these
02:52are all three methods for interacting
02:54with the real people doing the real work
02:56and trying to get an understanding of
02:58what would help them do their job better
03:00faster cheaper data modeling and
03:02analysis this is a technique for looking
03:05at the structure of data and although it
03:08came out of the 70s and the 80s when we
03:10were talking about building huge
03:12databases in the world of big data this
03:14has taken a revival this has God become
03:17very important once again because trying
03:19to figure out what kind of information
03:21you want on a dashboard or how the
03:23information that you have coming out of
03:25ten different sources is structured what
03:27are the elements that they that are
03:28common even though they might have
03:30different names and different
03:31descriptions in each of the different
03:33sources so data modeling business data
03:35modeling especially and data analysis
03:37are key into in today's world where
03:40we're talking much more about business
03:42analytics or data analytics in order to
03:44figure out where the organization is
03:46going decision tables or decision trees
03:49are two techniques for getting at the
03:51lowest level of detail a better
03:53understanding of how the organization
03:54works of how the individuals within the
03:57organization do what they need to do in
03:59order to get their job done if you start
04:02off with a decision table or decision
04:03tree you'll find that it guides the
04:05presentation or it guides the
04:06conversation all by itself it forces you
04:09to ask specific questions about specific
04:11conditions and the outcomes of each
04:13combination of conditions you're
04:16obviously requirements your features
04:18your user story decompositions are very
04:20key at this level of detail the word
04:23decomposition always means tearing
04:25something apart so if you're looking at
04:28and you're decomposing it you're trying
04:29to find what are the different
04:31components that the application would
04:32have to have what are the different
04:34actions that people would have to do in
04:36order for that user story to be
04:38appropriately implemented
04:40getting back to the attd or acceptance
04:43test-driven design and BDD business
04:45driven design your test strategy your
04:48test plan if you are following a true
04:50agile approach in an organization or
04:53even if you're following just a
04:55waterfall approach I highly recommend
04:57looking at accepted test-driven
04:59development because the scenario where
05:01if I give the developers the test that
05:04their program has to pass as opposed to
05:06giving them some vague user story or a
05:08vague solution requirement the
05:10developers are much more likely to
05:12deliver the content that I need they're
05:14going to deliver the program that will
05:15pass the test it is a step that has
05:18greatly improved our ability to deliver
05:21working software cheaply and quickly to
05:23the business community and it does what
05:25the business community wants it to do
05:27now there are a thundering heard more
05:29tools and techniques that you might be
05:31using in your tactical business analysis
05:33anything that you could think of at this
05:35point in time write it down keep a track
05:37of it you might bring it up in the
05:38discussion board and see what other
05:40techniques other people are using share
05:42your techniques and see if they will
05:44share their so you can build a better
05:46repertoire of tools and techniques at
05:49your disposal in order to come up with a
05:51good set of techniques for doing
05:54tactical business analysis so who are
05:57the players involved in tactical
05:59business analysis well at this level the
06:01common drivers of the process are the
06:03directors managers product managers
06:06product owners the people who have
06:08decision-making authority within the
06:10organization kind of at the level that
06:12is operational meaning they are able to
06:15decide things that are going to be
06:17happening that are going to have a
06:18direct impact on the people who are
06:20doing the real jobs you might also be
06:22involved with a business analysis Center
06:24of Excellence if you have one or that
06:26same organization that type of an
06:28organization where you have a pool of
06:30trained business analysts disposal for
06:33any different project under any other
06:35name would be exactly the same people
06:37that are executing tactical business
06:39analysis are going to be business
06:40analysts at all levels and under any
06:43other name also going to be product
06:45managers project leaders project
06:46managers subject matter experts your
06:48product owners on an agile team will
06:50definitely be involved in this as well
06:52as agile team members
06:54and agile implementations what a lot of
06:56organizations have gone to is having
06:58what is called a customer side team
07:00which is going to be people that are
07:02trying to keep ahead of the agile
07:04developers by taking a look at the user
07:06stories that are coming up in the next
07:08scrum in order to excuse me in the next
07:10sprint in order to be able to make sure
07:13that they are ready for the developers
07:15and the developers aren't sitting around
07:16twiddling their thumbs with nothing to
07:18do there's a lot of different people
07:20that might be involved in tactical
