Tag: Requirements

Getting Back To Basics: Third Fundamental – Identifying Your Sources

Written by Cynthia Low on June 2, 2008. Posted in Articles.

In April, I began a series of articles devoted to helping professionals wade through the sea of available business analysis information currently flooding the marketplace and focus on just the essentials. I like to think of it as Business Analysis Unplugged, my own personal back-to-the-basics world tour.

April’s article discussed the importance of understanding your organization’s overall business goals, and May’s piece covered how to create a common vocabulary among your project team. This month, for my third in the five-article series, I’d like to discuss something that can often get overlooked in the business analysis process: properly identifying the sources from which you will eventually extract your requirements.

Labeling
When we’re kids, we’re told that labeling people is bad. Well, this is good advice in life, but not necessarily in business analysis. The fact is, properly identifying and affixing your sources to specific categories is essential for planning and successfully extracting requirements. Although there are none that are set in stone, three common categories that I’ve used to label sources on past projects include: Customers, Users and Additional Materials and Experts. In this example, all of your sources would fit into one or more of these three buckets:

Customers
A customer is the person or group, internal or external to your organization, likely to pay for the products and services produced. This category can be further refined to include subcategories such as sponsors and champions, or domestic and international customers. The further you’re able to refine your categories, the better.

Users
A user is the person or group who is ultimately responsible for interacting with the products or services produced. Like customers, there’s definitely room for further refinement here. For example, direct users may touch and manipulate the system on a daily basis, while indirect users may simply request monthly or quarterly reports. Both groups will yield distinctly different requirements.

Additional Materials and Experts
This category is more than just a fancy name for Other. It could include additional individuals or groups with influence on the project, such as third-party vendors and subject-matter experts. It’s also important to note that your sources don’t necessarily even have to be humans. And no, I’m not talking about robots-at least not yet. There are many non-human sources that would fit into this category that you can leverage when extracting requirements. These could include existing systems, both hardware and software, or existing documentation, such as governance documents, previously captured business architectures, training manuals and service agreements.

A One- or Two-Person Job
In my last article, I encouraged group thinking for the development of a project’s glossary of terms. For labeling and categorizing your sources, I recommend essentially the exact opposite strategy. Like building a glossary, categorizing sources is busy work, but it’s busy work that should be taken on by as few people as possible; I’d recommend just the business analyst and, if he or she is feeling collaborative, the project manager. Too many opinions too early can lead to roadblocks of disagreement and the always dreaded analysis paralysis.

Within the categories, the business analysts should also identify each source’s role and then the benefits that each source will realize from the completed products or services. The phrase “no stone shall go unturned” applies well here, because eventually everyone on your list-from the daily direct users to the software developer at your partner company to the CEO of your organization-will be affected by what you’re creating. So, start with the big picture, and then become as specific as you can. Inevitably, you’ll find that some of your sources fall into more than one category. This is not a problem, and is to be expected.

Once you’ve created your detailed list of categorized sources, you should share that list with the team for feedback

Is It Worth It?
In our need-it-yesterday business culture, your temptation may be to just start calling and e-mailing your sources and asking them questions about their requirements. But remember, business analysis is about planning, preparation and clarity. By going through the process of labeling and categorizing your sources, you and the project manager will begin to get a clear picture of the scope of your project and the amount of time, money and effort that will be required for successfully eliciting requirements. You’ll also be able to identify the risks involved. For example, if you find that 60 percent of your sources are located in another country and many of them don’t speak your language, well, you’re going to have some extra work to do. It’s best to realize that from the beginning as opposed to three months in.

Next Month-Choosing the Best Elicitation Techniques
How’s this for a cliffhanger? Labeling and categorizing your sources is also essential for helping you identify the best techniques to use for requirements elicitation. Of course, this just so happens to be the topic for the next article in this series, which will appear here next month. Until then, remember, the more specific you are in your labeling and categorizing, the more valuable the information you’ll have at your disposal later.

Glenn R. Brûlé has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. As the Director at Large for the International Institute of Business Analysis (IIBA), Brûlé’s primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries, including financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.

Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM

Written by Cynthia Low on May 15, 2008. Posted in Articles. 1 Comment on Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM

In my previous article, Is it Time for the BA and the PM to Get Hitched? I set the stage for additional comments on the inevitability of the morphing of the business analyst (BA) and project manager (PM) into a single professional that I labeled the BA/PM for lack of an appropriate title. Along with that I promoted the idea of a World Class Business Project, Program, Portfolio and Process Office or BP⁴O, for short, to support this new professional.

