ArgonDigital - enterprise automation experts

Share This Post

The one success metric that almost everybody uses is the worst success metric of them all

I wrote a previous post telling you that The Purpose of Setting Success Metrics is Not to Achieve Them.  Now, I’ll tell you about the worst success metric of them all.  Ask any project manager on any project in almost any industry what their chief project success metric is and they’ll tell you one thing:  whether the project is on time and under budget.  This is certainly a valid success metric, but it is a horrible one.  It tells you nothing about the success of your project.  For example, if you’re creating software, and the project is completed on time and under budget, but the software doesn’t run, clearly it was not a successful project.  Usually things are not that clear cut:  you may be building software to improve customer service, and the software works perfectly, but none of your sales reps end up using the software due to a usability flaw that no one noticed.  It may have been the greatest piece of software ever written, but if nobody uses it, it’s still a total failure.  Saying a project came in on time and under budget tells me nothing about whether it was successful.

I once heard a new executive at an auto company say that his main objective for the next year was to bring all his development projects in on time and under budget.  I don’t know about you, but if I ran an auto company my main objective would be producing and selling cars.  All your projects could be on time and under budget, yet they will be failures if the cars don’t run.  Success metrics are defined as “statements about specific desired outcomes which help ensure business objectives are met.”  If the success metric is achieved, the project is considered a success.  The answer to the question “did my project come in time and under budget” has little correlation to producing working automobiles that consumers want to buy.

Why is this success metric used so much?  Because it’s easy.  It’s easy to create and easy to measure.  It meets the criteria for a good metric:  it’s quantifiable, it’s tied to a specific date, and it’s not ambiguous.  And it does measure a certain kind of success, the “will my boss be angry with me” criteria.  Needless to say, if an entire company is working toward the goal of “not making the boss angry,” it is not working toward the goal of creating successful products, since successful products often require tradeoffs and deviations from the original plan.

Why is this metric so insidious?  It’s all everybody seems to focus on.  That means you start worrying about the wrong things, such as “how can I cut corners to hit the deadline?”  Worse, it forces a zero sum game between saying you screwed up with the initial forecast or you screwed up with the execution.  There is actually another option that does not involve anybody screwing up:  the future is unpredictable and project managers are not fortune tellers.  If you are able to predict every twist and turn a project takes during its lifecycle, you should make your living predicting lottery numbers, it’s a lot more lucrative for someone with your skill set.  As with most things in an organization, it comes down to blame.  This is how office politics is born:  everybody spends their time trying to blame someone else so they don’t get blamed themselves, rather than focus on the one thing that really matters:  product success.

And in many cases, bringing a project in late and over budget is the absolute right thing to do.  There are many unexpected reasons why your project may take longer or cost more than expected.  When you get to that point, it is time to examine the tradeoffs between extending the deadline and the budget, or cutting scope.  These are the most valuable discussions you could be having, yet trying to be “on time and under budget” prevents these discussions with the thoughtless answer NO.  Sometimes going over budget is good for the project, sometimes it isn’t.  But these are important items that need to be considered to steer the success of the project.  Just having an automatic NO to every request that would put a project over budget ignores the reason for doing the project in the first place.

Avoid that game entirely.  Set a constructive success metric, not a destructive one.  Be more thoughtful about your success metrics by avoiding the trap of using the easiest one just because everybody else does.  The more thoughtful you are about your metric, the more thoughtful your project will be, and that will help you avoid many of the pitfalls that doom projects.  If you can’t think of any success metrics other than “be on time and under budget,” abandon the project.  You have more important things to do with your time than work on a project that has no measurable impact on the business.

The one success metric that almost everybody uses is the worst success metric of them all

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage