Documenting User Story Acceptance Criteria: some ways to do that

First of all, I have not written any posts for the last four years really so likely my writing skills are a little rusty. If you manage to go through the entire post and happen to notice anything you would like to challenge from an analysis perspective, language style (anything really) – be my guest. I will take all the feedback I can, quietly crying after that with a bottle of beer. If there is, however, anything you find worth your time spent on reading this article, letting me know about that will make me doubt my skills less for at least a few minutes.

What is this post about?

Dilbert’s requirements

This write-up is inspired by a recent post I read in Piotr Gorak’s blog on different formats of user stories. I am not going to focus here a lot on the user story technique by itself but rather on the specification of behavior that engineers are implementing as a part of a story. My main goal with this post is to outline different ways to write acceptance criteria, problems I had with them in the past, and what I did to overcome those problems.

In this post, I am NOT going to speak about how to build a comprehensive list of acceptance criteria that tests positive, negative cases, performance, etc. Instead, I will focus more on the mechanics of documenting what the story writer was able to think of when writing a story and discussing it with the team.

Writing Stories

To me, a story by itself is an expression of intent. It explains (should, at least) a problem that exists that software is supposed to address to make the user’s life easier. It may or may not mention the context to which it applies (a particular task the user is performing, a type of the user engaged in the task). A story by itself does NOT tell how to verify the problem is solved and if it is solved correctly. It does not state how to leverage the solution.

By a story I assume a technique to specify a few components:

• summary (traditional story format)
• conversation (whatever details the author captured)
• acceptance criteria (meat of the story)

Most of the stories I wrote over the last 6 years were user-facing i.e. included interactions between a user and a user interface.

When I experimented with formats of story writing, sometimes I would squeeze in the intended workflow of the solution the story implements into Conversation. On one hand that helped, on the other if there were other stories related to a particular workflow either I had to replicate at least some steps in other stories or rewrite the flow entirely. A co-worker of mine followed a different path where he would prepare user scenarios with basic, alternative, and edge case flows and then build stories around specific scenarios or their parts. In that case, user scenarios could just be linked to individual stories.

The detailed flow by itself can be used as a test or an acceptance criterion explaining how to verify the implemented solution. One problem is that one flow likely represents just one test scenario and an implemented solution to a story often includes more than one test. Hence the questions: 1) how to document ways to test the implemented solution? 2) How to define what must be achieved for a solution to address the problem? 3) How to remember what has NOT been done i.e. what scenarios are not supported?

Enter Acceptance Criteria

Acceptance Criteria, IMO, are the most important part of a story that serves as solution requirements explaining what and how the solution is supposed to achieve in order to address the intent of the story.

Of course, there are many ways to write Acceptance Criteria. Furthermore, the format in which Acceptance Criteria is written likely depends on the type of the story being implemented.

For instance, if the story deals with a number of configurations, some sort of a decision matrix will probably be the best method of communicating requirements. In other cases, where the story deals with the implementation of a particular flow with a number of decision points (Yes/No) a more appropriate format could be some sort of a flow diagram. If the writer is describing requirements for a data migration/conversion story or API then a likely format for specifying acceptance criteria is a field mapping document or a data spec.

In this post, I am going to focus on a more conventional text-based (not graphical) representation of Acceptance Criteria. I am also assuming that readers are familiar with concepts such as INVEST and requirements characteristics (from BABOK) such as Unambiguity, Cohesiveness, Completeness, and so on. I am also assuming that readers are at least attempting to maintain some level of quality of requirements due to the fact they are even attempting to define acceptance criteria.

Getting back to documentation of Acceptance Criteria, I know that some are doing that in the “system shall format” where each acceptance criterion looks like a traditional format of requirements writing e.g.“System shall accept non-negative integer values between 0 and 1000 as an input to the quantity field”

Depending on how much time to prepare documentation I had, how familiar the team was with the space in which we were working, and the complexity of the product I could then document acceptance criteria in a number of ways:

Test-case like

When I joined my first project in 2012, I was introduced to the format of requirements writing adopted by some of the teams. Each Acceptance Criterion was written as a test case basically containing a flow in itself. I am not really writing acceptance criteria in this way anymore because they tend to get quite verbose (even though they typically make every case really clear), sometimes with a lot of duplicate content and of course taking quite some time.

Statement-like. Example 1 (an example comes from a story focused on an API capability):

1. EmergencyIncident is capable of returning IDs and codes of all agencies (relatedRecords) associated with a particular discipline based on involvements between records and cad calls
2. RelatedRecords will be available for any dispatch i.e. fire, ems, law (ideal! at least for law)

Statement-like. Example 2 (for a story where we wanted to stop covering text of comments with notifications about new/unseen comments)

1. at no point should a comment text be covered with a notification about a new comment
2. we should not be showing notification box when there are no notifications outside of visible area
3. ctrl l should skip to the first unread comment in cad and mobile

The benefit of using this format is that it is really easy and quick to write. These statements serve more like instructions or reminders to have a conversation about specific steps. If that conversation does not happen, the risk is that a lot of work is a subject of interpretation by an engineer. Then when testing starts more conversations are needed to get an understanding of what has actually been done. Essentially, this may turn into an avalanche of unidentified details and of course rework.

Event-Response

This format is similar to given when then in my opinion with “event” being “when” and “response” the “then” part of the other format. It just skips the “given” portion or the preconditions that could be written for a few scenarios if preconditions are the same. If written well, this format can be quite straightforward and easy to read.

Event-response format

I liked and still like this format a lot as it has a very simple formula IF-THEN that even people with little experience can follow. The risks with this approach are standard – it is missing scenarios the writer has not thought of.

Given When Then (GWT)

At some point, I started experimenting with using the “Given When Then” format of writing requirements in Gherkin language. Honestly, I do not remember what made me do that. Maybe it was that I read Gojko Adzic’s book “Specification by example” or there was some other reason. I believe TDD and BDD were popular concepts and being a no-coder I just wanted to look cool in front of coding brothers and sisters. I do not think I intended to write acceptance criteria that could then be implemented using tools like FitNesse. Regardless, let the reasons to try GWT remain a mystery.

The approach seems to work well when there is a need to describe specific interactions and system output especially when a user’s action results in a number of outputs. For example, a checkout / confirmation of paying for a product or a myriad of other examples.

In all honesty, this is just a format, as good as many others if done right.

When I first started experimenting with the format I realized it was difficult for me to understand what a particular criterion tested without having to read through its entirety.

Here is an example of how I wrote it in the beginning.

early attempts

Because there can be a lot of “given” clauses and “then” clauses, the review was challenging so I added some sort of a header/summary for each such criterion. As a result, the format started looking something like this.

Given when then in a table-like manner

The team I worked with at the time was giving me good feedback on this format. One person who liked this a lot was the QA engineer because this work helped her prepare clearly-documented test cases that could then be automated. Writing a story in this manner of course was taking more time to spell everything out. I also had to keep in mind the format expectations (no OR, one condition per clause, specific examples, etc).

Until recently I was not familiar with use of “But” as a part of GWT syntax and now I want to explore that however that experiment has not happened yet.

Given When Then as a feature documentation

To me, the technique of GWT was good for documenting very detailed requirements however it was not really intended to describe user interaction flows. For those, I preferred to rely on either use case narrative or interaction scenarios written as step-by-step instructions (see Alistair Cockburn’s book “Writing Effective Use Cases“).

Recently however I discovered that a few teams from a different department are in fact using Given When Then to document actual workflows in the system. Way more high level. I am not going to show examples in this doc because some of those flows are actually reflecting functionality not yet released but such flows tend to be a lot longer with easily 5-10 conditions if not more per clause. According to that team, UX designers really appreciated that documentation format. My take, however, is that designers really benefit from seeing interaction flows regardless of how they are documented. Nevertheless, it was an interesting adoption of Given When Then in practice.

My techniques of acceptance criteria documentation today

Currently, I work with two development teams. With each, the format of writing requirements is a bit different. In one of the teams, I take a lot more active role in actual spec writing and hence I tend to write requirements in a more detailed manner to simplify/reduce necessary communication. For that team, I am actually still writing acceptance criteria in a “given when then” format. It is a little different now as I am not really using a table-like format, primarily since most of the requirements I now write in Azure Devops while in the past I wrote them in Confluence and linked to Jira.

latest acceptance criterion example

Another, slightly more complex example with more conditions (each condition is written in a separate line)

The engineers working with these features appreciate the approach [if written properly] because there is typically clear scope for every scenario covered and it is easier to determine how to break the implementation down.

With another team, I am a little less involved with writing acceptance criteria on the story level as the approach is somewhat different. Instead of feeding the feature spec to the entire team, I engage a single person. When I prepare feature definitions and scenarios to be covered, I then go over them with the team lead who then takes scenarios and breaks them down either himself or with the rest of the team into bite-sized stories. He then goes ahead to prepare acceptance criteria (typically in a statement-like format) and it is my job to review them before they go to the team for estimation.

Despite the seeming lack of standardization, the different approaches seem to be working for both teams. I am curious in trying to adapt given when then with this other team and seeing their feedback but that is a story for the future!

Metrics vs Indicators

As I am currently preparing for a CBAP test and going through BABOK a lot of questions come up. I will use this space to post some of those questions and thoughts and findings I had. One particular question for me was the difference between Metrics and Indicators.

I realized I did not have a good understanding of the difference between the two. BABOK 3 defines a metric as “a quantifiable level of indicator organization uses to measure progress against objective”, an indicator “as result of analyzing of one or more measures for addressing a concern about a need, solution, etc.”. Now we come to a concept of measure that I don’t think BABOK clearly defines but I understand measure as “a quantity /value defined through some tool/approach”

None of those definitions were really clear to me.
After some digging, what seems to be the answer is that a metric is a measured state of some sort of a unit at a given point in time e.g. 10000 page views in a week while indicator is something that actually can be used to judge if you are moving in the right direction. If the objective is 1M page views by end of 2018 and current measure is 200K and weekly growth is 10% that means the objective should be hit as planned

At the same time not all metrics are indicators meaning that not everything we measure is really important.

A few links that helped to figure this out for anyone interested

https://www.linkedin.com/pulse/20141002153744-18927814-on-indicators-measures-and-metrics-recap/

https://www.excitant.co.uk/what-is-the-difference-between-a-measure-and-an-indicator/

http://experience.stratusinteractive.com/blog/whats-the-difference-between-a-metric-and-kpi

Opportunity Assessment and Problem Pyramid: another way to look at a problem

Disclaimer

In this post I will speak about two techniques to elicit a problem and present it. One is the problem pyramid and its light alterations that can be used to elicit a definition of a problem. Another is the opportunity canvas that in my mind can be used in addition to the problem pyramid or instead of it for the purpose of eliciting the problem definition as well as portraying it in a canvas like format similar to Product or Business Model Canvas.

Intro

Even though I have already been working with software requirements for over 5 years, I believe I still lack a well-formed and structured method of eliciting information about a problem and then describing it so that it can be addressed. I will be asking a lot of Whys and of course, in the beginning of the project I will utilize a well-known problem statement format to capture the definition problem being addressed. I find that very often it is difficult to put enough meaningful information into the template and it becomes too general and thus meaningless. Quite often, the problem ends up being put together as “legacy design that makes any changes to the software very costly to implement and support impacting level of customer satisfaction. A solution then is to reduce cost of making changes to the system”. Frequently the only solution option then becomes to replace existing software with new software as a way to address the problem. Other solution options are not being looked at period.

Couple years ago I have found out about the problem pyramid concept (term coined by Robin Goldsmith) that allows to present the problem very neatly.

I have used this tool retrospectively trying to understand how well was the original problem statement put together and was able to find flaws in my work. I have also used this inconsistently during the actual elicitation sessions when I was trying to grasp the definition of the problem as seen from customer’s point of view. There were some challenges with using this tool however because often my work starts not from review of a problem but from review of a solution presented as a problem. You might have encountered something similar in your career where you are given a specific project to work on that may sound like “Implement or replace system A with system B; Implement interface for communication between system A and B using API”. You have a few choices then: start doing exactly what you are told, trying to figure out functional/solution requirements in the process and communicating them to the team or question what exactly you need to do starting a series of conversations to get to the actual driver of the project and the problem it is addressing. When trying to reverse engineer the problem being addressed based on the incoming solution description, there is another tool that may come handy. If you have read the disclaimer, you might have guessed its name as Opportunity Canvas. If so, you are right, this is the tool I want to focus more on in the next few paragraphs. .

Let’s look at a couple of scenarios where these tools can apply.

Figuring out what the problem is using Problem Pyramid
Recently I have had an opportunity to elicit information about challenges with existing software we are enhancing faced by larger customers. The representatives of those customers were able to meet me in person so I organized an impromptu meeting with those people and included the product manager so he was aware of what was going on.

Initial issue brought up by the customers sounded like “inability to partition CAD incidents based on certain criteria”.

We had a whiteboard and I was standing in front of it doing my best to figure out what questions I actually need to ask. I could not come up with anything better other than asking them to tell me a story of what is happening today to understand the context in which the problem materializes. After understanding the context better, I focused on getting a better sense of the symptoms i.e. how the users were actually experiencing the problem. Next, I asked the question about the implications of the problem i.e. what is the outcome of the symptoms as they appear. Having got a better sense of that, I was then asking questions about what would it mean to address the problem i.e. what would success look like for those customers.  I also asked about any steps users do today to try and get the issue resolved – any software or manual processes involved.

After some discussion, it turned out we dealt with more than 1 problem. A specific issue that was elicited was that a CAD incident could disappear from the list of incidents visible to the reporter without informing the reporter that the incident was successfully transferred to someone else and was being worked on.  The implications were that the issue was causing fear among reporters of the incidents that the system did not keep track of the incident and hence it was not available for first responders (officers) to see. The implication of that was dispatch of the incident was essentially delayed and whoever needed 911 help might have received it too late. Successful resolution of the problem meant that at no point in time there would be a lost incident that no one in dispatch knew the status on.

My notes from the meeting look quite unstructured even though I was able to capture some of the key statements.

The definition of the problem that we could then discuss with development team came down to include the following aspects:

• Who is affected
• What are the symptoms (scenarios when issue materializes, how often the issue occurs, how the issue is experienced by the user)
• What are the outcomes (how does this affect the dispatch process)
• Why is the problem happening – root cause
• What is success (what would change if the problem goes away and how can that be measured)

This really looks a lot like an aforementioned Robin Goldsmith’s Problem Pyramid even though my notes are far from articulating anything as structured. Item in red is what I have failed to elicit during the face-to-face session with the customers and had to elicit via the phone prior to a meeting with the dev team.

