Wednesday, March 07, 2007

What Is a Successful Project?

What Is a Successful Project?

A few years ago I would have promptly answered that a successful project is on time, on budget, and does what the customer intended it to do. Over the course of the last few years though, I've learned that things aren't quite so simple. Developing software is a human activity and it's taken me a while to figure out that 'success' is a profoundly subjective notion.

Let's say youre a painter and you've been hired to paint a house. You go in, do the job, and when the customers look at what you've done, all you hear are complaints: They can see a few rivulets of paint near the ceiling, the paint job is not perfectly even everywhere, etc... The fact is that there's no such thing a s a perfect paint job so it's up to the customer and the painter to come to an understanding of what's reasonable and what's not. Trying to settle the matter confrontationally is unpleasant for both sides and should only be a measure of last resort.

The same is true in software, only more so. The degree of sophistication to which any given requirement can be implemented can vary enormously and it's important to come to a general understanding with a customer about what is expected and how much time and money will be involved. As a simple example, let's consider Web form validation. A simple way to validate data entered on a Web site is to have the application issue error messages that are displayed when a form is submitted. However, in addition to this basic type of validation, the customer may want validation to occur 'live' as the user is filling in fields on a form - in practice this rquires either client-side validation with Javascript or asynchronous server calls using 'ajax'. The customer may also want automatic filtering on fields to prevent the user from entering incorrect data - a typical case in point is filtering provinces/states once a country has been selected, and then additionally filtering cities once a province/state has been selected. Depending on what the customer really wants, a story may simply state the validation rules for a given form or it may describe these kinds of things in detail. In the first case, XP would indicate the simplest approach applies and the customer would have to draft a subsequent story to enhance validation. In the second case, fancy validation would have to be considered a motherhood story - something that is an essential part of the application right from the start and cuts across all stories (other examples of typical motherhood stories include Security, Performance, Failover, etc.). Thus, the Fancy Validation motherhood story would be an aspect of development for every form and support for it would have to be built into the code framework fairly early on.

Every development activity can be approached horizonally or vertically. Implementing fancy validation right away across the board would be an example of a horizontal approach. The vertical approach would suggest getting substantial parts of the application working satisfactorily before contemplating such niceties. Agile development tends to emphasize a vertical (get it working end-to-end first) approach, but it's essential to pay attention to the customer. Perhaps the customer can be convinced to alter priorities; on the other hand, the customer may know exactly what he or she wants and having raised the matter and given appropriate feedback with respect to risk and cost, etc, it would be the developer's job to carry out the customer's instructions.

In the previous paragraph I was trying to describe the kind of situation where the developer may think that everything is ok but the customer isn't happy. It's even possible the customer is being unreasonable but the bottom line is that a project where the customer is not happy cannot be a success, even if it appears to meet the stated requirements and is also on time and on budget. Now let's suppose the developer and the customer meet to discuss a new project. The developer provides an estimate of 6 months. 2 months into the project, the developer shows the customer the burndown chart which clearly indicates, given the progress made so far, that the project is much more likely to take about a year. There could be many reasons for this to happen. Perhaps as per the earlier discussion, the customer wants features to be implemented in a more sophisticated way than anticipated. In any case, the customer decides that despite the delay, the project is worth continuing. At the end of a year the project is delivered to, and accepted by, the customer. On one hand this project has exceeded its initial estimate by 100%! On the other hand the customer made the decision to continue and is satisfied with the result. It's probably reasonable to suggest that this project is a success, in spite of the budget overrun.

While being on time and on budget is important, and it's also important to satisfy the stated requirements for a project, the reality of software development is that constant communication is essential. Ultimately only the customer and the developer can together decide whether a project should be deemed a success or a failure. There doesn't exist any infallible objective measure of success. If you ignore customer expectations, you may end up delivering something on time and on budget that the users aren't happy with, and then you'll spend a huge amount of time arguing over whose fault it all was - was development not getting the requirements right or was the customer not being specific enough: The kind of confrtonational quagmire one often runs into in waterfall-ish projects. Agile software development provides the tools to resolve these problems, but both the customer and developer sides need to put in the work to strike the right balance between "lots of cool bells and whistles" and "a lean, focused, no-frills piece of software that does what it's supposed to do." It's also a good idea to always think about the difference between the horizontal and vertical styles of development. Some features are best implemented horizontally and others vertically. In an agile development context such decisions ought to considered frequently and reviewed often. I hope this helps you to make your next project a success - whatever that means!

2 comments:

Justice~! said...

Vlad is
BACK
FROM
THE
DEAD!!

I *totally* agree with everything here. It's amazing to see some companies so determined to stick with waterfall, even after many catastrophic failures! I can't for the life of me figure out why...

Kelly Waters said...

Great post Vlad! I absolutely agree that success is more than delivering great software on time and within budget. You also have to satisfy your customer in terms of communication and approach, and ultimately the intended benefits must be realised too for the project to be a real success.

Kelly Waters
http://www.allaboutagile.com