How to choose the right project? Decision making frameworks for software organizations

Frameworks to choose the best projects in organizations are a dime a dozen.

We have our NPV (net present value), we have our customized Criteria Matrix, we have Strategic alignment, we have Risk/Value scoring, and the list goes on and on.

In every organization there will a preference for one of these or similar methods to choose where to invest people’s precious time and money.

Are all these frameworks good? No, but they aren’t bad either. They all have some potential positive impact, at least when it comes to reflection. They help executive teams reflect on where they want to take their organizations, and how each potential project will help (or hinder) those objectives.

So far, so good.

“Everybody’s got a plan, until they get punched in the face” ~Tyson

Surviving wrong decisions made with perfect data

However, reality is seldom as structured and predictable as the plans make it out to be. Despite the obvious value that the frameworks above have for decision making, they can’t be perfect because they lack one crucial aspect of reality: feedback.

Models lack on critical property of reality: feedback.

As soon as we start executing a particular project, we have chosen a path and have made allocation of people’s time and money. That, in turn, sets in motion a series of other decisions: we may hire some people, we may subcontract part of the project, etc.

All of these subsequent decisions will have even further impacts as the projects go on, and they may lead to even more decisions being made. Each of these decisions will also have an impact on the outcome of the chosen projects, as well as on other sub-decisions for each project. Perhaps the simplest example being the conflicts that arise from certain tasks for different projects having to be executed by the same people (shared skills or knowledge).

And at this point we have to ask: even assuming that we had perfect data when we chose the project based on one of the frameworks above, how do we make sure that we are still working on the most important and valuable projects for our organization?

Independently from the decisions made in the past, how do we ensure we are working on the most important work today?

The feedback bytes back

This illustrates one of the most common problems with decision making frameworks: their static nature. They are about making decisions "now", not "continuously". Decision making frameworks are great at the time when you need to make a decision, but once the wheels are in motion, you will need to adapt. You will need to understand and harness the feedback of your decisions and change what is needed to make sure you are still focusing on the most valuable work for your organization.

All decision frameworks have one critical shortcoming: they are static by design.

How do we improve decision making after the fact?

First, we must understand that any work that is “in flight” (aka in progress) in IT projects has a value of zero, i.e., in IT projects no work has value until it is in use by someone, somewhere. And at that point it has both value (the benefit) and cost (how much we spend maintaining that functionality).

This dynamic means that even if you have chosen the right project to start with, you have to make sure that you can stop any project, at any time. Otherwise you will have committed to invest more time and more money (by making irreversible “big bang” decisions) into projects that may prove to be much less valuable than you expected when you started them. This phenomenon of continuing to invest beyond the project benefit/cost trade-off point is known as Sunk Cost Fallacy and is a very common problem in software organizations: because reversing a decision made using a trustworthy process is very difficult, both practically (stop project = loose all value) and due to bureaucracy (how do we prove that the decision to stop is better than the decision to start the project?)

Can we treat the Sunk Cost Fallacy syndrome?

While using the decision frameworks listed above (or others), don’t forget that the most important decision you can make is to keep your options open in a way that allows you to stop work on projects that prove less valuable than expected, and to invest more in projects that prove more valuable than expected.

In my own practice this is one of the reasons why I focus on one of the #NoEstimates rules: Always know what is the most valuable thing to work on, and work only on that.

So my suggestion is: even when you score projects and make decisions on those scores, always keep in mind that you may be wrong. So, invest in small increments into the projects you believe are valuable, but be ready to reassess and stop investing if those projects prove less valuable than other projects that will become relevant later on.

The #NoEstimates approach I use allows me to do this at three levels:

• a) Portfolio level: by reviewing constant progress in each project and assess value delivered. As well as constantly preparing to stop each project by releasing regularly to a production-like environment. Portfolio flexibility.
• b) Project level: by separating each piece of value (User Story or Feature) into an independent work package that can be delivered independently from all other project work. Scope flexibility.
• c) User Story / Feature level: by keeping User Stories and Features as small as possible (1 day for User Stories, 1-2 weeks for Features), and releasing them independently at fixed time intervals. Work item flexibility

Do you want to know more about adaptive decision frameworks? Woody Zuill and myself will be hosting a workshop in Helsinki to present our #NoEstimates ideas and to discuss decision making frameworks for software projects that build on our #NoEstimates work.

You can sign up here. But before you do, email me and get a special discount code.

If you manage software organizations and projects, there will be other interesting workshops for you in the same days. For example, the #MobProgramming workshop where Woody Zuill shows you how he has been able to help his teams significantly improve their well-being and performance. #MobProgramming may well be a breakthrough in Agile management.

Picture credit: John Hammink, follow him on twitter

Waterfall in a Scrum world, yes it is possible. See how below

Can you do waterfall at the same time you are doing Scrum? Let's explore the subject a bit...

We all know what problems there are with waterfall and long term plans that are not changed. We start executing the plans and see that things don't really work out as we thought but we stick to the original plan anyway just delaying the project but trying to deliver the same scope we agreed to.

This has a knock-on effect on the subsequent projects (there's never only one project), and other projects get delayed, but not changed because that would require changing the plans (portfolio, roadmap, strategy you name it!) and the chain goes on, ad infinitum...

The fact is that any plan that is not changed based on what we learn during the project will have the same effect that a waterfall plan has: delay later projects and provide no visibility when the projects will be completed.

So, here's the problem. Many teams and companies are doing Scrum. They have their Sprints, their Sprint plans and they change the overall scope to meet the deadlines. They may even be releasing those projects on time. But there's something more macabre at play here. Despite being able to release projects on time these teams and companies are still riddled with problems: overtime, being late in some (but not all) projects, not being able to react fast to customer requests such as support requests, fix requests, etc.

How come? What's the problem? Well, the fact is that for Scrum (or any other Agile method) to work you need to really have plans that change. It is not enough to have team-level or single-project plans that change, you need to have the whole R&D, the whole company understand that portfolio plans, roadmaps also need to change!

Imagine this. Your team is working on one project and delivering on time, but, without your knowledge, someone in the company has agreed a roadmap that actually requires that your team start working on another project before you finish the current one. Obviously they never thought to ask you your opinion and your project manager even agreed to it, albeit many months ago.
The consequence: your resource plans are now fixed! Your company booked their R&D 100% without any room for changes (after all, we don't want any people twiddling their thumbs do we?).

Since the project that you are working on changes (as it should), you actually get to work on some features until the last sprint, which in practice means that the project that was supposed to start, cannot. Your roadmap just changed, but the VP of R&D does not accept it. "Just push harder" he says. Your team continues to work overtime and you can actually deliver that "extra" project almost on time. But as it happens, there were other projects you were supposed to be working on at that time, and they could not be started. So the roadmap was again affected. And this negative spiral has no end unless the whole organization acknowledges that company-level plans need to change as much as team-level plans do!

See, you can do waterfall at the portfolio level while you are doing scrum at the team level.

Be at least as careful with your commitments to the long term as you are your Sprint commitments!