The main difference with the problem pyramid is that the sections for solution options and actual scope of the solution were not actually filled in during the meeting with the customers. That was not done for a number of reasons – a) main goal was to first understand the actual problem b) doing both in a single meeting could well be an overload (similar to when I have tried doing as is and to be cjms in a single meeting).

The problem pyramid after the first meeting with the customers then looked like

To fill in items in red I needed an entirely different meeting where I actually presented the problem and then facilitated a silent brainstorming session with the dev team. In my opinion, it may be difficult and unnecessary to complete both the problem and solution parts together when dealing with a complex problem that is still ill-formed.

Where this tool fails in my opinion as well is capturing information about existing solutions and workarounds people do today because keeping that will be one of the solution options worth considering. Secondly, the problem pyramid is lacking context about the specific profiles of customers experiencing the problem and affected roles/personas. Something I refer to as the story unraveling which sets the context for the problem. That information can be captured however there is no immediate reminder about it in the technique’s skeleton. Nevertheless, it is a great tool that can be used during initial elicitation of the problem with the team or the customers.

Presenting the problem or opportunity using Opportunity Canvas

I have found out a term “opportunity assessment” from SVPG website. I have used that template on a project back in 2013 but can’t say it has helped me much then. Recently I read Jeff Patton’s book “User Story Mapping” that introduced a similar concept “Opportunity Canvas”. The purpose is to define the opportunity we are thinking about pursuing either by starting from the definition of the problem being addressed or the feature/product idea that might have come first before a problem was recognized.

I have used this technique twice in the past month and both times it worked well communicating what is known about a problem or opportunity so far. If we look at the structure of the canvas, we can see it is broken down to 10 sections, two of which are numbered exactly the same (Problems and Solutions). By the way there is an article explaining the opportunity canvas and specifics of using it in real projects that you can review as well. The author was also inspired by Jeff Patton’s book.

• Problems or solutions (1, 1) – pain points or solutions to certain pain points
• Users and customers (2) – who is affected by a certain pain point
• Solutions today (3) – if there are ways to address the pain today, what are those
• User value / How will users use your solution (4) – what is the value in case the change is made
• User metrics (5) – what to track to know the impact of the change
• Adoption strategy (6) – how customers will start using the solution and how they are going to be informed
• Business problems (7) – what is the value to your business given that a solution is in place
• Business metrics (8) – how would you measure success from standpoint of your organization
• Budget (9) – how much money, time and resources will this opportunity require

When a colleague was looking at this tool he asked me the reason for having two sections numbered exactly the same. Frankly speaking, I don’t recall the official rationale for this but my thinking goes back to the book where Jeff mentions that often we are presented not with problems but with solutions that we then have to analyze to understand the actual need for the solution. In this case, the starting point for the opportunity canvas can either be the problem or the envisioned solution proposed by one of the stakeholders.

Both times I used this technique I used it posthumously (after the actual conversation). This is of course not the best and effective strategy since the initial conversation that does not follow the format can easily miss some of the key elements that you have to assemble later to complete the canvas. That makes the whole process relatively ineffective. Nevertheless, even using the tool after the initial conversation but before any go-no go decisions are made still has merit.

What feels better comparing to the Problem Pyramid is that not only there is a place to mention the user and/or customer, but also that besides customer the business is kept in mind. Also, there is a place for a budget that can be used as a restraining mechanism setting clear boundaries for the cost of the solution. Lastly, the tool allows to specify existing workarounds or solutions in place allowing to assess the priority of the issue being looked at.

What I still lack even with Opportunity Canvas is the context element to describe in which context the problem actually occurs. I have a feeling that both customer section and adoption strategy could be used for that purpose however it is not intuitive. I also lack ability to describe scenarios in which the problem occurs. Finally, it really is unclear how to handle a case with a few related symptoms that may point to the same or multiple problems. Should an opportunity canvas be put together for each of those problems or a single canvas can be used to aggregate many similar problems into one.

To me it means that preliminary work needs to be done to dissect some of the sections into more specific parts. It is important to do a draft runthrough on your own, putting together everything you know in a canvas-like template. That will help to identify questions you definitely will need to focus on during the canvas workshop.

Conclusions

Here is my interpretation of how Opportunity Canvas sections can correlate to a Problem Pyramid.

Overall, opportunity assessment feels more like a tool to be used with a group of internal stakeholders (at least parts of it) when you already have a certain grasp of the problem to be addressed. At the same time, parts of it can be used together with problem pyramid when you are just collecting information about the problem you want to find solutions for. Also, the exercise of filling both problem pyramid and opportunity canvas can be split into 2 or even 3 parts: problem definition from customer’s perspective, problem definition from perspective of the business and solution definition if you don’t have the right audience for all parts at the same time. The problem pyramid can be enhanced with some of the elements of the opportunity canvas like Business challenges and Business Benefits to include the point of view of the business stakeholders onto the problem.

The resulting template for the customer/user facing problem definition would then include all of the items I mentioned above

• Who is affected
• What are the symptoms (scenarios when issue materializes, how often the issue occurs, how the issue is experienced by the user)
• What are the outcomes today (how does this affect the dispatch process)
• Why is the problem happening – root cause
• What is success (what would change if the problem goes away and how can that be measured)
• Solutions today  – existing workarounds

as well as the Solutions today section. In this case we should have enough information to put together a well-formed problem statement from customer’s point of view and later extend it with business perspective and then with solution options.

I look forward to trying this version of the tool and sharing what happens

 

Applying Customer Journey Map for capturing As Is experience across a suite of products

Disclaimer

I am a software analyst and in this and a few other posts I will be sharing my thoughts about systemworkflows I am revisiting at work, how I approach their redesign and what difficulties I encounter. This post talks more about development of a customer journey map for a number of personas across existing suite of products.  I haven’t written posts like this in a while and from a writer’s perspective they may honestly suck. I may also be wrong in what and how I do. You are free to tell me what you like, what you did not even get to because it was so difficult to comprehend and what you don’t like/don’t agree with. The way to get in touch is Facebook, email (donotcross03 at gmail dot com)

Intro

There are two capabilities we plan to include for users in the feature set we are currently working on: adding persons and vehicles to a CAD (Computer Aided Dispatch) call. While it sounds simple, this work becomes quite challenging because it affects multiple products used by different roles.  In the past I have already done the investigation on the side of the product I am working on (911 incident dispatch software) and that research gave me a relatively good understanding of the work to be done in the context of a 911 dispatcher’s workflow.

Information coming from dispatch however can be utilized by other personas like first responders (fire fighters, police officers, command staff) and record clerks (records division in police departments usually) meaning that there are integration points in system workflows between dispatch and responders, booking officers and record administration. This also means that whatever we want to build, needs to be designed in such a way it could be integrated into all those workflows that I still did not have a good understanding of.

I needed to understand the integration points between our part of the puzzle and the other products before putting together a vision of the to-be state for user flows we were planning to add. After thinking about the tools that could let me do that, I ended up selecting customer journey map for definition of as is experience and user story map for description of the to-be state of things.

Below I am sharing my experience with the technique and some of the observations.

I am not going to speak much on the topic of how great customer journey mapping great and provide a lot of details on all of the scenarios where this tool can come handy. There are existing great articles already that can tell you more about customer journey map: http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3367/Customer-Journey-Mapping-for-Business-Analysts.aspx, https://www.slideshare.net/vedenin/customer-journey-mapping-for-business-analysts, https://conversionxl.com/blog/customer-journey-mapping-examples/, https://experience.sap.com/skillup/discover-your-wow-factor-with-customer-journey-mapping/. There are even tools online that you can use to start building your CJM (e.g. https://uxpressia.com/).

