Dare to take out the trash: the danger of pet projects

A pet project is a common term to describe a project, that is someone's personal preference, rather than generally accepted as necessary or important. In most cases, we recommend shunting this type of project. As in "Run away from it, fast". In this blog we'll pinpoint the dangers of these projects for you. We'll also help you with detecting and mitigating them.


Generally, there are 2 kinds of pet projects:

The first kind contains projects where decision making is not objective, because of someone’s preferences. They are conducted within the official strategic roadmap initiatives. This, as you can imagine, has lots of consequences in your organization.

The second kind contains projects that are set up as a personal learning opportunity. Self-realization and autonomy are the most motivating factors in job satisfaction. Your employee probably acquires skills through these projects that also make him better at his job. It’s up to organizations to decide whether to create an official context for this or not.

Sometimes a personal pet project results in something that might help the company too. In that case you can even get this pet project on the official roadmap. Beware though not to treat this project as a pet project anymore. Do not confuse these two with experimenting. Experiments can be conducted within organizations. We should carefully weigh out the effects of incorporating R&D in the organizational structure. In this article we will focus on the first kind of pet projects: the ones that are on the official roadmap.


Danger, danger

Why are pet projects so dangerous? The truth is that the "personal attachment" to a project tends to skew the way we look at it. We tend to overlook things or turn a blind eye on certain aspects. Imagine your spouse loves cats. The agreement is "no cats on the table", but we all know that won't stop her from secretly feeding them cheese leftovers underneath the chair, resulting quickly in... Yup! Cats on the table.

In short: we’re living in a fast moving world in which everything changes constantly and rapidly. This means you need to be agile. Being agile means: being able to adopt to new situations, fast. But you can't go re-inventing your business every month. "Adoption" needs to happen with a focus on your business. Not just change for change's sake. "Experimentation” can help you with this. But "experiments" do not carry that personal attachment. If the experiment fails, you learn from it, you grow, and you try something else. Pet Projects pose a danger to this mentality:


Pet projects make you stray from your strategic direction.

Experimentation is crucial when you want to stay relevant. 


Pet projects disable you from handling change and disruption

In the end, Rose lets Jack go, right? Unlike experiments, where you actually want to find out if it fails or not, you do not want your pet project to fail. It makes "letting go" of the pet project so much harder. So, there is a big chance you’re wasting resources to keep it alive.


Pet projects put a mortgage on future projects

The person treating a project more favorably can have several roles in the project:

He can be the owner, who has the money to spend
He can be the executor, project manager or consultant
It can be you

Depending on the role this person holds, the impact of a pet project differs. Why does he want this? Nobody asked for it (this is for example the famous CEO-button), or in the way progress or results are presented (this is for example the famous “you can prove everything with numbers) or in the actual results.
The result is loss of trust by stakeholders and thus it will also put a mortgage on future projects.


Pet projects hold you back from anticipating and looking ahead

Pet projects are like horse blinders. You're so focused on them that you start losing track of the fact that the future is increasingly less foreseeable. You stop thinking ahead. To stay relevant, you do not only have to hit the sweet spot today, but you have to be organized in such a way that you can still be hitting that sweet spot in 5 years, in 10 years or even in 20 years. This means consecutive performance and the only way to obtain this is to continuously invest in innovation in order to avoid disruption. Pet Projects within company settings are not innovation or experiments. Either treat them as such or kill them.

How do you detect and avoid pet projects?

This is a difficult question to answer. Who's doing the "detection" here? As an "outsider" it is quite easy to detect these projects. From an inside (in relation to your company) perspective, it is much harder because it means going against the "owner" of the pet project. Company politics come into play here. Also, there is a difference in the kind of "pet projects". Entire road maps can be a "pet project", or just that one project, or just that one "deliverable" or "feature". So, depending on the type of project (the level of zoom), the way you detect these might differ.


Detect and avoid on high level zoom: blueprinting and road map definition

On the highest level of zoom, a "pet project" should be detectable by creating a "blueprint" of your service. We'll cover service blueprinting in depth in another blog post but the main idea is to check all aspects of your service traversing the customer journey. For each "phase" your customer can go through in the customer journey, you check the actions the customer takes, the touch points, the staff actions, the backstage staff actions and the support processes. Based on this "blueprint" you see where things go wrong. Now you can define how you can fill in these "gaps" and when you should fill those gaps. You construct a road map. If an existing project does not fit in here, it's probably a pet project.

First, you need to check if the outcome of the project is in line with the strategic direction of the organization. Secondly, you check is if the outcome will indeed be attainable and if it fills the blank in the blueprint. That last part is the hard part, because, a pet project owner will be convinced this is the case (horse blinders, remember). You could try one of the techniques explained further in the article or set up a prototype project. That's ok, since the project will then be handled with a mindset of "experimentation" and not as a "pet project".

Project level zoom: prioritize and validate

On a project level zoom you can still bump into "pet deliverables". Smaller pieces of functionality that do not deserve the attention they get. We, as an outsider, quickly detect these through our discovery approach. You can apply these techniques yourself when you come across a candidate pet project.
This is how we detect and avoid them...

