Business value is a concept that can mean different things to different people. A product manager at one company may value a long list of features that her customers have demanded for months. While the support manager at the same company may value a more stable product to keep the customers, she deals with happy. Business value is a difficult thing to define and indeed deliver. 

A team effort is required to define and deliver business value, with careful consideration needed to ensure all voices are heard. While a lot of what I will be covering in this article is typically the purview of business analysts and product management, I believe that engineering leaders have a critical role to play in this space. Engineering leaders bring software development experience and technical expertise to the table to provide a crucial element to the delivery of business value which I will explain in this article. With that said, let us get started.

What is Business value?

I like to define business value as any improvements to systems, processes or personnel that augments the businesses products or the ability to deliver products or services to their customers, thereby increasing their profit. No two businesses will have the same definition of business value, due to their products and customers being different and requiring different elements to add value. One company may find value in the ability to build out their new product offering quickly. While another may find value in responding to customer support requests from their large customer base. 

Due to the rapidly changing world we live in, the things that businesses value changes often. Companies often face new challenges that require a quick response; these challenges can come in the form of new software features released by competitors, or indeed rapid-fire changes in society that render the current products obsolete. Business needs or desires, therefore change just as quickly. 

Have you ever worked for a business that comes to the engineering team with new requirements, seemingly daily? It is not because they cannot make up their mind; it is in response to the changing business needs. This fluidity is one of the main reasons that Agile development practices have taken precedence from more traditional waterfall methodologies for software development. 

Why is business value important? 

Responding to change and delivering business value with haste is a crucial area of importance for modern businesses. All companies exist for a purpose. The majority of companies exist to return a profit for their owners (individuals or shareholders), while some companies exist to provide a social service. The critical thing to note is that they all exist to fulfil a specific purpose which guides their definition of business value. 

No matter the company large or small, if they stop innovating, and their products or services stop being relevant to society, that company will whiter and eventually die. Kodak is a prime example of this occurring in recent history. In today’s world, IT, whether it be hardware or software, is the largest driver of business value. It is therefore critical that the software engineering teams keep delivering the things that the business need to fuel their innovation.

We, as software engineers, are not employed to fill up our resumes with the latest technologies, but to deliver our contribution in support of the business purpose. 

The importance of engineering leadership

With software these days, forming a critical part of business value, the role of the engineering leader is more important than ever. Engineering leaders create the team and cultivate the culture that delivers great software. Engineering leaders trusted advisors to the business that take their creative ideas and convert these into instructions that can be understood and implemented by the engineering team, as such they provide a conduit between the business and engineering. 

Engineering leaders also provide advice and guidance around the possibilities and limitations of the technology they are working with, and where needed, provide a way forward for the business. 

How do we deliver business value?

So how do we go about delivering business value? Business value isn’t created by a soloist delivering a virtuoso performance, but a collaboration of the business and engineering teams working together to realise a shared vision. 

Below are the five ways this can take place; together, these provide a roadmap for delivering business value; these are:

• Define systems development strategy
• Help business define requirements 
• Visualise the work and prioritise
• Schedule and communicate delivery
• Deliver value often and get feedback

Let us now step through each of these one at a time and dig into a little more detail.

1). Define systems development strategy 

The first thing I like to do when starting to work with a new company is to understand their systems development strategy. At a high level, the systems development strategy details the state of their current systems, the high-level business strategy for the next 5+ years and maps out a plan to get there. An engineering leader will drive the creation and implementation of the development strategy to ensure the business can meet their current and future needs. Working closely with system architects and technical leads, the engineering leader can formulate a solid development strategy. 

The development strategy could mandate in house development or vendor-based solutions. The development strategy should detail the core architecture direction and technologies for the systems, including high-level plans for delivery. The development strategy underpins all efforts to deliver business value. Without a firm foundation of proper system architecture and technology, the business will have a difficult time delivering the value they need to survive. 

If the business doesn’t have a development strategy or similar document, the following is a great place to start:

• Gather business needs: Gather high-level business needs/strategy to cater for the now and future (5+ years) horizon. Not a deep dive, but deep enough to judge existing systems and measure other options. 
• Review of existing systems: Analysis of current systems around fit for purpose and whether it can be maintained and extended to meet the future needs uncovered in the above.
• Technologies / Architecture: Based on the review of the first two bullet points, we look to recommend a strategic direction. The decision here could range from replacing the entire system with a cloud solution, to replacing parts of the system with off the shelf software. Conversely, we may find the existing system is a strong foundation which needs modernising. In which case, the development strategy document would detail a range of architectural and technologies for future development. 

The above is a good starting point and will allow the business to get started implementing the development strategy. At the end of this exercise, we have performed an extensive analysis of the current systems and have a strategic direction for our systems.

2). Help the business define requirements

It is essential to understand what needs to be delivered before we can go ahead and deliver, well anything. It has been my experience that on occasion, the business themselves are not entirely clear on what is required. 

