Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles How Developers Can Learn the Language of Business Stakeholders

How Developers Can Learn the Language of Business Stakeholders

Leia em Português

Key Takeaways

  • Different people use different sets of words and meanings - be mindful of them.
  • Impediments and blockers are bread and butter for everyone - not only product developers.
  • Individual and team learning is crucial for your products too.  
  • When your project is stuck in a dead end - don’t panic, but try to apply real options.  
  • Be risk aware and learn how to deal with it in ways other than using only a “Risk log”.  

For over 15 years I have been interested in what we call "the magic of words and language". It is strictly related to how people throughout history have communicated with each other, and how true communication intentions have been distorted by words getting lost in translation. Now, when I have to move fluidly between business stakeholders and developers, I see even more often how spoken or written messages can be misleading, if we understanding through incorrect filters.

What is the easiest way to learn foreign languages? Talk to people who speak them. This rule is also applicable to us - cooperating and communicating within the project environment, but staying in separated clusters (like a developer team or operations) on a daily basis. 

If we look at different groups taking part in the software development process, we might easily see that they communicate on different levels in terms of language, using different "dictionaries" - sets of words, meanings and sentences - making it difficult to understand each other.

What I cover in this article is a sneak peak at the areas where I have observed the most tension: talking about impediments and blockers, individual and team learning, real options, and risk management.

Impediments and Blockers

Business stakeholders recognize blockers just as we developers do, i.e bottleneck issues, and work to address them; what we need to do is give these items monetary value. If they materially affect the financial position of a company at the end of the reporting cycle, we have to recognize them in financial statements. It’s not enough to just say, "We are blocked, do something". To allow business stakeholders to correct and efficiently prioritize issues, we should support their decision-making process with information that will help in monetizing problems. What part of the work is blocked and for how long? How does it affect delivery time? Is there any unexpected developer idle time? What other items in the queue are dependent on the blocked one? This kind of information will support not only the project manager, but most of all the budget owners, in making good decisions.

What is important from a business stakeholder’s perspective is an understanding of the problems you have as developers. That’s why I try to provide stakeholders with parallel situations they can accept and easily relate to. Do you have a problem with increasing work in progress? Relate it to inventory management, or assets under construction. Does your project seem to create technical debt? Comparite it to out-of-fashion bikes in your warehouse, or a necessary loan repayment.

You can read more about inventory accounting for product developers in the article Bikes, bananas and work in progress

Arranging a Budget and Planning Time for Teams to Learn 

I will start with something obvious, yet much forgotten: if we optimize our process for busyness and working at full capacity, we never leave time for a team’s active learning. I use the word "active" intentionally, because passive learning is something that happens to us when we repeat the same set of tasks, a well-known phenomenon that was studied in the 19th century. However, this applies mostly to manufacturing.

In knowledge-based work, which is our domain, making time for learning is crucial and is similar to finding time for improvement.

Of course, it does not mean that we should go to the team and say, "From now on, between 2:00 and 3:00 PM, you will learn and improve." Rather, it is about giving people space, comfort and the safety to say, "Now I will learn. Now I will read. Now I will do the work which will help us later on"; to give them the confidence of knowing that if they are idle, they can use the time for self-development, which is never a lost investment. But each project, in order to be sustainable, has to give its members space for learning and improving - which then becomes part of regular project budgeting (until it can be directly connected to project goals).

When you are budgeting a project, the learning part falls under the category of research expenses, and it shouldn’t be capitalized but always written off. That’s why you don’t need to account for it or track it separately. However, you may be doing this in your project reporting, based on the level of detail that is your stakeholders require.

The Benefits of Individual and Team Learning

Let’s start with the statement that knowledge work is a constant learning process. At any given moment in a project, we perform using the best of our knowledge. But we should never, and we do not ever, stop learning. When I design the workflow with a team, one of the basic questions is, "What are the learning phases?" not,"What are the steps in the process?" or, "Which phase precedes this one?" We focus purely on learning.

What I show to my projects’ stakeholders is discovered work vs. anticipated work, through continuous transparent visualizing what we had planned when the project started, and what we found out during analysis and development. This helps them to understand how we progress with regard to the budget and timing, and how we make decisions on what we continue to develop and what is less of a priority at any given point in the project. 

Business stakeholders are not your enemies; once they have enough sound information on where we are and what we expect to happen shortly, they are willing to accept reasonable requests or decisions - even additional learning time which team members may require.  

What you can do is approach the opportunities for learning using the learning curve effect. Although this is something we should not avoid, I often see this element being skipped over when planning a project or forecasting work. We tend to translate the metrics and statistics from the stable state to the initial phases, when the team is still formulating. Similarly, this applies to the new person in a role, who needs to learn not only her place in the project, but very often new responsibilities.

