Breaking Down the Silos for Better Requirements Elicitation

I’m sure that by now we have all seen statistics about the reason that X% of projects fail is due to requirements. They always point back to the fact that the BAs did not capture the correct requirements. Well, maybe, just maybe, it isn’t our fault. It may be the way in which our companies are set up that force us to miss requirements. Yes, I said it; the way in which our companies are set up may cause us to miss requirements. But now that it has been said, we can no longer use it as an excuse. We need to understand how our companies are set up so that we can overcome those obstacles and become more effective. If we work within product silos, we need to understand how to overcome these silos in order to develop an effective business process. First, we need to travel back in time to understand the foundational architectural principles.

A History Lesson

In order to understand the silos concept, let’s start by going back to Greece. The ancient Greeks, when not competing in the Olympics or writing epic poems about Odysseus, built temples. Imagine yourself as a temple worker assigned to column duty, we’ll call it column A. It was your job to understand the dimensions of Column A, what the column should look like, height and width, etc. Basically, you were a BA working within Column A and Column A only. Occasionally, you would interact with those working on Column B or C over lunch or something, and you would learn what they were doing. But, basically, you stayed within the confines of your own column and you made a great column. But there were business analysts back then that were assigned the responsibility of the Architrave. In architecture, the Architrave is the ornamental band that rests on top of the columns (sometimes called a lintel). If the BA working on the architrave did not coordinate all the efforts of the individual column makers, it would not work properly, or rest properly across the columns.

Figure 1.Greek temple façade showing “silos”

Many companies today are organized in very much the same way, but replacing the physical columns with product silos. We have built our product lines into neat, organizational silos (the columns from the temple), and the analysis work is performed within these silos. Since authority and control from the top of the column only extends to the bottom of the silo, analysis does not normally occur outside of the column, or silo. What happens is that when the Architrave project comes along, no one silo wants to take ownership of the work required to analyze it because it is not in their “column authority.” The result is that the business process that crosses over the silos is not fully analyzed because no one examined something that went across the silos. A manager in silo A controls the activities (and probably budget) within the silo and is reluctant to allow one of his analysts to go outside of the silo. The reluctance may come from budget concerns (“If I’m paying for the analyst, I’m accountable budgetary-wise for the work that analyst performs”), it may come from control (“This is my department and my analysts only work on my projects”), or it may come from organizational policies (“No analysts may perform work outside of their department”). However it occurs, it hurts the project because the overall business process that needed to be analyzed was not analyzed.

Let’s create a hypothetical example of how this happens. Imagine a grocery store with product lines (or silos) of Marketing, Retail, Sales, and Distribution. A corporate sponsor comes up with a great idea to have customers order groceries over the internet. Since it was initially pitched as a Marketing idea, a Marketing BA performs a stakeholder analysis and determines that Marketing need to update the store’s website, and Distribution needs to deliver the product. So Marketing goes off and starts collecting their requirements, and Distribution does the same. But the Distribution BA uncovers that Marketing has no plan to sell the product, so Sales should be contacted for their input. Now Sales is involved, but they are off creating their sales requirements, and not involved with Distribution or the website. The head of Retail hears about this project, and wants his silo to be involved because there could be an option for customers to pick up their ordered groceries at the closest retail store and thus drive business to his retail sector. So now there are four separate efforts going on to create the requirements, but they are not talking to one another. When they all come together, the requirements do not match up, as each person understood the effort from a different perspective (e.g. they were all concentrating on their individual column). The end result is that it’s a mess, and there are probably cost overruns, unsatisfied sponsors, and the business loses a lot of potential sales if their competitors are able to beat them to this particular idea.

Look at the Business from the Architrave’s Perspective.

The Architrave has the advantage of sitting across all of the columns. To do so, it needs to have a lot of information about each column: it needs to know how much weight each column can hold (or manage), it needs to know the design of each column, to keep that design going into the architrave, and it needs to span across all the columns. It also has a viewpoint above the columns, so it is able to see the “big picture.” Before you can even go into understanding the business process, you need to determine exactly what business processes that you are going to discuss. Since you are at the top, think of processes that you would have to perform as part of this Web-ordering idea. There are probably more, but within 10 seconds, you can probably come up with, “Sell new service”, “Promote new service”, “Order product”, “Purchase product”, “Distribute product” and so on. Look at all of these from a process-perspective, not a “which silo owns it?’ perspective.

Figure 2. Business processes represented across business silos

By looking at it from a business process level, we can see that the process goes across silos for several of these processes, and we begin to see how they work across the entire organization, not just in one silo. For instance, with “Promote new service,” we might just think that it is a Marketing function, or a Sales function. But when the analysis is done across silos, we are able to understand that the real intent of the sponsor is to combine the promotion with the Retail function so that they can coordinate the promotion. If analysts did not study the business process from a point-of-view of the business process, the coordination with the Retail channel would have been lost. Also, it may be that in studying the promotion process, the analysts discover more groups that become stakeholders: Legal, to negotiate contracts for Radio and TV ad spots; or the Customer Call Center, to understand the new service and be able to explain it to customers when they phone with questions. You will likely find more stakeholders as you analyze the entire process, instead of just looking at it from your own silo’s perspective.

Completing the Temple

Alas, while it’s great to perform the process analysis at the Architrave level, one needs to have the support of the columns in order to hold it up. A process cannot survive on its own without the foundational support of the silos. Eventually, the weight of the Architrave has to be supported by the columns. This is where the business process falls into the silos. After developing the business process, then you can start developing solutions to support the business process. By looking at the process as a whole, and from above all the silos, it becomes easier to determine exactly what needs to occur to support the process, and to assign the functionally to each silo as necessary. Also, since the entire process is documented, analysts do not get caught in the trap of having each silo assume that another one is going to complete work X or work Y. Black boxes may still be around, but going into the solution, the silos know which one is tasked with supporting that piece of the process.

Hopefully, you have a better understanding about the necessity to understand how the business operates throughout the business, not just in a single silo. Not only will you have a better documented business process, more well-defined stakeholders, but you will also experience better coordination across the silos when it comes time to develop the solution. I would like to explain more about Greek culture and mythology, but I have to run, I’m lashed to the mast of my ship, and I hear the sirens calling me…

Don’t forget to leave your comments below

---

Paul Mulvey is a Lead Business Systems Analyst at UPS. He grew up with a Humanities professor father who would probably be very proud to know that his son has still retained knowledge of the Greek civilization. He can be reached at [email protected]

© 2010 Paul Mulvey