Top 5 Reasons why we need Project Management Processes

We all follow Project Management processes in our projects. Mostly, they are tailored to meet the requirements of the project. Some projects need tighter control and more stringent processes that might have been mandated in the contract, while some need processes sufficient to self manage and execute the project to meet the deadlines and quality standards. Whatever be the reasons, if we don’t follow certain processes, it will definitely jeopardize the project. Here are top 5 reasons why we need to follow processes:

1)  To meet the deadlines:  This is first and foremost. Many times, there are delays in deploying the project at the client’s place only because there is no process defined for uploading the software or patches in the customer’s environment. Important steps like build packaging, testing the smooth installation are left out if these are not mentioned in a standard to do checklist. This can cause the team to run around for last minute activities that may result in more problems identified at the last minute. This inadvertently delays the final delivery of the project or product to the customer.

2)  To maintain the right quality: This one also tops the list and is again related to point 1. The difference is when certain processes or tasks are missed out and the team goes ahead to install the software/ product at the customer’s site. This ends up with high number of defects being raised at the customer end. Some of them can be precarious such as an interactive website not opening at all for the end user, or incorrect amount of cash being dispensed by the ATM machine.

3)  To ensure productivity: If processes are not maintained and followed, it can result in tasks or activities being identified in an adhoc manner with managers expecting team to stay late and complete work that could have been otherwise planned well in advance.

4)  To prevent re-work: Many a times, due to lack of process, the communication between team members and managers narrows down. Lots of assumptions are made. Tasks are completed with a different set of objectives in mind. E.g., Software developer ending up writing a code that result in performance issues in a mission critical product. This can cause the customer to wait for a long time for say, a financial transaction to happen and can cause a lot of dissatisfaction to the customer. The team then ends up fixing the problem in the next build or release cycle causing more re-work.

5)  To avoid blame gaming: All the above points lead to one major effect….Playing the blame game. Each team puts the blame to the previous team, or puts the blame of bad quality to production team. And this goes on in a vicious circle. Add political angle to it, and the project goes for a six. While all this could have been easily avoided by simply following right processes.