Let’s keep this in mind when planning work or identifying impediments. You can read more on the learning curve effect in a separate article I wrote on the topic, Never stop learning – why is learning curve effect so powerful?

Real Options

The InfoQ article "Real Options" Underlie Agile Practices explores how we can use real options for deferring decisions to the last possible moment. I would like to clarify one thing here: what is referred to as a "Real Option" in the article is, based on the Black-Scholes model, which is the method for options valuation but does not cover actually what real options are.

What we recognize in financial management as real options are alternatives for project or business investment. And you actually have four options to consider in your projects: the option to delay, the option to expand, the option to abandon or withdraw, and the option to redeploy.

I will skip over the option to delay, as it is covered in depth in the article.

The option to expand exists when a company has the possibility of making further investments that increase the net present value of a project (which originally maybe did not seem worth undertaking).

The option to abandon (or withdraw) is actually the option to close down the project during its lifetime, as continuing working on it is no longer financially justified. From my personal experience, this option is the most difficult to put to life, considering both sunk costs and the psychological aspect of the whole decision.

The final one is the option to redeploy, which is when a company decides, instead of abandoning the current project, to use the outcome of the project for another one. It is not always possible, hence cannot be taken for granted, but having this option minimizes the sense of loss that would result from a project closure.

Each of these options requires careful analysis of project cash flows and stakeholder decisions based on financial projections. Say, if you choose the option of delaying over abandoning, you need to ensure that the project NPV (net present value) is either still positive or will be positive after the course change. Any decision that affects NPV negatively would be rejected by business stakeholders and sponsors.

Risk and Uncertainty Management in Accounting

Let’s start with the differentiation which we usually experience between risk and uncertainty. Risk is something that may or may not occur, but we are able to statistically calculate its probability or frequency - based on past records. Uncertain events are those which we cannot predict with statistical confidence.

To deal with uncertainty, we do market research that aims to minimize it. We can use surveys, gather feedback and perform retrospectives.

Risk management, based on data, gives a much broader range of possibilities. The most common one is using expected values, which focus on the probability of outcomes. The next one is sensitivity analysis, which can be used when we can establish dependencies between the key variables in the project. It usually involves changing one key variable to observe how the others behave. Let’s imagine that we are asked by stakeholders what the impact of moving one of our developers to another project is. We should treat this developer as a "key variable" and analyse his impact on other variables. E.g. one developer less means decreasing the total cost, but increasing time to delivery. Another possible change is to the team’s learning curve when the person leaves, likely affecting project budget. Once all of these dependent variables have been connected and analyzed, we can make a decision whether this scenario is acceptable from our project perspective. What additionally supports us in these cases are real options - and this is how all of these concepts play together. 

Probably very well-known to developers are different kinds of simulation, including Monte Carlo simulation, to better understand the impact of a risk to the project. It relies on a huge number of data and can be used to analyze more variables at the same moment. What’s important for Monte Carlo method is the randomness of input data to generate more reliable probability distribution. Because this method gathers a lot of data points, it is more reliable in assessing probability than for example sensitivity analysis, which is only from the perspective of one variable.

And talking about impact, you can use the "impact-probability" (or "severity-frequency") matrix with four options for project risk: accept, transfer, control/reduce or abandon/avoid.

Finally, what is maybe not directly laid out by the data analysis but worth considering, are the types of stakeholders you deal with. People typically fall into one of three categories: risk seekers, risk neutral, or risk averse. It is important to keep in mind what type of personality your stakeholders represent. It’s worth being aware of this classification of people’s risk types not only when discussing project risks, but also when trying to persuade someone of a new idea or when building a business case. Whilst no one is probably really thinking about personal risk preference, it is something that is relevant to most of us all the time.

Even talking about rough areas like accounting or product development, there are still people behind these processes. Communication is the key to understanding your peers and customers; frequent communication helps to leverage extensive knowledge on both sides, and all of us can either contribute to this understanding, or at least learn something that enriches us as human beings.

About the Author

Anna Radzikowska, ACCA, KMP, product owner and project manager. "I have over 10 years of experience in finance, training and project management, working in the public sector, big companies and running my own business. Currently, I am the leader of the product support team and product owner of RPA solutions in the finance sector. Being a Kanban Management Professional and ACCA (Association of Chartered Certified Accountants) member helps me to combine theoretical knowledge and project work, with its practical application in daily activities, resulting in continuous support, training and improvements even after the project ends."

Rate this Article