When do you know you’ve achieved “Performance Management?”

I was giving a presentation to a customer recently, describing our unique capabilities to deliver a solution to him and his company that I really did feel would help he and his team solve a pressing business challenge. After I finished the presentation, he paused and asked me “when are we ever done with performance management? Do you guys just keep selling us software forever, or do we shake hands at some point and call it a day? When are we “there”?”

After growling “never foolish man, never I tell you” under my breath, I realized afterwards that he had a point in asking the question.

And it’s not that “performance management is a process, not a product, you’re never done.” (which is true by the way). Yes, you always want to improve; yes, you can always do better; yes, there will always be another new piece of technology. And many technology sales people make their living on going from company to company selling back into the same buyers over and over with a great deal of success.

But let me make the case for putting a wrapper around a specific performance management project and deciding that you’re done once the original objectives of the project have been achieved as a way to get “there,” as the customer was commenting to me. Lots of projects we’re seeing today have multiple phases, multiple teams, and multiple go/no-go dates that bring huge structural and process changes within the organization. And these projects can be great from a vendor perspective—lots of software, lots of services, lots of maintenance. But at the end of the day, is the vendor really solving the problem that the customer set out to address when the project was conceived?

After all, most projects don’t start big, they start small and grow big. And during the inevitable delays, funding pauses, and team reshuffling, the original issue that was to be solved remains unsolved, causing the pain, inefficiencies, and money drain that prompted the project team to be formed.

So here’s a vote to go against the prevailing project prototype these days and—wait for it—solve the original problem that caused you to call in the vendor in the first place! The most successful technology projects—the ones that really change the way you work and compete in the marketplace—are those that people are clamoring to use, not that they are forced to use. And yes, ERP once even fit into this category (don’t laugh). Have you ever seen the order entry process pre-ERP vendor? Not pretty.

But beyond ERP, the reason that most technology projects take off is that they start small with a pilot project that solves the problem that you have. As word spreads that Joe’s team in finance is doing great things with their new financial dashboards, suddenly Sue in supply chain or Jim in HR wants to see these magical dashboards and get their own reports. Now we’re talking performance management! You’ve created a bottoms-up approach to the issue that has people wanting to grab onto your coattails instead of jumping off them so they don’t get tainted with the stench of your project failure. I’ve seen it work time and time again. People want to tell others about their success; they want to show how much better they’re doing using your software. It’s just much harder to do that when it takes 3 years to go-live.

So in the big scheme of things, consider which scenario gets you a bigger benefit, provides momentum within your teams, and shows that you’re leading and solving problems that matter today. Think of that next time you see me pitching my vision and wheel of productivity and try solving the main problem first, and boiling the ocean 2nd. You’ll see a greater return for your investment; your people will be happy, and you’ll actually be “there.” And from the vendor’s perspective, we’ll have a happy customer that we can point to as a success. Wow, sounds like everyone wins here.