Chapter 5 - Investing the Work

Chapter 5

INVESTING THE WORK 

In this chapter we have learned that how the business is working and to make sure that is that business working according to plan and requirements. chapter we are discussing how to investigate a piece of work prior to changing it. Normally your change would mean building a software product or some other device to do some or all of the work.

we are using trawling to describe the activity of investigating the business. It is important to uncover the current business, including both its data and its processes, it is also important that you do not spend too much time doing so. Keep in mind that this is the beginning of the analysis process, and you would like to get through this step as rapidly as possible.
The trawling activity is central to the requirements process. It uses the outputs of the project blast off activity as its starting point for investigating the work and accumulating knowledge about it. Over the next few chapters, we will develop this knowledge into requirements for the product to be built. The dotted lines on the diagram indicate how trawling works when you are using iterative development.

Trawl. There is a lot to know about trawling—and we know that not all trawling techniques are applicable to all projects. 

Business analysist has to inspect the work, interview the business stakeholders, understand what they are saying, and then translate that knowledge into a form that can be communicated to and understood by the developers. Initially, the business analyst’s task is to record, clarify, and question the current state of the business.

Brown Cow Model illustrates four points of view that help to uncover the real business problem and identify useful innovations. The four quadrants which are - What-Now, What-Future, How-Now, and How-Future show the different viewpoints of work. Generally, it is not enough to have only two views of business - the "as is" and the "to be". To get a true light on the business problem and to ensure innovations, more views are necessary.

Stakeholders should not remain completely passive during the interview. Instead, do your best to involve them by building models business event responses, use cases, scenarios, and so on during the interview. This approach creates a feedback loop between you and your stakeholders, and it means you can iteratively test the accuracy of what you are being told. Follow these guidelines to make your interviews more effective:

 ● Set the interview in context. This step is necessary to avoid having your stakeholders talk about something irrelevant to your purpose. It also gives them a chance to withdraw gracefully if they have not prepared for the interview. 

● Limit the duration of the interview to the time stated in the agenda. We find that interviews running for more than an hour tend to lose focus.

 ● Have business use cases serve as an anchor for the interview. Users recognize business use cases, and it makes for more directed conversations if you talk about their work one business use case at a time.

● Ask a question, listen to the answer, and then feedback your understanding.

● Draw models and encourage the user to change them. Plenty of models are available to help you communicate your understanding of a process. You can also construct data models for information, and mind maps to link different subjects. 

● Use the stakeholders’ terminology and artifacts, both conceptual and real. If the stakeholders do not use their own language, then you force them to make technological translations into terms they think you will understand. This, sadly, usually leads to misunderstandings. By contrast, if you are forced to ask questions about their terminology, you inevitably make new discoveries. 

● Keep samples or copies of artifacts and log them for future reference. Artifacts are the things the stakeholders use in their daily work. They can be real things: documents, computers, meters, spreadsheets, machines, pieces of software. They can also be conceptual things: status, contracts, schedules, orders. Artifacts will inevitably cause you to raise questions when you examine them later.

● Thank the stakeholders for their time and tell them what you learned and why it was valuable. After all, they have lots of other things to do. Talking to you is not the reason they are employed, and they often view the interview as an interruption.