A project manager is asked to manage a project that is supposed to improve a software. He plays around with the software and also thinks that there is room for improvement but asks for data that supports the need to improve. He also wants to know what the business impact of an improvement would be. What are the KPIs, the Key Performance Indicators, that show that the project is successful? Unfortunately, the customer does not have any data whatsoever, there is just a “feeling” that something is wrong. Also, as he does not really know what is wrong, no business value can be attached to the project.
The project manager insists that a baseline is needed but the customer replies that he was not too happy about having a project manager involved in the first place since that conversation proves that project management increases complexity and adds unnecessary steps to the project. Sounds weird? No, that’s a true story. And I have experienced this more than once. And to be completely honest, I have experienced it on both sides of the fence: As a product manager, I was often annoyed by the additional questions asked by developers and project managers, and as a developer or project manager, I have seen product managers being annoyed when I asked those questions. In fact, starting a project without clearly defined goals and KPIs is like flying without a precise destination and without instruments that let you know where you are above the clouds.
“Improve a software” is not a goal. It could mean that the software should be faster so that people don’t have to wait or that it should have a more beautiful design or that it should have a better user flow or… but how do we know that there is a real problem?
Let’s look at this from a different perspective. What exactly is the business goal of the software? In how far does it help to achieve the overall business goal? The software could be a reporting tool where users download performance data for their department. This would definitely be an important piece of software. But what does “better” mean? Better numbers? Let’s trust the numbers are fine. Response times? Crunching numbers can be an expensive task in terms of performance, and a massive investment may be necessary to reduce waiting time. However, what is the business problem if people have to wait? Do people really stare at the screen while a report is being prepared when they know it can take minutes? They will probably answer their emails while they are waiting, so do we really have a problem? It might even turn out that it is cheaper to let people wait than to invest in a machine park that is expensive to purchase and maintain.
Maybe the usability of the reporting tool is suboptimal. Users may not like to wait for a report but they might understand that it takes time. What they don’t understand today is if a software is hard to use because there is more and more great software out there. Users may find it difficult to explain what is wrong with an interface but they may have a feeling that something is wrong. Measuring usability, as a consequence, is difficult but one thing that we can do and that is easy to do is to measure the time it takes a user from starting the software to the point he is able to submit the request for a report. This may not be the best way to measure it but it is easy to measure and maybe “time required” is a good indicator for usability and the feelings a user has when using the software.
We have just used the term indicator, and this brings us to Key Performance Indicators (KPIs). If a users needs 10 minutes to submit the request for a report today, what would an “improvement” look like? When would we regard the outcome of the project to be successful? If I bring it down to 9 minutes, would this be considered a success? We need to define a goal, but how do we know whether people are happier with 5 minutes than with 6 minutes? Maybe 6 minutes is enough? The problem is that if you don’t define the KPIs and goals here, you can achieve the best results that you can think of for yourself, but the customer may still be unhappy because he was expecting even better results. Or has measured success differently. For example by counting the number of complaints received per week.
We won’t go through all the details here but as you can see, defining the business problem can be a tough challenge. Defining the goals and the KPIs can be an even tougher challenge. But if you start into the project without doing this exercise, you are doomed to fail. Or you have a product manager who can sell the results of a project as a huge success although nothing was really achieved. But you want to be on the safe side. And to completely honest, you shouldn’t be required to define these numbers because the person who requests the project should have proved the need for the project already. But this is not what our reality looks like most of the time. Try not to fly without a destination and instruments. You may not survive.