In today’s tech infused world, many companies strive to rise above the competition and get results from their efforts and ideas as quickly as possible. It’s okay to want instant gratification – our customers seem to expect it – but as we well know, anything great takes time. But shaving even small amounts of time off valuable projects can yield big returns. So how do you compound that and make it a habit? Some ideas and principles from “agile” promise to get you there.
To explore the application of “agile” to portfolio management we need to start from “what is agile?” and why it’s effective at driving value. I’ll generalize some of the concepts you are probably already familiar with from agile development methodologies, and then tie those into portfolio management.
Agile does not equal scrum or kanban. Scrum and kanban (and others) are methodologies for applying agile principles. Agile principles can be applied in other ways, and for other purposes.
Essentially agile simply means you are continuously delivering value – whether for a product, project or most commonly, software development. You can apply agile principles using scrum, but agile in and of itself is not scrum.
Irrespective of “agile” per se, it’s to everyone’s benefit to deliver value continuously and ideally faster. By taking an agile approach, we can achieve that.
Sounds good, but how does it work? At its simplest (and these are the basic principles of agile) the process goes like this:
1. You make a list of the things you want to do. Within a project, that will be user stories or epics. In a portfolio, that will be the projects and initiatives themselves.
2. You figure out the business value of each. You can use your own metric for this, like our customers do with the “scoring” capability in Innotas, or you can use NPV or ROI.
3. You may do a little work to decompose really big things into smaller, more manageable things – which are also easier to estimate and deliver.
4. You stack rank your items by business value.
5. And then you start working down the list, always finishing what you’re working on before you start the next thing. In this way you’re always working on the most important thing, or the few most important (most valuable) things, and delivering them before you start working on something less important.
6. Then you go through this loop again, starting at step 1: check your list, make any additions that have come up due to changes in the business environment or based on new ideas, make sure the business value is correct, and reorder the list by value if necessary. Then start work on the most important thing and do it until it’s finished. Then repeat.
Unlike its older cousin ‘waterfall,’ agile is by its nature designed to adapt quickly to changes. In a rapidly changing environment, this can be the difference between success and failure; no matter how well the project was executed, if changes in the environment make it the wrong project you shouldn’t work on it any more. This is pretty important if you are trying to minimize risk and deliver more quality projects. Don’t get me wrong, waterfall planning has a place for projects that don’t have much risk and whose steps are well understood – like building a house in a subdivision, but not building new business software applications.
It’s fairly easy to see how this “agile loop” applies to an individual development project. But how do we apply the same approach to the project portfolio – the set of all the projects you will deliver over the next quarter or year or five years?
It’s very similar:
1. You figure out the business value of your list of candidate projects
2. You might do some subdividing of the projects if they are very large
3. You order the list by business value
4. You start working on the most important ones first
5. Review progress often, and re-rank projects if necessary
6. Repeat from step 1
Of course, you might have multiple teams working on multiple projects at once. But the idea behind agile is that they will be working on the projects that deliver (or preserve) the most business value. And they will be leaving the projects that align less with business value to later (or never). This is Agile Portfolio Management. And it’s different – although related – to agile project management.
Agile portfolio management doesn’t happen overnight, so you will need to incorporate where necessary. If your organization is already managing projects using agile methodologies, the next step often is to bring the task data from your agile tool into another tool – like Innotas – that enables you to aggregate management-level information across your projects so you can see and track that status of your portfolio as a whole. That way if your organization is also responsible for waterfall projects, you can manage them in the same system and make decisions based on the portfolio as a whole.
To sum it up
The key thing to remember about agile is the goal of continuous and frequent delivery of business value, to focus on business value as your key metric, and to embrace change in such a way that you continually deliver more value over time. Agile is an approach, not a methodology per se (although methodologies can be helpful). Also, everyone can use agile – it’s just prioritizing business value delivery over efficiency, and working to deliver that value as fast as possible. It doesn’t matter what methodology you use as long as it aligns with those principles.
And finally, the goal – and what you’ll achieve – is to deliver more value faster, while being responsive to change. Tools and processes can help you make the transition to this approach more easily.