MIS 5102, Spring 2011 Viju Raghupathi Assigned Reading, Week2

advertisement
MIS 5102, Spring 2011
Assigned Reading, Week2
Viju Raghupathi
Requirements
Breaking down the Silos for Better Requirements Elicitation
www.batimes.com, March 23, 2010, Paul Mulvey
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
Page 1 of 2
MIS 5102, Spring 2011
Viju Raghupathi
Assigned Reading, Week2
Requirements
(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...
Page 2 of 2
Download