The reason I have chosen cjm is that this tool provides a way to decompose user’s interaction with a product or a company in general from high-level tasks and goals to very specific steps and elements the person is interacting with. Besides that, the tool can help to capture the emotional aspect of interacting with the software pinpointing areas of experience today that are causing frustration and are subjects for improvement or on the contrary cause delight and therefore should not be lost.

My plan was to organize a two part meeting where during the first meeting we would build an as is cjm involving person and vehicle information and then during the second part of the meeting we would assemble the to-be part of the process primarily affecting dispatch. Spoiler alert: the second part of the meeting did not work out very well and that is one of the lessons learnt from this exercise. Nevertheless, the part where we have described as is experience, worked out pretty well.

 

Theory

CJM allows to convey the story of using a product through quite a few lens:

1. Persona – a specific type of the user / customer who is working with the software
2. A certain segment of user’s entire experience with the product (finding out about the product, using the product, interacting with support)
3. User goals (understanding what the user is trying to achieve during that specific part of the process)
4. Touchpoints (parts of the software, specific persons a user is interacting during their experience with the product)
5. Process / tasks (actual steps of the user, specific actions they take)
6. Emotion (feelings the software invokes during the process of experiencing it, be those positive or negative)

These lens are coming from Uxpressia’s CJM template (see image below). SAP presents a slightly different view – you can review it by following one of the links above.

The idea of the technique is to break down the experience of a product by a user to phases and then go through the specific steps in each one of those phases to understand areas of improvement that then can be used as the rationale for new projects and become target outcomes whose project strive to achieve. The length of the process of preparing a high-quality CJM can vary from hours (for smaller products) to weeks (researching the CJM of interacting with a large company like an airline) and can consume a lot of resources.

Preparation for the workshop

Since I was planning to have a 2 part workshop where both as is and to be would be explored, I invited product management representatives as well as onsite developers and quality assurance from my team. There are pros and cons for doing it this way. On one hand, developers may not be as effective in contributing to the as is process since typically they don’t interact with users as much as product management does. On another hand, product management representatives from other products may not necessarily be the best audience to come up solutions specific to your part of the product that they not be very knowledgeable about. The one definite positive outcome of such a team setup is that at the end of the workshop, both development and product management come to a shared understanding of what is typically happening in the product today. In my opinion, another positive side of this setup is that everyone is more alert to the meeting because the conversation about how the interaction takes place is happening now and there are questions being asked and eyeopeners coming up this very moment

Since I knew I was pressured on time, I tried to focus on phase, touchpoints and process for specific personas skipping emotions however those did come up primarily after realizing the deficiencies in the existing workflows.

To actually conduct the workshop, I needed to have some preparatory materials explaining the customer journey map (I had my materials ready from a workshop I ran in January with dispatchers so I planned to reuse those), my rough understanding of the existing cjm (in case the whole conversation turned out to go the wrong way, I needed a plan b that could be used to trigger thought process in the group), and a few reminders (I’ve printed out images of some of the most used screens in the system to remind attendees about the workflow users were going through). That actually proved to be helpful when identifying pain points in the existing flows.

I also took a few large paper sheets we usually use during our periodic SAFe-based release planning (that is something worth another topic on its own) and placed them on a wall.  The idea was to use the drawing board for as is process and then switch to to be and map it out using those sheets glued to the wall.

As for the group size, the workshop included 3 product managers for products that represent a large set of the entire suite, myself, 2 senior developers, 1 QA and 1 UX designer who was primarily observing what was going on. I have sent out the invites in advance however I failed to mention that the workshop is intended as a primarily offline activity. Because of that one of the product managers was present remotely constantly watching what is going on via a camera.

The exercise I prepared as an introduction to cjm is quite simple and easy to do. It is a task to draw a map for ordering food for a family gettogether on a Sunday evening while watching a movie. I have prepared a few slides explaining what I would expect from the participants and even did my own cjm for that in case things really go south however once I’ve explained what I want: phases, steps, touch points and told them it was ok to draw using blocks everything went really smooth. You can review the full example here https://docs.google.com/presentation/d/1BBmLfWXaE6BEAoWYisx4rou8J5lp8vdN_sdyffK43dI/edit#slide=id.p

Lastly, to run the workshop I also needed to define the approach – whether it is scenario-based and we review everything in context of a certain nature of a 911 call or it is a generic 911 call and we try to outline all of the possible branches the call process may follow. After a discussion with a UX designer, I came to a conclusion it was best to focus on specific scenarios rather than describing a generic call that would add too much often irrelevant facts and make it really easy to forget specific steps that may come up only for certain natures (i.e. how an in progress robbery is handled may differ from a suspicious person or domestic violence call).

The workshop, actually

The workshop was scheduled for 2 hours with the first hour dedicated to investigation of as is experience. It actually took 1.5 hours and one of the contributing factors was that not all of the participants realized it was an offline meeting only so some of the time was eaten communicating updates to the person online however we found a way to mitigate that more or less.

Before we have started I have shared the agenda that included the following main points:

1. As is process from a 911 call to what happens after arrest
2. Integration points between P&V throughout different products
3. To be process for person and vehicle entry

I have explained that we would be using the cjm for this and explained what cjm comes down to (the lens described above).

The first step was to determine the actual phases of a 911 incident and put those on the board. Initially, it felt more like a show and tell activity where I am standing in front of the board and everyone is waiting for me to write stuff and then nod in agreement or disagreement. That however was exactly the type of thing that I wanted to avoid. Because I was pressed with time, I skipped the exercise of trying to draw our own cjm for a pizza evening and very briefly explained it by drawing the blocks representing phases of the process (Determine food, find pizza place, find the right pizza, order, get delivery and enjoy the meal). I had to call everyone to the board to make sure engaging the participants into the conversation was really easy. That actually helped and everyone being closer to the board and given an actual marker had more rationale to do something.

The product managers were the ones who helped me to define the actual phases (911 call, CAD Incident, Arrest, Booking, Report, Report to prosecution, IBR report, Court case, Sentencing and Jail Management). Since the software we are developing does not cover some of those phases like Report to prosecution, court case and sentencing), those were mentioned with diving deep into details of what actually happens in those workflows.

The next step was to actually find out what is being done process wise by involved personas during each of the phases under discussion (911 call, CAD incident, Arrest, Booking, Report, IBR report).

I have used a specific example (domestic violence in progress resulting into arrest). Domestic violence is a frequent flyer in the world of 911 incidents where one of the spouses exerts verbal and/or physical violence onto their partner or children. This scenario may evolve into a variety of others including homicide, shooting, manslaughter, etc.) and can be a good starting point to understand all of the involved public safety processes

Adding meat to the bones

During this part of the workshop, we focused on adding actual details to each process phase. CAD Product manager added details related to the 911 call and CAD Incident. Law Product Manager was collaborating with Records Product Management (both were law officers in the past) on the arrest, report and IBR part of the process. As you can see in the resulting map, some parts were left blank (intentionally). At the end of the exercise, this is what the board looked like.

Digitized map

I have then converted the map into a digital format using uxpressia.com that turned out to be a nice tool for my purposes. There are some things that took time to figure out but I was able to put the whole thing together probably in under two hours. The result looks something like this (I removed pain points and ideas from here for the purpose of not releasing sensitive information)

