Projects get stuck, it’s a fact of life. Whether you use agile or other methodologies to develop your applications it can still happen. It’s not just individual applications, if you have a large numbers of projects to work on (products or otherwise), sometimes it’s hard to even agree an order in which to start work, and then the whole pipeline comes to grinding halt with endless meetings that can descend into disagreements.
Getting past this can be a case of easier said than done. The board has one set of priorities (hopefully) aligned with the business, departments and individuals have their own view of which features are the most important – usually their own – and of course the ultimate nail in the coffin of any project can be the availability of the required people and cash when you get down to it.
There are two parts to the unsticking process. The first is to stop thinking of groups of functionality as a project, collecting every feature that anyone can think of together to be delivered in one big step. Instead, try to break the project down into stand-alone features that, when delivered, can start deriving benefit immediately. Benefit is usually thought of as revenue generated but can also be, getting feedback from users, reducing a technical risk, reducing a business risk or increasing learning about the delivery process.
There is a bit of an art to slicing the project up into features. Think of the roles and other dimensions of your product. Could a feature be released for just one role? Could you limit it by geography? Is there a set of steps that could be done manually in the first instance? One could also run a risk review with stakeholders, posing the question: “What about the launch of this product keeps us up at night?” Take all the concerns and try to derive (small) features that would reduce the risks.
The second part is an “exercise” that will help you quickly get the order of the pipeline right. Follow these steps and you’ll be on your way to getting your project pipeline moving:
- Take a pile of index cards and write the name of every project’s features on a card, one feature per card, creating one pile of cards.
- Get a meeting together of all the stakeholders in a room with a very large flat table surface, and then get them to do what is called a ‘T-shirt sizing’ exercise. You’ll need two colours of Post-Its for the next stage, and a couple of Sharpies in those colours. Label four parts of the table with a Post-it each, S, M, L and XL with one colour, say orange. Discuss the size of each card in terms of benefit to the overall business. Create four roughly equal size piles of cards under the four Post-its. When everyone is broadly in agreement, take the orange Sharpies and write the benefit in the top left of each card, either S, M, L or XL in orange.
- It is a good idea to have someone with a pile of blank postcards during the above process. Every time a chunky project or features comes along for discussion, break it up in to the various components that can be delivered separately and stand on their own. Write a card for each sub-feature and size accordingly. If there are pre-requisites or architecture that needs to be delivered to deliver the feature, make a note on the back of the card, but include it as part of the feature delivery.
- Collect all the cards together one they have been labelled. Swap the orange Post-its for another colour, say blue and repeat the T-short sizing categorisation, this time based on overall cost to deliver the feature. Include financial cost, effort, duration, complexity and risk. Create four piles based on the T-shirt sizes, and then keep working through the cards until there are roughly the same number of cards in each of the blue S, M, L and XL piles. When people broadly agree, this time with the blue Sharpies, write the cost (S, M, L or XL) in the bottom right corner of each card.
- Now it’s time to create a 4×4 matrix of the size in terms of value and the size in terms of cost. Gather all the cards together and place them on the table in rows of cost and columns of value. Finally, evaluate what you have – go through diagonally taking the pile of ‘XL value/S cost’ and then ‘L value/S cost’, ‘XL value/M cost’ and continue gathering them up diagonally so you have piles in priority order. Lay the first 10 cards out in order and sense check that these are the best to start with.
This game is not the most scientific way to define a project pipeline, as of course there can be many variables to consider. It will however probably be the first time this group of people has discussed relative benefits and costs of all their projects’ features. Most importantly, it will get all your stakeholders thinking together about what is best for the business. It is a fun and engaging way to get all everyone irrespective of their role in the business or technical ability making the decisions that release the project pipeline, and start the process of delivering projects that will make a big impact, fast.
This is only the first step in delivering the projects, but in the space of a single afternoon, you could have the clarity needed to get everything moving forward and the business engaged.