Tag: Lean

Process Approach to Requirements Gathering

Written by Mani Ramasarma on May 4, 2015. Posted in Articles.

This blog was supposed to be on requirements elicitation techniques, but it ended up being an example of what peer review does. I finished my blog and handed it over to my colleague for feedback. He pointed out that I assumed people knew how to gather requirements for them to start using the techniques mentioned in the blog. In other words, the blog on techniques was a step ahead, and I should first explain the approach. Ouch! The bump on my head still hurts. So, here we go.

I interview many candidates. Whenever I ask “How do you approach requirements session?” the answers invariably include something akin to “I use JAD session” or “I shadow users”. JAD (Joint Application Design), shadowing, interviewing, and brainstorming are techniques used AFTER you have an approach. Think of it this way. You decide to go on a vacation. How do you approach it? You don’t start with “I will drive” or “I will fly”. These are ways (techniques) by which you reach the destination. The first thing you need to do is decide where to go, when to go, and how to go (approach). The series of steps you take (approach) has to precede the decision to drive or fly (technique). There is a very fine difference.

So, how do we plan an approach to a requirements gathering session? Do we call for a meeting and ask the business user “ok, so what do you want?” or “I am ready, go ahead and list your requirements?” Don’t be surprised if you get a very lengthy grocery list! To avoid such mishaps here is a process-based approach to requirements gathering.

The first point in my last blog was “Do your homework”. The first step as part of homework is to understand the organization and the unit. This understanding provides the big picture so that the goals of the requirements that are to be gathered align with the goals of the organization and unit. Next is to understand the business under consideration, and the scope of the system being worked upon. There are many avenues to it. One of them is to get hold of an AS-IS process diagram.

Start from a high-level process. Some call it “Level 0” or “L0.” Drill down from here to the lowest level possible – L1, L2, L3 and so on (do not confuse this with support levels). Normally you would achieve this by L3 or L4. If AS-IS diagrams don’t exist, your task is to create them.

A mature organization typically has all the “as is” processes documented. Go over it. Go over any other document related to the system that may be available – business bequirements focuments (BRD), functional specifications documents (FSD), user manuals, data flow diagrams (DFD), entity relationship diagrams (ERD), and DDD (sorry, I just created that one!). Get access to the test system and play around in the sandbox – see what it does, see what it doesn’t do. Talk to the technical people. Sometimes they know more about the business than the business users themselves. Ask for a walk-through by technical and/or business folks. If you have a knowledgeable lead, talk to them. By now you should have a good understanding of the way business is conducted. As you assimilate information, note things that don’t seem right. Always remember your title – Business Analyst – so make sure that you are always trying to analyze as you proceed.

Armed with enough knowledge, proceed to capture the “to be” process. Remember, you are documenting only the “to be” process and not the requirements. A common pitfall is to embed requirements in process documents. Be sure to avoid it.

Make a copy of the “as is” process and mark bottlenecks, pain points, workaround’s, manual processes, and non-value add processes. See if you can measure lead and lag times between points in the process. All the current weaknesses should be resolved in the “to be” process in addition to any new functionality or change in the process itself. Beware not to resolve a process inefficiency by automating it. You will be automating inefficiency.

Again start from Level 0 or L0. Make necessary changes. Each of the tasks define your high-level requirements. Here is an example of a L0 procurement process in a bureaucratic organization

Use the gathered requirements to prepare your high-level BRD.

Each of the boxes can further be broken down into next level processes. For example, the first task can be decomposed into

Again, each of the tasks can further be elaborated (here is a buzzword for the interviews – Functional Decomposition). Here is what it may look like, assuming that we go all the way to the lowest level possible (do not magnify the picture. It is there for illustrative purpose only):

At each level look for opportunities to eliminate both the deficiencies (what is missing) and the inefficiencies (what isn’t needed) in the current process. Keep this maxim in mind while redesigning processes – the shortest distance between two points is a straight line. A straight line is not always practical or feasible, but use it as a guideline to streamline the processes. Even if you manage to eliminate or refine one or two steps, it can result in significant time and cost savings.