When the business has a lot of ideas for improvements, they can sometimes get muddled together and lost. To counter this, I like to visualise the entire scope of these ideas using User Story Maps. User story maps are visual representations of functionality requirements where all the requirements documented using a system of cards. User story maps are typically arranged on a wall/floor and provide a visual representation of all the requirements. It becomes a more straightforward (not easy) task to slice and dice these requirements using a story map to cull anything that is not critical to the business. 

For the remaining requirements, we need to gather a little more information to progress to the next step, for each requirement we need to capture:

• Description: High-level description of the change. Not an essay but enough to provide a high-level order of magnitude estimate.
• Business benefits: Here we are looking to understand what benefits we can expect from the business change. 
• High-Level estimate: Order of magnitude level estimate, lots of refinement to still take place, however, gives us a good idea around sizing.
• Business SME and Sponsor: Details of people we can go to get more information.

The detail we capture for each of these changes is small, the reason being these items are a wish list only and not confirmed, so we do not want to waste more time on these then we need (lean thinking). While it is the domain of product managers and business analysts to flesh out business requirements and benefit statements, the engineering leader also plays an essential part in this process. Engineering leaders can use their experience to provide the high-level estimates for development, or indeed recommend ways to implement the requirement without the need to cut code (yes it does happen). 

Another area where engineering leaders should influence is ensuring and non-functional (technical strategy items or technical debt) is included for development prioritisation. These technical plumbing is not attractive to the business but could be critical for the business to achieve their long term goals. Engineering leaders are the people that need to fight to ensure they are on the table.

A final word on requirements, where possible, try to group requirements where they affect the same code or system module. Grouping requirements will assist us in prioritisation. The last thing we need to do is storing these requirements in our product backlog, to be reviewed and prioritised by the business in our next step.

3) Visualise the work and prioritise

In our third step, we are getting closer to the business deciding on their valuable items. Taking our list of requirements from our product backlog, we now present these to the business to discuss and rank in order of importance. Having an extensive list of items to visualise enables the business to understand that they cannot have everything, and they need to select the items that will make the most significant difference to their business (i.e., highest business value). 

A business analyst or product manager typically runs these planning and prioritisation meetings. However, the engineering leader also has a place at the table to provide insight and assistance to the businesses decision-making process. Who from the business should attend these meetings? It is essential to gather a broad cross-section of business stakeholders for every department or directorate that uses the software package(s) in question. We don’t want one department having too much influence that may not be of benefit to the business. 

The meeting will have the following schedule:

• Review items: The group will discuss each item in the (curated) product backlog in an open and honest discussion. 
• Accept or reject: The item will be approved for development or rejected. Rejected items will have their requestor notified, to ensure they are in the loop. 
• Ranking: Approved items get added to the backlog in priority order. 

I like to have the backlog in excel, which I distribute at least a week before the meeting to ensure folks have enough time to review, ask any questions before the meeting to ensure a smooth meeting. During the meeting, we view the excel sheet, top to bottom taking notes where required. At the end of this meeting, we have something special. We have a prioritised list of business value.  

The prioritisation meeting can be held quarterly or monthly, depending on the speed of change in your business. I like to settle on a quarterly cycle to meet with the business as not to overload these folks from actually getting their work done. 

If the business has urgent changes which require attention, a break glass mechanism can be built-in where a meeting can occur to review and approve changes to the delivery schedule. 

4) Schedule and communicate delivery

In the fourth step, we now have a list that ranks all the business requirements in priority order. We now have confidence that the business indeed wants these work items completed and the order they prefer. The engineering team can now spend time working out how to deliver these items. Remembering from step two, we gathered very high-level requirements, (so not to waste time before they were endorsed), we now need to finish fleshing these items out enough to commence delivery. 

There are a few mechanisms we can use to gather the information we need to get going, and the main one I like is the work or project inception. The inception is a process where we get the delivery team together to discuss the work that needs to be delivered. Inceptions can run anywhere up to a few weeks for big projects; it depends on how much time you allow here. During our inception, the delivery team all get on the same page with the requirements in question and can ask questions of each other or the business to get all the information they need. 

Technical delivery decisions can also be made, including creating simple prototypes to test out delivery options. Once the inception is complete, the delivery team have all their information, more confident delivery estimates are possible, sprint planning can take place, and the overall delivery schedule is known.

From here, the final step is the communication of the delivery schedule to all relevant stakeholders. Ensuring people can ask questions or point out any problems they see with this schedule. 

5) Deliver value often get feedback

The final step here is to get the job done. The best way to deliver software is in small chunks completed during our sprints (typically two-week blocks). Sprints are the quickest way to deliver business value, allowing the business to gradually use this value much quicker than waiting for a monolithic release to occur. 

At the end of each sprint, the team should be running product showcase events. A product showcase allows the engineering team to show off their excellent work to the business, who have an opportunity to provide their feedback on the software. This feedback loop is another mechanism to ensure we are hitting the mark in terms of the delivery of business value.

Conclusion

I hope you enjoyed reading this article. The key to delivering business value is having close relationships with the business stakeholders, ensuring that they are involved in each step of the process. The business stakeholders are the only folks that can define business value. However, it is the role of engineering leaders to ensure proper technical oversight takes place to ensure the timely delivery of business value.