In this article I would like to discuss requirements gathering and management. I believe it is the area of greatest overlap between the BA and the PM. Both the PM and the BA face the same challenges here. Even under the best of circumstances, it is very difficult if not impossible to identify and document complete requirements during the Initiation Phase of the project. The reasons are many and well known to both professional groups. There are at least a dozen approaches you might use for requirements gathering and it is not my intention here to present a tutorial on their use. Rather my focus will be on the need for a more collaborative effort between the BA and the PM in the process of effectively managing those requirements throughout the entire project life cycle. I have defined the Requirements Breakdown Structure (RBS) as an artifact in the Initiation Phase of the project. It is the infrastructure that supports requirements management throughout the project life cycle, the choice of a life cycle model and the choice of best fit project management tools, templates and processes.

Requirements Breakdown Structure

The RBS is a hierarchical description of the client’s needs. There are at most four levels of decomposition in the RBS:

Level 1: Client statement of a requirement
Level 2: Major functions needed to meet the requirement
Level 3: Sub-functions (for larger more complex functions)
Level 4: Feature(s) of the functions or sub-functions

The RBS defines what is to be done and can be thought of as a deliverables-based WBS which defines what will be done. Further decomposition of the RBS produces a deliverables-based Work Breakdown Structure (WBS), which defines not only what must be done but how it will be done. There is, however, a fundamental difference between the two. The RBS may not be a complete decomposition of what will be done whereas the WBS must be complete in order for the traditional linear approaches to project management to be appropriate. There is an obvious disconnect here. The temptation is to speculate on the future to fill in the gaps in the RBS. If you take this approach, you are planting the seeds for failure.

It is this lack of completeness that drives the choice of Systems Development Life Cycle (SDLC) and the supporting Project Management Life Cycle (PMLC) tools, templates and processes. The two life cycles are inextricably linked. Any project that produces an incomplete RBS at the outset must use some type of agile approach to managing the project. In these situations the obvious conclusion is that the professional who manages requirements gathering and management over the life of the project must be expert at both business analysis and project management. The learning and discovery of heretofore unidentified requirements occurs in the iterations that make up an agile approach. In other words, requirements discovery takes place throughout the entire project life cycle and is fully integrated into management of the project. This is not a situation where a hand-off from a BA to a PM will work. The complexity and uncertainty of the solution and the processes for its discovery negates that approach. A BA/PM is needed for maximum impact.

Project Landscape

At the risk of over-simplifying a complex and uncertain project environment, consider Figure 1. It is one way to envision the project landscape. Two variables define this landscape: the goal and the solution requirements.

Figure 1: The Project Landscape

Each can take on one of two values: Clear or Unclear. Traditional Project Management (TPM) approaches are used in situations where both the goal and solution are clear. These projects should use life cycles that are Linear or Incremental. TPM Projects, because of the clarity of goal and solution identification, can effectively use a BA and a PM with the requirements hand-off fairly straightforward. Agile Project Management (APM) approaches are used in situations where the goal is clear but the solution is not. These projects should use life cycles that are Iterative or Adaptive. And finally, Extreme Project Management (xPM) approaches are used in situations where the goal and solution are unclear and should use life cycles that are Extreme.

As I travel around the planet speaking to BAs and PMs at conferences and workshops, I always ask my audience what percentage of their projects fall in each of the TPM, APM and xPM quadrants. I’ve asked that question to over 5,000 BAs and PMs in the US, Canada, England, Germany, Switzerland, Czechoslovakia, China and India. The results are remarkably consistent:

Linear or Incremental 20%
Iterative or Adaptive 70%
Extreme 10%

I suspect that a major contributor to project failure is the force fitting of a Linear or Incremental approach when an Iterative, Adaptive or Extreme approach should have been used. The fourth quadrant where the goal is unclear but the solution is clear is not a viable choice. That is not unlike a solution out looking for a problem. Maybe you know of some consulting firms that act like that. I sure do.

I’ve made my point. We say that every project is unique: That it has never happened before and will never happen again under the same set of circumstances. It would be naïve to think that one project management approach would work for every project. We have already noted how goal and solution clarity and completeness of requirements drive the choice of development model and project management approach, but there are several other project characteristics that should be considered. I have had occasion to consider risk, cost, duration, complexity, market stability, business value, technology used, business climate, degree to which you expect to have meaningful customer involvement, number of departments affected, the organization’s environment and team skills/competencies.

Putting It All Together

I believe in and have always presented a one-stop-shopping experience to my clients. It is critical to project success that a strong sense of teamwork be created between the client and their team and the project manager and her team. The BA/PM professional is better equipped to do that than if a BA and PM were separately involved. The BA, PM and client structure requires three communication links, all working in harmony, while the BA/PM requires only one. With people-to-people communication being the major reason for project failure, we need to give serious thought to creating the BA/PM professional for those APM and xPM Projects. There is much to discuss about the preparation and development of the BA/PM and I hope to present that information in subsequent articles.

