Gather Business Requirements

Gathering business requirements is a step in problem resolution that occurs after a potential problem has been identified, but before a solution is developed. Its purpose is to collect, summarize, and communicate facts about existing conditions. These facts are then used to further define, quantify, and project the consequences and impact of continuing the status quo.

Steps

Identifying the Business Requirements

  1. Analyze the identified problem. Prior to gathering business requirements, the company needs an issue to focus on. Once a problem is identified, the company, in turn, seeks the optimum solution to solve the problem. The business requirements provide an outline of justification for the project and the details necessary to determine the optimum solution.[1]
    • That means that the company must continually gather data about its customers so that it can identify problems and so that it has data to provide justification for new projects. Once a new project is decided on, you can move on to gathering the business requirements.[1]
    • To clarify the problem, start with the problem statement.[2] The problem statement is essentially why you are starting the project. You saw a problem within the company or with your customers that needed to be addressed. Your problem statement should lay out exactly what the issue is.[3]
    • The "problem" could also be a need the company has or an opportunity for growth.[4]
  2. Gather the team. Since business requirements focus on a particular project, you can hold meetings with the relevant people from the project. The team will be composed of people in various roles associated with the elements affected by, or affecting the problem. You may need to meet more than once to gather the information you need.
    • In your team meeting, discuss what the problem is and who it is affecting. Make sure people at the meeting have numbers to back up the problem.
    • For example, a quality problem will require production and inspection people, such as industrial engineers and foremen, as well as any staff HR people if there are potential labor elements (union) involved.
  3. Address all aspects of the problem. That is, the problem statement should cover what the problem is, of course, but it should also cover who it affects, where it is happening, and when it is happening. It should also address what the problem is affecting, besides people.[5] Remember that the team is not identifying the problems, but the causes, consequences, and effects of the problem statement as previously developed.
    • With the group, begin identifying the various departments affected, how they are affected, and the existing impact of the status quo. Have someone write on a board or screen that's visible to everyone. Write down the problem statement at the top. Let people throw out ideas and write them on the board.[6]
    • Make sure people arrive prepared; if you've already created the problem statement, they should have read it and thought about it on their own.[6]
    • Don't judge ideas. As people throw out ideas, don't offer judgment, at least while brainstorming. People will be more hesitant to say things if they think they will be judged.[6]
    • Encourage everyone to speak. If someone hasn't said something, call on that person to see if he or she has something to contribute.[7]
  4. Narrow down ideas. Once you've brainstormed, it's time to narrow down your solution. Discuss which of the solutions seem like the best one. Basically, you're going to decide what your company is going to do to solve the problem. Maybe you've decided you want to return to some of your original designs with some updates.[6]

Developing a Project Plan

  1. Develop a project plan to complete the data gathering project. This should include a definition of roles, responsibilities, and authorities involved in the data gathering project. Spell out the departments involved and data to be collected and analyzed. Before moving forward, make sure that every team member is on the same page and committed to the plan and its eventual success.
  2. Define exactly what will need to happen. To bring about this project, you will need to define what exactly the company needs to do. For example, if the problem is that costs of a product are too high, the areas covered will include purchasing, production, packaging, shipping, and accounting, among others, to determine the current and past trends in costs of materials, production cycles, and cost.
  3. Establish deliverables. Your only deliverable in a data gathering project is a report of the current situation with past trends, along with projected consequences if status quo remains. If the business problem given to the team asks for data on projected solutions, these would also be included in your deliverables.
  4. Work with the necessary authorities. For this part of the project, you need to work with the heads of several departments to decide what is appropriate to demand for deliverables. Set up a way to work with the necessary authorities and processes to gather information. Typically, department managers are reluctant to provide access to those outside, so an agreed upon authority and access is needed upfront.
  5. Establish a schedule. Set out milestones and the sequence of tasks. This part is something else you could do in a small group or team. Essentially, you want to lay out when certain parts of the project will happen. Base your estimations on how long these types of project have taken in the past. That also means defining when the project will begin and when it will end.[8]
  6. Create a budget. Every project must have a budget. The budget will be based off of estimations with the accounting department. Discuss the numbers with the accounting department to determine what the budget for each part of the project will be.[2]
  7. Document the scope of the product or service. Develop a detailed description of what the product or service will be. You can work with the design team to come up with this description. It should include deliverables, resources, the schedule, and costs.[9]

