“Why do I need Requirements? I’m buying a Package!”

In the wide world of information systems, development of new software receives the most attention from industry writers. Whether it is traditional magazine articles and books, or blog posts, or discussions in groups on LinkedIn and other sites, it is all about “green field” development.

However, when one considers the wider view of organizations concerning information systems, it is common that new software development is not always the primary means of implementing new systems. Organizations do need software for many different functions and data, but a lot of those are common; organizations that realize this do not develop their own software for common needs, they buy it.  It actually started a few decades ago with functions like general ledger accounting and human resources, then it moved into more specific domains like insurance or banking, and on into cross-domain ERP packages popularized by major vendors.

When organizations first started to buy more than build, they were often delighted by the time savings: “I can have it now? And not wait 2 years for it to be developed in-house? Where do I sign?” What many organizations did not realize, and their internal IT people probably didn't see either (at first), was that it was only the pure development and system testing activities that were being saved. There was still the need to determine what the package was actually going to do. While software apps provide many common and standard functions, which ones are implemented, and how they are configured still vary significantly based on an organization’s own needs. Ahead of that, the decision has to be made concerning which package to buy in the first place.

This is where business requirements come in. Again, the focus and discussions about requirements these days is primarily about their role in new software development, such that some organizations forget or discount the need for requirements when buying packages… This is a recipe for disaster.

It is true that companies buy things all the time, and often use a standard Request for Proposal (RFP) process. A common process is a good thing, and proposals for quantifiable products such as hardware or components can be straightforward. An RFP for software, however, is specifying an intangible thing that has to perform a function in a specific way. That means defining complete and correct business requirements.

A web search on RFPs or package implementation failures will quickly identify a primary cause; “Failure to clearly define the business requirements for the project”.

