Skip to main content

A Requirement by Any Other Name

Written by Elizabeth Larson on . Posted in Articles. 1 Comment on A Requirement by Any Other Name

The response I received to a recent article on the importance of trust in gathering requirements prompted me to ask myself exactly what was a business requirement. Because there were no comments on the trust aspect and a variety of views on the definition of a business requirement, I had to ask myself this question: If the definition of a business requirement varies from person to person, is it still the same thing? To paraphrase, is it true that a requirement is a requirement is a requirement? After all, a requirement by any other name…

So what is a requirement? Many years ago I worked for a national retailer in an IT group which developed two specifications for developing software. The first was a business requirements document (BRD), which we called a “bird.” The second was a technical requirements document (TRD), which we didn’t bother to pronounce. We never agonized over which requirements belonged in each category. We put those that came from the business in the BRD. Generally speaking these dealt with the capabilities of the software, such as the way people would use the system and the data that needed to be entered or displayed. Those relating to how we were going to implement the software were documented in the TRD.

But as with many things in life, the more I have learned, the less I know. Not only has the distinction between business and technical requirements become blurred, but even the definition of a business requirement has evolved.

We used to say that business requirements described the “what” and technical requirements described the “how.” But the lines between these two are not clearly drawn. For example, is a business process a “what” or a “how?” Next we divided requirements into functional and non-functional and disagreed about whether or not non-functional requirements were considered technical.

Definition of a Business Requirement.

A requirement seems easy enough to define, since the IEE’s definition has been pretty well-accepted: -“a condition or capability needed by a stakeholder to solve a problem or achieve an objective.” One difficulty with this definition, however, is that requirements no longer apply to software only and business analysts work on a variety of efforts. Business analysis applies to the completion of feasibility studies, new business processes, recommendations on staffing, to name just a few. We are left to ponder whether completing business analysis work always results in requirements as defined above.

Another difficulty is that while there is general agreement that requirements can be classified and that one of the classifications is “business requirement,” there is no agreement on what those classifications should be. It would be wonderful to refer to a body of knowledge to help us out. Indeed, one of the truly great things about having a body of knowledge is that we practitioners can use language that is generally accepted and understood by all. We no longer have to waste time discussing the definition of a requirement, of business analysis, of a business requirement. Or do we?

The BABOK® Guide 2.0 describes its classification scheme to include business requirements (goals and objectives) stakeholder requirements (those coming from the business domain perspective), solution requirements (functional and non-functional) and those temporary requirements that help the organization transition from the current to the future state.

The PMBOK® Guide – 4th Edition, on the other hand, classifies requirements as project and product (so far so good). But project requirements are classified as “business, project management, delivery, etc.” Product requirements are “technical requirements, security requirements, performance requirements, etc.” There are many ways to interpret these categories. Perhaps technical requirements equate to functional requirements, perhaps not. Perhaps delivery requirements refer to the target date, perhaps not. The point is that if we are going to rely on bodies of knowledge to help us speak a common language, it would be wonderful if they were aligned.

So what is a business requirement, anyhow? Being the old dog that I am, I still like thinking of business requirements as the umbrella term for those requirements approved by the business domain, regardless of the level of detail. However, I do believe I can learn a new trick or two, and can certainly see the rationale for defining the business requirements as the highest level goals and objectives. (BABOK® Guide). And if anyone knows what a delivery requirement is, I’d sure appreciate your letting me know.

Don’t forget to post your comments below.

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected].

Eight Steps to Improvement

Written by Kupe Kupersmith on . Posted in Articles.

Kupe’s Korner

More and more organizations around the world are recognizing the need for better understanding of business needs and have turned to the business analysis role as a way to improve. Whether these organizations have employees with the title Business Analyst or not, they are beginning to implement proven techniques to increase the success of projects. This is just the beginning. Organizations need to start setting themselves up to continually improve their business analysis practice. My colleague and friend, Angie Perris, and I came up with an eight step approach to continuous improvement. The following actions demonstrate the typical steps involved in implementing business analysis process improvement. (Note: The steps and sequence may vary from organization to organization.)

1. Secure Sponsorship and Funding

Before beginning your business analysis process improvement effort, ensure that the process improvement program has senior management sponsorship and funding. Such sponsorship and funding are critical to the program’s success. Educate senior management about the value of business analysis and developing a repeatable, measurable process. Provide an executive summary of the strengths and weaknesses of your current business analysis approach and a cost benefit analysis for this endeavor.

2. Prepare the Organization for Change

