Skip to main content

Tag: Skills

A Fresh Look at Requirements and Requirements Elicitation in Complex Projects

Written by Robert K. Wysocki on . Posted in Articles.

Wysocki July28It 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.

rwysocki July30
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.

Business Analysts: Born or Made?

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on Business Analysts: Born or Made?

The short answer is both – shortest blog ever or ??? IF you know BOB F., please let him know he can claim his prize from me for his excellent answers presented in my last blog.

Back to our topic.  I for one have often blamed :)* my mother, Kathleen Ferrer (nee Morgan, September 26, 1923 – June 26 2014), the only person who both bore me and made me. I often thanked her for my life and her influence, and will miss her very, very much.

I thought I would try to investigate the common experiences or characteristics that lead one to an ongoing BA career.

So, here are some data from my life, left blank for the moment. Fill it in on paper or in your head if you wish, AND EVEN BETTER – Click here to link to the survey:

Then contribute YOUR experiences and characteristics (anonymously) to help all of us BAs and BA wannabes know – Born or Made?

All participants will receive a summary of the survey results if wished 🙂

Date of Birth: ______________

Gender: ______________

Age learned to read: ______________

Who first taught you to read? ______________

Age first fell behind in math: ______________

Who taught you most of your math? ______________

Number of houses growing up: ______________

Maximum distance between any two of these houses in kilometers: ______________

Minimum distance between any two of these houses in kilometers: ______________

Most advanced Business Analysis certification or degree achieved:

CCBA
CBAP
Other Business Analysis certification [give the acronym]: ______________

If your own experience suggests a new question relevant to your path to BA, please add it in the blog comments below. Nice to hear from you, readers are so rare in today’s world, and writers more precious yet 🙂

————————————————————————————-

:)* Blame, in my blogs, is always a joke. My true belief is that blame is a stone-age behavior in an information age culture, and is just as useful in that evolving culture as the sheet music to the song “In the year 2525” would have been during the Cambrian explosion. I could, of course, be completely wrong.