The hazy little light blue rectangles in the diagram above specify the system that performs that particular task. The diagram also includes manual tasks, reports, and emails. Check if you can automate manual tasks, and whether consecutive manual tasks can be replaced by a workflow. Again, do not automate inefficient processes. Deal with reports separately. Once the “to be” process is documented, have it validated by the business users. Validation is mandatory. It is so mandatory that I will say it again – it is mandatory to have these “to be” processes validated and approved by the business users. What you are left with is a bunch of tasks at the lowest functional level. It is for these that you need to gather functional requirements.

There is one more step you need to do before diving into the requirements gathering process – organize a requirements elicitation kick-off session. Invite business users and the technical team members. Highlight the importance of requirements, characteristics of a good requirement, what has been achieved so far, next steps, and the need for continued user participation and cooperation. The most important component is listing and explaining a good requirement. What are the characteristics? Here is a website that explains it really well. (The next blog will address this and requirements gathering techniques). There are some good examples on the website of how not to write a requirement, which is equal in importance to how it shall be written (a touch of BA humor there!).

The following diagram summarizes the approach

We are ready to launch into the requirements gathering process. That bump on my head is now better.

Don’t forget to leave your comments below.

5 Ways to Find Missing Requirements

Written by Laura Brandenburg on April 13, 2015. Posted in Articles.

Doesn’t it seem like we can hardly go a day without reading about how missed requirements are leading to incredible amounts of wasted time, energy, and money on information technology projects? I have been on enough projects to know that the statistics are most likely telling a realistic story about how projects get scoped, defined, and delivered, but that they are not necessarily giving a comprehensive account of the situation.

In this article, we’ll look at 5 practices we employ as business analysts to discover hidden requirements, and how organizational pressures, project circumstances, and business analysis processes can negatively impact the outcomes of those techniques, leading to the costly reality of overlooking requirements.

Practice #1 – Requirements Reviews and Buy-In

It is not uncommon to discover dozens of requirements during the final requirements review stage. Walking through a requirements specification, or a portion of a requirements specification, with the goal of being sure everything necessary has been included, almost necessarily uncovers additional information.

When you are getting ready to approve, finalize, or simply be done with a requirement, your stakeholders tend to invest a little extra time and energy in being sure it is right.

But the review process only works if you establish the importance of the review, making it very clear that once we review this document, development will begin based on what is inside it, and that means the cost of change starts to go up.

This stage of the process can go wrong if stakeholders do not show up to requirements meetings, do not understand the enormity of what approval means, or do not feel bought into the project in the first place. It also does not work if a critical stakeholder is not invited in the first place, which leads us to the next way to find missing requirements.

Practice #2 – Include All Possible Stakeholders

While it is never a great idea to invite dozens of people to a single requirements meeting, good business analysts ensure that all relevant stakeholders are looped into the project and given the opportunity to share their concerns, needs, and expectations. If you are consistently neglecting requirements in a particular area, identify a new stakeholder from that area to include on your project teams.

This part of the process can go wrong when business analysts are assigned to specific areas of the business and projects are assumed to only impact that area. It can also go wrong when managers assign uninformed stakeholders to projects or refuse to assign stakeholders at all. Organizational politics can also be a factor, say, if a business sponsor purposely excludes one or more stakeholders from the project.

Practice #3 – Apply Analysis Techniques

While stakeholders are the source of many requirements, other requirements are discovered by analyzing the stakeholder needs and discovering implications. The result of good business analysis is a complete view of the solution. For example, every field on a report must be entered into the system at some point, whether directly by a user or by some sort of data feed.

Unfortunately, well-intentioned templates can negatively impact the analysis process. When you are capturing requirements in long lists, it is difficult to make all of the necessary links between requirements. As luck would have it, the same is true if you are capturing requirements in a substantial product backlog. You need analysis models, such as business processes, use cases, or data models, to help you discover the missing connections.

What’s more, a large template can give the false sense of security. Just because you have filled out a 30 page template with twice as many sections does not necessarily mean that you have discovered all of the requirements!

Practice #4 – Invest (Just) Enough Time

Good requirements take time from stakeholders, from technical experts, and from someone performing business analysis activities. Part of being a business analyst is putting together a reasonable plan that explains the steps you will go through to elicit, analyze, and confirm the requirements, identify who needs to be involved in each step, and about how long each step will take.