Gathering and Documenting Data

  1. Establish the process. The existing process for manufacturing products or providing services for your customers needs to be established. Obviously, the processes will be established by whole departments working together to come up with the solution. However, it's your job to define the process in the business requirements.[10] Identify how the processes that are studied affects the problem, whether as cause or consequences. Study the process by:
    • Compiling observations of the process.
    • Conducting interviews with employees performing the process.
    • Analyzing quantified measures of the process such as volume, cycle times, cost, quality.
  2. Create a process flow diagram. One way to show the process is to use a Make a Business Process Model. You use shapes for each step of the process with arrows to show how the product or service moves. It is essentially a map of how the process works. It can show where problems could arise with the process if it the product ends up bottlenecking in a certain area.[10]
    • For instance, if one area can produce 40 of the products in one hour, but the next step in the process can only do 20 in an hour, then the process needs to be adjusted.
  3. Quantify process elements. Your process analysis shows how each step is going to affect another step. Therefore, the process for your project should not be automated until you've got a complete understanding of the process through an analysis.[2] Include an explanation of inputs and outputs with physical counts, cycle time, and other relevant data. In particular, note when process moves from one department to another as this is often the source of greatest inefficiency.

Reporting Findings

  1. Pull the information into a report. Once you have gathered the information for each part and written it up, you need to pull the whole thing together into one big report. Divide it into major processes and sub-processes, so it is easy to read. Use visuals where possible to clarify understanding. In addition, be sure to be as concise as possible, as many people will need to read this report.[11]
  2. Keep it concise. This statement does not need to be pages long. It can be a paragraph or two, as it just expresses the problem. In fact, the main part of the problem should be able to be expressed in a single sentence.[5]
  3. Confer with your team members. Confirm your findings with team members and department sources. This step is a quality control check to ensure nothing has been omitted or misrepresented. Ask if any revisions need to be made.[12]
  4. Make the needed revisions. If you need to make revisions, change the document. Once you have made revisions, you need to send it out again, making sure to highlight the differences so your readers don't need to read the whole document again.
  5. Summarize your findings. Write out a short summary of your major findings so that they can be easily understood by readers. In most cases, the summary should be no more than two pages. Make sure to include references or links if you have created an electronic report.
  6. Present your report to sponsoring party. Create a presentation and presentation materials so that you can show your findings to the sponsoring party. If an oral report is necessary, prepare for that meeting by reviewing your findings.



Tips

  • It's often useful to bring in a professional business analyst to accomplish this analysis. An outside professional isn't as close to your organization and will see things you miss.

Sources and Citations

  1. ↑ 1.0 1.1 https://www.ctg.albany.edu/publications/guides/smartit2?chapter=4
  2. ↑ 2.0 2.1 2.2 http://enfocussolutions.com/business-requirements-vs-functional-requirements/
  3. ↑ http://www.ceptara.com/blog/how-to-write-problem-statement
  4. ↑ https://www.ctg.albany.edu/publications/guides/smartit2?chapter=5&section=2
  5. ↑ 5.0 5.1 http://enfocussolutions.com/writing-an-effective-problem-statement/
  6. ↑ 6.0 6.1 6.2 6.3 http://www.brainstorming.co.uk/tutorials/runningabrainstormsession.html
  7. ↑ http://www.brainstorming.co.uk/tutorials/runningabrainstormsession.html
  8. ↑ http://www.requirementsnetwork.com/documents.htm
  9. ↑ http://www.dummies.com/how-to/content/what-to-include-in-a-project-scope-statement.html
  10. ↑ 10.0 10.1 http://www.netmba.com/operations/process/analysis/
  11. ↑ http://www.brighthubpm.com/templates-forms/2491-writing-a-scope-statement/
  12. ↑ http://www.brighthubpm.com/templates-forms/2491-writing-a-scope-statement/
Retrieved from "https://kipkis.com/index.php?title=Gather_Business_Requirements&oldid=355710"