For purposes of this blog post, an organization is defined as one business unit, department, or even as an entire company. If you start with a smaller group, it is easier to manage, measure progress, and adjust to feedback. Treat this process improvement initiative as a project that can be tracked. Form a team of BA managers and senior BAs to lead the effort. Establish the business reasons and the business goals for the effort. Create a compelling case for change, include the rationale for the undertaking, a process improvement effort and the expected benefits and costs for the people affected. Poor business analysis affects all phases of the project lifecycle. Motivated employees and great technology are very important to project success but, even with the best people, they cannot perform at their highest potential when the business analysis role is not understood and respected, or the business analysis process is not efficient. Develop a persuasive presentation of the problems and opportunities to communicate with the affected organization. Below is a list of common problems that can be addressed through business analysis maturity.

  • Business and IT stakeholders have different interpretations of the requirements
  • Requirements elicitation is haphazard
  • Important requirements are missed
  • Frequent and often unnecessary requirements changes delay the project
  • •Requirements are not always verified by the affected stakeholders
  • Solution alternatives do not consider business impact to operations
  • Requirements cannot be verified
  • Customers are not satisfied with the product quality
  • Milestone dates for requirements are missed
  • Reporting requirements cannot be met

3. Provide Core Training

“You don’t know what you don’t know.” The goal here is to level-set the BAs in your organization on fundamental business analysis skills, techniques, and language that will be used in your business analysis approach. This training will be the foundation for your organization’s business analysis approach and toolkit.

4. Come Together: Form a Community of Practice or a Center of Excellence Group

Get your BAs talking and sharing. Develop and promote an atmosphere where the BAs in your organization collaborate. Communities are strengthened by building relationships where people trust and help each other reach their goals. This can be accomplished by having regularly scheduled meetings where BAs get a chance to network, discuss their challenges, and find potential mentors.

It is more rewarding to work at a company that feels like a community. A community of BAs has greater knowledge and experience than any individual. BAs have similar challenges and can help each other. This group, or a subset of the group, can coordinate process improvement activities across the enterprise and continue to exist even when a process improvement project has ended.

5. Know Where You Are

In order to find out where your organization is today you must establish a baseline assessment by evaluating the skill level of your BA community and the standard practices followed in your organization. This evaluation looks at many factors including individual interviews or surveys as well as reviewing deliverables, standards, processes, knowledge, and organizational culture. This step can occur before training if there is already a clear understanding of business analysis competencies within your organization. Compare industry accepted business analysis practices to your organization’s processes to determine a benchmark. Conduct surveys to gather information from managers, project leads, and workers to gauge cultural opportunities and barriers to change. Begin to establish a baseline of analysis performance. Build a detailed picture of the present. This includes knowing your environment, existing project methodologies, types of projects, business analysis tools, availability of business stakeholders, etc.

6. Know Where You Are Going

Define your organization’s success criteria. Compare the picture of where you are to the one of where you want to be. The difference between the two is the focus of your process improvement program. Get a balanced view from management, project leaders, business analysts, and other staff about what they think is most important. Each will have different objectives they want to achieve. Prioritize and communicate the business analysis competency areas to address and build your improvement plan. Your organization may decide to make incremental changes or dramatic innovations to your current process.

7. Execute Your Plan

Have a team start using the new practices as determined in your plan. Make sure to have a team available for support and coaching. Keep track of strengths and weaknesses. Track your progress against the plan. As organizational goals are met, your plan needs to include a feedback loop to assess if any more process improvement iterations are required. Additionally your plan should accept and evaluate change requests from anyone impacted by the new practices.

8. Track Your Success

Communicate your program’s progress in reaching the organization’s goals. Continuous process improvement yields ROI due to better articulated requirements, clearer understanding of the business analysis role and responsibilities, improved customer and IT relationships, earlier defect detection, improved risk identification and management, better control of solution scope, more satisfied customers, etc. In order to continually improve, organizations must remain vigilant along the journey. The business analysis role and process is new to many organizations. This work has traditionally been performed by various individuals in an inconsistent manner. Creating an effective, mature business analysis discipline requires management commitment, time, and resources. It doesn’t happen by accident. Only a clear strategic plan for developing the discipline and the role will move an organization to the highest level of success.

To your continuous improvement,

Kupe

Don’t forget to post your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected].

Announcing the Outstanding B.A. Moment in America Award

Written by Marcos Ferrer on . Posted in Articles.

This month the O.B.A.M.A. award goes to the American Medical Association, for one of the most enlightened public positions on change I have ever heard articulated. The President of the AMA, speaking about HR 3200 (the evolving health bill in the House), said:

“It’s a solid start to achieving health reform this year that makes a positive difference for patients and physicians. The status quo is unacceptable. So let me be clear – without a bill that can pass the house, there is no health reform this year. But the debate is far from over. The AMA is going to be at the table to improve the final legislation….To the physicians of America I say – together we are stronger. .And to the patients of America I say – we are working to make the health care system better for you.”

 

Just THINK about the implications of this statement. Even though the health care bill is not perfect (the AMA has specific concerns about tort/malpractice and Medicare payment rates) they are backing a “risky” CHANGE PROCESS, with their eyes on the greater good.

How many of our societal institutions have “Unacceptable Status Quos”, yet persist in resisting change processes? In case my kind readers think “unacceptable” is too strong of a word (my readers would always offer the benefit of the doubt, no doubt), I offer the following buffet of “status quos” that resist scrutiny and possible change.

  1. The immense social and economic costs of enforcing “Prohibition” against marijuana, and treating hard drug addiction as a “moral” problem instead of a personal medical one.
  2. The strange fact that in the supposedly freest country in the world, we incarcerate more people than anyone except China, which has over five times our population.
  3. The insistence on “free market” processes in the face of the fact that no such thing exists, and the track record of its passionate supporters includes two Depressions plus world class executive performance bonuses in the middle of the second.
  4. The vanishing of journalism and its accompanying ethics.
  5. Ongoing economic discrimination against women, minorities, foreigners.
  6. Basing policy on (and destroying our economy because of) a terrorist stunt, statistically rare, and nowhere near as harmful as cars, cigarettes, alcohol, cancer, even bathrooms (yes, bathrooms kill).
  7. The persistence in emphasizing time and cost over quality in American endeavors (no one is less surprised than me that GM has “failed”).
  8. Taking 12 ounce drinks from airline passengers, because of the potential “danger”, and then tossing them into garbage cans in the screening area.

Remember, sometimes the emperor really has no clothes – now is a good time to speak candidly about the value of change, the process of change, and to be honest about the risks, even as the risk of not changing increases.

Rather than dwell on the negative, I ask my kind readers to send me THEIR examples of an Outstanding B.A. Moment in America, for publishing here!

Have fun, and submit your comments below.

Business Analyst Team Kick-off Practices

Written by Terri Moulton on . Posted in Articles.

Start your team off on the right foot, whether your project uses an Agile or Plan-driven project method, by ensuring that your team kick-off activities set accurate expectations and reinforce how you will work together. As the role of the business analyst begins to include more project management work, there are opportunities for business analysts to gain visibility and increase their business value within their organization.

Specifically, business analysts can take a larger role in designing and facilitating Team Kick-offs and Working Sessions, fostering productive collaboration between the business and the project team, and developing effective reliable relationships with subject matter experts. Often this work is called the “soft stuff” or the “soft side” of project work. The challenge most project professionals encounter is how to turn it into implementable work outcomes. This article focuses on the business analyst’s role in designing and facilitating Team Kick-offs and will provide specific techniques for Team Kick-offs employing adaptive or plan-driven project methodologies.

Project methodologies have been evolving from Plan-driven (e.g., Waterfall) to more incremental adaptive approaches (e.g., Lean Six Sigma, Six Sigma, and Agile). Some companies are firmly rooted in the ever popular Plan-driven methods where the entire project is defined in detail from start to finish while other organizations are evolving towards clarity and detailed definition in the short-term and are accepting of more ambiguity in future stages of the project. Of course, there are also firms who are using a hybrid approach to extract the best practices out of each method. Business analysts must understand the differences and incorporate them into their work at the activity level, not only at the theoretical level.

The Role of the Business Analyst in Designing and Facilitating Team Kick-offs

Prior to the recent acknowledgement and formalization of the business analyst role, the project manager owned the majority of the Team Kick-off activities and the business analyst was relegated to only administration and documentation. See diagram below.

business1

Business analysts worked more behind the scenes in support of the project manager and waited for their opportunity to influence the project during subject matter expert (SME) interviews and business requirements working sessions. Now, as business analysts increase their role to include more project management activities, they can build on their current facilitation skills used primarily for requirements sessions to help the project manager develop the project team. All of this work begins with taking a more active role in the Team Kick-off. The diagram below highlights additional activities that will leverage the Project Manager, ensure their leadership positioning, and increase the business value and initial visibility of the Business Analyst.

business2

In order to take on some of the above activities in the Team Kick-off, business analysts need to schedule meetings with their project manager to offer additional support in developing the Team Kick-off. Once new responsibilities are agreed upon, the business analyst should ask the project manager the following questions in order to begin the work:

  1. What outcome is this project expected to deliver?
  2. Which executive is sponsoring this work?
  3. How is this work perceived in our organization?
  4. When are you planning to conduct the Team Kick-off?
  5. What are the primary skill sets and knowledge that we need on this project team?
  6. Which organizations will you approach for resources?
  7. Which project method will you use to complete this work (i.e., plan-driven or adaptive)?
  8. What expectations will you set with the new project team?
  9. How do you envision the project team operating or working together?
  10. What expectations will you set with the stakeholders?