Next steps

The As Is map was intended to be the first part of the meeting and frankly speaking I probably should have stopped right there since the to be part of the meeting clearly did not go as planned. I also had to stop it half through since I already ran over time scheduled for the meeting. I think I will focus on the to be map (I will use storymapping to define it) in one of the next posts.

Lessons learnt

Number one: As is map is a good way of bringing different people to a common understanding. It is helpful for product management, development, myself because all of a sudden you are seeing the whole process in front of you with touchpoints, pain points and areas of improvement. You can challenge your own assumptions and build something common using the parts coming from everyone

Number two: when covering bigger processes, it is a bad idea to combine as is and to be into a single meeting because of complexity, amount of thought involved. Fatigue will develop naturally resulting into lower engagement level among participants

Number three: this exercise can easily take days hence it is important to understand what it is exactly you are trying to find or what aspect of the entire flow you want to focus on

Number four: you don’t necessarily need to build the map of the entire process if you are making changes to a part of the process. The reason I tried walking through the whole process was that I never did it before and felt this would be a good opportunity

Number five: it is important to develop a scenario-based mindset in the events of a complex process or a process crossing multiple products otherwise there is a high chance of getting rid in the myriad of details that may not be relevant in a particular scenario. If you want to compare or build alternative maps, you can dedicate a whole day to running a few scenarios and describe different maps every single time. This time I was unable to organize a day-long workshop with product managers

Number six: it really is debatable whether or not to invite development to as is maps. On one hand, hearing the conversations they are likelier to understand more about the current process and better see the problems we are trying to address. On the other hand, it is valuable time that can be spent on other important tasks. Up to you to decide!

Number seven: it does make sense to do a warm up exercise with a simpler map to build the right expectations with everoyone and transform the exercise into a collaboration as opposed to show and tell the main problem with which is not picking brains of others enough to have the learning happen

Number eight: bringing food (donuts) is a good idea because it gives people sugar, boosting their thinking process and b) who does not like donuts?

Number nine: sharing info in advance is optional. Someone will review it however most likely not

Number ten: prepare screenshots/wireframes/images from existing product, photos of existing customers to trigger thought process. This also means you may need to have done some preliminary cjm yourself just to make sure you can help bring everyone back on track in case someone wanders off

There are more things but I think I will stop here for now

Writing “Confessions of a dangerous mind”

I was thinking about “Confessions of a dangerous mind” with Sam Rockwell when writing the title. Truth is the post has nothing to do with the movie, so everyone interested in the movie – feel free to skip the article or search for better places.

Here is a copy of a poster for the movie fans not to feel bad. This was just to get your attention

—

This year I was involved as a co-organizer of a Product Stream at IT Arena Lviv conference 2015 (itarena.lviv.ua). Prior to this I have organized just one event – Eleks Battle of the bands in 2013 – so I can’t say I have a wealth of experience in the area. My main responsibilities this year were to guarantee quality content i.e. find speakers and ensure they present at the event. I have found a few interesting folks (according to feedback I’ve heard) but now I realize how far the initial plan was from the actual execution. This post is a braindump of things I wanted to share after the conference. Some of ideas require a lot more elaboration and deserve separate posts. If you have enough patience to go through this – then maybe you can spend even more time and share your ideas and experience in event management via comments to the post

—

• Design of the event
  • Waterfall is still alive. Almost any event is a great example of waterfall. This is particularly valid for conferences. This means that all phases preceding to the actual execution take 99% of time and therefore need to be thought through for the execution to go well
  • It is essential to define goals of the event. I knew goals of Eleks as the company I represented as a co-organizer of product stream but I did not know goals of the rest of key organizers. This made me narrow-minded in understanding the attendees of other streams
• People buy tickets to the conference and not a certain stream
  • Attendees don’t distinguish Product stream or Business stream or whatever stream as different parts of the conference. For them this is a single experience for which they have paid money and they expect the same level of quality and experience at any speech of any stream they attend. They don’t know the conference streams may be organized by different people or teams or they don’t care about that. They care about 3 days they spend at the conference
  • This means there has to be consistent work among stream leaders to help one another with speakers, content, promotion and any questions that arise as the conference is a shared responsibility. Failure of one stream becomes a failure of the entire conference
• Guidelines for presentations – how to define a high-quality presentation
  • What should be inside content-wise
    • Takeaways
    • Learning outcomes
    • Text + image combo or text limits
  • Font size
• Presentation censorship
  • Should not be 1 person making a decision about speakers
  • Should be a group of 2 or 3 that review on a regular basis to ensure unbiased decision
  • Keep track of all speakers who have already participated
  • Introduce a mechanism for rating speakers to decide whom to invite
    • Past experience
    • Topic
    • Presentation skills
    • Past ratings
    • Personal knowledge of the speaker
    • Travel cost
    • Cost of stay
  • Work with speakers – iterative approach
    • Central idea
    • Main takeaways/conclusions
    • Slide titles
    • Actual meat
    • Visuals
    • Presentation
    • Define timeframe for each stage – should be completed well enough before conference
    • Train speakers to present or check their presentation skills / if a speaker doesn’t agree – let them go and don’t let them participate
  • Substitute speakers
    • High risk that should be considered
    • May be needed to find 2-4 substitute speakers
    • Should be given some form of presenting at the conference not to feel second best
  • Workshops
    • People need to be motivated to come to workshops
    • Workshops should be paid separately
    • Integrated environment – buy conference ticket, workshop ticket or combo
    • Prepare real cases for audience
    • Collect audience expectations
    • Promote workshops through opinion-makers
  • Work with top level management
    • People at the top are often there for a reason and could be strong proponents of ideas so they should at least be made aware of opportunities. From there they can figure out who to involve
    • Senior people should be kept in the loop from the very beginning as that helps to generate even more ideas
  • Food catering
    • Lines like they are don’t always work. Lines helped Tom Gilb to start speaking to Alex Skrypnyk but that could be a rare exception
    • Need to think of ways to get speakers holding the floor right after lunch to eat quickly
  • Inviting speakers
    • A formal letter is not really important. Time is money. It is more important to check speaker’s availability on time than to spend a couple weeks preparing an official letter to find out it is already too late to invite the speaker
    • Timeliness of the invitation is key (6-8 months in advance)
    • Graphics is important – visual part of the invitation should be there
  • Keynote speakers
    • Keynote should be someone known by everyone regardless of age. That person should be the candy everyone is looking for
    • Keynotes deserve to be paid
    • Keynotes should make the people want to attend everything at the conference
    • Keynotes should be fun
  • Conference language
    • There should be one language of the conference. Speakers should be checked against that language. Questionable statement
  • Conference timing
    • There should be breaks between presentations to give people enough time (5-10 minutes)
    • Don’t put a keynote for 9am on days after registration or promote the keynote
    • The number of presentations in one day should probably not be higher than 8 (considering 40 minute long or so)
  • App improvements
    • Engage attendees more into conference by introducing more features than attendify app (rebranded for it arena) has
    • Local Bas and UX experts can be involved into design and development of those extra features i.e. thing feature through and mock it up
      • Reminder to rate speaker at the end of the speech
      • Other ideas tbd
    • People should start using the app a lot earlier than the conference starts
  • Screens and places
    • If there are tv screens available they all can be used to show conference speakers or presentations in real time not like this time where a bunch of screens was showing a static image for 3 days of the conference
    • Adjustable screens or better / larger screens
    • Multiple working screens in rooms with columns
  • Speaker companions
    • There should be someone responsible for either a foreign speaker or a keynote speaker and helping them get in touch with key people from different companies
    • There should be a person who is able to lead networking and serve as the connector between speakers and different executives/key people present at the conference
  • Talk to other related conference leaders and get them onboard to promote the event
    • Not direct competitors i.e. not happening around the same time
    • In this case, invite leaders of conferences like UXPoland, Agilia to get advice from them before and after the event
  • Conference experts
    • In case the organizers (or one of them) is not a professional organizer, there should be a 3^rd party consultant involved to help with pressing issues)
    • This will help to ensure many of items outlined above are at least known and considered
    • This is what of one of the speakers mentioned to me in a dialog. “Let’s say you have google, internet, scalpel and you need to do a surgery on a heart of a friend. What will you do? Call a professional or rely on youtube videos?” and this makes sense as there are professionals who have already done quite a few things to get a knack on what needs to be done to make a conference successful

