Redefining project success
When can one say that a project has failed? Although the answer to this question depends on the criteria used to measure project success, most project managers would not think the question (or its answer) could raise much controversy. In this post I discuss why the issue of project success is more ambiguous (and contentious!) than seems at first sight.
The crux of the issue lies in the observation that managers and programmers often use different criteria to judge project outcomes. As Robert Glass states in his wonderful book on facts and fallacies of software engineering:
There is a disconnect between management and their programmers. In one research study of a project that failed to meet its estimates and was seen by its management as a failure, the technical participants saw it as the most successful project they had ever worked on.
I’ll expand on this statement, drawing from Glass’ book, the research study he mentions, and personal experience.
Much of Glass’ discussion is based on a paper by Kurt Linberg entitled, Software Developer Perceptions about Software Project Failures: A Case Study. The paper details a lot of information about the project, its context, reporting structures and the composition of the team. Although this is important from the perspective of a research study, it is more relevant to look at how the various project stakeholders perceived the project.
First a few words about the project that Linberg studied. The project was aimed at creating a software-driven medical device. The management-approved schedule for the project ran over 14 months, but the project actually took 27 months to complete. Further, the software development portion of the product was originally budgeted at a little over a million dollar but ended up costing more than four million! In view of this there’s little surprise that management deemed the project a failure.
What about the programmers? Linberg interviewed/surveyed many of the developers who were a part of the team. One of the questions he asked was: what was the most successful project that you have worked on, and why? Surprisingly, more than 50% of the team answered that the project described above was the most successful one they had ever worked on! The reasons they gave were revealing:
- The project was a technical challenge.
- The product worked as intended.
- The team was small and high performing.
The following quote from one of the team members says it all:
[the project] was the most successful because of what we accomplished. The code was more solid than any I have ever written. The verification testing was extensive. All the other places that I’ve worked relied on the software developer doing the testing. I always thought that I could have done more testing. I also really enjoyed the people I worked with. I also think that it was the best-managed project of any that I’ve experienced. Also, the product was well designed. I did not see the scope creep that is so prevalent on other projects. I never felt pressure from schedule. I would ask the project manager and technical lead if we were in trouble. They would be cool, calm and collected. They emphasized the importance of doing the best job we could do. We were able to focus our energy on the tasks at hand!
So, we see a complete disconnect: according to (majority of) the developers the project was success because it delivered a quality product, but by management metrics of budget and time it was a failure!
Bridging the gap
To bridge the disconnect between management and developers, Linberg asked the team members why the project was late and over-budget. The following reasons were offered:
- Unrealistic schedule and expectations.
- Poor understanding of scope (underestimating the effort required)
- Lack of resources
One of the team members summarised the schedule situation as follows:
Unfortunately, I believe program management established over-ambitious and incorrect expectations during early meetings with the executives. In reality, we had no idea how long it would take to develop this system. It is a real tribute to this team that they pulled together and developed an excellent product.
Another had this to say about the poor understanding of scope / lack of resources:
We ignored history. Although we didn’t have experience estimating this type of development, there are groups of people in our building that have been working these types of applications for years. They typically have 6 to 10 people working on their applications. How could management not see that assigning one or two people and constraining the schedule would be unrealistic?
Yet, the team thought that the project was managed quite well. Quoting from the paper:
Compared with other projects, the software developers believed the project management on the project was between average and best. In two cases, the software developers said it was the best that they had experienced. One of the software developers that gave high marks for the project management stated that the project manager had good technical skills and could manage time lines.
In fact, one of the developers said:
The project manager, team lead, and program manager each provided leadership. The leadership worked very well together. The program manager knew his strengths and his boundaries. He left the software and firmware management to the software project manager. The software project manager was not threatened and left technical decisions to the team lead. We were always told of changes before they happened. The leadership was the best that I have experienced in my 14 years.
The overall impression that Linberg conveys is that the project was well-managed. So where is the problem?
The programmers felt that upper management was largely responsible for the disconnect. This makes sense: front line managers rarely have the clout to set overall allocations of time and resources. They have to work within the parameters set by executives.
Based on this, Linberg proposes a new definition of software project success, which is based on industry averages rather than arbitrary metrics.
|Failure||Does not meet customer expectations||Not learning anything that can be applied to future projects|
|Low Success||Below average cost, effort, and schedule performance compared to industry AND meeting quality expectations||Some learning can be applied to future projects|
|Success||Average cost, effort, and schedule performance compared to industry AND meeting quality expectations||Some learning can be applied to future projects and some artifacts can be used on future projects.|
|High Success||Better than average cost, effort, and schedule performance compared to industry AND meeting quality expectations||Substantial learning can be applied to future projects and a large number of artifacts used.|
|Exceptional Success||Meeting all quality, cost, effort and schedule expectations.||A Cancelled project cannot be considered an exceptional success.|
This definition begins to bridge the chasm between developer and senior management perceptions of project success. It does so by broadening the definition of success. The current project management-driven definition is too narrow because it takes only one perspective into account – the perspective of those who hold the purse-strings. Such a definition cannot work because it completely ignores the viewpoint of those who know software development best: the developers.
Linberg’s case study highlights the fact that there can be a huge gap between how developers and managers view project outcomes. Interestingly, the factors that cause the gap are usually present from the start of the project: unrealistic schedules, poorly understood scope and lack of adequate resources. One could hypothesise that most of the projects that “fail” do so for one or more of these reasons. Also interesting is the fact that even such “failed” projects can be deemed successful in the eyes of developers because they see things from a different perspective: what was learnt and what can be used again. Seen in this light, a project that goes over-time and over-budget can be successful because the experience gained can be used on future projects.
I’ll end with a story from experience. Some years ago I was a part of a team developing a product for a telecom software company. The product was ambitious in scope, and the timeline and budget tight. Nevertheless, the team looked forward to the challenge of designing and building a product from scratch. The architect, project manager and several members of the development team (excluding me) had years of experience in building software for the telecom industry. The product specs were developed by domain experts. Management’s initial intentions were good: they assured the dev team that they (management) knew that it would take time to develop a solid product from the ground up. To reduce risk it was decided to build the product using incremental approach with monthly deliverables.
Progress was slow but steady. Unfortunately, as the product started taking shape, business reality intruded: the sales guys who had been working hard had not been able to convince anyone to sign up. Funds began to dry up and management responded by cracking the whip. Predictably, the project started to unravel and was canned a few months later. Officially the project was deemed a failure, yet many on the dev team believed that a) it was one of the best projects they had worked on b) they had learnt a lot and c) what they had learnt wouldn’t go waste.
Was the project a failure? I suppose the answer is that it failed from a purely commercial standpoint. From a broader perspective, however, it fits quite neatly into Linberg’s definition of a successful cancelled project.
Perhaps it is time to rethink the definition of project success.