About Project Success and Failure

15 July 2009

Posted in Progress & Performance

Last week I got a number of interesting questions from Vassili Kurman, who is researching project success and failure. Vassili agreed that I would try and answer his questions in a blog post, so that it might also be of some value to me and the readers of this blog.

Here we go…

What does project success and failure mean for a development team?
In Scrum (the process I'm most familiar with) success is a happy Product Owner at the end of a sprint. Failure is an unhappy Product Owner. Note that this may not be the same as delivering what has been agreed upon at the start of the sprint. Team members may be unable to deliver what they had committed to, but with good communication the Product Owner might still be happy. And vice versa, despite delivering what was initially agreed upon, bad communication during a sprint may still lead to an unhappy Product Owner. Whatever the original plans were, the ultimate goal for the team should be to please the Product Owner at demo time. And when some sprint items aren't complete, a nice cup of coffee, a slice of cake, and a little dance might help.

What does project success and failure mean for management?
From a management perspective I see software projects as complex systems. For a complex system "success" could simply be defined as "continued existence". An organism is successful as long as it lives. A brain is successful when it is thinking. An economy is successful as long as there are people in it making a living. For software development this viewpoint means that projects are successful as long as they exist. They are successful from the day they are initiated (and financed) until the day the customer pulls the plug (and financing stops). The longer this inevitable death can be postponed, the more successful the project is.

What does project success and failure mean for other stakeholders, like the customer?
For a customer a project is a success from the moment the return on investment is positive, by which I mean that the project has paid back for its own costs. The higher the return on investment of a project, the bigger its success. This means that a project can be successful for management (it has been financed for a while), but not for the customer (when a return on investment was not achieved). But it can also be the other way around, with unhappy management and happy customers, for several reasons. But if you want to hear some examples of that, you'd have to buy me a drink first. 🙂

How is project progress monitored and who does it?
In Scrum the Scrum Master (together with the team) should be monitoring progress. It could be done in the form of burn charts, which plot the amount of work done against the number of sprints finished and the number of sprints still to go. But it depends on the situation. Some projects have no clear backlog to start with, and user stories simply materialize while the project is running. This makes it hard to draw burn-down charts (though burn-up charts would still be possible). It doesn't really matter, as long as the Product Owner is happy after each sprint, and management is happy that the project is financed, and the customer is happy and expecting a return on investment.

What metrics are kept to monitor the software development process?
The simplest useful metric is the number of user stories completed, and number of stories still to do. There are plenty of refinements (like using story points), and plenty of other metrics (like code analysis), but it depends on the project how useful it is to spend time collecting them. Metrics also need a return on investment.

What data is collected and how it is collected?
See the previous answer. I'm not an expert on metrics, so I have no preferences myself. I think it is up to the teams to decide. The costs of some metrics will be low, so return on investment can be achieved quickly.

What factors are monitored to identify project failure or success?
Happy product owners, happy managers, and happy customers. Happy team members would be nice too, but I've noticed that the correlation between project success and team happiness is quite blurry. Developers can be very happy making things that nobody in the world with a healthy mind would want or need. And vice versa, the things that are most valuable to a customer are often not the things that developers find most challenging. Finding the right balance between project success and team motivation is something that managers and Scrum Masters should concern themselves with. They are definitely not the same.

A lot (or a majority) of projects fail due to poor communication between stakeholders. How is this monitored, and are there any factors that can say that a project is slipping out of its track?
I'm not in favor of monitoring communication between stakeholders. They should learn to monitor that themselves. Experience tells me that (in our organization) team members, Scrum Masters and Product Owners are not afraid to warn management when a project is deviating from planning. It might be the first requirement for any agile organization: nobody should be afraid to tell management and colleagues when things are running out of control. When this is part of the organization's culture, you don't need to monitor projects as a manager.

Every team member is a project monitor.

(images: mpov and ogimogi)

Twitter – Subscribe – Newsletter – Bookmarks