Business Analyst Team Kick-off Practices

How are Team Kick-off practices different for plan-driven and adaptive projects? It is important to recognize that shifting the project method does affect how work is completed at all levels in the project. See the diagram below.

business3

All teams benefit from setting expectations up front, building trust, and understanding their shared purpose. The dimension that most increases a team’s probability for success is a clear understanding of their shared purpose. Business analysts can help drive shared purpose by designing the key messages, activities, and work approaches into the Team Kick-off. After all, project managers are known for following the plan and managing the schedule while business analysts ensure that the right work is completed within the work activities and deliverables. Shouldn’t this expertise be applied to the “soft stuff” as well? Do your project managers a favor…help them bring the team to life by focusing on the high-impact levers of project success.



To get started, visit the Team Kick-off webpage to download a FREE tool: The Team Kick-off Planner.

Terri Moulton is the Founder and CEO of CanChange. CanChange provides step-by-step solutions for common change management challenges. CanChange’s products support both individuals and organizations as they navigate change related to system implementations, process improvement and other business initiatives. To access tools, templates and additional resources for Successful Team Kick-offs and Facilitating Successful Working Sessions? Visit Terri’s website at CanChange. You’ll find step-by-step guides that will help you improve your skills and ability to design and facilitate successful requirements sessions and project kick-off meetings.




BA Times Only Special: Use the code “BABONUS” at the CanChange site to receive $20.00 off any product purchase.

Intentionally Incomplete

Written by Robert Galen on . Posted in Articles.

This is my initial blog for BA Times and I’m certainly happy to be joining the community. So, a little about me-

My name is Bob Galen and I’m from Cary, North Carolina. I’ve spent the greater part of 25 years in software development-in roles such as developer, manager, director, project manager, tester, and project manager.

For the past 10 years, I’ve been moving my thinking and practices towards those espoused to the Agile Methodologies. I’ve found them to be the most congruent, humane, and effective approaches for delivering software and I try to share my insights with everyone I meet.

Perspectives – you’ll see a strong skew in my blog posts related to the following topic areas:

  • Implications of software testing for the BA
  • Implications of agility for the BA
  • And leadership and soft skills topics for the BA

So that gives you a feeling for coming attractions. But, enough of that…

A key requirement artifact in the agile community is the User Story. Mike Cohn does a nice job of covering them in his User Stories Explained book. I may go into more definition later on the topic, but I wanted to explore one critical characteristic of the user story now. That characteristic is this –

The user story is intentionally incomplete. Yes, you heard me right. It’s ambiguous. It’s got glaring holes. It fosters questions…lots of them. Those questions come from different perspectives too. The developers will have a different set than the testers. Or the BA. Or the architects. Or even the ‘customer’.

What’s the point of having a requirement that is ill-defined? I’ll tell you. It’s to drive conversation surrounding each requirement from the host of different perspectives needed for their implementation. You see the questions are expected…in fact, demanded in agile teams. There’s the agile manifesto notion of “People and Collaboration over Process and Tools” and the user story is an initiator of this collaboration.

I think of it not as two-way collaboration, but multi-way collaboration. Minimally, when a team member picks up the user story for implementation, they gather in a triad of three primary roles-the development-centric, testing-centric, and business/customer-centric views. They discuss the details of the story from each of their perspectives and refine it.

Not only refine it, but leverage all of the knowledge gleaned so far from previous story development and project execution. That’s a key here. You defer specific definition realizing you’ll gain richer information with each Sprint or Iteration that you execute. So this “working software” knowledge is also spun into the evolution of each user story. Another driver for this is Lean’s Just-in-Time and Just Enough thinking when it comes to software development. It turns out that we’re often quite presumptuous in our software development efforts. We assume that we can predict the future in requirements or design of software or even our planning without first writing some of the software.

That approach perhaps works for simple or by-rote things, but not for complex applications or those that are new, novel, and competitive solutions to our customers’ problems.

For those of you struggling with this conversation-based requirement approach, I’ll leave you with a final thought. Have you ever seen a written requirement drive development and testing work that, when you pulled the two together, the code didn’t match the tests? Of course you have. I’ve seen this occur way too often. So while writing requirements is good and necessary, the user story is perhaps touching on an important but missing element in our requirement elaboration.

To be continued…

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected]