Read the transcription of the episode:

Multitude of ideas – how to handle project priorities

Today’s topic is resources, but not the ones your HR might deal with. Let’s think about the resources understood as ideas, a multitude of ideas that keep streaming into your company from various directions. You and your team have to plan out how to contain and process this potential in your monthly or quarterly perspective.

These ideas most often originate from your present or potential customers, your friends, you and your team, your superiors or leaders (presidents, CEOs, investors) or even your customer who is your ultimate boss. Usually, there are far more ideas than implementation options. Listen to this episode to find a simple way to manage priorities. You do want to make it effective, right?

In my conversations with startups, especially those at the beginning of their way (but with those more advanced, too), I could sense a feeling of frustration. The frustration caused not so much by an excess of ideas, but rather by their limited idea-processing capacity – their discouragement when it turned out their teams were three or even ten times too small.

I have a useful quote here, popular in the tech business sector:

nine women will not give a birth to a child in a month.

In other words, if production resources in a technological startup are increased overnight, let’s say if they hire more IT teams with a few more tens of programmers, it will not necessarily boost their SOFTWARE PRODUCTION. There WILL be an improvement, but not proportional to the growth in employment. Adding workforce, especially in software production, which is not linearly scalable, can only pile up challenges in scalability of this production.

While there are tools to manage the code versions, the internal product management is much harder, because features are mostly connected, parts of one large mechanism. Consequently, if too many people are working on it, it simply turns out that there is not enough product management control to make sure that what is being produced is still integrated and consistent. So, hiring more people to work on a given piece of software (or anything else in your firm) does not ALWAYS lead to a growth in production.

This holds true regarding the problem of multitude of ideas. Just like employing  more people to work on a given project does not always lead to a growth in production, having lots of ideas to process doesn’t need to call for extra human resources, as that might not yield the desired result. The shortage in the capacity to process this multitude is natural and desirable. Just imagine a situation in which you had plenty human or technological resources to develop software products and didn’t have any ideas. You would quickly face cost efficiency issues.

The resources – technological, developer, programming, architectural and systemic – are not cheap; the workforce highly qualified and well-paid.

I strongly believe that, in most cases, it is only natural that there will always be more ideas than the people to handle all of them.

This creates another challenge – how to manage the ideas. How to define, specify and select the best ones? How not to fail the communication with all those who have submitted these ideas? What’s the best way to keep the company’ broader purpose and mission transparent enough for the team to stay motivated? This calls for a creation of a system within a company that would manage the area in a simple, yet good enough way. It has to be user-friendly, transparent and efficient.

The IT sector often uses the terms “backlog” and “roadmap”. In short, backlog is a list of things to do – small projects, assignments combined into larger projects, called “epics”. As long as these sit in the backlog and wait, nothing happens. The first problem here is that, unfortunately, the backlog tends to be a bag full of random issues that rarely see daylight.

It’s a bag accessible only to the IT department and the people who MUST have access to it. As is not available to all the staff, it generates certain frustration in the organization, because the crew of the ship doesn’t know where the ship is going. Another problem is that, someone with the access to the backlog must use certain criteria to select the things to do and put them on the nearest period’s roadmap – usual with a monthly or a quarterly perspective.

What I’d like to tell you about now, is something that has given interesting results at AirHelp. It is a kind of matrix of ideas or a kind of business case, as we like to call it. It is a tool to support decisions that select the right projects.

Well, it all started, when a few years ago, we were facing a great challenge at AirHelp. I’m glad we are looking back on it now. At the beginning, when we were still a young organization of around 100 staff, we were flooded by a wide stream of ideas coming in from different sources – us, our Board, our founders, investors, and last but not least, our Operational Department staff.

There was a time, when all the ideas submitted to our task line-up coordinator were forwarded to the Technology Department for time estimate – how long it would take to implement them. Without much exaggeration, we were quite close to a situation when our Product and Technology Department spent most of their time and energy assessing various ideas and components, leaving very little of it to their actual implementation. Time efficiency plunged, too few things were put into practice and frustration levels increased.

Then, out of many other applications available, we introduced a simple tool – a Google Spreadsheet. Unlike JIRA used by our IT, for instance, Google Spreadsheet was most commonly accessible. We set up a dedicated spreadsheet and made it available to anyone in the company. Consequently, with the help of a google form, all ideas, no matter who they had come from, landed in one place.  Ideas had to have a simple description saying what field of company activity it concerned, specifying results and improvements expected by the submitter if a given functionality was implemented.

