For Project Management the end consumers are Delivery Managers, Account Managers and Project Managers. These are the individuals who will be using the system. Quality and IT team are just the facilitators for implementing the tool. Quality needs these tools so that they can shine off their processes and compliance without checking whether the process is doing any value add to the quality of the end product. Where does it lead to? An unsatisfied and frustrated team which delivers the projects.
I am not against the quality processes, I am against the implementation of theoretical processes without any practical verification. Example would be calculation of a metric which uses effort spent in re-work due to re-review of re-work. Sounds strange but that's true. Isn't re-work sufficient enough to check the quality? Project Managers get irritated with these kind of micro-checks by Quality Team.
Micro-managed quality checks are overhead for Project Management and reduces the motivation of the team. These are traditional quality checks developed with CMMi as base. CMMi has faded and lost it's charm in modern day Software Development. On the other hand if a Project Manager is asked, what is the required process, the response will be: "No process is required. Don't you trust us?" The quality process should be a mix of what is bare minimum required for Audit Compliance and a set of processes which will actually improve quality and motivation of the team. There are other means of improving quality. e.g. Incentive for the developer & team which delivers highest quality product or product with lowest number of bugs. Defect density, simple cost of quality or rework effort should be sufficient to identify such individuals and teams.
Many organizations have already realized the above mentioned aspects and are evaluating or using a completely new set of processes and metrics - Agile. However, the word Agile is highly abused word in today's Software Industry. Rather than true customer satisfaction, Agile is being used to distribute the responsibility and hence the blame in case of failure. Here the blame is partly off-loaded to customer too. Hence the overall project might seem successful when we say that it was not a problem of the team but customer was not good enough to coordinate with us or didn't participate in the review meetings. But the fact remains the same, its all part of blame game with the way Agile is going on.
Blame the team for poor quality, blame the team for delay, blame the Product Owner for poor inputs, blame the customer for not understanding what the customer needs. Real Agile indicates that one should take responsibility for his/her act. This is with the assumption that the the team is honest to take responsibility and improve and learn next time. As a matter of fact the same mistakes are repeated and it continues.
Agile means flexible and continuous adoption based on the circumstances and need. Agile means to follow a set of bendable or changeable rules which can help in sustaining and delivering quality product. Kanban is a very old but evolving Agile methodology which focuses on reducing the FAT surrounding the Project Management process and making it lean, which helps improving the motivation and efficiency of the team.
However quality of the product still remains in the scope of the individual or team. No quality check or process will improve the quality unless the individual or team is committed towards it.
Image Credit: http://dwillustration.blogspot.ca/2010/10/character-design-o-rama.html