The first article in this series drew a large response, and I would certainly like to hear your further thoughts on the BA/PM professional. I’m sure we could have a lively discussion. I promise to respond personally to every email and to incorporate your thoughts in succeeding articles.

Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3^rd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

Congratulations and Condemnation!

Written by Marcos Ferrer on April 30, 2008. Posted in Articles. 2 Comments on Congratulations and Condemnation!

Congratulations to John Dean for his analysis of what to do with a nearly infinite list of specific identity transactions (see March 2nd blog for the list, and John’s April blog for his ideas).

Improve on it if you can, but I like his idea of grouping identity transactions by the “certainty” required, and using known technologies (Human Chip Insertion, Fingerprints, DNA, Retina prints, id cards) to “produce” the needed certainty. Each “identifier” stakeholder can simply select the level of certainty they require from such a system. This is a huge simplification, and seems to be a doable analysis. There is evidence for the accuracy of many tests, AND we will have to consider the usual 4-D time/space complications (DNA is reliable, and is easy to plant at a crime scene).

Condemnation upon John for his focus on the “identifier” stakeholder, instead of “we the identified”, who live on the other side of such transactions (mostly).

Leaving out the identified in these analyses is (increasingly) the cause of problems like identity theft, loss of privacy, deprivation of due process (sure, you can fix your erroneous credit record – have fun with your new full-time hobby), erosion of civil rights, and much, much more (the teen suicide who was berated on-line by the adult mother of another teen?).

Leaving us out of the requirements gives John access to a seemingly EASY solution – “chip insertion”. The risk of crooks “stealing” someone else’s chip for illegal purposes can be dealt with by rigging the chips to self-destruct if removed or fiddled with. I leave the problem of “counterfeit” chips for a later discussion (solution, as usual, is premature,so nyah, nyah, nyah, Mr. Dean).

This kind of solution is especially tempting for management, in spite of being clearly odious to the “workers.

The day is coming where, if you are a convicted drug user, or a crummy boyfriend, or a whistleblower, or just a cranky person, people will be able to single you out electronically – even treat you the way we treat convicted pedophiles, just by accessing your history based on your chip id.

Convicted pedophiles and other sexual criminals already know what this is like – no chance to really start over, always labeled. The process created by the “identifiers” is great for labeling one for life; not so great for allowing for change and forgiveness.

The current system protects the interests of the “identifier” stakeholders (John, language is important – can we just call them fascists?). It assumes recidivism, and does not measure rehabilitation. Remember – Civil Liberties are not just for people that you like.

One can claim that measuring rehabilitation is a different problem from identification. Unlike John Dean, my perceptive readers immediately realize that if we can’t measure rehabilitation, then crime, or any “unapproved behavior” becomes a life sentence in the system John advocates. Do you really want the letter L tattooed on your forehead for life, just because you once littered?

We’ll deal with such “identifier” requirements next time. In the meantime, as a proof of concept for John’s analysis approach, would you agree with the following estimates of how much certainty is currently required for the following identity transactions?.

Amount of certitude required to identify:

A terrorist = 0.1% (if we harass 1,000 people to actually catch one terrorist, we are satisfied – witness Guantanamo).
Oneself for a driver’s license = 10% (or commerce will shut down – i.e., it is easy to fake the id required)
Oneself to buy coffee and donuts = 95.0% (5% of transactions are “fraudulent”?)
A death penalty convict = 70% (30% of death row inmates may not belong there, the states’ “management” are not investigating their own mistakes, of course).
A safe sex partner (varies by individual from 99.5% for those who want to witness your HIV test in person, no cheating, to 0% for Larry Craig, Senator from Idaho, who would prefer to know nothing about anyone next to him in a bathroom stall).

I finish with an important success point – small teams. I want to make the point that our two person “team” (John Dean and myself) is (so far) enormously productive.

In perhaps 20 total person hours of actual focused, asynchronous but responsive work, we have enough grip on the scope to already despair of the sheer scope of the problem – this is good progress!

Next month (unless John tees me off again) we will contrast John’s “certainty” requirements with the requirements that “we the identified” might want to add.

Stay tuned – if we get the requirements right, it may only take one generation to finish this, and none to soon!

Getting Back To Basics

Written by Cynthia Low on April 30, 2008. Posted in Articles. 1 Comment on Getting Back To Basics

Second Fundamental: Creating a Common Vocabulary

Right now, there is more information available than ever before about business analysis.

As someone who has dedicated his career to this essential discipline, I find this fact both exciting and a little frightening. On one hand, it demonstrates that business leaders have embraced business analysis as a key element to success. However, on the other hand, I worry that such a mountain of information, opinions and tools may simply be too overwhelming for those looking to bring business analysis to their organization.

