Projects to Products. Why?

project to product

In the agile world, we love products, and the general perception is that we dislike projects.

So, why is that? Why would an organisation want to transform from projects to a product focus.

Organisational Tax

First, organisations that run projects or project-based organisations generally carry a large organisational tax.

We need extra roles, we need processes, and we need policies that support various projects. We also need reports and project management update meetings to make sure that we are on track.

On a project, what we are trying to do is get from point A to point B. And we are trying to do that within a pre-determined period and budget.

Projects worked brilliantly when things were simple and straightforward.

It becomes much more difficult to manage when you enter complex situations and environments because there are so many variables and many of them are unknown, unpredictable, and volatile.

So, I always recommend that if you do work in a simple or complicated environment and you can plan long-range because all the variables are known, go with traditional style project management.

Because all the variables are known and you can fix a budget, a pre-determined scope for the project, and specify who needs to do what at what stage of the project.

Great, it works.

It has done for the past century and if you aren’t working in a complex space solving complex problems, it will probably do just fine.

Traditional waterfall style project management makes you predictable, allows everyone to see the whole plan upfront and track your progress against benchmarks and milestones along the way.

You’re going to be a winner. You’re going to get the promotion. Things will run smoothly.

Unfortunately, for many organisations, projects simply don’t help.

Complexity

The reason for this is because there are a myriad of unknown variables and things inevitably change. In essence, we need to learn as we move along the path of product development, and we need to inspect and adapt based on what we learn real-time.

We simply cannot know what we don’t know upfront, and we can’t pretend that unknown variables will not impact the products we develop and the markets we serve.

Because we learn as we go, it’s important that we make new informed decisions based on data and evidence. We learn in our own specific context, and we make decisions accordingly.

We don’t want to be constrained by some arbitrary timeline. Instead, we want to learn real-time and adapt based on the data and evidence of what we have learned.

We don’t want to be funded based on some arbitrary timeline. Instead, we want to invest money, time, and effort based on what the most valuable work is and what will deliver the highest return on our investment.

We don’t want huge upfront organisational tax in the form of structure, policies, processes, and rules; constraining our ability to change direction even if we know it’s the right thing to do.

This is why when we take a more product-based view, people find it more amenable to an Agile style of working that builds on the foundation of frequent inspection and adaption.

The difference between Agile and Waterfall Project Management

It means that whilst we may have a long-term roadmap split into various chunks of work, we’re not going to be forecasting that at a certain, predetermined stage the product will be finished.

What it does mean is that we can keep funding product development, we can keep developing hypotheses and running experiments to prove or disprove those hypotheses, and that we can take risks that empower us to develop the most valuable product that delights customers and stakeholders.

In other words, we keep investing real-time in product development to discover what features and new product developments are going to deliver the greatest returns on investment.

In traditional project management, the scope is determined upfront and the person doing the guesswork is largely blind. They simply cannot know upfront that which is unknown, and they are taking a great risk by putting huge upfront investment into a project or product that may or may not resonate with customers.

In essence, betting the farm that their idea will work months or years down the line.

The benefits of Agile

In agile environments, we like products because the #agile frameworks we use, whether that be #LeSS (Large Scale Scrum) or #scrum, are generally built around this idea of product development rather than project-based timelines and scope.

It enables us to have teams that are working on developing a product. We have teams that are working on specific features that increase the value of the product. And we have teams that are working closely with product owners and stakeholders to make sure that every item of work that we produce aligns with a customer value or a problem that a customer is trying to solve.

As the team works closely with customers, product owners, and product stakeholders, they develop real empathy for the end-user or consumer, and they are able to make better decisions based on what they have learned from those engagements and interactions.

In a project management environment, you work on the project from point A to point B and then it’s done. The team move onto something else.

In a product development environment, the team start to focus on quality because the product is never ‘finished’ and as the complexity of their environment evolves, they inspect and adapt based on what is learned and what is working.

The team also focus on maintainability and eliminate technical debt from poor craftsmanship.

Because they are working on the same product for an extended period of time, the team want the system and the product to be easy to fix, adapt, and maintain. It breeds technical excellence and ensures that the team are always working to the highest possible standard on the product.

So, working in an agile environment is great for both organisations and teams. It affords us heaps of benefits and empowers us to do the most valuable work, at the most valuable time.

We’ve come a long way over the past century of work and it isn’t always a case of choosing one style of working over another. Sometimes, we work in both ways at the same time within the same organisation.

Some things are better suited to traditional waterfall-style project management and other things are better suited to scrum and other agile frameworks.

Projects are traditionally short-term focused, and they place a great deal of constraints on the teams that work on those projects. They are also traditionally very expensive and carry a great deal of risk.

Products are traditionally long-term focused, and they unleash a team’s creativity, passion, and potential. They empower us to work on items that deliver the highest returns on investment and help to minimize risk through frequent inspection and adaption.

If you like the idea of #LeSS (Large Scale Scrum) and want to become a practitioner, visit our Certified LeSS Practitioner course page for course dates and promotions.

If you are thinking of adopting #LeSS as an agile framework in your organisation, visit our services page to explore how our consulting, coaching and mentoring services can assist you.

If you want to explore #agilecoaching as a potential career opportunity, visit our IC Agile Certified Agile Team Coaching course page to find out more about the course and how it can help you create new opportunities for yourself.

To keep a finger on the pulse of all things #LeSS, join our LeSS Matters community on LinkedIn.

 

 

 

 

 

More from our blog