Skip to main content

Author: Garnet Masenda

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? 

  1. There were more pressing issues that needed urgent attention
  2. 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.

masendadecemberarticle

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.

Know Your Audience: Don’t let your requirements get lost in translation

In my line of work, we have working sessions between Business system users and IT. In these sessions, the IT people demonstrate innovations that might add value to the business. I recently attended a session where a particular IT team had come up with a way to improve a business process through a system optimization. Due to my little appreciation of technical jargon I got the concept that they were selling and as you guessed, it was a TOTAL DISASTER!!! The business user community was hardly captivated, and they did not buy into the concept. It was tossed out.

Why did the concept fail to gain an audience? Simple answer: Right message, wrong language.

The IT team had a brilliant idea of how to improve a business process but did not know how to deliver the message. Their presentation was full of technical jargon that the business hardly understood. The essence of the solution was lost in translation and was not well received. The IT team forgot about the basics of communication, know your audience. The IT team did not tailor their message to their audience. Had they done so, words such as “xsd” could have become “format”. The art of communication is getting the message across and being heard. Knowing who you are communicating to and how they prefer to receive communication can achieve this.

In order to succeed as a Business Analyst, one must be an effective communicator. We communicate scope, risks, issues, and more importantly, business requirements and needs. The communication required by a Business Analyst is to restate business requirements so that we deliver solutions that address business needs and derive value for our stakeholders. Knowing your recipients of a communication piece is crucial in your quest to deliver the right solutions by understanding that you are on the same page with the consumers of information.

KNOW YOUR AUDIENCE

So how does one get to know the audience? Answer: Do your homework.

Leave no stone unturned in your task to know who is going to receive the message.

Business Analysts can be efficient communicators with stakeholders if they do the following:

1. List your communication objectives

Be clear why you need to communicate. Is it to clarify requirements? Is it to present new ideas? Put down a list of objectives you want to achieve through communication and use this list as a guide when you plan for the communication. The objectives identified will dictate your success criteria.

2. Plan for communication
A plan requires preparation. Always have a plan for communication. You to perform a rigorous stakeholder (audience) analysis exercise so that you know your stakeholders. Stakeholder analysis will answer important questions such as:

  1. Who is going to receive the piece of communication?
  2. How formal must I be in the communication?
  3. What language should I use?
  4. What is the best time to deliver the message?
  5. Which venue suits the delivery of the message?

Answering the questions above will help you formulate a plan and be ready to deliver the message in an appropriate manner.

A tool that I suggest employing for this step is the RACI matrix. It helps identify your stakeholders and determine when, what, and how to communicate to them.

3. Deliver the message

Make sure you know what you are communicating. You need to be an expert. If you are presenting to a group of people, rehearse your presentation beforehand, anticipate questions, and prepare answers. Your tone matters, show passion and belief in your message. The audience will respond to positive energy exuded by showing passion.

4. Measure your communication success

Be mindful of the objectives you have set and measure how well you have fared in achieving them.

There are ways to can gauge how well your message has been received depending on the mechanism employed for the communication

Mechanism Ways to gauge
One-on-one conversation
  • Read the body language
  • Types of questions asked by the other party
  • Contributions of the other party to the conversation
  • Ask questions
Presentation to a group
  • Read the body language
  • Types of questions asked by the audience
  • Contributions by the audience to the subject
Email
  • Pick up the phone and call the recipient(s)
  • Responses to the email

5. Learn from your experiences

This is probably the most important step. Learn, learn, learn and adapt. Please learn. I repeat the word learn because the adage “experience is the best teacher” holds true in this situation. If you have used a particular method of communication that has not worked, please do not use it again. Find a different way to communicate with those types of stakeholders. Tweak everything you do until you find that sweet spot.

I leave you with a favourite quote of mine:

“The basic building block of good communications is the feeling that every human being is unique and of value.” – Unknown

Until next time. Keep well

Don’t forget to leave your comments below.