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.

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.