While it might seem counter-intuitive, more time is not always better. Business and technology contexts change quickly. Investing too much time in the requirements process can mean that your early requirements become stale before they are even ready to be implemented. Minimizing missed requirements comes from crafting a plan that secures just enough time to discover the best possible requirements given the project goals and constraints.

However, it is not uncommon for a business analyst to be assigned a mere week or two to finish requirements before development on a sizable project is targeted to start. When organizations shrink project timelines, or the time dedicated to the requirements aspect of the project, without also shrinking the scope of the business analysis effort, then we nearly guarantee we will miss requirements.

Practice #5 – Start at the Beginning

You cannot solve a problem that you do not understand. You cannot address a business need that has not been defined. You cannot sell a product that the customer does not want.

Business analysts understand the big picture of the project, which includes why the organization is investing in the project and the over-arching goal to be accomplished.

I would venture to say that the vast majority of missing requirements are actually missed at the very beginning of the project. If no one inside the project compels the business community to be clear about exactly what problem needs to be solved, or if a business sponsor resists a business analyst’s typical “why” line of questioning, the entire team is working like a ship without a rudder. You run the risk of chasing rabbits down holes and discovering a lot of requirements that are irrelevant, while overlooking the big important requirements that should be staring you right in the face.

Create More Positive Outcomes

As business analysts, we can expect to face circumstances that, if left unchecked, will cause us to miss requirements. It is up to us to clarify the conditions under which we can do our best work and improve our contexts so we can improve our requirements.

Don’t forget to leave your comments below.

A Fresh Look at Requirements and Requirements Elicitation in Complex Projects

Written by Robert K. Wysocki on August 11, 2014. Posted in Articles.

It is widely accepted that the elicitation of complete requirements during project ideation is very unlikely except in the simplest of projects. There are a number of internal and external factors that affect the solution and its clarity that often change during the project life span that accounts for this. The environment is dynamic. It doesn’t stand still just because you are managing a project! These factors create process challenges that can be mitigated by a simple change in the definition we use for a requirement. This simple change of definition simplifies many of the project management process problems and improves the likelihood of delivering the expected business value.

THE REALITIES OF THE COMPLEX PROJECT LANDSCAPE

As part of the Ideation Phase of a complex project we can define
“WHAT” an acceptable solution has to contain and the business
value it is expected to generate.

At the start of a complex project we may “NOT KNOW HOW” to
achieve an acceptable solution.

The resulting incompleteness is a logical consequence of the
Plan-driven definition of a requirement. That incompleteness can
be removed by using a Change-driven definition of a requirement.

Using a Change-driven definition of requirements implies that an
iterative project management approach will be required.

Most project management processes use a Plan-driven definition of requirements. That will not work in the contemporary complex project landscape. This article introduces a Change-driven definition of requirements. That simple change eliminates the obstacle.

A SOLUTION TO INCOMPLETE REQUIREMENTS

To a certain extent we have become trapped by our own view of requirements and their elicitation. The IIBA definition may fulfill its objectives but at what price? The IIBA definition of requirement is a Plan-driven definition and it tries to define both the “what” and the “how”. In independent projects that works. But in complex projects that seldom works. The Effective Complex Project Management (ECPM) definition of requirements proposed below is a Change-driven definition. It focuses only on the “what”. The “how” is developed within the Work Breakdown Structure (WBS) and the project execution phase.

THE ECPM DEFINITION OF REQUIREMENTS

The IIBA definition is all well and good and I’m not going to challenge it. I assume it accomplishes what its creators envisioned. But let me offer a different perspective for your consideration. I believe we execute projects to solve critical problems or exploit untapped business opportunities with the ultimate goal of generating business value.

The need to deliver business value

Using cost, time and scope as the variables for measuring project success misses the point of doing a project. The success of a project is measured by the achievement of business value – the more the better. The total cost of the project is measured against the business value generated to calculate Return on Investment (ROI) and compare against other projects competing for the same resource pool.

Complexity and uncertainty

The IIBA definition of requirements is a one step Plan-driven definition. That gives rise to incomplete requirements except in the simplest of situations. The definition of an ECPM requirement given below is a two step Change-Driven definition. In the first step the requirements definition focuses on the “what”. At this level requirements are complete. Think of them as defining an ideal end state. With requirement defined the focus of the solution turns to the second step – the “how”.

