What is new in Business Analysis and Requirements Methods?

For many, many years I have used all available sources to keep up to date on what I do as a profession. Back in the day, I would read good old paper magazines being circulated in offices I worked in, venerable publications like ComputerWorld, Datamation, and Information Week. As the internet grew, the sources became websites and email newsletters, then blog postings by noted writers, followed by distribution through twitter and its accumulator services like paper.li.

But lately I find my sources are repeating the same topics over and over again; Agile, BPMN, Use Cases versus User Stories, etc.. Have we climbed on to a plateau of methods and methodologies? When was the last thing to come out that made a difference in the way Business Analysts provide better results?

My focus for a long time has been Requirements, their discovery, documentation, and use in delivering solutions. At least a decade ago I wrote posts on what combination of requirements techniques have worked best for me; I have seen nothing since then to change or add to that set of techniques.

I am trying to decide if this is a good or bad thing. I do miss the days of exploring new approaches, all the way from Structured Analysis & Design, through to Business Rules Management. I like to think my attention span is not that short, but I ask "What's next?".

Now, I will not say that having a stable set of techniques is a panacea for Business Analysts working today; getting opportunities to use them effectively is still as much a challenge as it has ever been. When I do get that opportunity, the work is still as fulfilling as ever.

But still: What's next?

The practical realities of software estimation

A great post from Scott Ambler about estimation. I ask a question, of course...

http://www.disciplinedagiledelivery.com/software-guesstimation/#comment-21334

What is a requirement? Well, what kind?

From discussion on linkedin

"What are requirements"

https://www.linkedin.com/grp/post/128312-6019368539587121153

My comment:

A lot of comments already, have not read all of them, but i think the question is too wide. We need some adjectives in front of "requirement". I don't necessarily like all of them myself, but I offer up the ones I hear most: business, process, functional, non-functional , solution, system, even testing. 
I think what most comments here are speaking to is the functional requirement. While precise wording can vary, I hold that the definition must emphasize the concept of "what, not how". I like Jose Santos version, but would shorten it to "A software requirement describes what a software should do but not how to do it, and it satisfies a need." I also like where commentators use the term "future". Certainly a requirement stated now implies a future state where it is met, but it is good to state/think it instead of assuming the implication.

David Wright

prototyping tools are not new, and may already be hanging on your wall.

linkedin conversation on prototyping

https://www.linkedin.com/grp/post/60878-6021176829337944068

So, key man theory and agile.

Later than I thought, but have always wondered about the Product Manager in the agile approaches that feature the role. They are the go-to person for the rest of the team with questions about what is being delivered, yes? What if that person, for any reason, has to leave the project before it completes? What impact does that have? Or am
I asking a rhetorical question?

Key Man Theory, heard of it?

Sometime in the past decades I read about a management idea called the "Key Man Theory". Of course, I can't recall where and when, but it stuck in my brain ever since. In essence, it states that if the success of your business operation or project is heavily dependent on one person, with unique knowledge or skills, you have a huge risk to mitigate. In less sensitive times someone might ask "what happens to us if Dick (or Jane) walk out of the office and get hit by a bus? are we screwed?". The nicer way of saying it now is "what happens if Dick/Jane win the lottery?". Either way, the risk is the same; things could go bad quickly.

This in the same idea as the financial product called key person insurance, but that may not be what you want to fall back on. It is good to avoid poverty if your business fails, but what if you love your business and want to actually save it? In this case the mitigation techniques are to reduce your dependence on the key man (OK, person) by looking to hire similar people, or start some knowledge transfer from Dick and Jane to other people in the organization. Dick/Jane may not be thrilled with this --- being the key person certainly gives leverage when asking for more money or other things --- but you have to do something about this situation; being empathetic and supportive of the key person will help. In the end, when they do leave/retire, they will have felt valued and may have enjoyed passing on their knowledge to the younger folk..


 So, I was drafting some thoughts on another post to come, which refers to the theory.  I thought I would make use of web searches to find some source info or references to use and, to my surprise, my searches found nothing... nada.  So question for everyone: do you remember 'Key Man Theory'? And if so, do you know what happened to it?

What to do when you see bad methods...

... and can't convince people of it.

I have had this experience a few times, and I have thought long and hard about writing about it.I still don't want to get into details, the old "if you can't say something good..." situation. But the possibility of it happening starts with joining a project already underway and the methods have already been chosen. When I first see something troublesome, I might nicely say something like "this is a bit different, how did come to be used?" The worst answer is "that's how we have always done it", and I really have to shut my mouth before reflexively responding "and how's that been working for ya?" ala Dr Phil.

