The project trap

This article first appeared in Shift — In The Pocket’s annual report on the next big digital trends. The full report can be downloaded here.

I was recently at a software conference where I heard delegates exchanging war stories about software projects that failed in a major way. There was only one thread that linked all the stories: they all talked about projects, never about products.

As these IT veterans knew full well, that correlation is not a coincidence. Let’s take a look at characteristics that projects typically have in common.

  • Projects are budgeted beforehand, based on some kind of business / functional analysis. After that, the budget is pretty much set in stone, regardless of changing circumstances or other evolutions.
  • They are typically rolled out in big-bang, all-or-nothing releases that have been planned long in advance. There is usually no validation whether the thing that is being built adds any value.
  • Projects are lead by project managers. Their job is to track progress (preferably using Gantt charts). In the project model, nothing is more important than the schedule.
  • They are carried out by project teams — people working together on a temporary basis. Maybe they know each other, maybe they don’t. They do know for sure that their ownership of the project is short-lived (after delivery it’s someone else’s problem). After a project is released, there may be a short period of after-care but when that ends, the project stops. Management then allocates the human resources to a new project.
  • Success is measured on project completion. If the project is delivered on time, on budget (or the project manager can convince the stakeholders that that is the case) then it is declared a success. The side-effects of this mindset often lead to accruing technical debt and poor quality.

The problems with projects seem obvious when they are spelled out in this way. While there is some low-hanging fruit there, not all project problems are easy to fix. Or rather, they are easy to solve but only when the entire organization takes a radically different approach to “projects”. That approach is called the product mindset. When you’re used to the project world view, it can be especially hard to shift towards the product way.

Let’s take that product approach apart and see what needs to happen to fully realize its potential.

Go beyond budgeting: a paradigm shift for finance departments all over the world

Let’s get one thing straight: you cannot fund a product the same way you would fund a project. By locking the budget and mapping it to pre-defined features you take away the team’s ability to adapt as they discover new information.

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.

Budgeting 1.0 also opens the door for people ‘gaming’ the system. Who hasn’t heard stories of managers hoarding budgets and inventing projects just to avoid their department’s budget being decreased? Teams compete over budgets within the organization instead of what they should be doing: competing in the marketplace.

Beyond budgeting proposes an alternative approach. These are its core principles:

Leadership principles

  1. Purpose — Engage and inspire people around bold and noble causes; not around short-term financial targets.
  2. Values — Govern through shared values and sound judgement; not through detailed rules and regulations.
  3. Transparency — Make information open for selfregulation, innovation, learning and control; don’t restrict it.
  4. Organisation — Cultivate a strong sense of belonging and organise around accountable teams; avoid hierarchical control and bureaucracy.
  5. Autonomy — Trust people with freedom to act; don’t punish everyone if someone should abuse it.
  6. Customers — Connect everyone’s work with customer needs; avoid conflicts of interest.

Management processes

  1. Rhythm — Organise management processes dynamically around business rhythms and events; not around the calendar year only.
  2. Targets — Set directional, ambitious and relative goals; avoid fixed and cascaded targets.
  3. Plans and forecasts — Make planning and forecasting lean and unbiased processes; not rigid and political exercises.
  4. Resource allocation — Foster a cost conscious mind-set and make resources available as needed; not through detailed annual budget allocations.
  5. Performance evaluation — Evaluate performance holistically and with peer feedback for learning and development; not based on measurement only and not for rewards only.
  6. Rewards — Reward shared success against competition; not against fixed performance contracts.

Beyond Budgeting is a management philosophy, not a turnkey solution. At In The Pocket we turned these principles into a budgetary governance system that gives our clients insight in what they are spending with us (as well as a means to control that spend).

Every 4 weeks we sit down with each of our clients and forecast what we will deliver in the next period and how much budget is required to get there. In the next steering committee we look back at what we promised in the last meeting and how our delivery compares to that promise. This enables us to work in an agile way without having to ask for blind faith on the part of our customers.

If I’m honest, it wasn’t always easy to convince the more traditional 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.

Change the definition of success

In the traditional project approach business and IT were separate silo’s. The job of business was to come up with ideas for new products. Their plans were then handed over to IT whose job it was to build the requested product ‘on time, on spec and on budget’. Preferably without asking questions.

Putting aside the problem of the development team’s motivation this definition of project success is all wrong. It’s not your spend that matters, it’s the return. If a project comes in on time and on budget, but does nothing to further your business interests, how is that a success?

One of the cornerstones of agile software development is its continuous focus on delivering value. The Lean Startup and MVP principles should be viewed in the same light; 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 than to find out after delivery — the way you would with a traditional project.

When you do run with an idea, the team building it needs to understand what the organization wants to achieve. Based on the mission and vision for that specific part of the business, team and management can agree on a desired outcome and what metrics can be defined to measure that outcome. That way you maximize the outcome, not the output.

Install product teams that are autonomous, cross-functional and stable

Every single adjective in this title is crucial in order to reach high-performing teams in your organization.

Autonomous

Traditional companies look at motivation and performance reviews with a carrot-and-stick approach. Turns out this approach doesn’t work well and can often be harmful.

Dan Pink popularized the science of what motivates people in his book, Drive. The book states that (once basic financial needs are met) people are motivated more by internal factors than by external drivers. Specifically 3 factors:

  • a yearning to get better and better at what they do (mastery)
  • a sense of self-direction (autonomy)
  • the desire to do what we do in the service of something larger than ourselves (purpose)

Motivation aside, digital products exist in highly complex systems. At In The Pocket we believe that self-organizing teams have the best chance at success in these circumstances. Autonomy does not mean that teams are not accountable for what they build. If you measure the success of a product (and you should, see previous section), it’s only logical to take up the results with the team creating the product.

Cross-functional

Although it’s not literally in the agile manifesto, 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.

Of course there are some finer points and trade-offs, especially in enterprise-sized companies with many architectural layers, but these questions are outside the scope of this article.

Stable

Of course teams need fresh blood sometimes but it is important that the team’s lifespan is not too short. When teams know they are in it for the long-haul, they are more likely to make decisions that also benefit the product in the long term. Take technical debt for example; the team has every incentive to get rid of technical debt before it builds up to the potential of making the product unmanageable.

Stability also ties in to the DevOps mantra of “You build it, you run it”, pioneered by Amazon Web Services. In the traditional model developers could throw their code over the wall that separates development and operations, and then forget about it. AWS empowered its teams and made them responsible for the day-to-day operation of their software. As an added bonus, it also brings them into contact with the customer, creating another feedback loop to improve the quality of the product or service.

The product mindset in practice

First a word about the project vs product juxtaposition. I may have given projects a bad rep, but only to illustrate that it is dangerous to forget the distinction between the 2 paths.

There is a time and a place for projects; namely when the thing you are building is relatively small in scope, the requirements are fixed and/or it is important to follow the plan that was set upon (for example a construction site). From a software development perspective the approach goes hand in hand with the Waterfall methodology.

However let’s say you’re building a digital product and you’re not 100% sure how users and the market will respond to it or even what it should like look exactly. In that case you may want to go the product way and try to validate your idea before creating an expensive plan to be followed to the tee.

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 go full product and you should definitely look at agile. The link between products, roadmaps and growth is investigated in more detail in Bram Braat’s excellent article.