DEFINITION: ECPM Requirement

An ECPM requirement defines a component of the desired
end state and when integrated into the solution meets one
or more business needs and delivers specific, measurable
and incremental business value to the client business unit.

The set of ECPM requirements forms the necessary and
sufficient set needed to establish the desired end state and
attain the planned business value.

Adapted from: Wysocki, Robert K, (September, 2014), “Effective Complex
Project Management: An Adaptive Agile Framework for
Delivering Business Value”, J. Ross Publishers

“How” is usually not known at the outset of the complex project. It can only be discovered through successive learning and discovery iterations that build upon a solution that is converging to the desired end state. So at the start of the complex project the definition of “how” is incomplete. Very little of the solution might be known at the outset or most of the solution known with only a few details missing but the solution is not completely known at the outset. So the “how” is the second step of the ECPM requirements definition and its discovery is imbedded in the Work Breakdown Structure (WBS).

The necessary and sufficient conditions statement means that all requirements are needed in order to achieve the planned business value and none of the requirements are superfluous. This is important because the project was justified based on the expected business value as described through the success criteria in the Project Overview Statement (POS). Linking requirements to the success criteria provides a basis on which to prioritize requirements.

This definition of a requirement is quite different than the IIBA definition but in its simplicity and uniqueness it puts the connection between requirements and the business value in a much more intuitive light. I have no particular issue with the IIBA definition but I believe that a working definition linked to business value is a better choice. I will use the ECPM definition throughout this article.

An example of an ECPM Requirement
from a project to establish a
Workforce and Business Development Center

A Business Incubation Center (BIC) (Figure 1) to support the needs of students, workers, entrepreneurs and local businesses for career and professional development and business growth.

Figure 1: The Business Incubation Center (BIC)

Requirements will be the causal factors that drive the attainment of the success criteria as stated in the POS. Every requirement must be directly related to one or more project success criteria stated in the POS. This definition results in a small number (less than 12 for example) of high level requirements at the beginning of the project, whereas the IIBA definition generates hundreds and even thousands of requirements which can never be considered complete at the beginning of the project. The last time I applied the IIBA definition resulted in my client and team generating over 1400 requirements! The human mind cannot possibly absorb and understand that many requirements. To expect that a decision as to completeness can be made in that example is highly unlikely. Subject to the learning and discovery that may uncover other requirements, the list generated using the ECPM Requirements definition can be considered complete at the beginning of the project. An ECPM Requirement is a more business-value-oriented definition than the IIBA definition. The learning and discovery derived from completed project cycles will clarify the requirements through decomposing them to the function, sub-function, process, activity, and feature levels. The first-level decomposition of a requirement is to the functional level and can be considered equivalent to IIBA requirements but in ECPM parlance it is no longer a requirement. It is a function that must be present as a condition of achieving the requirement. So while you can identify all requirements at the beginning of the project you cannot describe the details of the requirements at the functional, process, activity and feature levels. This detail is learned and discovered in the context of the cycles that make up the project.

BENEFITS FROM USING ECPM REQUIREMENTS

Framed in the language of the client
Relate directly to the generation of business value
Helps create and maintain client ownership and meaningful involvement
Integrates all of the steps that define effective complex project management
Reduces the number of requirements from hundreds to less than 12.
Become the basis for solution development
Related directly to project success criteria

PUTTING IT ALL TOGETHER

Current definitions of requirements include both the “what” and the “how.” This leads to incomplete requirements specification for every project except the simplest. The result is confusion and problems associated with the execution of the chosen complex project management process. The ECPM Requirements definition focuses on the “what” and with few exceptions will be complete. Choosing the best fit complex project management process becomes a well-defined decision. The “how” is identified incrementally through a Work Breakdown Structure (WBS) derived from the set of requirements.

Deploying this ECPM Requirements definition across the project life span introduces changes to the project management process that have every reason to significantly improve project performance and reduce the risk of project failure. The discussion of those changes is beyond the scope of this article.

Don’t forget to leave your comments below.

Requirements vs. Design – Does it Really Matter?

Written by Richard Larson on February 18, 2014. Posted in Articles.