I won't jump ship because of this (new ships not always passing by), so I make the effort. The real problem comes when you see that using the bad method(s) will make you produce bad or late deliverables. The worst response in this case is "Work harder, Work overtime, etc" because that is what always has happened, so it is seen as the norm for doing projects. Even if what you do eventually produce results in buggy systems and missing functionality, so that the change log balloons, that is also seen as the norm.

My personal problem is that I know it does not have to be this way, so it is tough to continue working to the 'norm'. If you are lucky, some project goes so awry enough that 'lessons learned' are considered; that's when you might have chance to suggest improvements.If not, I start considering my options for moving to a (hopefully) better situation. This could be within the organization if it is big enough, but leaving the org might be what is needed in order to join a better environment.

Anyone want to offer their similar experiences as comments?

Almost a year...

Almost a year since I posted, my my. Things have changed recently, in a way worth blogging about, so stay tuned...

Disciplined Agile Manifesto? Good but not what is needed...

Scott Ambler has posted his/DAD's updated Agile Manifesto at http://disciplinedagiledelivery.wordpress.com/disciplinedagilemanifesto/

It is indeed an improvement, widening the viewpoint and scope of what is involved in delivery of solutions... and yet, it does not deal with the nature of its objective, the 'consumable solution'. At some point there will be diminishing returns on the ability to deliver the best solution. Ninety percent of the cost related to a solution is incurred after it is delivered. The ability to deal with changing requirements after delivery is more important than before delivery, and yet software is delivered that deals with the moment, and the problem is that changing it after delivery takes too much time and effort.

I have said this before, but what we need more than agile solution delivery is agile solutions; solutions that are designed to accept change without needing to make changes to the solutions themselves. Business process management, Business Rules Management, mix-and-match services. All this out there, but does not get the profile it deserves.

So who wants to help me write an Agile Solution Manifesto? "we prefer configuration over software maintenance..." No, we demand configuration over software maintenance.  Who's with me?

Man, I have been really busy for the last 12 months

Man, I have been really busy for the last 12 months... I worked my last gigs with IAG Consulting, and then went independent to contract at one of the big 5 Canadian banks. It was for 6 months, been renewed, and seems possible a few more extensions will be offered.

I do miss the variety of engagements I had at IAG Consulting over the previous 5 years, and would love to do it again sometime, but a few changes in my needs led to the more traditional contract. That said, it is a great project I am on, to completely revamp how customers are treated when they come into a branch for one product and are helped to look at other complementary products and services for a better overall support of their financial needs. It is a big project , even for this bank, with more BAs in one place and time than I have ever seen before, with the project broken into components that are all being analyzed and designed in parallel.My role is primarily coordination across the components, and as single point of contact to many other stakeholders in the bank. I have been dealing with and learning from people in legal, compliance, privacy, internal controls, anti-money laundering and more.

So that is my past year in a few sentences. I think I will be posting more often over the coming months, probably more about my favourite combination of process, data, rules, services and such.

Cheers for the moment.

Agile Organizations - Dealing with Expected Change

Agile is an attractive word. It means swiftness with discipline, with an emphasis on alertness to change in one’s external surroundings and quickly responding to change as needed.

The word I want to focus on from above is external. When the surroundings that generate change are actually controllable, then the need for agility is greatly reduced. Agility comes at a price, and maintaining agility is a waste of resources when change is controllable.

A prime example of the difference between internal (controlled) and external (un-controlled) is an operating enterprise: business company, non-profit group and the like. The interesting problem for most enterprises is how effectively they control their own operations. The boundary between internal and external can become nebulous if control is lacking in parts of an enterprise.

Control sounds like a bad word. It implies top-down definition of all aspects of enterprise operations. This can be true, but control can also include delegation of authority, with expectation of results without definition of methods used. Control is maintained, but authority is distributed. This is the sphere of business management practices, defined and changing and transforming from Henry Ford to Jack Welch. It is not easy, and many others have and will address it better than I, so I will reference them as need be.

The topic of interest here is the boundary between internal and external, controlled and uncontrolled, event and response… but not between knowable and unknowable. An enterprise needs to know what is happening around it in order to focus its operations on knowing what events are important, events that it needs to respond to. For these events, an enterprise defines processes/procedures to execute when triggered by events, to provide the desired results in response to the events; successful enterprises include those that recognize that the nature of events and corresponding processes change over time, sometimes very quickly. So, at any one point in time, an enterprise needs to be in control of its processes, but that control can’t stifle the need to change as fast as the world around it changes. Further, this rapid change needs to be accomplished without disrupting on-going operations.

