What problem are you really trying to solve?

When I come into a project that is already underway, one of the first things I ask for is the list of project success criteria. In other words, exactly what problem is the project trying to solve and how will everyone know that we were successful?

Sounds very straightforward, doesn’t it? Unfortunately, projects rarely take the time to clearly define success in terms of addressing a business problem.

One of the many negative outcomes of this is that the project timeline becomes driven solely by what it will take to implement the technology pieces that are necessary to support the change. When the only success criteria for delivering a project are timeline and budget, the scope and quality tend to suffer, and that makes it difficult to answer common stakeholder questions like “what’s in it for me?” and “why are we doing this?”

If you don’t take the time to clearly define success and then maintain focus on the problem you’re trying to solve, it’s easy to implement a number of expensive technology enhancements that don’t actually improve the way you do business. Worse, you’ve used up employee morale on a change that hasn’t added any business value, and you’ve made it a heck of a lot harder to implement the next change.

Now what if the entire justification for a project is a piece of hardware or software that’s out-of-date and the organization just has to absorb the change? My change enablement approach still applies. Figure out who you’re impacting and go talk to them. Be honest that they shouldn’t expect any major improvements in their day-to-day jobs, and do what you can to make the change as painless as possible. When people can count on you to set accurate expectations and be honest about impacts, it’s going to make the next change that much easier.