Educate and Implement A New Process

Many years back, while trying to introduce formal project reviews, one of the project managers asked, " I interact with my manager on daily basis. We interact even in lift and in lunch. He knows pretty well the status of the project. Why is a formal review needed?". The answer is that

• There is no record of what was discussed in the lunch or lift and if it covered all the necessary aspects
• There is no formal report capturing the snapshot of project's health as discussed and agreed (if at all) in the lunch or lift
• We don't even know when exactly was the last time, such a lunch or lift meeting happened

That's exactly the value of Periodic, Structured and Formal reviews. There have been many such questions while rolling out other initiatives like capture of effort or defect or Code Quality data. You might have faced many responses (excuses) while trying to influence the practitioners to adopt the new process:  

• My client just wants a good quality product. He doesn't want to pay for processes 
• Team is already loaded. They will get demoralized if we ask them to do this extra process 
• Oh! Quality means a lot of reviews. We don't have so much time. 

The fact is that the success of any Initiative lies in it's adoption. Ideally target practitioners are explained the imperatives and spirit behind the initiative and the new process using formal communication including training sessions. Many a time, Senior Management is leveraged for these. 

However, many a time given the management's urgency to implement the new process, it may resort to 'mandating' the process (the 'tell' way) and "volunteering" practitioners into the process instead of soliciting their support. While “Directive” approach may help short-term acceleration and help as a jump-start, for long-term sustainability, processes need to be “sold” than “Told”. 

Any amount of “Selling” may not beget 100% buy-in. As in any product, even initiatives have Promoters, Passives and Detractors. To catalyze the change, it would help to enroll a few early-adopters/ enthusiasts as ambassadors who are “Promoters”. These people need to have a positive orientation, openness to provide initial feedback and also suggest alternatives. Once a critical threshold volume is achieved, it can propel further adoption to cover the passives. Some detractors may remain at the end. 

As seen below, initial phase may take more time i.e. to show early benefits, onboard a few "Promoters" etc., 2nd phase - more a 'Volume' game of converting the "passives" and the 3rd part where ROI has to be evaluated for achieving the 100th % Completion.

Now, coming back to the questions (excuses) on the top, capturing here a few amusing excuses I have handled and the common-sensical response to it. 

Excuse	Common-sense/ Response to the Excuse
My client just wants a good quality product. He doesn't want processes	When I purchase a car, I don’t pay explicitly for the brake test done on the car. But I expect the car manufacturer to do all necessary tests as a part of manufacturing the car.   Process is as internal strategy of the vendor to deliver Quality to the client.
Team is already loaded and will get demoralized if we ask them to do this extra process	Typically, new processes/ initiatives will need the team to capture certain extra info/ data towards certain org-objectives. 1.      The team has not been explained the same. Further, this can be because the 2.      Data is not being used for what it has to be used, after collecting the same from the team. 3.      It is true that collecting data involves effort. However there is a ‘least count’ for every parameter. For ‘Effort’ data in software development project, least count is about 30mins i.e. it is enough if company knows that a particular program took 2.5hrs to write. Capturing a data that it took “2Hrs 12Min 20Sec” is not of any practical value. Data collection mechanism should be efficient enough to deliver ROI (Return on Investment). 4.      Team is overengineering the expected process and hence some optimization may help
Client is demanding productivity for 9hrs/day and hence no time is left for any extra work. Hence I can't accommodate these	No company, including client’s, can interfere in the internal processes of another company, including vendor’s. The same team which finds this excuse, finds enough time to discuss appraisals the formal discussions, not to mention the enormous time spent on informal discussions. However, as a vendor, we must design the data capturing mechanism to be as light as it can be and benchmark with industry practices.
Ø  Oh! Quality means a lot of reviews. We don't have so much time. Ø  Processes are needed for producing documents which are needed for audits and certifications Ø  Why do we need these practices? Not many customers are asking for Quality Certifications these days.	These are the dinosaurs that have somehow survived their era and still walk around in the modern era. Response to these, Ø  Quality means efficient processes to deliver within cost and on-time. Not necessarily 0-defects. Ø  Processes, needed for achieve these, are needed by the client first and then the vendor. Ø  External auditor, if any, is only a third stakeholder.
We follow Agile. So we don’t need Quality	These are also dinosaurs that belong to the old paradigm that “Quality means Waterfall” and “Agile means non-Quality”. On the contrary, Agile is its own structured methodology and prescribes its own ceremonies. Plethora of tools like Jira, Rally etc. support these processes such as backlog, Release, Sprint, Stories etc. Atheist has his own ‘Code of Conduct’ and needs to comply to it.
Right now, my project is in bad situation. Once we’re out of it, we will definitely follow Quality processes	This is as wise as saying that since everyone on the road is in a hurry, let’s switch-off traffic signals during peak hours. We will follow traffic rules in the late night when all the traffic subsides. Doctor is needed only when patient is ill.
The pseudo-perfectionist: If I do something, I do it perfectly or I don't do it. From my next project, I want to follow Quality practices with perfection.	Don’t wait for perfection. Start now & improve. Agile – the contemporary paradigm – is all about launching and MVP (Minimum Viable Product) and continuously improving it.
My project is different and hence this doesn't apply	Validate the claim by checking against the applicability scope of the initiative. If it is applicable, education is the issue.
This was tried in my previous org (or in the same org sometime back). It didn't work	As long as the current initiative has been thought through well based on the current context, there is no need to project the past into the future.

Moreover, One of the common issues in practitioners adopting the new process is a mismatch between the "Space-Time horizon" of the initiative and maturity of the person. For example, the new process may be designed to benefit the entire organization over a long-term. The “What’s in it for me” Or “Can the benefit come-in immediately?” employee may not buy into it easily. 

Symptoms to identify Detractors:

• My project is different and hence this doesn't apply
• This was tried in my previous org (or in the same org sometime back). It didn't work

Navigating through these takes a new process to decent adoption level. However the efficacy of process needs to be continually monitored for identifying the processes to be continued/ improved/ revamped/ retired. To do these, processes have metrics defined to indicate various things like it's adoption to performance.