Guest Post: How to unblock technology projects in your travel company

Projects get stuck. It’s a fact of life whether you use agile or other methodologies to develop the applications that keep your travel business innovating.

By Richard Stobart, managing director of Unboxed Consulting

Projects get stuck. It’s a fact of life whether you use agile or other methodologies to develop the applications that keep your travel business innovating.

It’s not just individual applications either, if you have a large number 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 playground-like disagreements.

These are often centred on what is most important to developing the digital offering, which has become such a critical aspect of staying ahead in the travel industry. There is a often a lot of pressure, expectation and emotion – especially with increasing traffic moving on to mobile devices such as tablets and smartphones.

Getting past this can be easier said than done. The management team has one set of priorities, departments and individuals may have different views on which features are the most important, 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 start deriving benefit immediately. Benefit is usually thought of in terms of bookings but can also be user feedback, reducing a technical risk or engaging the public.

There is a bit of an art to slicing a 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 simple steps and you’ll be well on your way to getting your project pipeline moving.

1 – 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.

2 – 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 marker pens 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 marker pens and write the benefit in the top left of each card, either S, M, L or XL in orange.

3 – 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 prior to the feature, make a note on the back of the card, but include it as part of the feature delivery.

4 – Collect all the cards together once 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 marker pens, write the cost – S, M, L or XL in the bottom right corner of each card.

5 – 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 ten 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 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 everyone, irrespective of their role 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 rest of the business energised and involved in digital products that can make a big difference to their jobs, bookings and ultimately profits.