Tag: Facilitation

Time Value of Requirements: Always Solve for the “Why” of Today

Written by Garnet Masenda on December 28, 2015. Posted in Articles. 1 Comment on Time Value of Requirements: Always Solve for the “Why” of Today

Ever heard of “Time value of money”? The time value of money theory states that a dollar you have in hand today is worth more than a reliable promise or expectation of receiving a dollar at some future date. For all intents and purposes, this means what you can buy with a dollar today should be more than what you can buy in future with that same dollar.

Now let’s flip the script and replace ‘money’ with ‘requirements’. If money is something that has value to us, business requirements have value to our stakeholders. Business requirements value can appreciate or depreciate over time just like money does – usually the value depreciates.

I am going to focus on the depreciation in value of business requirements. As the clock ticks, each time a release date is missed, the value of elicited approved business requirements to our stakeholders diminishes.

I recently had an interesting conversation with a colleague of mine which triggered me to write this piece, here is a snippet of how it went;

Him: “I got sign-off on the Business Requirements document 11 months ago; nothing has changed because my change requestors in the Business Development department have not said anything to me.”

Me: “11 months is a long time mate? Do you realize that we don’t sell that product anymore?”

Him:”…………..” (That’s silence by the way).

Needless to say, my colleague ate humble pie and went to his stakeholders to have a conversation. After chatting with the business owner of the project, he realized how much the business domain had changed over time and how little the requirements previously approved were still needed. To his credit, he was willing to have the conversation and in the end delivered what was required to cater for the current needs.

What was important to the stakeholders 11 months ago was not as important anymore. Why?

There were more pressing issues that needed urgent attention
The change requestors wanted to tweak the requirements to satisfy their current need (not 11 months ago need)

In simple terms, after 11 months the change requestor had new priorities. The previously defined requirements had depreciated in value over time.

I understand that we as Business Analysts work requirements elicitation and documentation, and it might take a long time before the changes are implemented through code. This problem is rife in environments that employ the Waterfall methodology to implement projects.

The organizations that we serve evolve over time in order to remain relevant to the market they serve and so should we as Business Analysts. We need to understand and buy into the WHY of TODAY for us to be effective solution providers to our stakeholders. We need to ensure that as we do our job, we are working on “current” and “valid” problems/issues/opportunities.

The diagram I illustrated above delineates how a business requirement can potentially devalue over time when not implemented. When a requirement is finalized, it has the highest perceived value to stakeholders but that value will depreciate over time when the defined solution is not in use.

The question is how we ensure that requirements from 11 months ago are still relevant TODAY. The simple answer is we go back to our stakeholders and ask them. Observe their business processes in person if we have to. Our main objective is to understand the WHY of today?

So how do we change the narrative? How do we ensure that requirements remain relevant? How do we ensure that requirements approved a “long” time ago will still add value to our stakeholders as previously envisaged?

I suggest that you focus on the following areas:

1.Problem statement

Revisit the defined problem statement. Is the problem still a problem anymore? If yes, how has it changed and how has the business area coped with the problems from the time the problem was raised? Finding out their coping mechanism might influence your solution design; you can get some ideas here. If the problem does not exist anymore, then our job is DONE. Well done. There is no need to deploy resources on the problem that no longer exist.

2.Business needs (defined)

According to the BABOK, “Business needs are the problems and opportunities of strategic importance faced by the enterprise”. Business needs inform the “WHY” of the project. Your mandate is to determine whether the ‘WHY’ is still the same or how it has changed. If it is has changed then you need to determine to what extent and how it changes the definition of your requirements.

3.Goals and objectives

Reassess the goals and objectives previously set and change accordingly. Goals and objectives keep us honest as we work through the project and are ultimately used to measure the success of the project post-implementation.

4.Approved requirements

Review the requirements with your stakeholder. I am not suggesting that you frustrate your stakeholders by asking them to redefine their requirements. Do not position it as yet another elicitation exercise but as a way of ensuring that the requirements defined before will meet their current needs and will be aligned to their objectives going forward. You need some level of creativity when having the conversation; it is not always fun, but it has to be done.

5.Definition of Done

Revisit your stakeholders’ expectations of the finished product. It is important to validate expectations against the requirements. Here you need to incorporate carefully any changes to the solution to ensure that you deliver what your stakeholders will actually utilize.

But what is THE best way to go?

Become “AGILE” in your analysis. If analysis is agile then requirements will be defined “just-in-time” for development. Going Agile allows you to engage with your stakeholders at the time when resources are available to implement a solution. The only dependence of being Agile in our analysis effort is that the project team must use an Agile methodology to deliver projects. Your project stakeholders must buy into the Agile modus operandi for it to be successful.