Much has been written recently about design in the business analysis field. Some writers have even suggested that since most or all of what we do is about design, then requirements don’t matter anymore. It is popular – even exciting perhaps – for BAs to think of ourselves as designers, since much of the work we do results in solutions. We don’t disagree with the trend and the main concern prompting us to write this article is to point out the importance of including the “as is” state as part of any requirements – or should we say design – effort.

In thinking about the topic it is our opinion that a) perhaps people lack some perspective on where and how business analysis has evolved and b) the debate about requirements vs. design may be mostly one of semantics. Over the years, Elizabeth and I along with many others, have worked hard to help the BA profession carve out its place in the business world.This effort has involved moving from the extremes of having either a technical, systems analyst role or an administrative business “super user” role do the business analysis work.

Part of the impetus for the new design focus has been a strong aversion by some in the Agile community to business analysts or business analysis. Those who feel strongly tend to concentrate on the design aspects of a new product and don’t see the need for much if any actual analysis of the business or business need. (See Tony Heap’s blog its-all-design.com for an example. ) If business analysts are now just designers and we need little analysis, we are moving back to the earlier systems analyst role. Although that might be a satisfying career move for some, it does not usually serve the organization well. To say that we don’t need to worry about requirements is missing the essence of what a business analyst can and should be.

Early in Rich’s career he worked as a programmer-analyst doing COBOOL programming with a variety of databases. That was a euphemism for a role that was 90% design/programming and 10% analysis as we know it today. In thinking back, our jobs then were to implement decisions made at higher levels in the organization, both from the CIO and business management levels. Although we met occasionally with business stakeholders, we generally worked to adapt the business to available technology. While today’s “design” does not imply that we have to ignore business needs, it does suggest that we will focus on solutions without truly understanding the needs.

Haven’t we moved beyond that approach over the last few decades?

Let’s walk through some reasons why the emphasis on design over analysis is an issue. Being only or mostly interested in “design” implies that we don’t care about the “as is” state anymore, as is suggested in recent articles, blogs, and discussion groups. (See David Morris’ article, We Are All Designers Now. ) Without understanding the current situation, we cannot hope to understand:

How end users’ jobs will change with the implementation of the new product or product increment. If we do not know the extent of the change we cannot help workers adapt to the change, which increases the risk of lack of buy-in, unhappiness, and even possible sabotage.
Which of the issues with the “as-is” need to be addressed. If we implement new processes and systems without curing existing ills, we will lose credibility.
No new product or solution is devoid of the current state. Even when we create a brand new product or service, it must fit into the current environment and infrastructure. That means we will have requirements that must be met – not designs – to ensure the new solution contains existing functionality that works and without which the new product cannot perform adequately.
In addition, most of us work on projects that are not entirely new products, but replacements and enhancements of existing systems or processes. These efforts need plenty of analysis of the “as is” state and its corresponding requirements to make sure the changes we bring will fit into the rest of the business operation.
Even for brand new products, there are many business rules and decisions that apply across projects and should be taken into account for the project at hand. For example, the new Training Management System we built for our web site was contracted to a development company. The “specification” the development company used represented our decisions (i.e., business requirements) about what was to be built. The specification was clearly not a design – that was done by the developers – but represented our needs and requirements for the new system.
The BABOK® Guide version 3 talks about requirements being the representation of a need and design as a representation of a solution. That is a workable distinction, although it is a bit awkward to talk about “designs” at the same level as requirements. To understand the distinction better, it helps to substitute the words for the process instead of the outputs:
- Analysis is understanding the needs and requirements and communicating them to the builders of a solution.
- Design is how new features and functions will be incorporated into a solution, plus maintaining existing requirements that should be kept in the new solution.

The last point is perhaps our biggest concern with the new thinking. The business analysis community has fought for years to keep analysis distinct from technical design. In the end, we don’t care that fashioning a solution is called design. After all, what is now being called design is nothing different from calling the output of the process “To-be” requirements.

To illustrate our point, consider Figure 1. The example might be a typical enhancement to an existing system or process. In the traditional business analysis approach, the “as-Is” state is analyzed as a starting point to capture processes, data, and interactions that must be kept for any new solution. Those are “as-is” requirements.

