Software processes are a way of life for most of the organisations. But most projects in many organisations fail to follow the processes, sometimes creating process documents after the project is over. Thus they fail to realise the value provided by the processes and thus processes become just another overhead. Whereas some organisations/projects totally ignore the processes

This can be remedied using the few practices mentioned below which actually require very less time and the inherent value derived is very high. Some of these can help reduce operational time as well as reduce costly mistakes. There are seven such practices which shouldn’t be ignored in a project. These are enumerated below.

Checklists:
Human mind is forgetful, even the sharp ones tend the stress or pressure of some delivery is looming on head. Creating a checklist is a one time activity but the rewards are everlasting.

A checklist is a document listing the various tasks or activities and having a checkbox in front of each item. Checklists help eliminate the possibility of forgetting some activity and ensure all checks are in place.

Matrices:
A matrix represents data in tabular format. There are various matrices used in software industry. A matrix allows the person to see the data in a glance. This allows identification of missing conditions as well as to identify new conditions. Some of the matrices which can be useful in a project are 'Requirement Traceability Matrix (RTM)', 'Test Coverage Matrix', etc

Prioritisation:
Much needs to be done with very less time available. This calls to the need of prioritisation. Prioritisation helps us gauge and concentrate on high impact areas and gain higher rewards from limited available time

Prioritisation can be done by having a brainstorming meeting with involved parties. The other way that can be used is to use Pareto Chart. Pareto principle states 80% or effects arise from 20% of causes. Thus it involves finding these 20% causes with the help of Pareto chart.

Reviews:
Software review involves examination of code, test-cases, etc. by some other competent person. Any discrepancy identified is raised in a review report. The author either takes a corrective action or defends his view point. This exercise helps identify any issues missed by the author and also maintain standards. Also, too much familiarisation causes a person to overlook certain things. This is also termed as 'pesticide paradox'. Review by someone other than the author helps eliminate the possibility of missing something owing to pesticide paradox.

Root-Cause Analysis (RCA):
Mistakes are costly, repeated mistakes are a disaster. In order to prevent mistakes first we need to dig down to the actual issue instead of handling just the symptoms.

Finding the exact cause is imperative if we have to make corrections in order to prevent further issues.

There are multiple techniques for RCA. A well known technique is Ishikawa diagrams, also known as fish-bone diagrams.

Lessons Learnt Document:
Only a fool repeats his mistakes and the one who learns from others mistake is a genius. In software projects a mistake can cost as much as loss of project. In order to achieve this, a document enumerating all such problems faced during the project is created and is known as lessons learnt document. Lessons learnt document notes down all the issues identified via experience. This document acts as a guide for all the further project activities as well as can be used by other project members. Anyone joining the team anew should be encouraged to go through this document first.

Requirement Understanding Document (RUD):
Requirements are the starting point of any project and the prime area for inception of defects. Understanding requirements is the key to designing and developing a good software. A RUD is just that. Still the process for creation of RUD is more important that creating the RUD. The team should have a brainstorming meeting along with all the stakeholders. The end user and a business analyst have important roles to play in this meeting. The team should come up with all the possible questions regarding the use of software, clearing up the implicit requirements as well

Using the above mentioned practices/documents won't be taxing in terms of precious time. Still they can add a great deal of value to the project. Any processes are important but can only add value in the way they are used. The onus of using them effectively lies on the manager and the team members of the project.