There is a flip side to the story above; requirements do not always lose value. In the event that requirements appreciate in value, you still need to assess the areas I have mentioned above to ensure that we cater for the current business reality.

Time influences everything in life, the business environment we operate in changes and evolves over time. The longer we take to implement requested changes, the less valuable the changes will be to our stakeholders. Stay relevant by knowing the WHY of today.

Let me know your thoughts. Until next time. Keep well.

Taking the Helm: Navigating The Job Search Ocean

Written by Morgan Culverhouse on December 7, 2015. Posted in Articles.

Recent circumstances led me to get into the dark murky waters of a job hunt. Being that I was in my last position for 17 years with over 10 of those years being a Business Analyst, I figured it wouldn’t be that difficult to navigate the seas of an employment search. After all, there’s a job title field in nearly every employment search engine where I can enter “Business Analyst” in the text box, right?

Little did I know about the obstacles before me that would make the job hunt seas very choppy and rough.

One big obstacle is caused by the very broad definition of “What does a Business Analyst do” which can lead to some very interesting complication.

Following are several examples of job postings during my cruise on the employment seas:

Looking for a Business Analyst but needing a Project Manager

In more than one instance, I came across positions in my searches that were titled as a Business Analyst position but in reading through the job requirements section on the ad, the company would specify typical Project Manager related tasks. In fact, I also saw postings requiring the Project Management Professional (PMP) certification. This is not to say that a Business Analyst does not sometimes have to function as a Project Manager, but it might be better to have a Project Manager in certain positions.

Looking for a Project Manager but needing a Business Analyst

Conversely, I came across postings in my search titled as a Project Manager position but in reading the requirements it appeared they needed a Business Analyst instead. Again, not to say that a Project Manager can’t execute the Business Analysis function, but it would help to title the posting correctly.

Looking for a Business Analyst but needing a domain specific analyst

Next there are the job postings where the title reads as “Business Analyst” but the descriptions is calling for someone with domain specific skills such as PeopleSoft or ERP systems. This just adds to the amount of postings that have to be waded through to see if you could be a fit for the position.

Looking for a Business Analyst but needing a Systems Analyst

Another one of the fun posting types to come across are the ones titled as a Business Analyst but what they really are specifying in the requirements is a more specialized analyst such as a Systems Analyst or Business Systems Analyst or even IT Business Analyst title. Business Analysts can wear many hats but what does the employer actually need?

Related Article: Business Analysis is not a 9 to 5 Job

Looking for a Business Analyst but needing someone to work in Operations

One of the last items I’ll point out are postings looking for a Business Analyst but upon reading the description the company is actually looking for someone to work in Operations either fielding customer calls or entering data into a database. This is a useful and needed individual in the organization, but the title of Business Analyst for the position can be misleading to job seekers.

So what leads to these issues with the postings? There seem to be several issues:

Employers might not understand what they need;
Employers might not know the proper title for their given position;
The Business Analyst title allows us to branch off into many specialties leading to some of the varied misclassifications.

In the end, these are some helpful hints to keep in mind if you find yourself in the deep voyage of seeking employment:

You need to read the posting and not just the title – when I first started I only looked at “Business Analyst” titles but I found some hidden treasures in the text of postings that swayed me one way or the other. You’ll never find that hidden gem if you base your job search on title alone;
Understand your own capabilities – know what it is that you can bring to an employer;
Understand your own limitations – You’re most likely going to get asked in an interview about your limitations, so it’s best to get to know them now;
Create and practice a couple versions of a personal “pitch” – you’ll want a short elevator pitch as well as one a bit longer;
Utilize your networks as much as possible.

Above all, enjoy your cruise.

A Journey of Discovery – I Know What I Want

Written by Adam Alami on November 16, 2015. Posted in Articles. 1 Comment on A Journey of Discovery – I Know What I Want

Throughout my career, I’ve experienced a number of situations where issues are not always apparent at first glance. Many times, superficial observations belie a fall sense of calm, while, in some cases, problems are known to exist, but still overlooked. These are some of the starting points of requirements analysis process:

I know what I want.
I know what the problem is.
I know the problem and the solution.
I do not know what I want.
I know there’s a problem.
I know there’s a problem, but I am not sure what it is.

Knowing exactly where your stakeholders stand is, in my opinion, the starting point towards eliciting and understanding requirements.

Even when the stakeholders claim that ‘I know what I want,’ to assume that these so-called ‘needs’ are valid and known would be naïve. A Business Analyst should be aware that the needs expressed by the stakeholders are not always exhaustive, valid, and will not necessarily lead to the right outcome.

What Happens When A Stakeholder is the “Know What I want” Type

