Project Aida has a budget of $725,000 and is required by June 1st. All the requirements have been defined for a new content management system to appropriately archive sensitive corporate information within the defined retention polices. The delivery team successfully implemented all the defined requirements and the new system was ready to go June 1st. Final costs for the project total a bit over $723,000. Of the 19 departments targeted for the new content management system, three are actually using it. Was this project successful?

Project Isolde has a budget of $1.7m to implement a new demand planning and replenishment system that once implemented will reduce on-hand inventory by 1.5 days. The project is expected to take 18 months. The project was actually completed in 20 months for a cost of $1.9m. As the system was implemented and the users learned to use it, on-hand inventory shrunk by 1.8 days. Was this project successful?

Project Tosca has a budget of $975,000 to revamp how customer data is gathered and analyzed to enable more targeted marketing campaigns. Three months into a 9 month schedule, management decides to cancel the project because it is not producing the expected results. Was this project successful?

Which projects do you consider a success? What criteria did you use to reach that conclusion?

In many of the organizations I have had the opportunity to work with, there is a surprising lack of clarity about what project success means and what we really need to assess during the life of a project. I believe we should focus on answering three questions. Are we doing the right work? Are we delivering effectively? Will we recognize when we are done?

Are we doing the right work?

We need to make good decisions about what work we take on. What problems are we solving? What is the value to the business if we solve them? Why is this problem more important to solve than that one? How will we know that we have solved the problem? There is a $50 solution and a $5000 solution, which do we really need?

Shouldn't we be able to answer these types of questions prior to starting work on something? Simon Sinek tell us that leaders who have the greatest influence in the world have one thing in common. They all Start with Why. To help us understand the why we can look to the concepts of the Pragmatic Marketing Framework. Even if you are not working on a commercial product you still need to understand much of this information. We need the business more engaged in and more accountable for seeking the answers to what and why.

Are We Delivering Effectively?

Once we understand the right work we have to effectively deliver it. Here agile principles and values come to the forefront. Are teams engaged? Are they focused on solving the problem? Are they seeking and learning from frequent feedback? Are they delivering business value incrementally? Is their solution being incrementally validated by real users in realistic scenarios?

Why are any of these things important? They give us our best chance of getting a solid solution that solves the right problem and is accepted by its intended users -- our best chance to make the business bigger, better, more efficient. Couple that with realistic measurements of what is done and is not, leadership can now make informed decisions on how to move forward based on actual work already completed.

Do we recognize when we are done?

Sounds silly doesn't it? Do we know when we are done? You might be surprised.

First we have to agree on what being "done" really means. Many believe that "done" is completing all the requirements. I do not. The goal of the project is to solve a set of business problems. "Done" is solving them.

If we are constantly asking "Are we doing the right work?" and "Are we delivering effectively?" we are learning as we go. We will learn that some of the initial work defined is not needed; we will learn that other work we did not think about upfront is needed; and we will learn better ways to do what we are doing. The content management problem is solved when we can archive data in these 5 specific ways and retrieve it in those 4 ways. When new ideas arise beyond that, as they will, then we can ask ourselves if they are needed to solve the original problem, or if they are part of a new problem that should be vetted through a business case and prioritization process.

So what about our three projects? Here is my take.

Project Aida -- FAILED. It spent the acceptable amount of money in the prescribed time frame, but it produced a solution that few are using. It did not solve the problem; the company's sensitive information is no better protected.

Project Isolde -- SUCCESS. It spent more money and took more time than expected, but it exceeded expectations on improving the economies of the company's inventory. I am disappointed in the number of project management organizations that would consider this project a failure based solely on budget and schedule. Isn't the business better off because of this project? I'd take the overspend and budget overrun any day for a better result.

Project Tosca – SUCCESS (sort of). Isn't this what we want to have happen? We recognize that a project is not solving the problem it was intended to so we stop and regroup. I've seen way too many organizations that would continue to execute this project because it was not safe to suggest shutting it down – that would be an unacceptable failure. I consider it a success because the project was executed in a way that allowed it to be shutdown. We can't tell if we are doing the right work or if that work is leading us to the solution we need. Why wouldn't we shut this down? That is a win for the organization, we stopped the on-going spend for something that was not going to produce.

Many believe that scope, schedule, budget are the keys to determining the success of a project. I do not. They are indeed important, but they are constraints to manage and work within. Projects are investments, and as with any investment success is getting an appropriate return. Projects are expected to achieve a specific outcome for the business -- protect sensitive information, reduce on-hand inventory, create more targeted marketing campaigns -- did they actually do that? Did they do that for a reasonable return?

We need to focus on solving business problems and frequently examining whether the work we are completing is bringing us closer to those solutions. This is the promise of agility. Couple that with credible, proactive product management practices that discover and refine those problems, and we have the ability to better understand how to shape the future path of our projects for our best benefit.