BA Personas – Consumer, Detective or the swindler

Recently I’ve been thinking about Business Analyst personas and their portraits. Right now I am seeing three major categories that I am calling after fictional characters I’ve either read about or have seen in the movies. Of course there are more but these are the ones that nearly jump to my head.

These personas are Johnny Mnemonic, Sherlock Holmes and Moist von Lipwig or Consumer, Detective and the Swindler

Johnny Mnemonic

In my previous project I’ve mostly tried being Mr. Mnemonic who is a data courier from the future with HDD in his head working as a mule of information. The guy literally dumps everything into his head only to forget about that once the project ends. He has to sacrifice part of his memories to remember what’s needed and stay with that information overdose until its over. Such a BA is trying to read as much as possible about a project/problem, dumping all sorts of data into head without spending enough time to process it. Being Mnemonic is like trying to swallow a Big Mac in one go. It may be possible but you won’t feel well afterwards.

The more I think about this, the less I find this approach working in real life. First of all, concepts from how many domains can a head reasonably hold? I find it difficult to believe it’s possible to keep up with knowledge from more than 3 domains at the same time because a) at some point the knowledge becomes obsolete and is no longer useful unless some maintenance work is done b) its tough and not always useful to be a repository of masses of data because that data needs to be processed and processing takes time c) the devil is in details so dumping a lot of data helps understanding the concepts but it is not possible to become an expert in a short period of time (a few weeks or a month) so that won’t allow to replace a SME on a project d) memorizing way too many things means not being able to do something else and spending time more fruitfully.

To me it makes sense to dive deep down into a certain domain on a long-lasting project or when there is interest in a particular business domain. In the reality I currently face, it is frequent that BAs either spend years on certain projects/accounts becoming SMEs in the industry and customer organization knowledge holders or on the contrary jump between projects of different sizes in different domains. Going deep does not make sense on a 4-6 months project because doing so every time will be too expensive and still does not guarantee quality BA work. I want to avoid being Mr. Mnemonic in the future on the projects I start. What is peculiar however is the root cause of willingness to become Johnny Mnemonic type of character. One of the reasons I see is the fear in not being able to speak the same language as the business guys or technical guys…project stakeholders whatever and lack of domain modeling skills. Another possible reason of why this is happening is the lack of ability to organize communication and build it so that knowledge is owned not just by one person/one BA but a growing part of the team. Finally, a symptom of Mnemonic may signal issues with systems thinking and ability to cut and slice domain into processable chunks

Sherlock Holmes

Well I can’t boast sharing the traits of this persona but the way I see it is an investigator going the other extreme. Instead of dumping as much knowledge is possible, the person spent some time on developing deductive reasoning and invested into learning very specific details to support deductive reasoning. Another important trait is the skill of observation. This is a true skill of Sherlock Holmes type of persona and it provides ability to see specifics that can support or help to determine a hypothesis. Plainly put, this is an extremely meticulous person with impeccable planning skills and a gift for observation. Sadly enough, this is not me. This character is also stifled by boring and routine tasks that may undermine the ability to solve problems.

Moist von Lipwig

For those who have not read Terry Pratchett’s “Going postal” or “Making Money”, Moist von Lipwig is a brilliant swindler, playing on fears and greed of the crowd. At some point, he is faced with dilemma of taking a governmental job or losing life. He chooses to live and becomes a very creative and remarkable manager of the postal office and then of a state bank applying all of his conman skills for the public good.

Of all the characters, this one is my favorite and the one I’d like to become one day. Not in the sense of cheating people but being able to combine the needed skills of the two characters above with creativity, empathy and humor.

A swindler or a conman at least one like Ponzi, Mavrodi, Frank Abagnale from Catch me if you can is skilled in dissecting the system and seeing its weak points. This means both observation skills and ability to be an agent of change. Through the con actions, the person challenges the system and makes it strive to adapt to the new challenges. Better security systems come up as a result of successful robberies or fear of such, fraud exists because of imperfect systems and business processes and it helps to detect such imperfections. At the same time, putting a crook at the top of the pyramid can mean one of the few options – either a very bad system with things like nepotism or a very well designed system exactly because it is designed with vile nature of humankind in mind.

A good conman needs to be empathic to understand how to approach a potential victim. A good conman also needs to be quick and witty. A good conman is also lazy and will carefully consider the pros and cons of doing something as time consuming as completely mastering a new domain. A good conman will have his favorite techniques ready at his fingertips. A good conman can be a dreamer and lead others. Sometimes this dream can be a mirage but of a really big scale.

On the contrary, a good conman needs control at least in certain points and this control should be rather strict. Also it requires having someone with an even greater con-artistry talen standing above him.

Another possible challenge with Moist is accountability in the sense that Moist-type of BA will try to avoid situations where he is accountable of something as much as possible. He will accept the responsibility only when properly motivated or controlled (where his head is at stake) and in all other situations will build the system in such a way he gets the most with minimum effort. This can be a particularly good skill when it comes down to things like MVP development to define the minimum amout of work to be done for things to work.

Alright, this is the end of this post which is rather a “speaking out loud” type of thing. Would be interest to hear of other BA profiles / personas from whoever is not bored to look through this. Next thing that would be interesting to do is try to map the profiles to popular types of projects.

Business Analysis, design thinking and movie making (Pixar)

During a trip to Spain I have visited Pixar exhibition at CaixaForum in Barcelona. The expo described 25 years of Pixar’s animation history, their projects and approach to movie making. I was surprised to find out how meticulous and detailed their approach was. Also, I was surprised that their design process appeared like a very firm, thought-through combination of waterfall and iterative approaches. It was also interesting to learn that Pixar started as an actual technological startup that provided hardware and software products for animation for example for Disney.

I was not allowed to take pictures in the exhibition hall but I’ve tried to memorize some of the items that really stroke me. So, Pixar’s approach in a nutshell:

1. Story
2. Script in text
3. Storyboard and digitalized storyboard
4. Video reel using storyboard
5. Storyboard in color
6. Modeling and prototyping i.e. to create actual physical objects
7. Rendering and filming
8. Voice over

Here is an article about pixar animation approach with more details

I may be missing a few steps in between but what I recall is that the part before rendering the movie took roughly 3/4 of the entire process. Before starting to actually film, there is a story and a script written, designers then draw and prepare storyboards without considering actual implementation and any technical constraints. This is done so that designers free their minds to the maximum and stay as creative as possible. The engineers will then try to figure what and how can be implemented but in the beginning, this is a no limit stage.