A few years ago, I had an opportunity to work on a project where the client was the ‘I know what I want’ type. They were quite sure that all they needed was to modernize their IT platform, retire legacies, and introduce new capabilities to improve process efficiencies. Quite predictably, they insisted on building the project with the focus on these ideas. The entire requirements analysis were based on the idea that ‘I want to modernize the technologies I use.’ The analysis of the requirements and implementation of the solutions, from end to end, cost the company close to $50 million.

We delivered state-of-the-art solutions and implemented them successfully. However, when the company ran a benefits tracking activity to see how the modifications fared, it was found out, quite surprisingly, that the benefits were not fully realized. As for the improvements in efficiencies, there wasn’t much to speak about, either.

Related Article: Process Approach to Requirements Gathering

As analysts, we were again asked to assess this situation. This time, however, the stakeholder’s stance was ‘I am lost.’ The first instance of the project implementation was thoroughly based on the stakeholder’s suggestions, and it was assumed that the ‘requirements’ as the stakeholders saw them, were the only ones and the correct ones. In the second instance, however, we began from scratch to make the voyage from the unknown to the known. What we found had little to do with the needs that the stakeholder had insisted upon being delivered in the first instance:

The organization had deep-rooted cultural problems like:
1. Dissatisfaction among staff
2. Rifts among senior management
3. Power struggle across the organization
Relations between business functions were either absent or dysfunctional.
Communication across multiple channels was broken and was often ineffective and insufficient.

As it turned out, modernization was indeed necessary, because the organization was carrying the risk of working with outdated legacy systems. The processes, too, were overdue for a review and possible re-engineering. However, these weren’t the only requirements. The organizational and cultural issues needed to be resolved before handling the technical issues. The root causes of inefficiencies were fundamentally cultural. The unbiased process of requirements analysis unveils the true problem.

What Was Learned

Never take for granted what stakeholders assume to be requirements. What the business user expresses is just one piece of the puzzle. There are unknowns that need to be discovered and put in front of the stakeholders.

Unfortunately, there is no single formula that would apply to every situation. However, there are requirements analysis principals that can be used to bring objectivity to the process.

Do not mistake what your stakeholders are telling you for the absolute truth. The truth has multiple versions. A Business Analyst has to discover every version of the truth to reach the absolute truth.
Be skeptical. Go above and beyond expectations, do your homework, investigate, and gather information in a structured manner to determine the accuracy of the stakeholder’s perceived requirements
Never leave any room for guesswork. Rely only on facts and evidence.
Data is of utmost importance. Try to collect information from every plausible source.
To counter biases, use multiple sources of information.
Never reason from insufficient data.
Every situation is different. Use your intuition.

We are called ‘analysts’ for a reason! When Sherlock Holmes walks into a crime scene, he does not solely rely on the questions ‘What has happened?’ He goes above and beyond. A Business Analyst always needs to know that the ‘needs’ expressed by the stakeholders are not always exhaustive, valid, and they will not necessarily lead to the right outcome.

Align Your Requirements to Corporate Strategies Using Business Architecture

Written by Daniel Lambert on November 9, 2015. Posted in Articles.

In an article entitled “Business Analysts and Business Architecture” published earlier this year in the Business Analyst Times, I got a comment from Duane Banks, a Business Analyst at United. I had shown a graphic were Business Analysts were only involved in some operation planning and mostly in delivery and execution of initiatives. He said the following:

With Business Architecture, Duane and many other Business Analysts are right to assume that the scope of the perspective of a Business Analysts can be much broader than traditionally perceived by the IT industry. With Business Architecture, Business Analysts can now be involved in the strategic, operational and even marketing planning on top delivery and operations of projects, as shown in Figure 1 below.

Business Architecture Propagating Corporate Strategies to IT Professionals

BABOK® Guide v3 is very clear about this. Business Architecture is one of 5 new perspectives that a Business Analyst should take into account while managing its business requirements. In the Business Architecture perspective, reference models are listed instead of methodologies or approaches. They are called meta model, which can include up to 11 different maps, as shown in Figure 2 . No single part of this meta- model should be assessed or altered in complete isolation from the rest of the model.

This diagram takes into account Requirement Mapping and Process Mapping and allows it to be linked to other maps. To execute the business strategies included in business architecture, you need to include requirements and business processes. If the meta model of a corporation’s business architecture is well defined, you can even easily link a requirement among thousands to one or a few processes among again thousands of processes, as in the telco world for example. In brief, a good Business Architecture Model will enable the Business Analysts, the Process Experts and the IT/Software/Enterprise Architects in a large corporation to stop working in silos and start working together, as shown in Figure 3.

Deriving Business Requirements from Business Architecture

Let’s now take a closer look at requirement mapping within Business Architecture and show how both disciplines can work in pair.

