Agile Business Coach

Tell a Story

I intend to publish a cleaned up version of this when I find a magazine to publish it in.

“They blew up the Death Star!”

Is this a good thing? Did the good guys win?

A story’s ending has little value unless the listener understands the context. “The Usual Suspects” start with the ending and then builds the context. Telling a story provides context for the ending and should generate interest for the listener so that they care about the out come. When you listen to a story, you can imagine how you would alter the outcome by making a different decision at a key point “Why didn’t Romeo wait five minutes?” The same rules apply to presenting the results of learning.

When presenting the results of learning (analysis), people have a tendency to present the final results and omit the story that built up to the result. This approach makes it difficult for the person being presented with the results to understand the context for the final results. Even worse, it makes it very difficult for someone to provide feedback. The learner often feels frustrated because the person they are transferring the knowledge to does not care about the results as much as they do. The listener often ignores the results and goes back to the original source in effect building their own story.

To illustrate this I would like to tell a story.

A colleague, Rohit Darji, and I were working on a risk system for an investment bank’s trading division. We needed to calculate the risk numbers for various levels of the organization. A separate project was developing a common system to manage the organization structure for risk, management accounting and performance management systems. The business manager on the project had a bit of experience with modeling databases and had created the model shown below.

We spoke to another business user who added an extra couple of management levels to the model. They also told us a couple of the problems with the current model “Its not flexible enough. Management often reorganize which means levels are added or removed depending on which way the political wind is blowing.” And “It does not handle joint ventures where two groups share the profit and risk on an initiative” We updated the model as shown.

From experience on a previous project, I knew that there were a few problems with the model. The first problem we addressed was the ”Account”. The business users with the hardest problem to solve were the management accounting group. They have to reconcile the trader’s view of the organization with the general ledger, that is, the financial accountants’ view. They explained that each trader had a number of books that could be split across legal entities for a number of reasons. The organization had a number of legal entities for a variety of reasons including regulatory constraints, tax and so that it could trade with counterparts using an entity registered in the same country as the counterpart. The traders expect to see a view of their profit and loss ignoring the legal entities, and the financial accountants want to see it by Legal entity. The management accountants told us that each department had a general Ledger account in each legal entity. The tricky part for them was to ensure the trades in the book were posted to the correct profit centre. We redrew the model including the concept of a “portfolio”. A portfolio identified which legal entity a trade was in.

Next, we decided to tackle the flexibility problem. Two “pigs’ ears fixed the problem. We kept the group as the entity that included everything, namely all legal entities and all management units. The group would be the root of the organization structure tree.

Finally, We addressed the joint venture issue. We asked the management accountants “Is there a single line on the general ledger for a joint venture or does each participant in a joint venture have its own line. Their reply “Each participant has its own line, and by the way, the risk and profit are split in different proportions.” The first part meant that the JV was below the department, and the second part meant that there was an allocation type associated with the allocation. Our final model looked as follows:

We had developed the model using Visio. We went over the model with all the business users including the business manager explaining how it would support all of our requirements. They nodded and smiled. We handed our model to Steve, the developer, who quickly implemented the model using 4 classes. The System handled all of the problems that I had encountered on previous projects. We moved on to our next project feeling we had done a good job.

We had spent about 2 hours on the modelling and a 8 hours getting buy-in from the business. Our approach was “They blew up the Death Star.” We did not take them through the story of how we came to our final model. We just presented the final model.

Three months later, the business manager on the project called us to say there was a problem. We attended a hastily arranged meeting to discuss it. The system could not handle the reporting requirements of the traders. We asked what had happened.
“The traders want to see their Profit across Legal Entities and the system does not support it.” We were confused. We had specifically addressed this requirement with the model, in fact, it was the first change we had made to his model. We had checked the system to ensure the data could be entered. “The system should support it look” we said. We took out our final version of the model and explained how it would support the requirement. The business manager took out his model that he had given to us at the start of the project. “I entered the data based on my model. I could not see how your model would work. For Example, what would the user see?”

I sketched the following screen layout on a flip chart.

“ Yes, that’s the screen we built for the users. But how would the user see the results for a single legal entity or for all legal entities?”

I added a drop down box to allow the user to select either a single legal entity or “All” legal entities.

The colour drained from the Business Managers face. “I could not see how it would work so ignored your model and stayed with my own.”
“Can it be rectified?”
“No. It took 2 months to set up the data and we have gone live in production.”

On my fourth attempt at creating an organization structure data system, we had solved most of the problems with the software. But we had failed because we had failed to explain to the business manager why we had changed his model. We had told them the final result without explaining why we had come up with the model. We should have told the Business Manager a story rather than “They blew up the Death Star”

Posted by chrismatts at October 13, 2003 1:00 PM