(see http://www.orionsecuritysolutions.com/the-o/item/188-request-for-proposal-mistakes).

Even the (in)famous lawsuit between Waste Management Inc. and SAP concerning a failed project included a claim by SAP of Waste Management "failing to timely and accurately define its business requirements" as a contributing reason for the failure.  

(see http://www.cio.com/article/486284/10_Famous_ERP_Disasters_Dustups_and_Disappointments).

(For even more on the importance of requirements, see the Business Analysis Benchmark Study from IAG Consulting, see  http://www.iag.biz/resources/library/business-analysis-benchmark.html  )

So, an organization cannot skip over or pay lip service to business requirements definition in software package projects. Done properly, good business requirements can be used to directly fill the part of an RFP that scares most people: the functionality and data that a package has to meet to be considered for purchase.

 

When first putting together a list of candidate packages, there may be a lot of vendors who claim to meet your needs based on a summarized description of their products; sending vendors an RFP containing good business requirements will quickly weed out the ones who don’t measure up. Many times, (good) vendors react to this kind of RFP by declining to respond when they see that their product really does not meet the business requirements; this saves both parties time and effort on a deal that would never have gone through.

This will normally lead to a short list of vendors who have a product that could meet the requirements. Getting to one vendor usually involves product demonstrations, on-site trials and other means of evaluation. Of course, other requirements need to be met as well, perhaps technical requirements the software has to meet to run in the desired environment (although hosted and other “cloud” options are changing this). The best scenario is to have two or three vendors whose products will meet the requirements, after which the remaining negotiations can be about getting a good price … all because of having defined the business requirements.

And last  but certainly not least, having the business requirements eases the implementation of a package. In decades past, buying a package meant buying code; if alterations to the package were needed, that meant changing code, and getting it to work. This was often difficult and would commonly void any agreement with the vendor to support the package and provide updates.

These days, good packages are built to be configurable. A vendor will often have consultants who can configure the package; and what do those consultants need as input? Your business requirements.

If by chance and very good luck, the project has reached this without having defined the business requirements, they will have to be defined now if the package is ever going to work properly; and there is a very likely possibility that when the requirements are finally documented, it is clear that the wrong package was purchased. That’s when stories about project failures turn up in industry magazines and sites, and even the regular media if the failure is colossal enough.

So, you’re buying a package? Don’t forget your business requirements…

documented Requirements as an essential artefact for systems development

Let’s start with a clear statement:  I view documented Requirements as an essential artefact for systems development.

Given that, I don't want to imply that Requirements are 'sacred' in some way or worse yet, an end in them-selves. They are a vital but intermediate deliverable along the way to delivering the solution that your business needs to succeed.

This brings me to the often-cited problem in Requirements work most commonly known as 'analysis paralysis'. Requirements gathering, analysis, and documentation cannot be some endless task that defers delivering the Requirements because of uncertainties or changes in the details of the Requirements. It does require sufficient time, but historically I have seen the effort spent on Requirements average around 25% of a total systems project. If you are spending more than 25% on a regular basis, you might have some paralysis going on.

(Sidebar: the other 75%? Typically I see 50% on design, build, and unit testing, and 25% on the rest of Testing: System, User, Acceptance, Volume, Regression, and probably more I am forgetting.)

How can you avoid paralysis?
- Define a clear scope of the Business process or function that is to be supported by the solution. If you have or can quickly put together a process map (start by defining all the external events the business must respond to), then it can be shown what you are gathering Requirements for, and what you are not. Having that Process Map also helps identify units of work in process steps that can be documented as Use Cases.
- If nailing scope down is difficult, then time-box the work; take what you do have defined as likely in scope, and spend 2 to 3 weeks of focussed work with business involvement, and you will be surprised the volume of Requirements you will produce. Stop at the end of the time-box, and re-group/review with your Sponsor. You may have enough to start a round of development/delivery, or a better view of how much time you need to finish a complete set of Requirements.

It is also important to recognize the Requirements will change, but not necessarily for the reasons you might think. For example, you may document a portion of the requirements and review it with the business staff involved in the gathering, and you just may have written it down wrong or misunderstood what they told you; reviews/walkthroughs are essential for any quality product. If you can succeed in getting agreement that the documented Requirements are correct from the business, the amount of change after that point will be minimal.

Agile methods proponents will tell you the business changes too much and too often for documented requirements to remain valid; don't believe it. Core information systems requirements about collecting, storing and using data do not change much over time; what does change the most is process/procedural activities, the main reason why an Information System should not automate business process, especially now that BPM tools are available that are designed to accommodate procedure changes. As author Steve McConnell once said, the main reasons requirements change during agile development is that the requirements were not fully investigated before development started.

The last advice I would offer to fellow BA's is that you do document the Requirements as your work, but you do not own them; they belong to the business. So, don't agonize over what may happen to Requirements after you have delivered them. There is a quote about working whose source I must track down, as it guides me every day; it is:…

"Show up on time, do your best; don't get attached to the results".

Wise words. Besides, there is always another project up next that needs its Requirements documented, so get to it!… 

Writer's Block

I have this current desire to write something meaningful about business analysis, and information systems in general, but the spark of a topic eludes me. I have been prowling aroung the various LinkedIn groups, then over to Modern Analyst, and then to BA Times... leaving the occasional comment on somebody else's post, but even other peoples' posts seem to be covering mostly the same ground: BA social skills, ruminations on agile, etc.

Other things I have grown tired of include programming as an art (it isn't), and the mis-use of the terms "iterative" and "incremental"... maybe I am just getting old...

I remind myself that I am always looking for more about the confluence of business process managent, business rules management and data services, but don't see much. The vendors are getting there, IBM of course, and a search finds offerings from SAP and Bosch, but I don't get the sense that anyone is actually doing it.... or, they are and keeping it quiet, since the potential for improvement can greatly increase competiveness.

Anyone have any tales to tell about this?

Software Engineers? real ones?

Anyone who attended an Engineering School for Software Engineering, I would like to hear about your experiences and the merit of what you learned. I often like to propose to people that software development should be following an engineering approach, as opposed to craftsmanship or "artistry', but I am not an engineer, I took Comp Sci in University (a long, long time ago, in what now feels like a different universe).

So, please use the comments section for this post to educate me on real Software Engineering, it will be greatly appreciated.

Are we past the period of "Agile vs. Traditional"arguments?

Are we past the period of "Agile vs. Traditional"arguments?

Using Twitter and various industry newsletters, I try to keep up on the state of systems delivery methodologies and techniques (or whatever noun you like to describe these things). For a long time in the first decade of this century, you could hardly go a day without someone weighing in on the "Agile vs. Traditional"topic; in the early days, it got quite emotional and vitriolic at times. The debates and discussions got more civilized over time, and now I see little or no debate.

So, did Agile "win"? Or has it been absorbed into some new overall way of doing things? I still see many articles on Agile, but they seem to be more on how to make it work rather than why you should use it.

Let me propose this "new way" as follows: we need to move our focus from agile systems development to developing agile systems. Thoughts?

Using requirements tool remotely.

I have just realized that my last post here was back in May of last year... probably due to a combination of being busy with work I am enjoying, and not having any sudden urges to share something on the overall topic of business analysis, or IT in general.

So what's keeping me busy? an on-going project for a new system that has multiple stakeholders spread across the United States. What this means is that the project is using a requirements tool accessible over the net, so we have a meeting or two with stakeholders gathered in one place, followed by follow-up work done remotely using the tool, email and skype. That meant a lot less travel, and my "commute" was to walk down the upstairs hall in my house.

The interesting thing is the remote use of the tool. Maybe only a few years ago, being able to do this would have been seen as an amazing new capability; now we get annoyed if response time is less than immediate. It would seem that user expectations are still zooming ahead of tech capability.