Recommended
More Related Content
What's hot
What's hot (19)
Similar to Presentation the importance of understanding end user workflows
Similar to Presentation the importance of understanding end user workflows (20)
Recently uploaded
Recently uploaded (20)
Presentation the importance of understanding end user workflows
- 1. The Importance of Understanding End User Workflows Before You Design and Develop Ease adoption and assure value of your business system
- 2. You will learn… 1. Why System/process Adoption = Business Value 2. Why failure to understand business process and context risks adoption failure 3. Why first person observation as well as interviews are important tools in understanding the business process and its context 4. How to use other tools and techniques to capture workflows, their pros and cons 5. How data flow is a natural product of process flow 6. Why “Yes, this type of analysis is agile”
- 3. Why do we care about the process? People’s time and energy are valuable and best spent on tasks that benefit from human intervention Activities do not exist in isolation People Resent being asked to jump through superfluous hoops Appreciate and adopt software that makes their live easier Adoption is achieved through easily used, full business process support is cemented with innovation that makes doing business better is return on investment, it’s VALUE
- 4. Modern Requirements Analysis Business Users focus upon how the user accomplishes their task within their working “ecosystem” Business Users insist upon providing intuitive user experiences with streamlined workflows Business Users emphasize efficiency Business Users want low frustration and high output and performance Thus, the BA needs to understand not just what the system will be required to do but also how the system fits into the user’s work life
- 5. You Must Appreciate How the user will make use of the system in their daily routine What are the pain points of the current system or process What is the value of automating repetitive tasks that do not require human intervention Failure to do so risks delivering a product that fails to innovate risks delivering a product that makes the user’s job more onerous risks that the system will not be adopted Results in failure to provide VALUE
- 6. Elicitation Ain’t Easy Case study by E3 Consulting to assess and re-engineer a process The team asked for A workflow map Task descriptions for each step in the map People and roles involved and the part they played in each step List of screens, reports, Excel sheets, etc. used during the process The client team could not provide these.
- 7. It’s Hard to Describe What You Inherently Know Experts: possess a large amount of inherent knowledge gained through collective and individual experience hold knowledge that is no longer something they think about and has become reflex and muscle memory don’t realize how much of their activities are guided by that inherent knowledge individually hold slightly different inherent knowledge, which when combined creates a full picture of the business ecosystem in which they function
- 8. Gaining Insight Work with subject matter experts (SMEs) who actually perform the tasks today Identify the happy path(s) the most common problem scenarios recurring edge cases the highest business value scenarios and prioritize holistic data flows business rules roles gateways Create buy-in from the involved end users
- 9. Scenario Evaluation Which scenarios are the most common? Which scenarios are wrote? Which wrote scenarios can be automated? Which scenarios result in the expenditure of the most time? Where and what are the “gotchas”? Where do people provide the most value in this process? Where can we add value?
- 10. Scenario Evaluation Which scenario is the 80% solution? Is this the most ideal scenario? If not, why not? What are areas for improvement in this scenario? What is hidden in that happy path? Is automation in this case “evil” or unwanted? Who can do the tasks? What approvals are needed within the process? What gateways are there?
- 11. Scenario Evaluation What are the most common issues/problems? How can process re-engineering or a new system take away the pain points? What do users need to know when things go wrong? Which of the exception or issue flows are so rare that they don’t need to be addressed
- 12. Tools and Techniques First person interviews and observation Business Process Modeling (BPMN, UML) Use Cases and modelling Stickies and a whiteboard Whatever works for you and your team
- 13. First Person Interviews and Observation Plan ahead to identify your objectives for each session Keep interviews informal, but go into each one knowing what you must accomplish and what information is necessary for it to be successful Determine the appropriate level of detail ahead of time Don’t waste time, only ask the question once, if possible Determine when is the best time to observe Peak time Normal time Slack time Use consistent methods to record observations or interviews such as a check list, voice recording, video recording, etc. Get documentation or spreadsheets used in the process ahead of time to become familiar ahead of time
- 14. First Person Interviews and Observation Passive/Invisible observation – no interaction with the worker during the observation session; takes notes and then follows up after the session Active/visible observation – interaction with the worker during the session to ask questions; takes notes Apprentice – participates directly in the process learning, to do the job themselves, takes notes
- 15. Interviews and Observation Initial interviews will record the process as the SMEs perceive it Observations will help you understand the gap between SME perception and the realities of the day-to-day Follow up observation with interviews to help you understand what you saw Additional observations may be valuable to see more of the scenarios in action and to better understand the process
- 16. First Person Interviews and Observation Pros and Cons Data acquired during these sessions are generally reliable Observations can be used to confirm information gained in interviews Observations can give insight to the physical environment where the work is performed Relatively inexpensive Allows the analyst to perform direct measurements Exceptions may be difficult to capture, especially in one session (interview or observation) Observations and interviews can be prone to bias Workers may behave differently while being observed
- 17. Business Process Modeling Excellent way to express connections and interactions between people/actors and business elements Can be used to prototype or storyboard a piece of software from the business point of view without delving into implementation Helps focus on particular set of interactions in a particular set of circumstances Helps determine the completeness of requirements by walking through the entire scenario Helps to focus upon and detail high value business scenarios/processes Creates a highly readable and relatable model for reference
- 18. Business Process Modeling Business Process Model and Notation is a graphical representation of business processes BPNM is a widely accepted and standard notation Many BPMN tools exist to assist you in creating your BPMs Resembles flowcharting so there is a familiarity with the symbols UML is broadly accepted as a worldwide standard formal notation Allows for less focus on the notation and more on the process Can be used to maximize reuse of model elements Diagrams can be used by developers as they move into design Well documented standard with lots of examples and information about it
- 19. Business Process Modeling Pros and Cons Allows for graphical representation and communication of a process Easily transportable and relatable Appeals to visual thinkers and logical thinkers Allows teams to work at various levels of detail Helps establish scope as you evaluate scenarios and identify those highest in value Business teams may not respond well to the notation, or get hung up in the semantics May not appeal to people who are more verbal (use export function, if you have it) Be careful to use the proper notation to avoid discussions focused on your notation rather than the contents
- 20. Use Cases and Modeling Use Cases provide a detailed written description of how users will perform tasks using your system, from the user’s point of view. Use business terms to describe a technical product and process Support a focus on the user’s end goal Support in depth exploration and description of a scenario Use Case Models are useful to quickly describe the scope of a project or product Are simple, business centric representations of a system that may be made up of many different technical components Help represent business roles and their relationships with the system
- 21. Use Cases and Modeling Are part of the long established UML standard Can be targeted to the scenarios of highest value Put the focus on the interactions of actors with the system and takes focus away from implementation details Can be scaled to fit your team or company’s needs/wants Can be very useful when working with a completely new domain or product Are very useful when discussing scope and scope creep
- 22. Use Cases and Use Case Modeling Pros and Cons Use Cases are highly descriptive and useful for poorly understood scenarios Apply a well known and used standard Use Cases appeal to verbal thinkers and the Models appeal to the visual thinkers Can be used to provide a clear delineation of scope Are a great tool when working up scenarios, especially alternate and exception flows Are not considered part of the Agile arsenal of tools Can get out of control unless you are disciplined in their application Models may be dismissed as too simplistic to provide value Are not object oriented Tend to drive discussion to functional discussions, be sure to have the non-functional discussions as well
- 23. Whatever Works! Don’t be married to a particular method or tool Sometimes paper and pencil (or whiteboard and marker) works best Post-it notes are your friend when working in a collaborative environment Not every customer, not every team is the same so you should be flexible in your methods and use what fits your context at the time If interpretive dance turns out to be effective, don’t be afraid to use it Your goal is gaining a full understanding of the business process you will support and the business context in which it is used
- 24. Data and Data Flow Analysis Entity identification and definition Data objects/entities Data attributes Data relationships/entity relationships Systems of record
- 25. Data and Data Flow Analysis Holistic view of how data is used, where it is going Upstream Downstream Reporting Aggregation and analytics Flow diagramming and analysis Data flow diagrams Context diagrams Communication diagram Interaction diagram
- 26. Business Process Analysis Never Sleeps Business process analysis and evaluation should continue during System design Development Acceptance testing After deployment to production
- 27. But wait! Is this stuff agile? Yes, it is You and your team define how deeply you want these efforts to go Agile focuses on getting just enough information just in time and at the right level, keep your eye on that Begin at a high level and dive deeper as you move from planning to implementation You can use the higher level conversations to allow you to identify your scenarios and scope and write your epics Closer to implementation time, delve deeper into individual steps and the data elements involved, write your stories and acceptance criteria Work closely with your SMEs at all levels of detail and solicit their input on workflow and usability at all stages Ensure that the SMEs are part of the acceptance testing efforts
- 28. You learned… 1. Why System/process Adoption = Business Value 2. Why failure to understand business process and context risks adoption failure 3. Why first person observation as well as interviews are important tools in understanding the business process and its context 4. How to use other tools and techniques to capture workflows, their pros and cons 5. How data flow is a natural product of process flow 6. Why “Yes, this type of analysis is agile”
Editor's Notes
- Today’s users are so much more savvy than the users of 10 years ago. A large percentage of them do not remember a time when they didn’t have some sort of computer or mobile device at their fingertips. Because of their experience, they are more demanding in terms of user experience and ease of use. Unnecessary steps and repetition of steps in tasks drive people to distraction. They want to be able to quickly get into a piece of software, complete their task and move on. If software makes their lives more simple and allows them to focus on the issues and exceptions in their work-day, the software will be used and adopted into the user’s workday. With every person who finds the software useful, uses it frequently and lets others know how well they like using the system, you and your organization are building return on investment. Deep and quick adoption of a system is the best way demonstrate the value your system is providing to the business. Other metrics, such as time savings cement the value equations. Nothing is more wasteful than a piece of software that no one uses or that makes people’s work-lives more frustrating.
- Today, especially in Agile environments, the business team is highly invested in the analysis and design phases for software. Working so closely with the business helps to ensure that the system fits within the business’ ecosystem of interrelated tasks and jobs. Product owners are as savvy as their users and insist on the most efficient workflows in order to protect and increase productivity. Furthermore, if the business can reduce frustration on the part of the users, they can reap another benefit in the form of job satisfaction. A series of systems or one overall system that allows a user to complete their daily tasks quickly and with little to no frustration can make a difference in employee retention and morale.
- As a business analyst it is incumbent upon you to understand how your system will fit into the user’s daily life. How does it impact the user if there is a problem or the system goes down? What are some of the instances today where users become frustrated by a non-performant system or one that takes special actions or interventions in order for the task to be completed? Are there any points in the process where a machine can take over steps or tasks so that human beings can focus upon those areas where their time is most valuable? Failing to appropriately understand how the system will fit into the business and help it accomplish its mission introduces risk. The risk of frustrating and blocking the user’s ability to perform their work. It may fail to innovate and allow users to perform their tasks better or more efficiently. It risks that people will not like the new system and seek ways around its use . It may damage the business’ trust in your ability to deliver quality products . A really bad system can damage the user group’s morale and job satisfaction, leading to increased costs and employee turnover.
- I don’t think this is really something that I NEED to tell you, but it is worth discussing. A good reference on this topic is at http://www.e3businessconsultants.com/business-consulting/case-study-business-process-analysis/ You are probably not shocked by that, but why would a team who has been using a process for a while not be able to describe it to another team? There are a good many reasons for this.
- Think about some of the tasks you may know by heart, like making coffee, cooking a simple dish, or doing the laundry. You have been doing that for a very long time. If asked to describe the process of making coffee in your office to someone, you may be surprised at how detailed a description you will need in order to assure that the person with no previous experience or knowledge of the context could follow up on your conversation and do the task all by themselves. In my experience, we don’t appreciate how much of our work or personal lives are driven by this unconscious knowledge that we carry around. Also, each person may hold different pieces of information and may work in slightly differing ways, so it is important to talk to more than one person in order to gain an insight to collective knowledge.
- When performing analysis it is especially important to work with subject matter experts who actually do the job. Very often, analysts are paired with managers or other supervisors who do not necessarily do the work you are being asked to support. The danger here is that you could miss something that is important and intrinsic knowledge held by the people who are doing the work day in and day out. When ever possible, you should always have an SME on the team who will be using your software. When performing analysis, always look for the “golden scenario” where everything goes right. Understand what it takes for this to happen, how you can help to make it happen more often and then determine if the task with those parameters can be automated. Automation is not always evil. Work with the SMEs to understand which are the most frequent problem scenarios. Ask how those could be prevented and which are the ones that are of the highest priority to the business. Which ones take the most time and may have the least payoff? Always look for data flows from upstream and downstream in order to understand how the system fits into the business environment. What are the business rules that govern the workflow? Where are the checkpoints that decide the workflow? Working closely with the business in order to answer these types of questions will help you understand the business and will help them with buy-in on the system since analysis went the distance to understand their jobs and support the full process.
- When interviewing SMEs, always consider the scenarios you are witnessing or following in a discussion. As mentioned before, discovering the most commonly performed processes and those that are wrote will support your ability to find tasks that can be automated. This will take the boring part out of people’s day. Asking which scenarios eat up the most time in a worker’s life will help you identify the scenarios where more time should be spent in analysis and design. Ask probing questions to help understand the contributing factors associated to these scenarios. Identify any “gotchas” that seem to be a recurring hassle for the users and then work with the business and technical teams later to identify ways to prevent them. Ask users where human action or intervention is the most valuable in a process. This allows you to focus on providing support to the users in the most needed places in the process. Also, ask where a system can make things easier than they are today. Adding value to a system and easing a person’s work routine is instrumental in building buy-in and adoption for a new system.
- When you are doing your scenario evaluation, it is important that you get a sense of which scenarios hold the most business value. This will make sure you focus upon the most prevalent scenarios as well as those that take up the most time while employees work to solve problems. One of essential things you to do is look for hidden information, inputs, and/or decisions. Remember, sometimes things are so ingrained in your SME’s knowledge, they omit steps, data, or gateways because they are not really even thought of any more, they have become part of the common knowledge base. Working with the SMEs to identify the possible scenarios and teaming with the business to prioritize those will be a major step toward full process coverage and better adoption.
- When evaluating your scenarios, the common issues and problems will be one of the places where your analysis can provide a large amount of value. Are there steps to be taken in the human process that can alleviate these pain points? Are there implementation details that your system can use to help alleviate them? More importantly, understanding what tools and information that the system users will need in these scenarios will facilitate the creation of a valuable system. As important as discovering the different ways things can go wrong is determining which scenarios are the highest value, which are average, and which can wait on the back burner. Time and money not spent on scenarios that don’t matter is money that can be spent on the high value items.
- There are at least as many tools and techniques for process elicitation as there are Business Analysts. Everyone has their favorites and then make their own tweaks and customizations. For the context of this session, we will talk about and look at examples of the following:
- You may be tempted to wing it in an interview with your SMEs. You may have some knowledge of the domain and you may feel comfortable with the SME, but you should always start any meeting with an agenda so that you can be clear about what success should look like, when you walk out of the interview. Always acknowledge that you appreciate the SME taking time out of their busy schedule. Generally, the SMEs are the primary resources in their group. Be sure you make sure they feel appreciated. Keep the level of detail appropriate to the needs at the time. If you are at the start of a project, doing a deep dive into a process may eat up your time and take focus away from other areas. If you feel like a deep dive is appropriate, you may need to schedule another meeting for that discussion. On the flip side, if you need detail, be sure to focus upon detail. In my experience, the worst thing you can do is assume you know what someone is talking about. You may think you know the subject, but unless you do it every day, you are probably missing something. When you are observing a person or interviewing them, be sure to record your information and make sure you know what it is you’re writing down. Nothing breaks trust or frustrates an SME more than having to tell a BA the same thing over and over. Make sure you understand if your business is cyclical and plan to observe your SMEs at different points in the cycle. Something that is pretty easy on a light day of traffic can become a real pain when it’s crunch time. Our triple witching days are a perfect example. These are the pay periods where payday for all of our different pay frequency options fall together. (i.e. weekly, biweekly, semi-monthly)
- Examples: Our finance team is receptive to our BAs observing payroll calculation workers, but only in a highly passive manner. We are not allowed to interact with the payroll worker at all. Our payroll specialists who provide payroll support to our clients allow for more active observation, but within highly controlled conditions with 6 payroll specialists hosting 6 BAs in a rotation of 15 minutes each.
- Interviewing is a powerful tool. Always plan your interviews in advance. Generally use more than one question to cover the same topic, in order to put the user into different perspectives on the same topic. This may help uncover some intrinsic knowledge or hidden information. Interviewing allows you to become familiar with a task, especially if you have never seen it done or have very little to start with when you are planning to do an observation. Collecting some information on the process in advance primes you for observation. It also allows you some time between getting familiar with the subject and watching it being done. It will also help you understand where some spots of intrinsic knowledge are, once you are in the observation phase of analysis. Follow up an observation with additional interviews. This will allow you to digest what you saw in observation and prepare questions for the SME on what you saw and how it may differ from content you received in your first interview. I urge you to observe your SMEs more than once, so that you can witness different days, different scenarios and different client interactions. Doing this and performing follow up interviews will go a long way to help you ensure project success.
- Keep these cons in mind when working on Interviews and Observations. Be very careful as you work so that you avoid them.
- Process diagramming is a great way not only to come to understand a process, but to be able to effectively communicate it to others. It is particularly useful to help capture the differences in workflow between one scenario or another and to identify differentiating gateways. BPM will help you discover if your requirements are complete by allowing you to walk through the process scenario by scenario to understand the nuances and complexities. The output of this type of discovery is a very easily read diagram that can support your efforts as your team works through the SDLC.
- The BPM is a very widely used method for recording processes. It uses BPMN which is a standard notation, so it is not something that has to be translated if other organizations are brought in to work on the project. There are a lot of tools available to you to help you create and further document a business process model. I am most familiar with IBM’s Blueworks. My company uses it across our BA practice on our IT team. It has many features and helps to keep more information than just the process flow at your fingertips. Other tools include IBM Rational System Architect, jBPM, and Microsoft Visio. You can use those formal tools or use your whiteboard and sticky notes to create a BPM. Taking a picture with your smart phone and saving it for posterity allows you to have something to refer to in the future. Developers like these models as they move into design as they help them understand how the work must progress and how data will move within the system. They also point out areas where reuse may be possible as well as identify business rules.
- The thing that I have found most useful for BPMs is that they are very easy to create and very easy to read. Our business owners have found them to be very valuable to them as they work within the business to relate to others how systems will flow. It is incredibly useful in general in that it is a simple vehicle for communication and discovery of missed requirements. It really works for visual and logical thinkers as it uses logic to create the visual representation. Scope definition is also easy as you draw out the process and identify the areas, steps, gateways and rules that will fall into the jurisdiction of your project. Be careful, however. Some people may not respond well to the notation. Be aware that for some, the semantics of the language can be distracting. They will focus on the meaning of a box versus a diamond and lose sight of the real purpose of the exercise. Also, verbal thinkers may have some reservations when using these diagrams. If you are working with a verbal thinker, be sure to use enough words in your process elements to help them feel comfortable with the exercise. Finally, be sure you are using your notation consistently. Not being consistent can also derail your conversations.
- Use Cases and Use Case Models are well known and long established analysis tools. They were created as part of the Unified Modeling Language. Use Cases are detailed descriptions of specific scenarios for use of a system/process. Use Cases always use business terms to describe a technical product or process. Implementation or other technical considerations should not be a part of a Use Case. Most importantly, the Use Case focuses upon the steps taken in order for a business user to reach a specific goal or outcome. Given their detailed nature, the Use Case is an excellent way to explore and define a process scenario at a granular level. Use Case Models are extremely useful in describing a project or product’s scope. This can be done very easily by including/excluding functions within the project/product boundary. Use Case diagrams are very simple images that can represent highly complex systems, since each major function is contained in a single use case. They also represent business roles, other processes/systems and their interrelationships within the system or process.
- Use Cases and their associated models are useful in targeting the highest value scenarios since they tend to be detailed more so than user stories. Use case templates are easily available on the internet or can be created yourself, based upon your research and the needs of your team or project. The most powerful thing about a Use Case is that it describes the conversation between a user and the system with an ultimate goal in mind. When executed properly, this allows for laser focus upon the details surrounding a scenario. Use cases can be scaled to fit your needs. You need only perform use case analysis on those scenarios where you perceive the most value, leaving others identified, but not necessarily heavily elaborated. Use cases and use case models are especially useful when working with completely new domains, processes, or systems. If you find yourself in a completely new knowledge domain, the rigor of a use case is an excellent framework for the necessary conversations. The framework can give you confidence in covering the material you need to cover. Use Cases and Models are very effective when determining scope of a product/project. The simple use of the Use Case list with the In/Out of Scope column or the system boundary in a diagram is all you need to communicate what’s in scope and can be a very valuable tool when the inevitable scope creep comes up.
- I find that the detail in use cases is extremely helpful when working with poorly understood or completely new processes. Outlining the steps in the process helps everyone understand any vague areas and forces that they become clear. The use of the use case appeals very much to verbally oriented people who may be confused by diagramming. However, if you have a highly visual thinker on the team, don’t rely solely on the Use Case. Associate it to a diagram. The usefulness of the Use Case in defining scope cannot be understated, in my opinion. I have used both the Use Case List and Diagram to great effect. The biggest issues I have dealt with concerning Use Cases have been knowing when enough is enough and getting agile teams to buy into the value of use cases. Knowing when to stop analysis is an age old problem. The greatest tool in your arsenal to guard against analysis paralysis is a healthy relationship with your product/project owner and the ability to work with them to identify appropriate priorities for your scenarios. Another tool that may work is to time box your efforts in creating your lower value use cases. Lastly, since Use Cases are functionally oriented, your object oriented programmers may not respond well to them, however you can use them to identify business and data entities as you work on describing the process. Finally, and not any less importantly, please be aware of the need to consider non-functional requirements while writing/diagramming. Consideration of performance, environmental, or usability is essential to your analysis efforts.
- Context Diagramming is another form of software diagramming that defines the boundaries of a system and the interactions between it and other entities. In this respect, it is also very useful in identifying scope. It also helps begin the discussion of data movement between entities (human and system). You can develop your context diagrams at various levels of detail, allowing your team to drill down further into interactions to better understand them. This gives the team flexibility in determining where their time and diagramming are best spent. As you develop your context diagrams, you will identify the impacted business objects, systems, roles, and interfaces. This is one of the most valuable aspects of the context diagram. I have found it very helpful in diagramming the “Happy Path” for a system and identifying where we have gaps in our knowledge of interfaces or entities. I have found it very useful to create “Before” and “After” context diagrams to help myself and the team understand the impact that the new system/process will have on existing architecture. This is exceptionally powerful when working on a project that will involve the efforts of multiple teams or impact several systems or interfaces.
- Given that context diagrams are very flexible in terms of their level of detail, it can be a blessing or a curse. Blessing in that you don’t have to delve into too much detail if that is not needed for the current topic. It’s a curse in that you can get bogged down into ever decreasing granularity or become confused in your diagram’s levels of detail. Be very deliberate when defining it. Keep your diagrams consistent across the levels being depicted. Context diagrams are very easy to create and lend themselves well to a collaborative whiteboard session. Get the team up to the board and let them construct the diagram while you facilitate. The team will better understand and embrace the diagram if you do so. Keep the talk out of the implementation realm. Since you use the term interface, your development teams will want to start specifying those. Pull them back out to the higher level. Remember to focus upon a conversational type transaction rather than a detailed description. When you have identified the interactions between the objects, you will need to discuss any details in the processes or data that may be poorly understood. Do not miss this step.
- Prototypes are incomplete examples of the software or process. It allows the team to create a working model in order to put it through the various known scenarios in order to evaluate the efficacy of the proposed software or process. The best thing about prototyping is that it allows for the team to test out your vision without necessarily writing a line of code. It should also be very inexpensive as the prototype is only a “sketch” of the final product. When creating a prototype, keep in mind that you are working to define a process or workflow rather than a system. Implementation details, such as whether something is a radio button, dropdown list box or other control need not be a part of the prototype. Prototypes can be as simple as a narrative, a storyboard or a screen sketch on paper. Whatever method you choose, it should serve as a concrete expression of the proposed workflow and serve as a facilitation tool for your conversation with the business and technical team members. Your prototype should have very little value in itself but serve as an iterative tool for development of the product/process.
- Prototypes should be very inexpensive. There are tools out there that support it and your team may elect to use those, however you can go very “low tech” as well. Additionally, they should not require any of the team participating in their creation to have technical knowledge, since they are a representation of the workflow to be followed, not a representation of implementation choices. It can be challenging to keep implementation out of the equation, but putting in the effort to do so keeps the focus where it needs to be. Done properly, the prototype can help your users realize the system you will be producing for them before you spend too much on implementation. Avoid getting into design discussions as you create the prototype. Keeping the focus upon user and system interaction will help. Remember to counsel your business team members on the impermanence of the prototype. Keep reminding them that the actual implementation may differ from the prototype, but be sure to communicate any significant divergence early and widely. Lastly, be careful how good your prototype is. A very well mocked up screen or slide show can give some customers the feeling that “you’ve pretty much done the work”. This is a very real danger if you make your prototype look too real.
- Ultimately, the best tool to use is whatever works for your whole team. Learn as many tools/techniques as you can and use them in various forms and incarnations in order to get the job done. Focus on identifying and specifying what the business needs and do not give too much regard to your methodology. In the end, any of these are simply tools to help you meet your end goal, which is to provide your business with a valuable product that makes their work easier, more profitable, or stand out in a field of competitors. As BAs, we are required by circumstance and environment to be as flexible as a reed in a wind. Each team, each product, each project is different. We have to be able to switch between tools as well as adapt them on the fly while working to solve the present problem. This is the greatest challenge for us and I think one of the biggest thrills for us as we do our jobs.
- Now for a quick word about data and data flow analysis. As you work on your workflow analysis, you will naturally start identifying data entities, some of their attributes, and the flow of that data within your system/process and with entities outside of it. As you work, you should make it a point to start a list or dictionary. This is especially critical if you are working in a new domain, on a new product/process or with a completely new team in an established environment. Identifying objects such as Customer or Order and the attributes associated to them will drive a good portion of your conversation, especially in terms of understanding some of the limitations you may need to put upon them or the relationships between entities, and/or their systems of record.
- Data does not exist in a vacuum. Data is generally part of a system’s ecosystem and may have a life outside that particular system’s boundaries. Keep in mind the full data ecosystem while you are working. Reporting engines, upstream, and downstream systems may be outside the scope of your project, however changes you make to data coming in and going out could be an impact. Consider this carefully and include impacted teams early in your process. You can better understand how the data ecology may be impacted using the tools listed. Be sure to consider their use where they provide value.
- You are never finished with your business process analysis. Sadly, at the end of discovery, you don’t get to spike the ball and do your dance. Process analysis should be a part of every step in the software development process. Check the process for value and adherence to your project’s stated goal in every phase. Even after a product is completed, the process that it implements should be continuously evaluated as it is used, since there is always room for improvement and changes will be introduced as the business changes.