This part (no limit creativity at the time of design) reminded me of a couple of stages in design thinking process – what if and what wows. According to a number of sources, there are 4 main questions that drive design thinking process: what is, what if, what wows and what works. The story  part of the process seems to match to the “what if” phase where the character is invented and is put into an unusual environment/story  in which the character will need to act in an usual manner to fully uncover the potential. The storyboarding and its digitalization reminds of “what wows” as at the storyboard and modelling stages the concept of what is going to be in the finished movie is prepared and tested. All of the images designed here will be then rendered using computer graphics but it is the quality of the thought and creativity put here that will define how successful the movie will be.

When I started thinking about this more, I’ve realized that their process also reminds of a part of software developement process and can be mapped to it quite nicely together with some of the deliverables produced at different stages of the process.

1. Story corresponds to a product vision and helps to understand what the product is going to be all about and why it is distinct
2. Script corresponds to use cases as it provides the interaction view on everything happening in the product (business and system level)
3. Storyboard can be mapped to both the storyboard/navigation flow as well as the wireframes
4. Modeling and prototyping is the actual prototype of the app, either in prototyping app, paper or in code
5. Rendering and filming with the voice over is the actual implementation/development of the product at the end of which there is a finished product (in most cases :))

What is interesting however is the difference between time and effort spent on script, storyboarding and prototyping  vs actual development. Unlike in agile projects, development moves forward only when the “thinking through” part is over and everything has been completely defined. Characters/personas have been defined to their fullest, all interactions have been written in great details and there is clarity on the sequence of events from start to end. I could see how much research and analysis goes into character design after  seeing in the part of the expo dedicated to “bug’s life” the drawings of different types of bugs in their actual sizes and comments on proportions of parts of bodies. There were even drawings of different types of bug eyes to make sure actual biology is taken into account so that the designed character looks realistic.

Of course,there are differences between movie making and software development but in general I get a feeling that it is worth to learn more about design approach in movie making and see what parts of it can be reused in business analysis and product design parts of a software development project. One idea that comes to mind is to write requirements documentation more like movie scripts (maybe that would at least make people want to read them :)) and rely on storyboarding a lot more heavily. It would also be interesting to learn about script and storyboard review processes in movie making to understand how exactly that happens and how many people get involved in such activities.

Pixar has produced a handful of movies but each one of them is a masterpiece and I feel like there is a lot to learn from them and movie making projects in general about how to make commercially successful products that meet different constraints.

Planning BA work for onsite project discovery

In this post I am looking at the techniques to eliminate / reduce impact of Business Analysis planning mistakes during discovery phase especially when the customer requesting the project has not conducted feasibility assessment. By lack of feasibility assessment I mean absence of clearly formulated goals or lack of business case – basically a scenario when decision to proceed with a project has not been made yet. Main techniques I will look at include

• stakeholder map
• context stakeholder map
• problem list/problem statement
• root cause analysis

Intro

Recently I’ve been involved into a discovery phase for a new client of the company where I work. We were tasked with development of a solution approach to help the company achieve their objectives. The original request stated something like “Application UI facelift to transition to HTML5 and optional DB changes”. The onsite visit started with interview sessions and it took nearly three days to collect information about goals and objectives of different stakeholders. At the end of 4^th day onsite I was still not clearly understanding the direction in which I should be moving after 6-8 hours of daily meetings. I did not even have enough time to process all of the information I have gathered to see whether I have enough to make certain claims or I still needed a few more sessions. At that point I felt like Atlas holding the vault of sky and that was not a good feeling! For the customer this also raised questions as from their perspective they were giving all of the requested information but I still was not able to come back with specific solution approaches to help them achieve the goals they were stating. There were too many goals and too many approaches to start from!

So what exactly went wrong?

Poor planning may immediately jump out as the answer but what exactly would that mean? After giving it some thought and discussing with a mentor (thank you D.Bezuglyy), I come to the following conclusions and gaps in my work

1. Stakeholders were not mapped to the problems they wanted to solve
2. Stakeholders were not categorized according to level of influence and importance
3. Schedule was not in line with the defined stakeholder map
4. Stakeholder expectations for the discovery portion (analysis phase) were not fully elicited
5. Problems at hand were not properly prioritized to identify the key problem for the project and remove other problems from scope. This also led to challenges with expectations management in general as there were too many items to consider without a clear focus

Why did this occur exactly like that?

For one thing the customer organization has not conducted a feasibility analysis themselves and therefore they did not have a clear sense of the exact problem they wanted to solve, the exact cost of that problem and expected ROI. As a group of technical consultants we were called on stage before the decision to even start the project took place. What does it exactly mean? I kept working in the context of multiple goals/objectives without a clear sense of whose objectives are to be serviced first.

On another hand, as a Business Analyst I did not articulate that issue to them early enough and did not focus sufficiently on helping the business side to arrive at a summary of a single problem they would like us as a technical team to address first. As a business analyst I aimed at gaining an understanding of the cost of existing problems to business and possible financial benefits realized due to project implementation. I was trying to address the problem that required a higher level of authority and I did not articulate this to the customer as a part of general expectations elicitation.

So what did I learn from this and how can this challenge be overcome?

After discussing this with a mentor and projecting onto environment in which discovery took place I have the following understanding of the BA approach to analysis phase when no / limited project feasibility analysis has been done.

1. Model the organizational environment to get a sense of main organization blocks and their issues (Context Stakeholder Map)
2. Perform root cause analysis to identify business priorities as the problems to be addressed
3. Model environment of a specific problem
4. Identify dependencies and conflicts pertaining to the problem at hand
5. Develop problem statement together with success criteria for the problem to be considered addressed
6. Develop solution scope definition/solution context

 Let’s look at the steps in details.

1. Model the organizational environment to understand problem at hand

Canvas business model is a good way to provide a 10,000 feet view of the organizational structure (as-is). It’s a good tool but I did not really use it this time. Another powerful technique is a stakeholder map.

Stakeholder map helps to reflect all of parties already involved and to be involved into conversation together with their expectations and problems. The central block of the map at this level is the organization itself or the main goal the organization seeks to achieve. Stakeholders don’t exist in the vacuum so it is important to always keep in mind the central part of the map that brings all of these stakeholders together. Such a map could be developer per each problem that is being investigated or for a group of problems that correlate to a higher-level objective

The main objective at this stage is to articulate all of the stated objectives that come from different parties in the organization

After this is done, the next step is to categorize parties identified in the stakeholder map based on their influence in the organization and by their degree of contribution to the organization e.g. decision-makers, influencers, users, providers, etc. Decision-makers block in my case included CEO, CTO, Product Management director. Influencers block included VP of Development,  VP of marketing and Implementation Director.

The tool to categorize this can be the influence vs importance matrix that helps to group stakeholders based on their influence. That technique also helps with keeping track of parties that may have negative interest to addressing a specific business objective which can be quite important for any project. Another group of stakeholders to be identifies is the group of irrelevant objects that are not in context of the problem being solved and therefore can be dropped.

It is important to identify stakeholder groups to make judgments on whose problems / objectives are really to be considered as a part of the project. In case there is a clear sense of decision-makers and the goals they want to achieve than those goals can be used to shape the direction of the project.

Stakeholders are categorized based on the fact whether or not they can impact the direction of the project and how heavily (influence) as well as the interest they have in the project (high, low, negative). I am still struggling to understand how exactly this breakdown works but the likely scenario to identify level of interest is by gaining knowledge of specific items/benefits a given person would get if a project was / was not successfully delivered.

