What do you do when the client isn't focused on the business outcome?

One of the values that we bring is that we can help our clients to decide what scope to cut by providing them with a framework that links quantifiable business objectives to specific features. We create an objective chain to do this and it helps to spotlight features that don't feed into the core business purpose. Typically our stakeholders are able to cut a minimum of 10% of features and as much as 90% while achieving their objectives.

What we are finding though is that it is sometimes a challenge because the features that are good for the company are not necessarily good at making the lives of the people using the software easier or better.

We have recently run into a case (I'm changing the dollar values and the features for confidentiality reasons) where the business side of our client had identified $50 million in potential savings each year in an area of the business related to giving discounts. The issue was that the discounts were being calculated manually and there was the serious possibility that customers were claiming millions in discounts twice. The discounting system and rules are very complex with overlapping effectivity dates, products, regions and discount rules.

The business was confident in the $50 million number based on industry studies that showed that typical companies were giving away 5% more than they needed to in improperly calculated discounts. However, no one could identify specific types of problems that might be leading to double payment. We did a little research and analysis and decided that the biggest risk area was multiple overlapping discounts and so made that the focus.

There were several issues that came up. The most critical was that the users of the system and the business team while acknowledging the problem with overlapping discount agreements, were basing their decisions on the efficiency of the team. The calculating team is an offshore team with 8 people focused on this portion of the process. The company had done a study to show that full automation could reduce headcount from 8 to 2 people.

However our view was that the savings associatied with reducing headcount from 8 to 2 people was so minimal that it wasn't worth the effort in the beginning when we were faced with such a large amount in overpayments. Instead we felt that focusing on the features that would automate detection of overlapping agreements were absolutely critical. Deploying those features as quickly as possible was paramount because of the massive revenue leak associated with the problem. Leaving a majority of the process manual would actually be ok if the system had the ability to determine when multiple discounts were being applied to the same purchase and thus eliminate the lost dollars.

It turns out that the business simply didn't want to fund the project unless their work was decreased, even though in the overall scheme the cost savings was minimal. In the end they approved funding for a first phase that has full automation but does not actually focus on detection of the business case driving error conditions. The detection of the error conditions will come in later phases, so ultimately they will get the business value.

We see this often where at the level of individual features, the subject matter experts have mandatory features that will make their life easier but don't necessarily contribute to the business case for the project. These features create a death by a thousand cuts situation. Our methodology can identify the "unnecessary" features, but ultimately it is up to the client to decide if the business case is really the highest priority.

RML™ Requirements Model 5 - The Data Flow Diagram (DFD)

The Data Flow Diagram (DFD) is a very useful part of the Requirements Modeling Language (RML™). The Structured Analysis Wiki contains a great explanation of how to create a DFD, so I’m not going to cover that information here. Instead, I’m going to provide one answer to the question “How do I know when to use a DFD?” This answer comes from my own (unique) view of the world, so some of you probably won’t relate to it, but others will--I’m sure there is at least one more out there…

Sometimes I have what I think of as an "equation" in my head. In vague terms, I may be thinking “Customer Data + Product Data + Input from Sales Rep + Taxes = Order”. But that's not really right, nor is the equation a good representation of the information.

And, the “equation” also misses a few other particulars about creating an order that I’d like to convey: Sales Reps update customer data, the Finance staff maintains the rules for the tax calculations, and orders flow to the Order Fulfillment system after creation.

The data flow diagram is great for representing all of this. Here’s my “equation,” expressed as a data flow diagram:

I have found that business users, as well as developers, react well to this model—it provides a “big picture” with which to begin a conversation about creating an order. It paints exactly the picture I want to convey and validate when I’m thinking “Customer Data + Product Data + Input from Sales Rep + Taxes = Order”.

Display this picture, and you’ll get some interesting questions and comments:

• How is customer data populated initially?


• Does the order fulfillment system update the order store with information about the fulfillment of the orders?


• Where does the product data come from?


• Are all of the tax rules manually entered, or is there also an electronic source for them?


• And, maybe, “No, that’s wrong, updating customer data isn’t a separate process. Customer updates need to automatically flow out of changes made when creating the order.”
  

One note: it doesn’t have to be technically perfect to be useful. I often provide “conceptual” DFDs, in that I intentionally provide conceptual, but not technical information. For example, conceptually, there is a “products” data store. Technically, there may be multiple stores: product list, product descriptions, etc. The important thing is that they work together to provide product data. Developers and architects are very receptive to this; they understand I’m illustrating the behaviors of the system without defining the implementation (which, after all, is their job). Oh, and how does the audience know it is conceptual? I put the word “conceptual” in the title!

You may notice I didn’t number my processes. That’s because I rarely decompose them and many people tend to take the numbering as ordering. So, for my usage, numbering adds confusion rather than clarity.

Happy diagramming!

Related Articles:

How To Choose A Software Requirements Model

Six Requirements Models For Agile Projects

What does "requirements sign-off" mean in agile?

I was recently working with a cusotmer on a project using an agile methodology. The organization was moving towards trying to do most of their projects in agile, so the nature of this is that they have a lot of non-agile pieces to their methodology still in place. We were cruising along in defining requirements and development was well into the first sprint, when the project manager told me we had a target date for the requirements to be signed off.

Wait a minute! Hold your horses folks! Sign-off? In an agile project?

I took it upon myself to remind her of the development methodology of choice for our project… and that she was asking me about sign-off in a methodology where it doesn’t really make sense…. one where the users have the right to prioritize whatever features they want in the backlog at any time. So if they forgot some features during our elicitation process, then that’s ok, they just need to figure out where to put it in the prioritized backlog, realizing something else may drop off. She laughed immediately reassuring me she hadn't lost it and that she understood completely, but the corporate process required this! So we began the discussion of what a “sign-off” would mean to us.

In the end, I think we got pretty creative with it. We did have lots of requirements in the form of user stories and other models like process flows, state tables, etc. And we were working closely with the users to elicit and review them. So what we asked them to do was to “sign-off” that at that moment in time, there were no major requirements missing, that they knew about, and there were no major issues with what we’d written down, that they knew about. The key is this means that they did in fact look at them, they participated in the activity and so development is not developing a prototype of something too far off basis. But it also keeps open their right to realize something new they need after they see it, think about it, sleep on it, or whatever.

What I really like about this is approach is that it doesn’t force anyone into a corner where they feel like they are signing away their life over a massive requirements document that they barely understood or that they are signing on a dotted line to say they are mostly perfect and got it all the first time around. So more or less, I think our version of sign-off allows the spirit of agile methodologies to prevail still.

Lessons from a Bad Haircut

I got a lousy haircut the other day. I’m not happy. And, one of the things I’m least happy with is the fact that I can trace one comment I made to what ended up happening. I still hold the hair stylist responsible, because she’s the expert. I left something unspoken related to the comment, so what I said in total was inconsistent. She should have asked the questions to get it right. She should know that lay people use industry terms incorrectly and she should be restating what she is hearing to make sure her understanding is right. She’s the expert.

It’s made me think about how I do my job. I’m the expert. I do ask questions. I do present information in multiple formats—diagrams and words—to make sure I convey what I heard and get it right. Still, reminders can be good. My lousy hair cut reminded me: even when a person appears to know what they’re saying, they may not. Or, they do know; their use of language is just different from mine.

Next time I’m tempted to accept an answer on face value, I’m going to remember my bad haircut. Because, while my hair will grow back in 6 weeks, bad software can last for years.

Live from REFSQ: Deriving Information Requirements from Responsibility Models

Tim Storer from St. Andrews University in Scotland presented this paper. His underlying assumption is that in large scale socio-technical enterprise systems, you are constrained by the design of the platform you select, integration to other systems, and systems of systems factors. He contends that the functional requirements in these projects are more useful in the procurement process where you select the system to implement, and specifically less useful in the actual implementation. The reason for this is that the system is already constrained by behavior based on what you select. While I don’t entirely agree with the de-emphasis of functional requirements he implied, his overall point is absolutely valid in that you often are in a situation where you must configure the system and adapt business processes around the system.

This paper discusses how beyond the functional requirements, you also need what he calls “information requirements” which help you to configure the purchased system for the given context. These requirements tell you:

• What information is needed


• Who needs the information


• Who produces information for the system


• Flexibility for access to that information


• Consequences of incorrect information flow

And these requirements influence platform configuration, organizational changes, and system integration.

To identify these information requirements, they use “responsibilities” as a starting point. They have defined “responsibility” as “a duty, held by some agent, to achieve, maintain or avoid some given state, subject to conformance with organizational, social, and cultural norms.” They are not goals, but rather more abstract and less formal. They are not concerned with specific types of agents. Then for each responsibility, they determine the resource needs, ultimately leading to information requirements.

In his example, a self service check-in terminal has responsibility of “provide boarding pass”. Then they can look at the resources needs– blank tickets, ticket database which is fed by ticket server, etc.

For the information resources, you then have to look at what happens if it the resource is unavailable, inaccurate, incomplete, late, and even early. And ultimately you get to the details mentioned above to form the information requirements.

What I found useful in this paper is helped validate some of our own thinking we are applying on projects in that we look at something very closely related with data requirements. We’ve written before about our People, Systems, Data (PSD) approach to discovering all requirements using visual models from RML™. In this case, if we break down the Data component of PSD in combination with the People component of PSD, we have something very similar to what Tim spoke to. Very briefly, we use the People models (e.g. Org Charts) to identify the people using the system and then look at what stories they need to execute in the system (e.g. User Stories). Now we can also look at the top-level data model (e.g. BDD – a Business Data diagram), and for each data entity in the diagram, we look at how it is:

• Created


• Viewed


• Changed


• Removed


• Copied


• Moved

(And yes, I deliberately did not call out the CRUD because I’m not a big fan of the acronym!). In doing this, we can actually complete the list of user stories and identify system integration points. Similar to above we would also use the user stories to cross-verify the BDD was complete. Our data actions closely map to the list in Tim’s presentation:

• What information is needed -> the BDD entities


• Who needs the information -> Who views it, changes it, copies it, moves it


• Who produces information for the system -> How is the data entity created


• Flexibility for access to that information -> Who views it


• Consequences of incorrect information flow -> exceptions in the stories that come out of the list

Now in a recent example, we were working with a system that we did not know well. There were six main data objects and a list of about 10 user stories for the system. I wanted to validate whether the list of User Stories was complete, so I proceeded to walk through each of the 6 actions above against each of the six data objects. Not every data object could have those actions performed in the system, but it was useful to deliberately check each. In the end we identified about five new User Stories.