The “current state to be retained” in the “Design” box below are also requirements. They could be processes, data, or user and system interfaces. The design process comes into play when determining how to integrate them with the new features being added. Those new features could equally be called “To Be” requirements as well as design. This is not technical or physical design, but the “logical” design mentioned earlier.

Examples of “To Be” requirements (or design if you prefer) include many traditional BA outputs including:

Process models showing an “As Is” as well as a new business process.
Data models showing “To Be” data requirements and business rules relating to the relationships between entities.
Use Case models with interaction requirements and corresponding business rules.
Prototypes and mock-ups indicating interface requirements. These models tend to cause the most “overlap angst” with other staff such as UX experts. Data models come in a close second in the “don’t step on my turf” confrontations.
Interfaces with other systems.

SUMMARY

In the end as long as we are talking about “logical” design and not technical or physical design, the authors agree with the current trend calling BAs designers. In actuality, BAs have always been designers because we help people conceptualize and visualize solutions that will help businesses meet goals and objectives through solutions. As long as we don’t forget the importance of “As Is” and “To Be” requirements and the part they both play in any solution, then emphasizing design over requirements becomes to us an academic argument.

Don’t forget to leave your comments below.

The Best Reason to call BAs Designers?

Perhaps the biggest reason to call our work design has nothing to do with the BABOK or Agile. It is financial. Yes, the accountants are reluctant to capitalize analysis work, but they do allow capitalizing design work. This makes a huge difference for funding of projects since capitalized costs can be spread out over the useful life of the product being built.

Elizabeth and I have a friend who runs a consulting firm in Minneapolis. He tells us his clients won’t typically pay for “analysis” or “requirements” work. But, he also understands the value of business analysis for the success of his company’s projects. So if he couches the same work as “design,” the clients are more willing to pay for it.

About the Authors

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

Where is Go? Six Steps to Incorporate Lean Principles into the Requirements Process

Written by Eric Spellman on April 30, 2013. Posted in Articles.

Your project timeline is about to click over from discussion to action. The initial smoke has cleared and answers to frame-out the big picture have addressed questions like:

What methodology fits best?
Should new technology be introduced?
Who will participate in the governance model?
When and what will be delivered and who’s writing the checks?

It’s time to Go. The clock is ticking and expectations are high.

Then it hits you. How do I start? Who do I talk to? What am I going to deliver and in what format? In other words, “Where is Go?”

Unless you’re one of the lucky few Business Analysts driving the process continuum from business case development and project planning into the elicitation phase, your version of Go usually begins somewhere between “go figure it out,” and “we need to start coding yesterday.” More often than not, it seems that a considerable number of projects start on a wild goose chase, tracking down project definition documents, trying to make sense of the available artifacts, or something – anything – that illustrates current state. Starting off in scramble mode is not only ineffective and inefficient, it is never accounted for in a project timeline.

Saying this is a stressful and difficult situation to start is an absolute understatement. Especially since Business Analysts hold the key responsibility of translating a business objective into an executable solution. To start a project with such uncertainty is simply an unwarranted risk. To help mitigate that risk, here are 6 steps that will significantly reduce the non-value added time spent in scramble mode. These steps will provide a consistent starting point on virtually any project – regardless of the methodology you’re operating within or the technology being used.

Step 1: Know Your Lane

Don’t rely on titles to provide role and scope clarity. Unfortunately the Business Analyst, Business Systems Analyst, or whatever multitude of variant prefixes are added to Analyst, will not define project accountabilities or responsibilities. Seek out and schedule time with the person who will be “Accountable” for your deliverables. Understand anticipated deliverables and who will be receiving them, established timelines, and project reporting requirements.

Lean Principles: Identification of the Value Stream (project perspective)
Tool belt: RACI matrix
BABOK Reference: sections 2.1, 2.3, 2.5

Step 2: Stay in Your Lane

Be a collaborative team member, but stay laser-focused on your deliverables. Scramble mode equals multiple levels of ambiguity: don’t cross over into project management, technology design, or any other functions not directly related to defined deliverables – something that’s easier said than done as Business Analysts are solution- and quality-driven individuals. Dysfunctional teams (broadly characterized as too many team members who are too broadly focused on performing too many roles), probably contribute more often to failed projects than scoping issues, poor requirements or misused technology combined.