What we are discussing here is Controlled Agility; the ability of an enterprise to respond swiftly to changes in its surroundings without losing its internal cohesion.

The basis for controlled agility in an enterprise includes understanding that:

•         an enterprise runs on its processes, not its org chart
•        processes are composed of distinct activities and decisions
•        processes run on information, gathered and stored and used
•       processes are guided by business rules, especially when decisions need to be made.

With this basis, an enterprise is well-positioned to be Agile without losing Control. It all comes down to understanding Change.

Change comes in many degrees of impact to an enterprise. Consider workflow, which is based on process with roles and authority levels defined. If all loan applications over $100,000- go to Fred to be underwritten, the workflow will change temporarily when Fred goes on vacation. Those loan applications have to go to someone else until Fred gets back. This kind of change can happen frequently, but more importantly, it is a kind of change the enterprise knows can happen.

Frequent known changes are the heart of controlled agility. This is the kind of change an enterprise must be able to do, without changing itself, as part of operations. It should not need a project, especially an IT project, to make the change.

Temporarily changing workflow might be considered a simple example, but it is actually an example of an overall type of change that can occur frequently, and that is business rule change. Business Rules are so embedded in how an enterprise works, it is actually a new and revealing approach to call them out separately. In a lender enterprise, it is likely a fact that “Customers may apply for Loans”, but “Customers may apply for Loans, only if they are 18 years old or older” is a Business Rule; it constrains an aspect of enterprise operations and, as said above, rules change (next year it could be 19 years). An enterprise that knows the facts and rules of their operations is well positioned to change rules as quickly as needed. However, rule changes still need to be controlled to avoid using incorrect rules to the detriment of the enterprise. Still, these changes should not require a project to change the structure of the operation and, again, not need an IT project.

A major use of rules is to support making decisions.  Loan underwriting across many financial lending/leasing enterprises is heavily rule-driven, the information about a customer and the loan product being used to decide to lend or not. These can be complex rules, or simply that the enterprise does not lend to anyone with a Credit Score below a stated value; and again, the rules will be changed over time as a lender tunes its underwriting, or is willing to take on more risk, etc..

Decisions also play a role in defining what processes/activities are used to respond to events. We all know of BPM diagrams with boxes for activities, diamonds for decision points, and arrowed lines connecting them all. A process may be composed of 20 possible activities, but less than 20 might be used in response to any one event because of decisions based on rules.

What can change for a process? The number of processes in an enterprise, once all are defined, is relatively stable over time; new processes usually mean the enterprise has expanded its products/services to areas which need their own processes. Within a process, however, the exact activities that are carried out may change, or be re-ordered, or even be retired. It is the ability to change processes as quickly as possible, again without a project, that marks an enterprise as Agile.

Changes in decisions and rules used in processes are the most frequent changes an Enterprise must do. Changes to the activities in a process change less frequently than decisions/rules, but often enough the agile enterprise needs to it as part of its operations.

Are there aspects of an enterprise that are more stable? And are types of changes to them not necessarily known or predictable? This is a loaded question, because the answer is information or specific data used by an enterprise. Once all the information needs are known for an enterprise, these are very stable over time. The need to change information needs is similar to the need to add more processes; it happens when (as above) the enterprise is expanding into new products or services different from current products/services. To be more precise, information needs may change as the enterprise expands, but they may not as well; data requirements have been shown to be the most stable aspect of an enterprise.

So we have two ends of the change pendulum: from frequent and known, to rare and unknown. As said earlier, frequent known changes are the heart of controlled agility. 

To Agile or Not To Agile

After a long period of trying to grapple with "agile" or "not agile" etc., I finally realized something; it really depends on what you are trying to develop. My thoughts now divide software grossly between "product" and "process".

If you are developing a software product, especially to actually sell to customers, then I think product development methods are the way to go, and Agile fits this approach well. You do start with a Product Owner's vision of functionality, and user stories are a great way to express that vision as a starting point for developing a prototype or first release.

If you are dealing with a business process to automate, then a 'vision' is not appropriate; you have to document what the process is, completely and clearly. High-level process maps supported by use cases are a great approach for this. You have to  realize that there can be no arbitrary first release for a process based on a sprint or other cut-off. If you are automating a process to, say, transfer money from one bank account to another, you can't first release the "from" account piece without the "to" account piece.

