A process is a collection of related and structured tasks that produces a specific service or deliverable. It is best understood by a flowchart of a sequence of activities. We use processes in our day-to-day activities such as cooking a meal or crossing the road or driving a vehicle. Some of these are so institutionalized that they have become a way of life for us and so we don’t equate them with processes. Examples of processes in IT are Requirements Development, Risk Management, Code Review (a.k.a. Verification), Root Cause Analysis and Production Support (a.k.a. Service Delivery). Processes are defined to facilitate consistency and predictability of quality and timelines. At a higher level of aspiration, processes are defined to enable continuous improvements in effectiveness, efficiency, internal checks and compliance to policies and regulations.
From discussions with quite a few IT companies and teams, I have learned that Project Managers by and large “do not follow process”. Documentation is not done, metrics are not gathered accurately (if they are gathered at all), code is not tested properly . . . the list is actually predictable. Delivery and Quality leaders have come close to throwing up their hands in dealing with this problem. Auditors hand out NCs in the hope of influencing PM behaviour – this accomplishes little more than getting themselves branded as cops. Companies organize training programs on Process Adherence, Quality, Six Sigma, ISO 9001 and CMMI with the same objective: to ensure that PMs observe process and thus bring in consistency and high quality to all their project deliverables. Despite all these efforts, it appears that many Project Managers resist this organizational expectation, nay, mandate.
What can be the reason for this? We frequently think of two possible reasons: the errant PMs have an attitude issue and willfully ignore published processes. Or they possess inadequate knowledge and understanding of the process that needs to be followed. I suspect there is a third reason in many cases. Is it not true we do things when we believe in them, when we see the value in doing them? Could it be that the Project Manager who does not follow process is actually not convinced of its benefits?
A PM I met recently tells of wondering why in the world he has to collect so many metrics in his project. He did not know where these metrics ended up after his weekly submissions. Another PM was certain that he was submitting metrics only to get the Quality team off his back. Yet another PM felt that the processes he was asked to follow were taking away from his ability to innovate, that they were a totally unnecessary overhead.
A few clients also may not understand the benefits of following relevant processes. One PM told me, “The customer told me to just send the darn code already. He was not interested in our documentation. I tried telling him that documenting the changes we made to the code is a part of our delivery process, but he was in no mood to listen to me. He wanted the code yesterday.”
Project Managers need to be taught the reasons behind the processes they are being asked to follow, not just the details of the process. We need their “buy in”. If they don’t believe in the processes they follow, why should their team believe in them? And how can we expect the PM to articulate the reasons they follow a certain process to their clients?
So what exactly are the benefits of following process?
- It prevents us from reinventing the wheel. If your company has laid out a process for a critical activity, it means that you do not have to worry if all the inputs have been sought, if the right persons are engaged and what to do once the task is completed. The PM’s time is more usefully spent on identifying areas of innovation and improvement.
- It allows us to identify accountability and opportunities for oversight. Clear roles and responsibilities help avoid misunderstandings and slips through the cracks. A good process will also help in identifying check points for monitoring progress. Problems and issues can be detected early.
- It reduces failures in project management. Uncontrolled changes in requirements (a.k.a. scope creep) are avoided. Acceptance criteria from the customer on important deliverables are clearly captured and quality criteria (such as completeness and critical steps) are documented for all to see. Timelines and scope are well understood. Risks are managed effectively, as in the documentation example above.
- It provides opportunities for improvement. Relevant operational metrics can be captured and used by the organization for more effective estimation tasks in the future.
Processes do not exist in a vacuum. Their relevance and usefulness cannot be taken for granted. Occasionally, a process may involve an activity that is no longer pertinent or required. Process resistance can also arise when inappropriate or superfluous processes are shoehorned into certain projects or by “one size fits all” approaches. There have been mistakes at both ends of this spectrum: process overkill in smaller/lower complexity projects and process inadequacy in larger/high complexity projects. Quality teams should provide guidance on how to tailor processes to suit a context, and project teams should be allowed the elbow room to tailor processes for their project (with the appropriate oversight and audit to ensure that the privilege is not abused). Such measures will go a long way in moving Project Managers from indifference or reluctant compliance to wholehearted commitment.
Ravi Bhuthapuri
April 10, 2011