Don`t forget to leave your comments below.

The Top 8 Mistakes in Requirements Elicitation

Written by Aaron Whittenberger on . Posted in Articles. 1 Comment on The Top 8 Mistakes in Requirements Elicitation

Whether you are an Enterprise Business Analyst, Enterprise/Business Architect, Business Intelligence Analyst, Data Analyst, Process Improvement Analyst, Agile BA Team Member or IT Business Analyst, you work to bring about change within the organization. Sometimes these are small incremental changes, and sometimes these are big changes that require an organizational shift or cultural change. Whether small or large, most of those business analysis roles deal with gathering requirements. One of the key activities of a Business Analyst is to draw out and document business change requirements from stakeholders throughout the organization. As the International Institute of Business Analysis (IIBA®) celebrates their 10th anniversary this year, we are reminded that business analysis as a profession is still maturing, as is the practice of business analysis in many organizations around the world.

As organizations struggle with maturing their business analysis approaches, let’s take a look at some common mistakes that practitioners commit when eliciting requirements from stakeholders.

1. Improper Stakeholder Analysis

Often times resource managers or the Project Management Office (PMO) assigns resources to projects almost as early as the Project Manager (PM) and Business Analyst (BA) are assigned. With these resources the project marches on and the Business Analyst never does a proper and complete Stakeholder Analysis. Stakeholders can be missed because that early in the project all the lines of business within the organization that are affected may not be known. Perhaps as the project moves on, it takes a turn into a new business line; and if the Business Analyst doesn’t recommend that a representative of that business unit be assigned to the project team, then they are not doing their job. If you have stakeholders from one line of business answering for another line of business, you may not have all the business or functional stakeholders engaged in the project that should be.

One of the first activities that the Business Analyst should complete upon being assigned to a project is a Stakeholder Analysis. This helps ensure that the proper stakeholders are engaged in the project. However, a Stakeholder Analysis is not a one-and-you’re-done thing. It is an activity that should be considered throughout the project’s timeframe, especially when elicitation discussions take a turn into a new business area and there isn’t a representative from that business unit on the project team. This is the time for the Business Analyst to raise the red flag, complete a new Stakeholder Analysis, and recommend new resource(s) be engaged on the project.

2. Improper language in the requirements

Business Analysts that work in very large organizations or with very structured teams, especially Quality Assurance teams, have heard that your requirements have to be well structured and testable. Many Business Analysts have been told that requirements have to be SMART: Specific, Measureable, Attainable, Realizable and Time-bound. I worked in one place that advocated that requirements had to be SMART-CC, adding Complete and Concise to the SMART acronym.

Quality Assurance Teams advocate the SMART test for requirements as they want requirements that they can test. Even though, most of the time, QA teams test the solution against the solution (functional and non-functional) requirements, most Business Analysts will attempt to make their business and stakeholder requirements SMART. A lot of times the BA will fall into the trap of expressing the requirement from the technical viewpoint and in technical terms. So they have taken a requirement for/from the business and applied technical terms or changed the viewpoint of the requirement, which adds ambiguity and confusion for the business stakeholders.

Remember the business requirements and stakeholder requirements are primarily from and for the business stakeholders. Even though the technical team will use those requirements, the business is the main consumer of those requirements. Therefore, they should be expressed in business terms and from the business standpoint. Likewise, the solution requirements have to be SMART for testing purposes. The technical teams are the main consumer of those requirements, so they should be expressed in technical terms.

3. Jumping to design before getting the requirements

I have been in many stakeholder requirements elicitation activities where the stakeholders start talking about design and in which system this solution will be implemented. If the BA doesn’t squash those discussions immediately when they start too early, then they tend to multiply and consume the actual elicitation of requirements. Soon you have a design for a solution before you truly understand the business problem you are trying to solve—before you understand the business need.

This tends to put blinders on the entire project team, and everyone marches down the same path toward a solution because that is the only thing the team can see. Once the solution discussions begin, and are not halted by the BA, it tends to give everybody hearing the discussions a single focus, even though they don’t fully understand the business need. Quite often this leads to alternatives to the“initial solution never getting considered. This also leads into my next two mistakes BAs make during elicitation activities.

4. Not guiding the conversation during elicitation with a group of stakeholders

Even with a small group of stakeholders, even in a one-on-one stakeholder interview, discussions can go off course onto tangents that are not relevant to business needs. Sometimes the conversation can be so far off course that it is not even relevant to the present project. These conversations tend to distract from the task at hand and waste time during requirements discussions. It can cause stakeholders to become frustrated with the process and become disengaged with the project, as they find better use of their time than to continually hear a couple of people dominate the conversation with what they did over the weekend or other irrelevant topics. Another distraction is when there are two or three conversations going on in the room. Of course, all these issues compound as the number of stakeholders in the conversation increases.

Part of the task of the facilitator is to keep the discussion on topic. When the conversation goes off on a tangent, it can be difficult to find the proper time to rope it back in. The sooner the facilitator brings the conversation back on topic, the less likely further discussions will stray off, the less time is lost, and the more engaged your stakeholders stay in the project.

5. Getting approval for the requirements without a shared understanding of them

With today’s tight project schedules, often times the requirements approval process is rushed so much that ensuring that all stakeholders, business and technical, understand the requirements in the same way is difficult. With stakeholders coming from different viewpoints, ensuring that they all understand the requirements is a task in itself. A structured requirements walk-through will go a long way in accomplishing this task. As everyone in the walk-through hears comments from other stakeholders, a common understanding begins to take form. The stakeholders learn how others view the requirements.

6. Feeling requirements must be 100% complete and accurate before sharing with the stakeholders

Novice Business Analysts can fall into the trap of feeling that the requirements that they are documenting must be 100% correct before they share them with anyone. They feel that any corrections or changes to the requirements mean that they did not do their job correctly. So in an effort to make sure they are correct, they go talk to more stakeholders. They make sure to elicit from everybody in the organization. Then before you know it, the project is in analysis paralysis.

BA Managers have to ensure that there are no performance measures on the BA’s evaluation that measure changes to requirements. It is not a good measure of how well the BA did the job of elicitation. The BA themselves have to remember that they are one person and they cannot know everything. Changes to requirements are not any indication of how well the task of elicitation was done. Using a more collaborative approach to requirements elicitation, where the requirements are more visible throughout the process, is a better approach to ensuring the requirements represent what the business actually needs.

7. Not building trust with stakeholders

Often times BAs move from one project to the next, have four projects going on at once, and don’t take the time to get to know new stakeholders that they had not previously worked with. Getting to know the new people who you are working helps you understand their viewpoint and agenda. This will certainly help if conflict arises during elicitation. Understanding each person’s viewpoint will help the BA resolve the conflict by helping each person to understand the other viewpoints in the conversation. The BA cannot accomplish this if they do not understand the viewpoints in question. Taking the time to get to know someone shows them that you value their input and participation in the project.

8. Blindly using a template

I was recently handed a Business Requirements Document (BRD) template that had several categories of requirements including documentation, reliability, scalability and training, among others. All of these categories are non-functional, or solution, requirements—and as I said this was in the BRD template. Recognize the fact that these are solution requirements and do not have any place in the BRD. If you receive a BRD like this, remove these categories or mark “N/A” or “Will be defined during design and included in the Functional Requirements” in each category. If you do the latter, check the Functional Requirements document template to ensure that the category is in that template as well. If not, add it. Don’t blindly use a template just because that is what the organization uses. Don’t try to define solution requirements during business requirements. How do you know what your training needs are if you don’t know what the solution is? BAs are agents of change. Challenge the template and help the decision makers in the organization see the value of a correct template.

Conclusion

To do an effective job at requirements elicitation, avoid these traps that can get your activities off track. Be sure you have everyone in the conversation that should be, define the business need before designing the solution, ensure that there is a shared vision of the requirements, and document the requirements in a collaborative approach with the project team. This will help ensure that you do an effective job at eliciting the requirements for your organization.
So there is my list, what is yours?

Don’t forget to leave your comments below.

A Brave New World for Business Analysts

Written by Suzanne Burgess on . Posted in Articles.

Change is always with us, in both big and small ways. As business analysts, we should embrace this constant feature in our work by looking for ways to help understand it and use it. All too often we see the change only as a project in which we elicit and document requirements. We need to think further than the project. We need to know the reason for the change – what problem is being addressed and what are the forces behind the reason for change?

Thanks to technology, today’s companies must change constantly or die. Research shows that the average lifespan of a company is much shorter than previously thought. For example, on the Standard & Poors Index the average lifespan of a company is 15 years compared to previous generations. Companies like Kodak, which were once world leaders are now footnotes because they did not see how to use changes in technology. Although Kodak invented the digital camera, they set it aside so it would not impact on their main business of selling film. Kodak did not take advantage of this possible disruption – a digital camera – and is now history.

The disruption change brings to an organisation can be seen as an opportunity for that organisation to innovate and reinvent themselves. The same opportunities apply to BAs. BAs are better positioned than most professions to understand these types of change by analysing the underlying reasons for them and reinvent themselves based on the environment they find around them.

I believe that business analysts must adapt by developing expertise in the following areas:

  • strategic thinking,
  • customer-centred design, and
  • data presentation and communication.

To a lesser extent, all three of these areas are already listed in the IIBA Body of Knowledge Underlying Competencies. Competencies such as learning, communication, and leadership should be expanded to better understand the changing technological environment and provide value to our organisations.

One lesson from Kodak’s mistake with the digital camera is to think strategically and not to try and hide from new innovations. Business analysts have been told time and time again to not “jump to solution”; however, that may not fit with the new environment of organisations using already developed or outsourced IT solutions and applications in the cloud. Mark McDonald said it best in a Gartner Blog on “Amplifying the role of the business analyst” when he stated “Increasingly, enterprises and CIOs do not have the resources or time to continuously create new solutions. This changes the role of business analyst from introducing new solutions to solve issues toward a greater emphasis on redeploying existing solutions to new issues.“ 

While organisations are attempting to understand the technology changes, end users or customers of their products, they are also trying to keep up with these changes. Business analysts have always included the end user in the stakeholder lists and analysis, but now is the time for them to recognise that customers are THE stakeholder. In my opinion, good design and usability of an end product signals the success of a project. Customers today have many platforms to voice their disapproval and affect the organisation. Good design comes from including users in the design process and experimenting with them to see what works. This user-centred approach works well with our requirements elicitation.

The change businesses are experiencing means that they will look for answers everywhere, including all the data available to them through websites and social media and other means. The Harvard Business Review recently declared: “The steady invasion of hard analytics and technology (big data) is a certainty.”  And business analysts should be equipping themselves to understand what this means and more importantly, how to present data. We need to understand what exactly the stakeholders are looking to the data for and how to present it to them so they understand it to make a decision. I disagree with this article in Slashdot stating that big data means the “death” of business analysts. No, I think the change coming from big data provides a great opportunity for BAs.

As organisations face change and decide how to respond, we BAs face the same need to change. How we respond to change and whether we change also and in what ways will determine whether we are successful. I believe our profession needs to start focusing more on strategic thinking, customer-centred design and data presentation and communication. What are your thoughts?

Don’t forget to leave your comments below.

Watch Out For Think-Holes

Written by Marcos Ferrer on . Posted in Articles. 2 Comments on Watch Out For Think-Holes

ferrer Oct1Answer to last month’s question: Change the “head of the fish” to balance benefit as well as cost. Example: “Why does internal service impact profitability?

Most of us have a pretty high opinion of our own thinking*. We are biased, but don’t see it that way. This makes complete sense. WE are ALIVE**. We are the latest survivors of billions of years of disaster, uncertainty, death and taxes***. We are the WINNERS! We must be doing something right. Right?

Right! As survivors, we have tremendous adaptations. Adaptations that got our ancestors away from lions and tigers and bears oh my!**** These adaptations are less useful than they used to be – see if you agree.

Fast thinking vs. slow thinking:

We have almost instantaneous abilities to recognize friends, spot strangers, see (and dodge) dangers, identify objects and their uses, feel body language, judge tone of voice and much, much more. The Nobel Prize winning economist Daniel Kahneman describes these abilities as System 1 thinking. 

Here is an example of System 1 thinking:

What is this picture?

ferrer Oct01

Here is an example of System 2 thinking:

If the average expenditure by a middle class consumer ($50K-$115K/year) at a SaveMoreBySpendingMore™ store is $18.25, and middle class consumers represent 94% of SMBSM customers in 2012, and our total customer visits per year in 2012 were 78,543,228, how much revenue came from middle class customers? *****

If the above seems excessive as an example, try this example of “slow” thinking (for most of us):

How much is (40 x 52) – 80?

Even though we “know” we can calculate the above fairly quickly, and we have a sense that the answer is not 17, or 15,000,000, we (I mean I, as my brilliant readers are not so limited) cannot calculate it as quickly as we can recognize a $100 bill.

The “thinkhole” here is the temptation to go with “first intuition” when it is not always the best approach. This can be appropriate (“Duck – here comes a rock!”), it can also be less (way less) than useful (“Let’s build a really cool space airplane just like the astronauts/pilots always wanted. That will be cheap, reliable and fun, just like flying jets.”). One way to characterize a BA is as a person who is willing to do the complex thinking for a larger group.

Anytime a complex decision is offered to a meeting, there is a real danger of the decision being made “quickly”, and almost surely “wrongly”. In such situations we must be ready with clear options and open facilitation to keep discussion (and follow up analysis) alive.

Some of you may recall the training video “Going to Abilene”, where a bunch of IBM trainees decide to go to Abilene after one of them tosses it out as an idea. They have a miserable, hot, dusty day and only get 1 hour in Abilene for their trouble. When they get back to training camp, they argue and place blame until they realize what happened. They went to Abilene because no one wanted to “contradict” their colleague or “put down” the idea. The colleague who suggested Abilene was quite clear. “Don’t blame me! It was just a thought. I didn’t think it was the greatest thought in the world, but when everyone went along I didn’t want to stand out!”

Solution: Do the slow thinking. Don’t force decisions. Simplify for the audience. 

Let’s look at some other thinkholes:

Aversion to Loss will prevent Desirable Strategies for Gain

Would you rather have a 100% chance at $1000, or a 90% chance at $1200 with a 10% chance of losing $50? Why? What if you get to play 10 times in a row? It is difficult to overcome fear of loss. The loss can be intangible – reputation, comfort, preference, etc. These fears can actually prevent our work as change agents. 

Solution: Do the “math” so all can see the tradeoffs, then duck . 

Preferring Apple Pie to Cherry, Cherry to Peach, Peach to Apple

Most individual pie eaters (not all) are consistent (their preferences are transitive, and Apple will beat Key Lime via Cherry), but most groups are not. Politics can illuminate this. In 2000, many democrats preferred Ralph Nader to John Kerry, and John Kerry to George Bush. By voting for Ralph Nader (their first choice), they got George Bush (their last choice). 

Those on the left that preferred Nader were NOT happy with Bush, and yet could not make the rational choice – to vote for Kerry instead. Groups can be “dumb”, even when individuals are smart. 

Solution: Show choices AND consequences, when it matters. 

Overestimation of rare effects

This shows up most often when use case “alternatives” spin out of control. We may be discussing retail transactions, and everyone agrees we should take cash, credit, debit, bitCoin, PayPal and checks. The debate breaks down when we start discussing barter, which is far more complicated (and rare, in commerce). There is no denying that barter happens, AND it may be a waste of time holding up decisions and consensus and progress to handle barter. 

Solution: Add it to the alternative paths, and schedule it for LATER.

Misunderstanding probability

This one I want to make money on. If I explain, I won’t make any money. I offer the following bet, without explanation, to anyone who wishes to take it (the law firm of Finch and Associates, LLC will hold the money and administer the bet, unless they don’t want to ):

I am willing to bet my $1 against your $1 that: If we pick 50 people at random, then at least two of them will share the same birthday (same month and day, though possibly a different year).

If that is not attractive we can make it my $5 against your $1 as long as we pick 70 people at random.

Any takers? Why or why not? I have lots more, open your wallets.

Solution: Which humble reader shall provide?

Thanks for reading, leave any thoughts, and have fun!

Don’t forget to leave your comments below.

* Not my humble readers, who know that they are WAY too smart to fall for this.

** Life is clearly biased in favoring existence over non-existence.

*** Us, and Naegleria fowleri, so don’t get too excited.

**** And humans. Next time you are nervous in public, now you know why.

***** Answer next month. No more scroo’n ‘round, on with Thinkholes!