Effective product delivery is a constant challenge in today's dynamic business world. Whether embracing agile methodologies, implementing DevOps practices, or following traditional project management approaches, one common thread runs through them all: the need to manage risk. Contingency planning is a pivotal element in risk management, and understanding the distinction between real and perceived risks is crucial for success. In this article, we'll delve into the world of product delivery, risk assessment, and the importance of addressing risks early to ensure the smooth execution of your initiatives. 

Real Risks vs. Perceived Risks

Distinguishing between the two is fundamental for effective risk management. 

Real Risks are those that pose a tangible and quantifiable threat to your success. These risks can potentially disrupt timelines, budgets, or overall project objectives. For instance, if a critical feature is not delivered on time, it may lead to the loss of a customer to a competit...

In the business world, it's not uncommon to see reports and metrics that indicate smooth and successful operations. However, such metrics can be misleading at times. Even though everything seems fine at the surface, a closer inspection may reveal underlying issues, inefficiencies, and employee dissatisfaction. These are commonly known as the "watermelon metrics."

Causes of Watermelon Metrics

Human beings have a natural inclination towards optimism and tend to exhibit a desire for positive outcomes, but besides this, there are other reasons why we fall into the watermelon metric trap.

1. Not measuring the right thing:

One of the reasons why data analysis can be misleading is when organizations measure the wrong things. While the data may seem comprehensive, it might not provide the complete picture. This often happens when companies focus on irrelevant metrics or only quantitative data, ignoring the qualitative aspects. For example, if you track the volume of tasks completed instead of the ...

With today’s rapidly changing business environment, every organization seeks to improve its business agility. While it is common to start a digital transformation program to achieve this, about 70% of IT / digital transformation projects fail, approximately 45% are late, and 25% get canceled! Let’s discuss possible causes and ways to get them back on track.

When talking about agile practices, the distinction between projects and products often comes up. The idea is that the limited lifespan of projects tends to be pushed onto the delivery team, which leads to the team being assembled at the onset and dismantled when the project completes. Agile practitioners advocate for a product view, where teams are dedicated to a specific product and deliver incremental value at a regular cadence, across initiative lifespans. This usually works really well, and I too favour a similar way of working in most cases. However, I have recently seen various examples of this idea being misinterpreted, which creates a situation in which teams struggle, largely due to their setup.

It’s one of those words that come back over and over again in context of modern delivery approaches and organizational structures. The word seems common enough to mean approximately the same in people’s minds, however I have found that it is often confused for something else. According to Merriamm-Webster, autonomy is the quality or state of being self-governing. This distinguishes it from the term empowerment, which is the state of being empowered to do something. In other words, autonomy is an internal property - it comes from within -, while empowerment comes from someone’s approval.

Autonomous teams make their own decisions, they do it based on their objectives and all the relevant information they have available about the world around them. Empowered teams also are told to do exactly that. However, the scope of their decision making power - sometimes explicit, more often implicit - limits their autonomy significantly and can even shrink should a decision be made that does not align...

Almost daily I receive at least one phone call from some agency wanting to sell their website building services, triggered by domain registrar information. I have developed a way to quickly get to the point and waste less than 30 seconds of my or the caller's time. I understand the caller is doing their job, I try to do mine. All is professional and we can both go on with our work.

Just this morning though, I was triggered... As I pick up the phone, I was greeted by "Can I speak to the business owner over there?", in a way that clearly demonstrated disdain for those picking up the phone. I could only respond "Over there?" and annoyed I put the phone down. No opportunity to quickly align on the purpose of the call, share our expectations and go on with our day. No opportunity for the caller to learn and improve. Definitely no opportunity for this company to ever sell any service to us.

First impressions rarely make a relationship, but they can definitely break one.

Relationships are built...