Is your software project doomed to fail?
Recently, I attended a software conference where I heard delegates exchange war stories about software projects that failed miserably. There was only one thread that linked all the stories: they all talked about projects, never about products. That's not a coincidence.
Working and thinking agile is the key to success these days. The product mindset plays an important part in the agile method. If you want to escape the project trap, it's time to get into that product mindset.
Let’s take a look at characteristics that projects typically have in common:
- Projects are budgeted beforehand. After that, the budget is pretty much set in stone, regardless of changing circumstances.
- They are typically rolled out in all-or-nothing releases that have been planned long in advance.
- Projects are led by project managers. Their job is to track progress and nothing is more important than the schedule.
- They are carried out by project teams . Their ownership of the project is short-lived.
- Success is measured on project completion. If the project is delivered on time and on budget, it is declared a success.
The problems with projects seem obvious when they are spelled out in this way. Luckily, they are easy to solve, but only when the entire organisation takes a radically different approach to projects. That approach is called the product mindset.
So how do you get into the product mindset? Let’s take this approach apart and see what needs to happen to fully realise its potential.
1. Go beyond budgeting
It all starts with budgeting. You can't fund a product the same way you would fund a project.
Beyond budgeting is an international movement that wants to replace the traditional budgetary control system with a more adaptive process.
The traditional system with fixed, yearly budgets has many disadvantages. Other than being inherently change-averse, it comes with a lot of overhead and bureaucracy. It also opens the door for people ‘gaming’ the system. This results in teams competing over budgets instead of competing in the marketplace.
With beyond budgeting, we can work in an agile way without having to ask our clients for blind faith.
At In The Pocket use a budgetary governance system that gives our clients insight in what they are spending with us. Every 4 weeks we meet with the client and we forecast what we'll deliver and how much budget is required. In the next steering committee we look back at what we promised and how our delivery compares to that promise. This way, we can work in an agile way without having to ask for blind faith.
It can be hard to convince management and finance departments to abandon yearly budgets. Usually the trick is to demonstrate the value of the Beyond Budgeting approach on a small scale first.
2. Change the definition of success
It’s not your spend that matters, it’s the return. One of the cornerstones of agile software development is its continuous focus on delivering value instead of delivering on time and on budget. If a project comes in on time and on budget, but it doesn't create progress in your business interests, how is that a success?
Don't maximise the output. Maximise the outcome.
Take an idea and validate it as soon as possible. If it turns out to be a bad idea, it’s better to kill it early on than to find out after delivery . When you do run with an idea, the team building it needs to understand what the organisation wants to achieve. Team and management can agree on a desired outcome. That way you maximise the outcome, not the output.
3. Create a solid product team
Thirdly, the product mindset calls for autonomous, cross-functional and stable teams.
Dan Pink popularised the science of what motivates people in his book, Drive. The book states that people are motivated by 3 internal factors:
- Autonomy: self-direction
- Mastery: getting better at what you do
- Purpose: doing what we do in the service of something larger than ourselves
Traditional companies look at motivation with a carrot-and-stick approach. In this project-based approach, managers divide all projects top-down to different teams. This results in less focused and less motivated teams. At In The Pocket, we believe that autonomous, self-organising teams have the best chance at success. Our teams are still accountable for what they build though.
You can’t do agile software development without cross-functional teams. It’s also a prerequisite for autonomy. There can be no self-direction if a team can’t carry the product to the finish line on their own.
The project mindset has a rough start and end date. The team’s lifespan should not be too short though, which is one of the advantages of the product approach. When teams know that they are in it for the long-haul, they're more likely to make decisions that benefit the product in the long term.
Choose the right mindset for your situation
I may have given projects a bad rep, but only to illustrate that it's dangerous to forget the distinction between the 2 paths.
There is a time and a place for projects when:
- The thing you are building is small in scope.
- Requirements are fixed.
- It is important to follow the plan that was set upon.
Let’s say you’re building a digital product. You don't know exactly what it should look like or you’re not 100% sure how users/the market will respond. In that case, you may want to go the product way. This way, your budget is much more flexible. You can focus on the results without worrying about the details. In addition, the team can keep on working and adapting to the customer's needs.
Think of it this way: is the thing you are building something static? Or should it live and grow? If it’s growth you’re after, you should definitely go for the agile way and get into the product mindset.