Criteria for the Success of a Software Project - Testing Tools

When do we say that a software project is successful? Success is a perception. After a project is completed, you can ask the team members and also some persons outside the team whether the project is a success. Do not be surprised if you get different answers. It is very difficult to get an objective answer to what a successful project is.

The four criteria for the success of a project are:

  • The software must meet all the quality requirements.
  • The software must be developed within the time frame.
  • The software must be developed within the budget.
  • The relations amongst the team members should be cordial during the project execution and after the project is completed.

We will study each of these criteria in detail.


The most important requirement of a software product is that it should meet the requirements of the customer. In addition to the user requirements, the management of the development organization may put additional requirements to ensure that the product is developed at a low cost and also to ensure that the software can be maintained at low cost. If the management wants to modify customized software to make it a generic product at a later date, additional requirement may be put such as portability. In general, the characteristics of a software product can be divided into

  • Operational characteristics
  • Transition characteristics
  • Revision characteristics

Software quality triangle

Software quality triangle

Software quality triangle, depicts these characteristics. Operational characteristics specify the requirements during the operation/usage. Transition characteristics specify the requirements for its usage in other hardware/operating system environments. Revision characteristics specify the requirements for making the changes to software easy. The operational characteristics are:

  • Correctness: The extent to which the software meets the specifications.
  • Usability/Learnability: The effort/time required to learn the usage of the software. The usability of a well-designed GUI is very high compared to a menu-driven interface.
  • Integrity: The software should not have side effects (like another application does not run when the software is invoked).
  • Efficiency: Effective usage of the storage space, faster execution time etc.
  • Reliability: The software should be defect-free and should not fail during the operation.
  • Safety: The software should not be hazardous to environment/life.
  • Security: The software should not have ill-effects on data/hardware. The revision characteristics are:
  • Maintainability: Easy to maintain so that time/effort required to remove defects in the software is minimal.
  • Testability: Easy to test so that the time/effort required to test the software is minimal.
  • Flexibility: Easy to make modifications so that the time/effort required for making modifications is minimal.
  • Scalability: Easy to increase the performance of the software if the application demands it. For example, a database application that gives good response time for 10 users should be scalable for 100 users if required.
  • Extensibility: The ease with which the functionality of the software can be enhanced. If you want to add some additional features, you should be able to do it easily, and you should not say that you would rewrite the entire code.
  • Modularity: If the software is divided into separate independent parts (called modules) that can be modified, and tested separately, it has high modularity.

The transition characteristics are

  • Portability: Ease with which software can be transferred from one platform to another platform (for example, from Windows NT to UNIX) without changing the functionality.
  • Reusability: If portions of the software can be used in some other application with little or no modifications, the software is said to be reusable.

Interoperability: Ability to make the software exchange information with another system and make use of the information transparently.Ideally, every software product must have all the above quality characteristics. However, depending on the application, only a subset of these characteristics may be required. Before starting the development of a software product, a requirements specification document is written clearly indicating all the quality requirements. After the product is developed, the software has to be tested to ensure that it meets the requirements of the customer and also the internal requirements. To differentiate between the two types of testing, the two terms 'validation' and 'verification' are used. Validation is used to check whether the software meets customer expectations. Verification is used to check whether the software conforms to all the specifications.

The customer is not bothered about the re-usability or portability of the software as long as it meets his requirements. So, the customer independently carries out an acceptance testing of the software. To meet the deadline given by the client, sometimes the software is delivered compromising on quality. This leads to increased maintenance costs. Generally the maintenance cost is much higher than the development cost. So, to make the software project a success, the first and foremost important requirement is the quality of the software.


To deliver the product within the time frame without compromising on quality is another criterion for the success of a project. Many clients are ready to pay more money if necessary but they do not like to compromise on time—after all time is money. But then, there is a problem. While giving the project proposal, the development time is estimated to be, say, 6 months. The client wants it in 3 months. To grab the order, in most cases, the manager will agree. Once the commitment is made to the client, it is the manager's responsibility to see that the project is completed within 3 months, then only the project is a success. Here, the perceptions differ—the manager may argue that even if it is delivered in 5 months, for him it is a success because it is within his initial estimate. But the fact remains that the customer is the ultimate reference. More than the project team's perceptions, the perception of the customer is important.


