Sucessful software project
A student asked me: How do you know if a software project is successful or not? If the software run well, is it successful? If the code passes all tests is it successful?”
Answer: A software project is successful if it is delivered to customers on time, within cost, has all functions required by the customer, has low defects, and it provides value to customer. Time and cost are related to each other. The time the team spends on the project is also big part of the cost. The other is the labor cost and if the project needs more people than it was planned for than it will cost much more. If the project is late (Need more time) than it will cost more. Of course either the customer will have to pay more for it or the company will have to come up with additional money.
The software must have all functions that the customer asks for in the software requirements specification (SRS) and more because there are many “derived functions” that the team comes up with in addition to the required functions to make the final product works better. Of course, it may cost more as the team has to spend extra time for them. No software has “zero defect” but there is a clear difference between software that works, with few defects that can be fixed and software that has so many defects that take much more time and efforts and maybe unusable. Even software that is delivered “on time, within cost” is not actually finished when it is delivered to customer and it is the customer will have to find the missing functions and send it back to be fixed.
The critical issue is: Are customer using it? How much value is it producing in customer's business? How much it help the customer solve the problems? Many software people do NOT care about the value issue because this is not documented in the SRS so it is “not our problem”. Software team creates it, and it works, so if they do not use it, then that is their problem, not ours. This is NOT a good way to achieve customer's satisfaction because software team need to understand why the software is not being used? Maybe it is too difficult to use? Then it is a usability issue. Perhaps the way customer document the requirements is NOT good so the software cannot solve the problem. Then it is a Poor requirements elicitation issue. Whatever the reason, if the software is NOT being used, it has no value and if you are a professional software developer, you will find out the reason and propose a solution to make sure that the customer will be totally satisfies. If the customer is happy, guess who do they will give the next project to?
Sources
- Blogs of Prof. John Vu, Carnegie Mellon University