So, use the appropriate technique for the software you are developing; no one technique meets all needs.

You have to have an acceptable budget for a project before you can start managing the budget for a project.

Over the decades, I have seen many methods and tools for managing things you create, but don’t offer any help in actually creating them. In the BA/requirements world, the key example is Requirements Management Tools; useful once you have requirements, but defining clear and complete requirements is the difficult part. Anyone who has read my past posts knows that doing requirements definition/discovery is, well, what I do.

But there other such things, and some of which having good requirements can help. For example, do you need to budget for your projects before you start them? You have an annual or quarterly process about submitting budgets and getting approved, and then a separate process for changing the budget during the projects. However, do these processes and supporting tools actually help you come up with a budget number you are comfortable with? No, so you need something else to help with that and, no surprise, requirements can be that something.

What can clear  requirements help you get? Estimates, for design, development, and testing. But, you ask, are you saying to do all the requirements for your upcoming projects long before they start, to get budget amounts? Yes and no. Requirements can be defined at different levels of detail, you just have to balance the level of detail to the granularity of the estimates needed for budgets.

When you actually start to elicit requirements for a project, the first thing you have to do is scope the requirements analysis work. This scoping will take a half-day to a day to complete. What I am suggesting is to do this scoping work-only for all your planned projects. This scoping will provide the main business activities and information  to be addressed in the project. That is enough detail for t-shirt sizing of each project,  small/medium/large; align this sizing to previous projects  of similar sizes, get the costs of those projects (not always easy but it should be somewhere) and you have numbers that are based on something real. The percentage amount of variations might still be high, 20 to 40% for example, but the numbers are based on something real, not just SWAG or other “best guesses”.

Is a day per project for requirements scoping during budgeting too much to ask to get some real numbers? I think not.

Celebrating a 5 Year Anniversary

I am celebrating of those significant work anniversaries in 2013; I have now been a Requirements Consultant for five years with IAG Consulting. For some decades before 2008 I was an employee of several different organizations as (early on) a programmer and then a Business Analyst. As those years went by, I had begun to wonder if doing business analysis as a consultant was a viable career choice; finding IAG Consulting showed me it could be, and it would be tough to see myself resuming my earlier life as an employee. As a consultant, virtually every work day is meaningful and delivers value to a client; you frankly get the focus and involvement of people when you are a clear cost, more than (sadly) an employee Business Analyst usually gets.

On the other hand, I could probably not be the effective consultant I am today without at least many years of the experience I gained as an employee. One thing as an employee does have is usually the chance to attend conferences; I also participated in industry-level standards efforts at different times. In the end, though, the move to consulting was right for me.

Since then, I have worked on projects for dozens of companies, working with hundreds of good business people to help them effectively and completely define their requirements for processes and systems. I expect to be at it for many years to come, so if you organization is looking for this kind of help, come visit us at http://www.iag.biz/ to see what we (and I) can do for you.

In response to "#NoEstimates Part 1: Doing Scrum without estimates"

In response to "#NoEstimates Part 1: Doing Scrum without estimates" at http://neilkillick.com/2013/01/31/noestimates-part-1-doing-scrum-without-estimates/

Sure, estimates are, well, estimated... based on what the person estimating knows at a point in time, the choices are (1) I estimate it it will require "X" to do it, or (2) I can't estimate what is required to do it. I think this comes down to people not wanting to accept that an estimate could be wrong, or not right enough.

I get an estimate when I need car repairs, to make sure I can or want to afford it. My mechanic calls me when he finds something he did't know that will change the estimate, and I decide what to do. If I find over time that my mechanic always under-estimates the cost, eventually I will change mechanics. The average reality should be a bell curve around an estimated value, an estimate is almost never exact, but a statistically acceptable variation is what you should look for.

   Now, such analogies of physical things are problematic when used to describe an aspect of software development. Software is intangible for one thing, and we really haven't been creating it very long to have some good tools like other disciplines (like Engineering) for predicting outcomes; but like everything else, it takes time and money to create it, so the people investing that time and money usually want an idea of how much that investment will be to get what they need. Just saying an estimate is worthless isn't really going to go over well.

    The advantage of software over physical things is that you can indeed create small amounts of it that can be seen to work. Long before 'agile' got its name, a lot of software projects switched from estimates  to time-boxing: give me x amount of resources and the project will deliver what it can in that 'box'. Investor spends a little to see what he can get for that amount. If it looks good, run another time-box. If it doesn't look good, you can stop with only a small investment amount having been spent.

    Lastly I would comment on your statement on what does an estimate have to do with creating good software and a good return on investment. ROI is a funny thing, often very date-specific; delivering great software after a competitor has already done it and captured the market will kill your ROI. Some windows of opportunity are very short; miss them and the return is nil. In these cases, you have to have some way of knowing if you can make the window. Like it or not, an estimate is one way of trying to figure that out. It is these  kinds of situations that will make investors wary of new development and look for packages or services to meet the need. Nothing is perfect  but not being to estimate software development may just lead to no new software being developed.

