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.
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!