For every project, you need some sort of "discovery" track where you can detect the following elements:

1. The actors: Who's involved in this project? Who will be using it? For whom does this project needs to provide results?
2. The struggles: What are the issues the actors are struggling with? What is their "pain"? What will they start doing in order to resolve that issue (what is their "Job to Be Done"). Check out this article to get a good understanding on how this knowledge could be achieved.
3. The "solutions": What can we offer them in order to help them in their "Job to Be Done". What feature could we build within this project to provide an answer.
4. The goal: What is our business goal? This should be aligned with the strategic direction of the organization.

You can read up on this process here. The result is a set of possible features that will be of assistance to the actors. But they should be in line with the company goals as well. At this stage you will be able to start seeing the cracks in a "pet project". Are these indeed the "actors" we should be focusing on? And if we build those deliverables, are those in line with our business goals? You can start finding these cracks by just having this one workshop. The pet features can be:

every "deliverable" or "feature" that is not directed to a specific actor
every "deliverable" or "feature" that does add to the business goals (directly or indirectly)
every "deliverable" or "feature" that does not solve a "struggle" for the actor

Need more proof?

So, imagine the goals defined do sound reasonable and in line with the strategic direction. The definition of the actors is correct as well. Should you still be worried then?Unfortunately, yes. Because the proposed "deliverables" can still have a "pet project" character. Imagine our customer needs "fast means to get in touch with the right person in our organization". The deliverables could be:

Let's add a contextual contact section on every page of our site, showing the contact info of relevant sales people, in relation to the content on the page.
Let's add a chatbot
Let's add live video chat

Can you spot the pet project? It could be any of these, really:

contextual contact section: you might want to keep the "salespeople" up front and center because you firmly believe they should hold the reigns.
chatbot: you just think AI powered chatbots are so cool, and it will take the load of your customer support or sales.
live video chat: you believe this to be the perfect mix between a "personal approach" and a digital solution.

"Feature validation" and "backlog prioritization"

In order to spot the pet projects from the list earlier, you can apply a set of very simple fast techniques.

Basic effort vs ROI prioritization

For each feature, one can look at a couple of parameters:

What is the feasibility? What will we need to do (development, content creation, system configuration...) in order to get this to our customer?
How is this aligned with one of the goals defined previously. Will we benefit from this?

If you do this prioritization, you'll already see discrepancies in what your features are and the goal alignment. Another more thorough technique to help in prioritizing is the Bono Six Thinking Hats technique: you simply go through all deliverables and you "judge" them whilst wearing a different "virtual" thinking hat:

White Hat: Gives you the option to ask clarifying questions to understand the deliverable a bit better.
Red Hat: Here you can offer your opinion based on "gut feeling". You can voice your "opinion" without having to justify yourself
Yellow Hat: Here you can offer reasons why you think this idea might indeed work.
Black Hat: The black hat makes us consider the reasons why something may not work. Mind you, "emotion" does not belong here. That's the "Red Hat".
Green Hat: Allows room for proposals, suggestions, ideas, alternatives.
Blue Hat: Manages the process and use of the other hats.

All the above can be done "within the organization" without ever talking to a single customer or end-user. But we all know what happens if you claim to know your customer... So, if you really want hard facts you can take it one step further. Does the proposed feature indeed perform "The Job to Be Done" for your customer? Customer interviews and validation of the feature set by the KANO model can get you the insights you need. Simply ask your customers these 2 questions per feature:

"How attractive would it be if you had feature X?"
"How annoyed would you be if you did not have feature X?"

Plotting the results will quickly tell you which features will delight your customers, which ones will be strong performers, which ones will leave them indifferent, and which ones will deflect customers. If these results clash with the core of what the pet project tries to entail, you better adapt it or kill it.

graph agile
We've successfully applied this technique in multiple projects, saving our clients from implementing the wrong, and thus expensive (pet project) features.


Let him/her down easy

Now imagine you did the work, and you detected a bunch of pet projects. How do you confront the "owner" of the pet project with this? What? Wait. You didn't include the owner in all the above? That's a big no-no. Pet project owners have a "passion" for their project. That passion cannot be replaced. It is highly valuable, and you should not crush it. Include the pet project owner in every step of the way. They will understand why the "pet" does not belong in the project. The insights, input and understanding coming from the techniques will hopefully spark his passion for another, better or alternative project or deliverable that will fit the bill.

If the owner was not involved, walk them through your reasoning. If you did include him or her, he or she should understand why their project does not fit the bill, or what they could do to include it in the road map.

Are you in trouble with certain pet projects? Or do you need a hand in defining the right projects and road map?

Contact us

Don't miss out

It's more than digital, it's your business
The Reference is nothing without its customers. Melexis is the stock market-listed global player in the semi-conductor and sensors industry for whom we facilitated future company growth by updating the brand, building the completely new corporate website and giving shape to the use of online channels. Read more about this client.