This post originated from an RSS feed registered with .NET Buzz by Raymond Lewallen. Original Post: A successful software project can be one that is never started Feed Title: Raymond Lewallen Feed URL: /error.htm?aspxerrorpath=/blogs/raymond.lewallen/rss.aspx Feed Description: Patterns and Practices, OOP, .Net and Sql Latest .NET Buzz Posts Latest .NET Buzz Posts by Raymond Lewallen Latest Posts From Raymond Lewallen

What is the most important piece of a successful software project?  The development of the software.  Programming.  Development.  Coding.  The majority of time, resources and energy are focused on the coding of the software for a project.

Do you know what else can be considered a successful software project?  The one that never gets developed.  Let’s say a customer comes to you with a problem and you present a solution that involves the development of a custom software package.  You have an idea of the amount of money the customer is able to spend, the resources available, the scope of the project, time needed to complete and many other factors.  Once everyone involved evaluates requirements and the risks involved, the decision may be made that the project not go forward.  This is a successful project.  The right decision was made given all the input and variables.  You did your part: gather requirements, evaluating scope, estimating time, money and resources.  By making good decisions you’ve probably saved the customer a lot of anguish because they didn’t realize in the beginning what all may be required (resources, time, money, quality, scope).  You’ve helped your customer by helping make a good and appropriate decision not to continue the project at this time.  In the future, when aspects of the customers business (again: resources, time, money, quality, scope) change, the customer is likely to come back to you to again re-evaluate the customers requirements and needs again.  Perhaps this time the right decision will be to go ahead and do the project.  Everybody wins, everybody is happy.  You avoided a possible disaster by not getting greedy and not taking into consideration the customers stance.  I’ve seen very bad things happen because of situations where developers convinced their customer to invest the time, money, resources etc into a project that in the end turned out poorly because of change of scope, decrease in quality, risk assesments that are too high and “risky” that get ignored or other reasons.  These are reasons that good and frequent meetings and evaluations during a planning phase can help avoid.