Skip to main content

NGISAOBAMSCLWHNBSO 200YWINFGEONSBIIBA

Written by Marcos Ferrer on . Posted in Articles.

National and Global Identity Systems – An Opportunity for BAs to Make a Social Contribution the Likes of Which Have Not Been Seen in Over 200 Years, and Which Is Now Feasible, Given the Existence of Our Neutral Standards Body, the IIBA.

What contribution, you ask? How about establishing the scope, risks and requirements for Identity Systems?

What’s that you say? This work is being done already?

IT IS TRUE that Amazon, PayPal, Blue Cross, MySpace (and now MySpace lenders), VISA/MC, your local police, and the Transportation Safety Authority, among others, are “solving” the “problem” of identity every day. Did you know that DisneyWorld now takes your fingerprint when you enter their park? I will buy a free dinner for the analyst who can tell me why (I know they do; I interviewed them mercilessly until they admitted it).

WHAT IS MISSING from current identity systems projects (ah, the many thousands) is a committed effort to determine requirements of a whole group of stakeholders – “We, the Identified” (WI).

WI are primary users of Identity! If you doubt this, ask yourself who initiates the transaction requiring “identity”? What do we call it if someone else initiates this transaction instead?

In spite of the clear stake that WI have, the systems focus primarily on the needs of the organizations (understandably), and coincide with ours only where the organization also benefits (sure, we all like fast transactions, even if we are being messed with – just so it’s fast!).

The problem here is partly one of the unintended consequences of otherwise rational economic behavior (I missed this reason last month). It is an example of “hidden costs” like pollution, where no single party has an incentive to make improvements in the absence of any outside duress or any market for trading on the costs. An example of the “hidden costs” of poor requirements is the fact that the potential terrorist list has now exceeded 750,000, AND 60% of all “bombs” actually get through airport security (these are recent TSA tests).

So, given the scope of the enterprise (in this case the People of the United States, their constitutionally elected government, and the multitude of identity systems with which we are currently saddled), I issue the following challenge to all BAs:

  • To perform a volunteer led, BABOK compliant elicitation, analysis and documentation of the many conflicting requirements related to identification systems within the United States of America “enterprise”.
  • To successfully negotiate acceptance of these requirements by all stakeholders, public and private, in such a way that the requirements are adopted into public legislation, practice, and/or the constitution.

Remember that, just as in every project, management (WI, the people?) reserve the right to make any final requirements decisions, and to resolve any disagreements for better or for worse. The political acceptance or rejection of our work will be its acceptance test.

AND – I didn’t forget – we still have an agenda of “BA implementation” problems to discuss. This project will give us PLENTY of opportunity to explore these, in a hands-on way.

We begin next month with a statement of the problem, and an attempt to scope out the stakeholders and their interests.

What do you see as existing issues with personal identity in systems today? How recently have you tried to get your own medical records? Any victims of identity theft out there? Victims of planted DNA?

I, for one, have had enough! How about you?

Marcos Ferrer, CBAP is an experienced teacher, public speaker and instructor with ESI International. He has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Mr. Ferrer began his BA career in 1982. While still a student at the University of Chicago, he developed a consulting practice with local property management and accounting firms. Following graduation in 1983, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in a number of different fields. In 1990, Mr. Ferrer became an independent consultant, again working with a variety of clients, most notably in the family entertainment industry. He has also worked on multiple government systems projects and “business” projects, including.

In November 2006, Marcos Ferrer became one of the first 16 CBAPs certified by the IIBA. He as served as Vice-President for Certification at the DC-Metro chapter of the IIBA.

© 2007 Marcos Ferrer

“Oh No, You Gave Me What I Asked For!”

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on “Oh No, You Gave Me What I Asked For!”

Part 3: Recommending Solutions that Address Expectations

As discussed in the first two parts of this article, project professionals realize that projects fail when customer requirements are not clearly defined and customer expectations are not met. The consultative questioning presented in the earlier parts is essential to understanding the business problem and its limitations. The project manager or business analyst can then analyze root causes of the problem or opportunity, and will be able to recommend a solution to solve the business problem at hand. If the recommendation is accepted, we can then recommend the most effective implementation approach. The major steps involved in the consultative approach are:

  1. Asking questions to uncover problems and synthesizing the responses
  2. Analyzing those problems
  3. Advising clients by recommending solutions.