Business Analysis - what is it, anyway?

Way back in college I had a an economics professor who was a bit radical. I took his Intro to Economics course, and the first thing he said is " The only thing I am not allowed to change is the name of the course, but  what I will be teaching is totally different than what the course description says." And that is what he did.

I say that because sometime between then and now I started this blog and called it "Business Analysis". At the time it seemed to be the best name for attracting readers for what I would write.

Since then, one of the ongoing discussions out here in the interweb is, just what is Business Analysis? What does someone called a Business Analyst do? My usual rejoinder is to re-use of some Bill Clinton's words: "It's the Requirements...dummy." OK, I leave out the "dummy" unless i really know who I am talking to, but that is the essence. Suffice it to say, my answer (repeated many times, which you could see across many linkedin BA groups) has not  settled the issue. And that's OK, one must not assume their opinion will matter to everyone, especially when they have not paid for it (like buying a book or attending a conference).

(An aside: I was in a tourist shop somewhere and it had a little laminated sign that said "Everyone is entitled to my opinion." I bought and put it on the wall in my cubicle... when I still had one.)

So, to get to a point here, I wish I could change the name of this blog to something more specific to Requirements, but so far I find that is not possible on this platform, and I don't want to start a new one and lose followers and such. That is a technical problem, but it illustrates that I want to be more specific about what I post about. I think that could be summarized with a title like "Requirements Discovery". Until I (bother to) sort out the tech thing, just think of that name when you come by this blog.

So, if you are reading this post because of it's title, I will admit that I did not specifically answer the question; I can only opine on what I think it is: that its core is Requirements Discovery, Description, and Documentation and, despite what else a Business Analyst is asked to do (project manage, test, etc), BAs are the only people/role that has this focus.I don't mean to restrict the scope of what anyone thinks Business Analysis is, but I say if you are not doing Requirements work, then you are probably doing something other than Business Analysis.

Follow-up to “So, you’re buying a package? Don’t forget your business requirements…” Don’t over-analyze!

Follow-up to “So, you’re buying a package? Don’tforget your business requirements…” Don’t over-analyze!

For those of you who do define requirements for their software development projects, but are new to buying packages, a cautionary warning; they are not the same thing. Consider the following “the system shall” requirement  statements.

1) The system shall determine if a person ordering pizza is a current customer.

2) The system shall determine if a person ordering pizza is a current customer, only if the person is phoning to place an order.

3) The system shall determine if a person ordering pizza by phone is a current customer using the person’s name and phone number.

Each requirement is at a certain level, increasing in detail from (1) to (2), and from (2) to (3).

- Requirement (1) is at high-level, stating that the system shall do something with certain information.

- Requirement (2) is more detailed, stating that the system shall do something with certain information, in a certain situation.

- Requirement (3) is fully detailed, stating that the system shall do something with certain information, in a certain situation, according to certain rules.

Requirement (3) is what you need to provide to designers/developers to use in new software development. However, this not what you need to provide to vendors when you send them an RFP; in fact, this level of detail can be over-kill analysis and can restrict the number of vendors who could meet your needs. By being very specific about rules and restrictions, you may eliminate a vendor who has a different and possibly better approach to meeting the business need, e.g. a better way to determine who is a current customer.

So what level of detail do you need? High level requirements like (1) can be useful at the start of a project, to describe scope and support planning; this level can also be used in a Request for Information (RFI) sent to vendors, just to get an initial view of what the marketplace looks like.

When you get to an RFP, you need more detail to differentiate vendors better, and Requirement (2) is an example of this level, which I call mid-level or standard-level of detail for requirements. At this level, you can see the difference between vendors in meeting your requirements, enough to evaluate their product and decide which one will serve you best.

So I now have two recommendations for organizations looking to buy a package:

- Don’t forget your business requirements…

- … but don’t over-analyze your needs,  so you can best evaluate those packages. 

“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?