Archive | BA work planning RSS feed for this section

Business Analysis, design thinking and movie making (Pixar)

16 Apr

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.

Advertisements

Planning BA work for onsite project discovery

23 Mar

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 4th 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

Stakeholder_map_for_Organization_X

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.

influence vs interest

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

problem list

  1. 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.

  1. 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.

Context Diagram

  1. 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.

payroll impl

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.

  1. 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.

  1. 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

Worth reading separately