That’s why in April I began what will be a series of five articles covering how to cut through the vastness of information and get back to the very basics of effective business analysis. In my first article in the series, I discussed the importance of understanding overall business goals. The next step is developing a common vocabulary to be shared by your entire team.

A Glossary of Terms

At the very beginning of a project, it is absolutely essential that you and your team develop a glossary of terms, which is a type of requirement model that lists in alphabetical order the terms, definitions and aliases that may be required to support the development of your solution. The document will ultimately be the foundation from which all of your requirements are developed.

As obvious a suggestion as this might seem to be, I would estimate – and it’s a generous estimation, mind you – that only about 10 percent of organizations today actually take the time up front to create a glossary of terms.

What is the difference between a client, a user and a customer? What is an executive sponsor? Are sponsors and stakeholders the same? What is the difference between business requirements, user requirements and specifications? And, what about all of those acronyms that we only vaguely understand? What do those mean? These questions and many others should be discussed and agreed upon and then documented in your glossary of terms.

The easiest way to do this is through brainstorming sessions with key personnel. Once everyone is in the same room – either real or virtual – the group should work together to hammer out as many essential terms as possible. In order to build consensus on definitions, the facilitators of these brainstorming sessions should use voting techniques in lieu of all-out dictatorship.

Avoid Confusion Today . . . And Tomorrow

With tight deadlines and demanding stakeholders always a concern, it’s tempting to bypass the busy work of developing a glossary and assume everyone is on the same page. I can tell you from firsthand experience this type of shortsightedness will do nothing but hurt you – both today and tomorrow.

It’s a simple fact: words and phrases mean different things to different people -especially when we enter the always-dicey realm of corporate jargon. If terms aren’t understood from the get go, misunderstandings of expectations, wants and deliverables are inevitable, and they could lead to conflicts throughout the life of a project. A comprehensive, well-put-together glossary will save you valuable time and energy, allowing you to focus your efforts not on simply communicating but on developing the most effective solution.

Create a Living Document and Share It

Technology has been wonderful for businesspeople – and not just because it allows us to secretly watch hockey highlights from our desks. Technology today has made it easier than ever to create, share and store information. A glossary of terms is no longer a bunch of pages that you bind together and then stick somewhere on your bookshelf. You should always think of a glossary of terms as a living document that has the power to evolve and grow along with projects, programs and organizations.

Even after a project has been long completed and celebrated, its glossary of terms is still valuable and should still be maintained because it can be used as a baseline for future projects. Aside from some unique particulars, the terms and acronyms will be applicable to teams throughout your organization.

And, this brings me to the sharing of information. If your organization has an Intranet site or one shared location for information, glossaries of terms should be housed there and made available to everyone. Glossaries are excellent tools for educating new employees and saving them from having to smile and nod at all of your confusing acronyms for their first six months on the job. Knowledge sharing is an easy, efficient way to help increase another kind of sharing – profit sharing.

Next Time: Requirements Sources

Next time, for my third article in this five-part series, I’ll cover how to determine the sources from which you will extract your requirements. In the meantime, I’ll allow you to document your own definitions for extract and requirements.

This is the second in a five part series of articles by Glenn Brûlé.

Glenn R. Brûlé

has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI (www.esi-intl.com), he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. As the Director at Large for the International Institute of Business Analysis (IIBA), Brûlé’s primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries, including financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.

The Eye of the Storm: The Business Case

Written by Terry Longo on April 30, 2008. Posted in Articles. 1 Comment on The Eye of the Storm: The Business Case

You may have noticed that one theme in this blog is change management, which I think must be central to a BA’s approach to managing requirements. Actually, I take that back…. To some degree, it seems that there is an overemphasis on the requirements themselves, at the expense of managing the business case for satisfying those requirements.

I will try to state my concern philosophically first, by asking the question “Where does the BA stand? What ought to be the BA’s primary point of view?” Here are the stands I see taken by BAs, to varying degrees:

The requirements themselves – extremely challenging to set one’s bearings on the requirements themselves, because they will change!
The requirements process – obviously a more stable view, giving one the prism through which to view and manage the constantly changing requirements
The business case itself – this is the most advantageous point of view from which the BA should start his or her day

Saying it another way, if my mission is to manage the requirements, I could lose sight of the business case itself, which will change as requirements and solution elements (scope, schedule, cost) change. But if my mission is to keep the business case alive and fresh, by continually reflecting within the business case, in business case terms (benefits, costs, risks), the changes to requirements and solution elements, I have not only (a) taken a stand that puts me closest to my stakeholders from a business benefit point of view but also (b) made change management my core activity, because the business case cannot be kept fresh without it.

Do you agree? How central is continuous business case management to the way you work? If it is not central, what are the obstacles/challenges you face in making it so?