Despite the many meetings that have taken place, they still did not bring enough clarity as I’ve tried to consider problems of all of the parties I’ve met with without defining any sort of priorities. Given that the decision makers are known – CEO, CTO and product director, I should have elicited their needs first and then based on the feedback I get from each one of them update the stakeholder map and the list of objectives associated with each person.

Another technique that can be used at this stage is the preliminary problem list where all of the problems brought up by the stakeholders are written down in the problem statement format. The intention is to write those problems as sentences that can be read to understand a specific problem of a specific party and how that problem affects that party.

An example can be as follows:

Problem of Legacy technology affecting CTO‘s ability to manage timely delivery of features planned as a part of product roadmap and impacting delivery of items committed to existing customers or to product management to enable further organizational growth.

The list may consist of many more statements that will then need to be prioritized. Analyst’s job at this stage is to provide them as input to decision makers to identify priorities and help analyst reduce the number of problems at hand

2. Perform root cause analysis to identify business priorities

This step is more appropriate in the scenario when there is no clear sense of a specific business problem to be addressed first.

Let’s look at example of objectives posed by CEO: a) increase revenues through facelifted UI of the product b) reduce implementation time for the product c) replace existing payroll product that was costly to support. These objectives are different and call for different solution options. It is of course possible to design solutions that satisfy all of these goals but is that really needed to address all of those problems at once? One problem may be more important than another. In this case, I need a clear list of priorities from the CEO. In case this priority list cannot be easily obtained from a conversation there are ways to get to it using current reality tree and root cause analysis (e.g. pareto chart or fish bone diagram)

I will look at an example of a root cause example later in this post.

3. Model environment of a specific problem

Once the focus has been determined i.e. understanding of the specific problem to be addressed is there, as a BA I can proceed to definition of the problem context. In this case I still need to understand the organizational context to be aware of people I may need to go to but this time I am focusing on the macrocosm of a specific issue as opposed to all issues the organization is facing. In my case, the specific starting point has been the payroll application that the customer wanted to replace so this time I can work on defining the context of the problem in which I will be working. This context map is a more focused version of context stakeholder map that may also include non-human parties. The main goal here is to give a sense of all parties associated with a given problem. In case with payroll software product, this includes the parties within the organization selling the product as well as the parties outside of it who are end users of the product.

4. Identify dependencies and conflicts pertaining to the problem at hand

This step is relevant in case there is a conflict between stakeholders within the space of a single problem. This also means the need to perform a root cause analysis and a possible current reality tree (link to this technique is at the end of the post)

I have not used root cause analysis heavily before so this technique is quite new to me but the main goal is to identify and outline all the factors contributing to a given problem. In case of payroll application redesign project, the problem at hand would be high cost of support of existing product which in its turn could be broken down to a few more specific problems as for example cost of payroll product implementation. There could be a few layers of root cause analysis here to a) identify key contributing factors b) identify root causes behind those contributing factors.

Here is an example of a fish bone diagram I’ve put together for purpose of understanding the technique. It is not quite detailed but it can serve as the starting point for the conversation regarding specific reasons behind long time of payroll setup and why exactly payroll configurations and data import as well as other setup activities consume so much time.

As a result of this diagram, it is possible to start investigation of factors that contribute to such a lengthy time with payroll setup components as configurations and Year to date (historic) records import. There will be a list of causes driving those issues and they can be identified and described using the same approach.

5. Develop problem statement together with success criteria for the problem to be considered addressed

At this stage I am working on a more detailed definition of the problem at hand. The main objective is to arrive at a statement that covers the majority of needs of decision making group and define success criteria for the problem.

A well written problem statement avoids use of solution language so that specific solution options don’t distract attention and don’t provoke certain solution bias. This is another aspect of work I need to improve to ensure the business requirements are written in such a way they are agnostic of a solution.

6. Develop solution scope definition/solution context

At this stage, I start moving in the direction of the solution domain and start working on defining what the solution entails. This is more of definition of actors who will use the product as well as the use cases the product should support so I am not going to provide details on this now.

—

Frankly speaking I have not written this long of a post in a long time so hopefully whoever reads this does not get bored.

I did not write about storm clouds and current reality tree as those deserve a separate post and I can’t say I’ve mastered those techniques well yet.

As for materials I’ve used and considered for this post, here are a few links

• http://www.stakeholdermap.com/
• http://www.managingforimpact.org/tool/influence-and-importance-matrix
• http://cs4760.csl.mtu.edu/2014/resources/Onion.pdf
• http://www.ceptara.com/blog/how-to-write-problem-statement
• http://en.wikipedia.org/wiki/System_context_diagram

Worth reading separately

• http://www.sbaclub.org.ua/2013/01/blog-post_29.html (storm clouds)
• http://www.sbaclub.org.ua/2013/01/blog-post.html  (current reality tree -> from theory of constraints)
• http://gsvc.org/wp-content/uploads/2014/11/Stakeholders-Identification-and-Mapping.pdf

Business Analysis Work Planning Mistakes

In this article the author investigates most common mistakes of a business analyst during product/project analysis phase

Main mistakes include:

1. Lack of domain glossary needed for the project (half checkmark)
2. Poor expectations management from analysis phase – not asking customer regarding what they expect to get as a result of analysis
3. Not agree on templates/format in which analysis results are delivered (Checkmark)
4. Not try to elicit and outline customer’s risks
5. Don’t try to reuse past experience  – very challenging to do in reality
6. Try to follow the process without understanding what to do
7. Lack of clarity regarding what to do next (half checkmark). A lot of information was requested but it was not properly analyzed in fact

Conducting my first BA+UX workshop

The idea of the event was to investigate an internal process of business travel management and to identify existing pains and try to address them using

• combination of business analysis and UX techniques
• a lot of clever heads
• prototype a possible solution

This is more of a followup to make sure the important items are not forgotten

What I did good:

• game for group dynamics and to set the mood (marshmallow challenge with spaghetti)
• eliciting expectations from everyone
• getting everyone involved and active (I am particularly happy that some of the participants who I’ve not seen very active in the past felt involved and contributed)
• got peopple interested – in the end a part of the group (3 people out of the original 6) were interested in further work and stayed after the expected closing time (6pm)
• managed expectations more or less, 50-75% expectations were reached for a part of group (2 out of 3, 3 out of 4)
• logistics (supplies, food, materials) – as there was a dedicated team member

What I did poorly:

• i did not organize the knowledge exchange prior to the meeting
• interviews were not monitored to ensure the questions were valid and to the point
• facilitation during the training session was not quite there and there were a lot of distractions
• managing scope of the event. the overall plan was too ambitious
• defining the scope of responsibilities
  • there was a huge gap here as the other person who co-organized the event felt the overall idea has changed and everything should have been done differently
  • in practice very few of the original objectives have been reached need specifics here

general observations

• this was not a workshop but more of an initiative/project ->format should have been different with the current team
  • one team doing everything end-to-end
  • many teams doing different projects
  • not one team working out using parts of the process
• still, there are people who are interested in getting this done
• i should have prepared better in terms of BA work
  • NOT all stakeholders have been identified
  • introduction on the matter should have been better
  • needed to focus on a smaller piece that could have been swallowed in one take
  • need to learn BPMN and EPC better to be able to quickly use those notation models
• i need to build my team to do things like this better