Requirements will usually be linked to a value stage and/or capability. In Figure 4 below extracted from the BIZBOK Guide , let’s take a look at this Value Stream, entitled “Acquire Loan”, made of Value Stages in white.

If you take a closer look on how to «Approve a Loan» in this Value Stream, you need to «Validate an Application» beforehand and «Issue a Second Approval» afterward. When you «Approve a Loan», the additional Routing Map or Process Map occurs with 9 steps in this case. It involves stakeholders like the client, the loan administrator, the loan officer, and the contract officer. It also involves the following information concepts: terms of the loan, loan agreement, and minimal monthly minimal payment of loan. It finally involves the “Agreement Structuring” capability and its children “Agreement Terms Management”, which enables the Value Stage “Approve Loan”.

This finally leads to a User Story which could be as short as this one: “As a Loan Officer, I want to set the terms of the agreement to reduce the monthly minimal payment.”

To avoid confusing anyone, Figure 5 shows how a User story could be written using Business Architecture elements that are made available to Business Analysts by Business Architects and their Business Architecture meta model. The user story is longer, but it includes every necessary element of the business architecture. Some of these elements are Capabilities, Information, Stakeholders, a Process, and Values. The count is 14 elements, but it could have been higher if Figure 5 had included the one or two software application(s) in the Asset map that would need to be modified to fulfill this requirement. Finally, it could also have included specific elements of the Strategy Map.

Impacts of Business Architecture on Business Analysts

As you can see, Business Architecture is not just hype. It can assist the Business Analysts in its daily work as shown in this example. There are at least 4 impacts of Business Architecture on Business Analysts:

Business Architecture enables to build more relevant user stories and business cases using appropriate business strategies and precise vocabulary before they get approved and funded as a project,
Business Architecture enables clearer requirements definition and requirements validation,
Business Architecture enables to scope, frame and categorize requirements based on business strategies, and
Business Architecture avoids requirement duplications across business units and departments.

Article entitled “Business Analysts and Business Architecture” written by Daniel Lambert and published in Business Analyst Times on March 16, 2015.
BABOK® Guide v3 is available here for IIBA members.
Figure 2 is extracted from the LinkedIn article “Increase your Transformation Success Rate with Business Architecture” written by Daniel Lambert published on LinkedIn on April 21, 2015.
Figure 4 in this article is Figure 3.8.3 extracted from the BIZBOK® Guide on page 331. To access the BIZBOK® Guide, you need to become a member of the Business Architecture Guild.

Leadership Lessons: A 7 Phase Methodology – Phase 3 – Understand the Status Quo

Written by Peter de Jager on November 3, 2015. Posted in Articles. 1 Comment on Leadership Lessons: A 7 Phase Methodology – Phase 3 – Understand the Status Quo

Editor’s note: We will be showcasing each phase of Peter de Jager’s methodology in weekly posts. Click here for phase 1 and 2 and check back every Tuesday to read the next phase.

Creating something new, is always an act of destruction. When implementing change you replace the old status quo known to everyone, with a mere vision of a goal in the future. Having respect for the existing Status Quo, builds respect for you.

How long did it take to establish?

Some status quos have been around for only a few months, others for years. The older the status quo, the more likely it will be difficult to remove. The older a status quo, the more it’s been proven as being valid. It’s easier to buy a new car, than it is to buy a new home. It’s not because of the smaller financial cost, it’s because of the larger emotional investment.

What investment/sacrifice did people make to achieve it?

How much have people invested in this status quo? Did they build it on their own time? Was it something that ‘cost’ them personally? The more they’ve invested in the past, the more difficult it will be to move them forward.

How many people subscribe to it?

Is this a corporate-wide ‘status quo’ or is it something that only a handful of people share? Is it a part of the corporate culture or just a local way of doing things? One of the measures of the size of a change is how many people will be affected by it.

What Values does it encompass?

If the status quo is also a part of personal values, or beliefs, then it may pose additional challenges. Example: Getting rid of the corporate Christmas turkey may be more difficult than changing the accounting system, because the turkey connects with ideas of gift giving, Christmas, bonuses and friendship. Culture is supposedly something difficult to identify, if you examine an organization in light of relationships, then culture becomes more visible. It also becomes visible of course… when you inadvertently try to change it.

What mythologies support it?

Each corporation re-enforces its beliefs/status quo through stories. e.g.. Nordstroms and the late night delivery of a customer’s parcel through snow reinforces the concept of a certain level of customer service. If your goal was to change customer service levels, then that particular story would have to be addressed somehow. Even if only because the staff would remember and look to that story for support of the status quo.

Who are the Heroes & Heroines?

Who are the people in the history of the corporation who have become major influencers, even if they are no longer around? What stories are connected to them? What were their beliefs regarding change?