This article focuses on analysis and recommendations.

Analyzing Problems

Once we have asked business, project, and product context questions, we should have an understanding of the business problem we’re trying to solve, as well as an idea of the project’s product or service that will result from successfully implementing the project. Before we can recommend a solution, however, we must analyze the problem, which requires the ability to break the large problem into smaller pieces and to get to its root cause.

Using Models And Prototypes to Analyze Problems and Verify Expectations

To understand the business problem, we need to understand the current situation and the limitations of the current situation.

Tip: Modeling provides the structure to ask the right questions at the right time during the project, and provides a basis for solid recommendations.

Models present a clear way to learn about and document the situation, known as the current state or “as-is.” Once we understand what is happening today, we can analyze how to improve the situation and recommend a better approach. Modeling provides the structure to ask the right questions at the right time during the project. We call those “question points” and they are valuable because the modeling technique prompts them. By graphically displaying the issues, we can more easily see the “gaps” between what is happening today and what is needed in the future. Models, then, provide a basis for solid recommendations.

Modeling also provides the means to ask questions that might well be forgotten, since the models’ structure forces thoroughness in questioning. Modeling also provides a way for business analysts to translate their interpretation of the requirements to both the business clients and the technical team.

There are a variety of models that can be used during the capturing of requirements. Below is an example of the kinds of models used in software development. Some of these, such as business process models and prototypes are useful in any project where the output is a tangible product, such as a new car, service, or process.

The following chart shows a table for requirements models used in software development

Model Benefit of use Main Use Can be Used for Non-Software Components
Business process Change management. How will use of the product cause business processes to change. Document the current “as-is” and future “to-be” business processes, identify gaps. Determine ways to get to “to-be.” Use as a basis for other models to assess impacts. Yes
Data model Provides structure for getting information requirements. Gather the information required to support the proposed process. Requires understanding the business rules enforced by data, and planning how to convert from the current to the future state. No
Use case model Defines how the new product (system) will work. Documents interactions between the end-user and the system. Shows the interactions of other systems and time triggers to the system. Yes
Prototype Can be used to document navigation, design, usability, errors and messages, look and feel of the end product without investing the time and resources needed for full product development. Prototypes are mockups that can be “paper and pencil” or mockups using technology, but without full functionality.
Prototypes provide the ability to see and use a model of the product before full implementation. 		Yes

Requirements Model Usage

Advising Clients by Recommending Solutions

The Recommendation. In addition to the more obvious recommendation structure (summary, body, attachments), the recommendation should carry the right tone for the intended audience. The tone can be formal or informal, folksy or precise, direct, or subtle. It’s important that the tone not distract its intended audience. Having the wrong tone and level of formality can distract the audience, break trust, and ultimately lead to the rejection of the recommendation and loss in credibility of the author.

In addition, the recommendation should include input from those who will be affected by its implementation, which will give the recommendation a far greater chance of acceptance if it is reviewed by key stakeholders and if their input is included in the final draft. The more stakeholder input is sought, the more likely that supporters will defend it against saboteurs. Ideally these stakeholder champions will also participate in presenting the recommendation, which will provide added credibility to the recommendation.

Presenting the Recommendation. Presenting the recommendation can be done formally or informally, in written or verbal format. No matter which format or venue is chosen, the structure of the presentation is important. Having a summary and details, for example, works in every venue. Even the most informal setting requires giving a great deal of thought to planning the presentation approach, including such things as choosing the right venue, how much in advance of the meeting to distribute it, roles and responsibilities during the presentation, the agenda, ground rules, when to take questions, and more.

Finally, the consulting approach requires presenting a recommendation that best serves the organization, even if the

Tip: Be courageous. While we want to keep the audience in mind, we need to present what we think is the right thing for the organization, even if we perceive that our audience is not receptive. By doing our homework, analyzing impacts and alternatives, we can present with confidence.