On that basis, ideas underwent preliminary evaluation in two areas.

Firstly, an estimate was made of the impact that a given improvement would have on business  – how much good a new functionality would give – on a 1-5 scale – 1 meaning little and 5 meaning a lot. Subjective as it seemed at that stage, at least all the suggestions were evaluated by a single person, using the same set of criteria, so the bias was minimal.  The evaluator had the experience in implementing a few dozens of functionalities from scratch to practice at the Technology Department, which had given her a good sense of what impact particular innovations might have on our business.

Secondly, the time and cost of creation was roughly estimated. Again, it was done by the same person, and this time the scale was 5-1. The projects evaluated as cheap got 5, the time and money consuming ones got 1. The instructions defined very cheap as something like replacement of a text on a website. Very expensive meant coding a complex functionality from scratch. In the middle of the scale, there was a transfer of a functionality that worked well in one place to another, where it could be adapted. So the evaluator placed the suggested innovations somewhere on the scale ranging from a simple text replacement to complex, advanced functionalities on the 5-1 scale.

Then the two component scores of the estimate – the business impact and the cost – were multiplied by each other, giving the result from 1 to 25. 1 meant that a project was expensive and of little advantage, whereas 25 meant very cheap and tremendously beneficial. As there were still over a hundred suggestions to consider at that stage, they were all ranked by score, high to low. We decided to focus on the top 20% of the list, sort of following the Pareto principle, expecting top 20% of the list to give 80% of the result. By the way, it turned out later that the Pareto principle proved better than anticipated.

So, although in a quarter of a year we actually had the capacity to implement only 10 bigger innovations out of all submitted, at least we had the scope limited from 100 ideas down to 20, that we could focus on in detail. That in fact has increased the productivity from 10 to 50%.

As a result, in the first place, our Tech Department was relieved, not having to process all the initially rejected, less viable projects. Secondly, a company list was created, available to all our staff, rated high-to-low, of projects being implemented.

Anyone could check at which stage a given person’s project was. The submitters could see how their ideas were rated and where they landed on the list. They could raise objections as to the business impact or implementation cost scores and argue that the impact was higher than evaluated or the expenses lower. That sometimes helped the evaluators change their perspective on a given entry and notice the things they had overlooked. Some other times, the submitters simply had feedback information that there were better ideas in the line so they had to be patient and wait their turn.

This way, a lot of the authors’ frustration was avoided about their prized innovations that got lost in the process. Moreover, in the times when we didn’t have our backlog, the company founder, owner or CEO could make everyone drop all their current work just to introduce a functionality they thought was most urgent. With the prioritised list of ideas in place, we could reply to company leaders or anyone else that, according to our evaluation standards, their idea was great, but it was, say, the 22nd in the queue.

That would often open a discussion during which it turned out that a leader didn’t exactly mean that everybody should actually drop everything and do his thing. On the contrary, it was just a good-willed suggestion of a useful functionality for the team to consider at their convenience whether it made sense and when to work on it.

Obviously, the system implemented hasn’t solved all our problems. There are still some ideas that look insignificant from the perspective of the company, but are of crucial impact on a particular person’s work in a given department, where a given functionality would be of great help. Anyway, despite being unable to tackle all problems, the system helps keep tabs on our resources and ideas and make better use of them.

Also, the system helps us decide how much these resources should be increased, or are worth increasing. Making  our quarterly or monthly plans, we can see how many projects are rejected, how many of them aren’t going to see daylight. Important as it is, it’s often overlooked at tech companies at the work planning stage. We should not only see what the team has declared worth implementing over the next quarter. What we should not lose from our sight is the alternative cost of those few projects that nearly made it, but were rejected as not doable.

The ranking of ideas in a company allows for better management of intellectual resources, more transparent internal communication as to what we do, why we do it and in what order. It helps adjusting our strategies as there is just one place where we keep all our immediate plans and deferred projects that are patiently waiting their turn.

I highly recommend this system to all those who care about maintaining the human face of business, building the climate of cooperation and keeping innovators motivated. Use this simple method to stay transparent about company plans to implement or defer submitted projects.

Use it to give feedback to the authors and to rank their ideas. It is tremendously motivating to get feedback and terribly destructive for teams to see innovations ignored. If unacknowledged, they will soon stop coming. This may pave the road to killing incentive and making your company growth harder than it has to be.

Good luck and have a great day.

Click the picture to listen more or record a voice message.