Lean Principles: Eliminate Waste (wasted time focused outside delivery scope)
Tool belt: become familiar with causes and remediation techniques of Dysfunctional Teams
BABOK Reference: sections 2.3, 2.4, 2.6

Step 3: Identify Your Consumers

Temporarily narrow down your immediate focus and define your Consumer as the person/role who is the primary recipient of your deliverables. Invest time with them as they will be your most important relationship on the project. Understand why they need your output, how it will be used, and what they will be producing. This will provide significant context around your purpose, and key partnerships required to ensure smooth handoffs in the supplier-to-consumer process.

Lean Principles: Identify Customers and Specify Value
Tool belt: SIPOC matrix
BABOK Reference: section 2.2

Step 4: Capture Consumers Critical-to-Quality (CTQ) Requirements

This is the essential step that will formulate true value-add deliverables defined by each consumer group captured in Step 3. This will be the “What”, “How” and “Why” guidelines used to build your artifacts. Capture exactly what your consumer needs and their preferred format. Be sure to be as diligent, detailed and explicit in understanding and capturing these CTQs as the business/functional requirements that will ultimately be delivered. Our key objective is to produce the exact amount of information needed in a consumable format.

Lean Principles: Identify Customers and Specify Value
Tool belt: CTQ Tree
BABOK Reference: Sections 3.1, 3.2, 3.3

Step 5: Identify Your Immediate Supplier

Identify what you have to work with in order to produce artifacts that are aligned with your consumers’ CTQs. Understand who, what and how your inputs are being provided. This will help define the time and effort required to create quality artifacts. To the extent possible, work with your input partners to provide them with your Critical-to-Quality requirements.

Lean Principles: Respond to Customer Pull
Tool belt: SIPOC matrix
BABOK Reference: Chapter 2 (inputs)

Step 6: Draft Deliverable Review

Take a meaningful, yet bite size piece of a scheduled deliverable and craft it based on the established CTQs. Review it with your consumer(s). Keep this as an iterative process until your requirements package is complete. Embrace the continuous improvement mindset and don’t be afraid to keep making modifications through the elicitation phase.

Lean Principles: Pursue Perfection
Tool belt: Driven by consumer (see available options in BABOK Chapter 9)
BABOK Reference: Chapter 9

Efficient and effective are two of the more appreciated words project leads and business sponsors love to hear, usually due to their positive association with time, cost and quality. If Business Analysts understand for whom and how work will be used, the way in which that work is created will be a much more fluid process.

Business Analysts share similar principles with their Business Process siblings. Both strive to create value as defined by our consumers, utilize various toolsets to align needs with approach, and leverage appropriate methodologies/frame works to ensure quality and on-time delivery. Integrating Lean principles and tools with the BABOK has proven to be an excellent combination of complementary knowledge and tools to broaden thought perspectives for Business and Systems Analysts alike.

But regardless of methodologies used or tools leveraged, complementing your approach by reaching out to those organizations and/or personal contacts who possess those related battle scars will provide a GPS-like solution to finding Go.

Don’t forget to leave your comments below.

Eric Spellman is a Managing Director at Magic Hat Consulting. He has 20 years of experience as a key strategic leader and tactical contributor with organizations engaged in transitioning and integrating process improvement within requirements development, program management and strategic planning. Eric’s business domain experience includes Banking, Insurance, Pharmaceutical, and Software Development. Eric is a certified Lean Six Sigma Black Belt and SCRUM Master. He has served as a chapter board member for the IIBA and an active member/contributor to several Process, Requirements, and Project Management groups.

Jack Merritt is a Senior Director and leads Magic Hat Consulting’s Business Enablement practice. He is a Lean Six Sigma Master Black Belt with 17 years of experience deploying Lean & Six Sigma programs and executing projects delivering over $200M of demonstrable annualized savings from operations and improved effectiveness of sales forces. Jack has taught DMAIC, DFSS, DMADV, Statistical Process Control, Innovation, and Practical Statistics at several universities. His areas of expertise include: Sales and Marketing processes, Customer Service effectiveness, and Transactional Finance. Accomplished in executing Hoshin and Strategic Planning programs, Operational Metric Development, Kaizens, Work-Outs, Lean Value Stream Mapping and Process Flows, Project Management, Financial and Process Modeling.