recommended solution differs from what was initially presented by the stakeholders. Those listening to the recommendation do not need to be completely in support of the proposal, but they will more likely accept it if the project manager is thoroughly prepared and the recommendation crafted with care. That means ensuring that the recommendation addresses the business need identified and analyzed, that the recommended solution addresses that need, and that impacts of the solution to all areas in the organization have been taken into account. Remember, project managers and business analysts do not need to make the decision to accept the recommendation. That’s for the sponsor and executives. However, project professionals do have an obligation to be consultants to the business by having a clear understanding of the problem, and developing a thorough recommendation for a solution that’s the right thing for the organization.

In addition to your main recommendation, be prepared with alternatives and some analysis of why they were not your proposal.

Summary

In this series, we explored how to uncover client expectations and why this is so important to delivering the right product. Uncovering expectations takes time and requires the art of consultative questioning. It demands patience with clients who have difficulty articulating their requirements. Uncovering expectations takes a commitment to defining requirements in sufficient detail to understand what those expectations truly are. It requires a process for eliciting the requirements, and also for analyzing, documenting, and validating them. Finally, the consultative approach we presented acknowledges that the expectations we uncover may require recommendations for shifting the business to adopt and embrace them.

(For parts 1 and 2 of this series, return to the Home Page, click on Articles and then on September 2007 and October 2007)

 

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. Each has presented numerous workshops, seminars, and training classes to thousands of participants on three different continents. They regularly speak on business analysis and project management topics at Business Analyst World conferences and Project Management Institute (PMI) Global Congresses. Elizabeth and Richard are frequent contributors of articles to international trade publications such as CIO; ComputerWorld; BA Times; PMI PM-Network Magazine; the University of Houston book, IT Project Management Readings; Certification Magazine, ICFAI Professional Reference Book – Project Management-Emerging Perspectives; and many others. Elizabeth and Richard are also contributing to the Fourth Edition of the PMBOK in a section on collecting requirements.

 

The Problem

Written by Marcos Ferrer on . Posted in Articles.

Now we are starting to move! We have looked at what business analysis is:

  • Thoughtfulness
  • Due diligence
  • Uncommon sense

We have discussed some of the reasons that it matters:

  • Failed/challenged projects and wasted resources
  • Neglected stakeholders (my favorite is taxpayers!)
  • Critical infrastructure systems present and future (what will you do when someone plants your DNA at a crime scene?)

Now we ask the question – what is the problem with implementing BA, given that it works, and given the high cost of ignoring it? Why doesn’t everyone Just Do IT (pun intended)?

This topic is huge, and I restrict myself to the following incomplete, but analytically organized list, and trust in my Gentle Reader’s patience if I only address one of these topics today, at the end of the essay.

Problems with Human Nature and Limitations:

  • Thoughtful people tend not to be bullies; bullies tend to end up bosses
  • Thinking is hard, and when left alone, many will choose not to
  • For some reason, ego often trumps collective goals – managers have to manage egos – everyone wants to be important. This gets out of control when it reaches the point where misguided managers will assuage feelings at the expense of outcomes.
  • Personal agendas also often trump goals – especially in IT, where the priesthood is fond of obfuscating choices. They love selecting technologies that they think are cool, or will enhance their career opportunities, regardless of justification.
  • Fear is prevalent, even though many hide it from themselves.
  • Work avoidance is commonplace, and due diligence IS WORK.

Problems with Cultural Issues (American):

  • From the earliest ages, we are taught to value action over thought (in the battle between jocks vs. geeks, who wins the sexual selection sweepstakes?). No wonder the cry of “Don’t think, code!” is loud in the land.
  • Even though the founders of this country were followers of the Enlightenment (If you don’t know what this is, well, that is part of the problem – Google it!), there is a strong, superstitious, anti-intellectual streak in many Americans, even in many successful ones (the world is 6000 years old, and was made by an Intelligent Designer, presumably because God didn’t have the chops?)
  • As a capitalist, free society, the Gold Makes the Rules, and that is fine for private enterprise, where bad rules put you out of business, and allow your resources to be put in the hands of someone who might make something out of them. This is not so hot for government, where the gold is shared by legislative priority, in a system where states compete with each other for their share of a pie that no one really owns, and rational, national, greater good use of the money is actually quite rare.
  • For some reason, turf behavior is often tolerated, almost without question.
  • Ethics have become undervalued in our society, whereas wealth, power and appearances are highly valued. Due diligence (BA) is ethical, whereas its absence is extremely questionable. Morality is no replacement for ethics – it is too simple, typically offers easy outs (confess, forgive, judgment is mine sayeth the Lord, purify oneself with jihad, etc.) and tends to be absolutist, in a world where the greater good cannot be accomplished by following platitudes – not even “Thou shalt not kill”. I mean, really, thou shalt not kill what, and why? Cows, for food? People, to save nations? Viruses, to prevent apocalypse? Fetuses, to save families?

Problems with Complexity

  • Some problems are inherently complex, even insoluble at this time (maybe forever).
    Examples include:
    • Mathematically unsolved problems
      • Optimal container packing
      • Efficient material (and network) routing
      • Protein folding
    • Problems that we may not know enough to fully solve at this time, but where useful tools are being found
      • Artificial Intelligence
      • Natural language comprehension
      • Direct brain/computer interfacing
  • There are limits to how much complexity each person can absorb and share, with teams of more than six people achieving increasingly diminishing gains in applicable knowledge.
  • As a project (in time and person hours) gets larger, profound issues of communication arise. The number of possible relationships among team members grows extremely rapidly, and forces division of tasks, increases risks of missed coordination, and often leads to “us vs. them” mentalities.

Social and Political Problems

  • Differences in political goals – e.g., electronic voting might be perceived as favoring one party over another, or national identity systems raise concerns (and rightly so) about civil liberties. Question: Are “We the People” (Nos Populus) being sought for requirements, and honored as stakeholders, or are we destined to being merely “We the Known” (Nos Notus)?
  • Unreasonable requests, ah they are many. My favorite is what I call the “FBI problem”. The request goes something like this: “Give me a system that will find hiding evildoers and track their webs of intrigue so that we may gut their activities once and for all”. When I ran into this one, it took me 12 months to get executives to accept that even the FBI struggles with it.
  • Labor vs. Management – a fossil marking the end of the American industrial age, now applied to governing ourselves and educating our children, with predictable results.
  • I could go on, but I am out of room.

I want to keep my promise to address ONE of the problems listed. Here it goes:

Problem with Complexity:
Some problems are inherently complex. How to not get nailed.

Answer:
Know enough computer science to know about solvable and unsolvable problems. This can help you avoid, or at least identify, bad project scope choices that need addressing (Do you really want to re-invent accounting, or just implement it? Will it be YOU who breaks 128 bit encryption, or is the project goal actually different from that?). to be able to spot these kinds of problems. Here are some fun samples of deep stuff that might help you save a project someday, including the mathematics of voting (you can’t always get what you want, but if you try sometime, you just might find…):

http://en.wikipedia.org/wiki/Voting_system
http://en.wikipedia.org/wiki/NP_%28complexity%29 (be sure to scroll down from the definition to the applications)
http://www.aaai.org/AITopics/html/welcome.html (note the dates and aspirations and name change)
http://www.aaai.org/Organization/sponsors.php (short list of the folks who SHOULD take on AI – are you one?)
http://en.wikipedia.org/wiki/British_national_identity_card#Vulnerable_individuals (interesting – the requirements of “vulnerable individuals” require more work, not resolved, not political, just, gosh, overlooked a little, maybe – what IS the plan? – hmmm….)
http://en.wikipedia.org/wiki/Bin_packing_problem (you can do it for your suitcase, but can you do it for a moving truck?)
http://blogs.zdnet.com/Murphy/?p=822 (what IS the best technology, anyway? How did we go wrong? You’re going to love your first Mac!)
http://en.wikipedia.org/wiki/Protein_folding (if you are in the biology business you already know this, for the rest of us, it is just interesting, and we are generalists).

