Why Projects Fail

Big, cross-departmental projects are always a challenge. However, there is one specific, foundational step that I find is often missed that inevitably comes back to haunt the project at the end.

This is if you fail to start by very clearly defining what problem you are trying to solve. Successful projects need:

1) Clear agreement what you are (and are not) trying to solve with the project

2) A way to measure if it worked

This may seem obvious but I find these steps easy to skip, and often are. If you go in assuming everybody agrees you will find yourself in debates where both sides of the debate can't understand why the other is taking the side they are. It is insidious because both sides may be making a good suggestion for solving the problem they think that they are solving.

An Example: SaaS Product Pricing

Pricing is one of those complex projects that have many stakeholders. Let's look at just a few of the problems that a pricing revamp could solve:

• Making pricing simpler to understand

• Increasing ASP (average selling price)

• Making it more flexible

• Preserving opportunities for customer growth

• Giving you an advantage over competitors

Of course you would just love to say "yes" and solve all of them. The problem is that some of these may be in conflict with each other. The more flexibility you offer the more complex the pricing may be to explain. Pushing for higher initial ASPs may take away some opportunity for future customer growth. Lacking this definition of what you are trying to solve can have two parties advocating for solutions that don't make sense to the other side, but make total sense to themselves.

If you try to solve everything, you will likely end up with a solution that does not truly solve anything.

Just as important is recognizing what you are not trying to solve for with the project. This means that you can avoid worrying about improving in an area or even being ok with lose ground in that area in exchange for solving the problem in focus.

Measurement

You should also not start a project without knowing how to measure its success. Let's go back to the pricing example. Some of these things are straightforward. For example, you could look at ASPs before and after the new pricing and try to eliminate other variables.

Some may be a bit more challenging. How do you measure pricing simplicity? Of course you could ask your sellers: "I the pricing easier to explain?". This will be anecdotal and noisy most likely. What else can you do? Well, you could report on how long deals are in the "Negotiation" stage in Salesforce. Presumably simpler pricing will get through negotiation and procurement faster.

If you are currently missing the ability to measure your success criteria, that should be the first problem you solve. This will at least give you a baseline to see whether or not the project is successful.

Choosing the right measurement is as important as defining what it is you are trying to solve. It is also worth tracking the related metrics that, while you are not trying to solve for them, could be affected by the change. An extreme example would be just to say you are going to license your product for $100/yr for unlimited usage. It's dead simple, you probably transact really quickly but you would see your ASPs flatline and no customer growth upside.

How this Helps

If you get agreement before you start solutioning all forks in the road can be tested against the original success criteria. Now there may still be debates about which solution may be most impactful, but now you are doing the productive work over finding the best solution, not arguing past each other.

With the measurement in place you can also go beyond anecdote to real data about the impact that the project had.

If you ask 5 people that are all working on a project what you are solving for and you get more than one answer then you have a problem.

My Recommendations

1) Make the first meeting (or few meetings if necessary) just about what you are trying to solve

This may feel unnecessary at first, but you may be surprised as you solicit the opinions of the team how many opinions people have in their head. This time will pay itself back later. Also make sure that those successes are not mutually exclusive.

2) Pull the baseline metrics for the measurement that you are going to use

You may find in doing so that you are missing some visibility into what you are tracking. Or you may find that the problem you thought you need to solve is actually not a problem at all! It is important that you find this out now because if you do it afterwards your data will already be affected by the project itself and you won't know whether you truly improved or not.

3) Get everybody to sign off

We have gone as far as to put checkboxes or signatures from everybody involved.

4) Use the success criteria as a tie breaker for debates

This allows you to say: "This is a valuable suggestion, and one we may take up in the future, but it does no align with what we are trying to solve right now". If you are in person, print the success criteria and put it on the wall during meetings. Or put it up on the top of any documentation so it gets drilled into everyone's head.

5) Actually measure after the project is completed

You should definitely celebrate completion but remember you did not do the project to feel good about yourselves, but to solve the original problem. Don't move the goal posts after the fact. Acknowledge that something did not work and iterate if necessary.

Hopefully this helps you avoid what I see as a pretty common mistake when kicking off a project.

I would love to hear if others have suggestions for how to set projects up for success.