Project costing is an extremely complex process. While giving a project proposal to the prospective customer, it may not be possible to foresee each and every item to be costed. The initial estimate for the project cost may turn out to be erroneous for many reasons:

  • The initial estimate of the number of people required may be incorrect.
  • The initial estimate of time may be incorrect because of which penalty has to be paid.
  • There maybe unforeseen technical problems because of which additional personnel or external consulting services may be required.
  • There may be changes in requirements due to which additional effort is needed.
  • Due to oversight, costing under a particular head might not have been accounted.
  • There may be changes in government rules as a result of which the cost would go up (e.g., increase in sales tax).
  • Personnel leave in the middle of the project, because of which the schedule is likely to be affected.

The reasons can be many more. A meticulous planning and foresight are required to do the project costing. As experience is the best teacher in project costing, the project manager has to document all the factors that affect the project cost while executing each and every project. The process of cost estimation needs to be improved continuously.

Another important aspect in estimation is the risk items. During project proposal preparation itself, the manager has to analyze the likely risks and the corrective action to be taken and account for such costs as well. For instance, it is now common in some organizations for people to leave in the middle of the project. The manpower attrition is a risk item—the corrective action is to have backup personnel i.e., put additional personnel from the beginning of the project itself.

Note that the software has to be developed within the planned cost of development. If there is additional expenditure, it eats into the profit margin, which is not acceptable to the senior management.


The software project manager has to ensure that cordial relations are maintained amongst all the people throughout the execution of the project. Sometimes, the project is completed as per schedule within the budget and quality software is delivered, but the relations are strained. The manager has to ensure that good relations are maintained between: Project manager and the team members,Project manager and the top management

  • Team members and the client/end users
  • Development team and other teams such as quality team, test team etc.

It is a very challenging task for the manager to take all these groups of people along with him during the execution of the project. The most important element in managing the relations is 'expectations management'—how do you manage the expectations of these groups during the execution of the project? It is a complex task and many people opine that software project management is more of personnel management rather than technical management.

Consider a project, which involves development of a software product that will take the whole world by storm. The product is conceived and our businessman (the top management, as we call him/them) asks the project manager to bring out the product in just a few weeks. Generally, we like to give only good news to the top management, so we never say 'no' because most of the people do not like to listen to a no. The project manager says 'yes' knowing fully well that it cannot be done. If we keep the expectations of the people very high and suddenly drop them, it is a bad expectations management. One can imagine the problems that will be created by giving a commitment that cannot be fulfilled. Tempers are lost, sometimes jobs are lost, careers are ruined and the software development environment turns into a battlefield which leaves many'dead'. Is it worth working on such projects?

Many project managers do not inform the clients the correct status of the project, but keep telling 'everything is fine, we will deliver as per schedule'. And, finally when the actual day of delivery arrives, the customer is informed that it is likely to take a few more days. This is a wrong strategy because raising the expectations and suddenly giving a shock is very dangerous.

We need to tell all the persons concerned, the client and the senior management, the reality of the development status as well as the issues related to quality of the software. Similarly, the manager has to get the right inputs from the engineers and make the engineers open up and express their opinions so that they give realistic dates for development and also the realistic picture of the quality of the software. Any issues related to the quality have to be resolved through discussions with the quality team and the test team rather than fighting endless battles.

It is very common during software project execution, for the project managers to shout at the engineers, the top management to shout at the project manager, the client threatening the project manager that he will cancel the order and so on. These unpleasant situations are due to lack of a process-oriented approach to software development on the one hand and due to improper relations management on the other hand.

Though relationship management is one of the most important tasks of a project manager, it is not given enough emphasis. But, one has to remember, a project can be considered a success only if at the end of it, everyone associated with the project is happy to have been associated with the project.

To summarize, a software project can be considered a success only when quality software is delivered within the time and within the budget and the execution goes smoothly without affecting the human relations.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Testing Tools Topics