If what you are up against hasn’t been dealt with according to your research, and your client insists on proceeding, try to get a PHD for the project, not just a salary.

Alternatively, you can ask your stakeholders if anyone (or try yourself, in a quiet room) can describe how to solve the particular knotty problem by hand. If no one can at least describe how to proceed, there is an excellent chance that the problem is unfeasible.

The above approach worked once when a stakeholder wanted a system that would compute detailed violations based on the total dollar penalty assessed, without anyone having to indicate the violations individually to the system. I call this the “Detail from Summary” problem, and it is not typically soluble for real world data, where MANY detail configurations can result in the same summary.

Next Month:

National Identity Systems – An Opportunity for BAs to Make a Social Contribution the Likes of Which Have Not Been Seen in Over 200 Years, and Which Is Now Feasible, Given the Existence of Our Neutral Standards Body, the IIBA. If that is too much, just call it NISAOBAMSCLWHNBSO200YWINFGEONSBIIBA.

Enough for now – be well, BA, Kind Reader!

“Oh No, You Gave Me What I Asked For!”

Written by Elizabeth Larson on . Posted in Articles.

Part 2: Using Consulting Skills to Uncover Expectations

As presented in Part 1 of this article, project professionals realize that projects fail when customer requirements are not clearly defined and customer expectations are not met. Project managers and business analysts face a number of challenges in developing the kind of usable products that customers expect.

In Part 1, we mentioned five pitfalls to uncovering expectations: 1) the Time Trap, 2) Stated Requirements Don’t Meet Expectations, 3) Ineffective Questioning, 4) Using the Wrong Techniques and 5) Accepting Solutions Presented by the Business. This article continues the discussion by addressing how these common pitfalls can be addressed by using a consulting approach and focuses on consultative questioning.

Using Consulting Skills to Overcome Requirements Pitfalls

Overcoming the many pitfalls described in Part 1 requires a consultative approach. Why is that? Being a consultant to the business helps ensure that expectations are met. The background of a situation is assessed by understanding the business problem, analyzing the current state, understanding the limitations, and gathering supporting statistics that detail the exact impact of the current situation. The project professional is then in an excellent position to recommend a solution that will solve the business problem at hand. Effective consultants have learned that the key to success includes:

  1. Asking questions to uncover problems and synthesizing the responses
  2. Analyzing those problems
  3. Advising clients by recommending solutions.

This article explores Step 1 and focuses on consultative questioning.

Asking the Right Questions

Asking the right requirements questions can be challenging, because we need the right context for asking good questions. Being a consultant requires asking questions to obtain the right perspective, before trying to understand the details of the end product. Once we have the context, we can then move on to questions related to our product.

A few good consultative questions to ask, regardless of the product or service of the project, always include the business context with such questions as:

  1. What business problems are being solved with the project?
  2. What opportunities is the organization taking advantage of?
  3. What are the external threats that this project addresses?
  4. How does the project take advantage of the organization’s strengths or compensate for its weaknesses?
  5. What is the product description and project vision?
  6. How does this project link to the organization’s strategic direction?
  7. How will this product be perceived in this organization?

A few good questions for understanding the project context can include such things as:

  1. How much are you willing to spend on this project?
  2. What is the priority of this project in relation to the other projects in this portfolio/program/organization/division?
  3. What are your time constraints and what causes them?
  4. What risks do you see with this project?
  5. Who/who else should we talk to?
  6. Who are the subject matter experts and what experience do they have?
  7. If you had to choose among time and cost, scope, and quality which is the most important to you? Least?

Some good questions for learning high-level product requirements includes such things as:

  1. To what extent will this new product cause business processes to change? Which ones will change and in what way?

    Tip: avoid questions related to detailed features and functions until the business, project, and product context are clearly understood and documented.
  2. What do people need to know in order to use this product?
  3. How will internal and external customers use the product
  4. How will the product be sold? Maintained? Supported?
  5. What impacts to other areas are you aware of?
  6. How stable are the product requirements?
  7. Tell me about the best/worst product feature you’ve encountered? Easiest/hardest product to use that you’ve had to use?

Synthesizing Responses

Synthesizing responses uses active listening skills to take a great deal of disparate information and organize it in a way that is useful to the appropriate stakeholders. It starts with active listening, which involves ensuring that what is said by the speaker is actually heard correctly and completely by the listener. The listener needs to ask clarifying questions and paraphrase what is thought to be heard. Asking good and relevant questions builds confidence in the speaker that there are no assumptions or misconceptions on the part of the listener.

To effectively synthesize information, critical thinking skills are needed along with the ability to:

  • Process large amounts of information. Similar past experience can be useful, but care should be taken to avoid making assumptions based on past project experiences.
  • Organize, discriminate, and discern disparate pieces of information, putting them together in concise and useful ways.
  • Distinguish between what’s important from what is not, and discard the unimportant. Experience is invaluable in making this determination. Analysis tools can also be extremely helpful. For example, Pareto analysis is a helpful technique for determining the major factors causing a business problem. It uncovers the critical 20% of causes that lead to 80% of the results.

Traceability and Creating Structure from Chaos

A useful tool in synthesizing a large amount of information is the traceability matrix, which is a table for recording requirements. The structure of this table is hierarchical, so that high-level requirements can be documented in the beginning of the project and details can be added as more is learned. In addition, requirements attributes, such as a unique identifier, textual description, requirements source, rationale, priority and many more can help categorize requirements as they surface. , a globally recognized business analysis and project management training company. Each has presented numerous workshops, seminars, and training classes to thousands of participants on 3 different continents. They regularly speak on business analysis and project management topics at Business Analyst World conferences and Project Management Institute (PMI) Global Congresses. Elizabeth and Richard are frequent contributors of articles to international trade publications such as CIO; ComputerWorld; BA Times; PMI PM-Network Magazine; the University of Houston book, IT Project Management Readings; Certification Magazine, ICFAI Professional Reference Book – Project Management-Emerging Perspectives; and many others. Elizabeth and Richard are also contributing to the Fourth Edition of the PMBOK in a section on collecting requirements.

Tip: Use traceability to help ensure that each requirement is linked with project deliverables, project objectives, business problems, and business objectives, preventing rogue requirements from sneaking into the project.

Although there are many techniques for creating structure from chaos, traceability provides the most effective way to organize large amounts of disparate pieces of information, ultimately helping to ensure that every requirement adds value, that what was approved is actually implemented, and that changes are controlled. It does so by providing a structure that allows requirements to be linked to business and project objectives, business problems, and deliverables. Traceability also helps ensure that the product can be built, tested and verified after implementation. Finally, logical groupings of the table help manage changes more easily.

Summary

Uncovering expectations takes time and requires the art of consultative questioning. In this article, we focused on tips for effective questioning. We presented several ideas and examples of asking the right questions, regardless of the product or service of the project. We stressed the importance of synthesizing the information obtained to make it relevant. We also showed how a traceability matrix can be a useful tool for synthesizing sizable amounts of information like requirements. Part 3 will conclude the series with the remaining steps of the consulting process, and will focus on analysis and recommendations.

 

Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Co-Principals of Watermark Learning (www.watermarklearning.com), a globally recognized business analysis and project management training company. Each has presented numerous workshops, seminars, and training classes to thousands of participants on 3 different continents. They regularly speak on business analysis and project management topics at Business Analyst World conferences and Project Management Institute (PMI) Global Congresses. Elizabeth and Richard are frequent contributors of articles to international trade publications such as CIO; ComputerWorld; BA Times; PMI PM-Network Magazine; the University of Houston book, IT Project Management Readings; Certification Magazine, ICFAI Professional Reference Book – Project Management-Emerging Perspectives; and many others. Elizabeth and Richard are also contributing to the Fourth Edition of the PMBOK in a section on collecting requirements.

Business Process Modelling or “Life without Use Cases”

Written by Maria Murphy on . Posted in Articles.

I recently became involved in a project that has been ongoing for the last 18 months. In that time, a lot of documentation had been developed and over 80 use cases have been written. The problem is, that despite this activity, the system development has not progressed and the project is facing a fast approaching deadline. The team is now trying to develop requirements specifications, prototype and build-of-the system all at the same time. Big Challenge!

I am working in an agile environment where there is rapid change and the business needs are evolving, and this needs to be managed. As we know Requirements are never really complete until the project is finished, as the needs of the business will inevitably change over the life of the project’s development.

In this instance, the project manager does not like use cases and has decided that a process orientation modelling approach is required to meet the deadline. The approach is to develop business process maps from the user pathways, document the information flows, develop prototypes and then build the system. Use cases are “banned” and process mapping is the key focus for business analysis and the BA team.

As a BA, use cases have been the main way to capture functional requirements for a system, so at first I was a little perplexed. I thought to myself, “if we don’t have documented requirements specifications (via use cases or an alternate method), then how will the developers know what to build, how will the clients know we have the requirements right and what requirements will we test the system against?” Will process maps be enough?

Anyway, I started to map my processes and sub processes for the system. The rest of the BA team and I are working side-by-side with the information architects and developers and, as each process map is delivered, a prototype is built and shown to the client area. Sign off and development begins (all within a week!). It’s a hectic schedule but it seems to be working.

The business maps are slowly uncovering the business requirements and are a key communication tool for the project team and business area to discuss the “current” and “future state” requirements for the system. The process documentation is highlighting the inputs, outputs and document flows for the system and, importantly, the client understands this type of documentation and is therefore able to quickly sign-off on the processes. The project is now gaining some traction and we are progressing well along our time-lines, and meeting the deliverable for each stage of development.

When I discussed this Case Study with a colleague of mine, he commented that this points to an oft overlooked element for requirements- that of communication. The requirements specifications task is not just about documenting the requirements it is also about communicating them and, as business analysts, we need to be flexible around the vehicles we use to communicate. We should not push the communication vehicle we are comfortable with, rather we should ensure that the requirements are accurately communicated via a vehicle that our clients are comfortable with. This requires flexibility.

The real key to our success in navigating this agile environment has been teamwork and collaboration between the development, analyst and business teams. Without this interaction, between members, our project would not be progressing well. Communication is so important and as an agile analyst, I believe this capability is a core skill in an agile environment.

I must admit that when I look at the node map for the business processes and sub processes, it does look strangely like a use case “context diagram” and the documentation does indeed specify the functional requirements but as long as we don’t format these documents as “use cases”, the project manager is happy. For me, I guess these documents are not exactly use cases, however “a rose by any other name would smell as sweet.”

Adrian Marchis from Modern Analyst commented on my recent blog about Business Process Modelling and agreed that a “use case shows the steps (or process) that an actor employs in order to accomplish a goal” and, therefore, “process vs. use case is just a name”. He suggested that in reality the details of a use case can be documented as either a use case or as an activity diagram or process flow. He noted that although clients may like the process flow format for its visual properties, it does have one drawback and that is that process flows may not offer the same level of detail found when using use case specifications.

Business process modelling may be a different take on documentation of system requirements for the team, but the client area is happy and, so far, the developers are comfortable with the level of requirements specifications contained in the process maps and associated documentation.

Maria Murphy is a business manager and information and communications specialist. She has over 10 years senior management experience within the medical/pharmaceutical industry, not-for-profit organisations and government. She has a reputation for innovation, managing change, driving strategy implementation and successfully delivering programs. She has extensive experience in the management of large federal government contracts, project management of large scale ICT business system reviews, development of requirements, systems planning and change management. Maria is currently a consultant with SMS Management and Technology. She is the Regional Lead for a Business Analysis at SMS and provides advice to her colleagues on developing requirements specifications for appropriate IT systems to support clients’ programs and initiatives.

 

Maria is on the Board of WIC (Women in Information and Communication), is a member of the International Institute of Business Analysis (IIBA), Australian Institute of Company Directors (AICD), The Australian Computer Society (ACS) and The Australian Business Analysis Association (ABAA). She can be reached at [email protected]