Every time I analyzed a failure, I found a common thread responsible for causing the failure: “Attention to Details”. Ramcharan, in his book “Execution”, has recommended all Managers and business leaders to practice this attribute. Here’s the excerpt from the book.
“You get the impression (implicitly), that it is about doing things more effectively, more carefully, with more attention to the details. But nobody really spells out what they mean. To understand execution you have to keep three key points in mind:
• Execution is a discipline, and integral to strategy.
• Execution is the major job of the business leader.
• Execution must be a core element of an organization’s culture.”
It is very hard to internalize this; practice this principle for success. I have seen that if you are able to do this you will become the most successful person.
I was reviewing a project issue. The project was managed using Agile Scrum methodology. We finished a sprint and the customer found some basic issues with the code. The coding practices, agreed between the customer and the vendor, were not adhered to. When I asked the PM, his reply highlighted the following reasons::
• The team underestimated the task
• We got input late from the customer
• The customer had approved the demo
• While completing the demo, the team hardcoded certain things
• The team completed the work on time and delivered
• The quality aspect was not included while considering the completion date
If you sit down and look back, you will find that this is not unique. This happens every time we face some challenges. If you dig deep into the situation you will get replies like “I asked X and he told me that he would complete it, etc., etc.”
Let us look at some of the issues in this case. Before I preach, the principle let me confess “Execution is very difficult. Building the culture takes a lot of time and is also impacted by the surrounding environment. However, if you understand and internalize the principle, you will succeed in the difficult task of execution.”
How do we find issues with code? We all know the answer – “Code Review”. How we achieve effective code review without getting into each aspect of code? Some questions like the ones mentioned below may be helpful.
1. Who reviewed it?
2. How much time was spent on the review?
3. How many bugs / observations were found?
4. What reference documents were used for review like checklist, guidelines, etc…?
5. How many lines of code or pages of document were reviewed per hour?
If you ask few of them or a combination there of, I can guarantee you, you will know the effectiveness of the review. Based on your observation, you can take course correction measures before it becomes too late. One can ask many simple questions like these and can unearth the truth. “Execution is not about asking and reporting; it is about finding, exploring and helping people get into right mind set.
I think I have used simple words to explain the principle of “Attention to Details”. These questions will take a different form depending on whom you are dealing with. It will also change with the maturity of your subject. All people are not alike and they do not need the same treatment. What I am advocating here is to apply this principle differently depending on maturity of the subject.
I think this principle can get deep into our strategic thinking. This applies at each level in an organization. It is very core to our culture. If we do not have deep understanding and cultural alignment, I fear, the company is likely to oscillate like a pendulum between two extreme ends called “Success & Failure”. Sustainable success demands attention to details and its internalization into working culture.
Thursday, July 29, 2010
Thursday, July 15, 2010
Getting out of “Compliance - Correction” syndrome leads to Project Success
After getting quality certification, one of the most important ways of pushing implementation is often verifying the success with periodical audit. “NC – Non Compliance” is a buzzword in software industry. You see various forms of audit - Internal, External, Statutory etc. These are conducted periodically. The frequency of such audits could be monthly, quarterly or annually. The non-compliance instances are discussed and actions are initiated. A lot of preparation is required before the scheduled audit. The audit report is prepared and it is sent to seniors. Normally, the success is judged based on % compliance. Bosses often ask for these reports for achieving higher compliance. Although an audit is important, one question keeps coming to my mind, “Does this add enough value for sustained improvement?” One may not have a very clear answer here as very often we come across high % compliance and on the other hand we also come across project failures. I’ll name this phenomenon as “Compliance -Correction “Syndrome.
Postmortem has its own importance and so is the audit. One can learn a lot from postmortem. Do you have a better way which can be used for sustained improvement and still one uses audit for some spot checks? Let us look at an analogy of One Way Street. Few of us must have been caught by the police while entering one way street from wrong side. Police imposes fine on violators. Normally, you find police standing on the other side of the road or at the exit point. The intention is to catch violator. Can we think differently? What about if police is deployed at the entry point? And he starts stopping vehicles entering one way street from the wrong side. This will certainly have an implication over the fine collection. I argue; it will have a better impact in bringing discipline and in bringing sustained improvement in behavior. Therefore, if the goal is not penalizing for doing a mistake you can always think of a better way of doing the same thing effectively.
I think we often miss the spirit of a quality standard. We start following in words and not in spirit. It is important to remain focused on the goal and look at the spirit of these quality standards. The moment you do that “Compliance” will have a lower ranking on your priority list. You will start thinking in terms of using quality for improvement.
I am sharing here an example from one of my project experience. We had a software project where we did not have conventional coding. The existing code was to be analyzed and appropriate documentation was to be created. Naturally, this project had a different lifecycle phases. At a higher level one can look at conventional Development Life cycle phases and customize the same to suit the specific needs of the project. The same was done here. All the quality steps like unit testing, review, testing was looked upon from project necessity perspective. All the stakeholders were taken in confidence and their concurrence were obtained on the customized processes applicable to the project. The team was empowered to tweak the process for better effectiveness as they proceeded on the project. Transparency, empowerment, and continuous learning were the buzz words in the project. The SQA played a role of reformer. He worked with project team to customize the process, remained an active participant throughout the life cycle. The result was phenomenal. Fortunately compliance in the audit process was 100%. Let us look at the results:
Test Cases Success Rate 95.74%
% Schedule Variance -15.38%
TDI’s to SP Ratio – Last Milestone 1.26 TDIs/SP
In the above table TDI’s to SP ratio is the measure of defect density and negative variance means savings. The defect density improved by 66% over the first iteration. Besides the positive metrics, the Client experience was superb.
I term this as an experience which is very positive. It is not oriented towards “Compliance-Correction” syndrome. Compliance here is a byproduct. One can repeat this every time irrespective of the type of project. I suggest the following steps:
1. Customize the Quality Steps looking at the type and need of the project. This step is critical. Look carefully at Design, Construction, Unit Testing, Review and Testing. Define the specific steps for each of them. Do not forget to make SQA as a partner here.
2. Work in a culture of transparency, empowerment and participation. This sounds a little theoretical. Believe me if you attempt it, you will find your own way for doing this. Success will teach you to follow this in all projects during your life time.
3. Listen to all stake holders. Be open for change.
4. The steps finalized as a part of customization, are not final. Tweak them as you progress based on your learning on the project.
5. Look at Customer Success Factor (CSF). It may be advisable to understand the personal success factors for the immediate customer contact and integrate those as a part of your project success. Define your measurements and success criteria in line with CSF to Monitor and control.
I have seen projects failing because the team simply does not do the basic simple steps as mentioned above. My advice is to remain focused, get out of “Compliance-Correction” syndrome and follow the above steps. You are bound to embrace success.
Postmortem has its own importance and so is the audit. One can learn a lot from postmortem. Do you have a better way which can be used for sustained improvement and still one uses audit for some spot checks? Let us look at an analogy of One Way Street. Few of us must have been caught by the police while entering one way street from wrong side. Police imposes fine on violators. Normally, you find police standing on the other side of the road or at the exit point. The intention is to catch violator. Can we think differently? What about if police is deployed at the entry point? And he starts stopping vehicles entering one way street from the wrong side. This will certainly have an implication over the fine collection. I argue; it will have a better impact in bringing discipline and in bringing sustained improvement in behavior. Therefore, if the goal is not penalizing for doing a mistake you can always think of a better way of doing the same thing effectively.
I think we often miss the spirit of a quality standard. We start following in words and not in spirit. It is important to remain focused on the goal and look at the spirit of these quality standards. The moment you do that “Compliance” will have a lower ranking on your priority list. You will start thinking in terms of using quality for improvement.
I am sharing here an example from one of my project experience. We had a software project where we did not have conventional coding. The existing code was to be analyzed and appropriate documentation was to be created. Naturally, this project had a different lifecycle phases. At a higher level one can look at conventional Development Life cycle phases and customize the same to suit the specific needs of the project. The same was done here. All the quality steps like unit testing, review, testing was looked upon from project necessity perspective. All the stakeholders were taken in confidence and their concurrence were obtained on the customized processes applicable to the project. The team was empowered to tweak the process for better effectiveness as they proceeded on the project. Transparency, empowerment, and continuous learning were the buzz words in the project. The SQA played a role of reformer. He worked with project team to customize the process, remained an active participant throughout the life cycle. The result was phenomenal. Fortunately compliance in the audit process was 100%. Let us look at the results:
Test Cases Success Rate 95.74%
% Schedule Variance -15.38%
TDI’s to SP Ratio – Last Milestone 1.26 TDIs/SP
In the above table TDI’s to SP ratio is the measure of defect density and negative variance means savings. The defect density improved by 66% over the first iteration. Besides the positive metrics, the Client experience was superb.
I term this as an experience which is very positive. It is not oriented towards “Compliance-Correction” syndrome. Compliance here is a byproduct. One can repeat this every time irrespective of the type of project. I suggest the following steps:
1. Customize the Quality Steps looking at the type and need of the project. This step is critical. Look carefully at Design, Construction, Unit Testing, Review and Testing. Define the specific steps for each of them. Do not forget to make SQA as a partner here.
2. Work in a culture of transparency, empowerment and participation. This sounds a little theoretical. Believe me if you attempt it, you will find your own way for doing this. Success will teach you to follow this in all projects during your life time.
3. Listen to all stake holders. Be open for change.
4. The steps finalized as a part of customization, are not final. Tweak them as you progress based on your learning on the project.
5. Look at Customer Success Factor (CSF). It may be advisable to understand the personal success factors for the immediate customer contact and integrate those as a part of your project success. Define your measurements and success criteria in line with CSF to Monitor and control.
I have seen projects failing because the team simply does not do the basic simple steps as mentioned above. My advice is to remain focused, get out of “Compliance-Correction” syndrome and follow the above steps. You are bound to embrace success.
Thursday, July 1, 2010
In the Wonderland of Quality Certification
I was a student of engineering. I have often heard student’s talk, “what principles are taught in class room and what get’s implemented in life are two different things”. This is because of the failure of implementation. I have a different opinion on the subject. I have always found that whatever principles are taught, they can be applied in totality in practice. The gap is often found in understanding and putting the principles in simple steps for implementation. The art of putting a principle in simple steps for implementation and the passion for implementation are the two keys for success. This is same as having an Engineering degree and being an engineer. I studied engineering and regularly scored high grades in Design, Applied Mechanics etc. But my work life began in Industrial Engineering field. I never practiced Design principles in my life. In practical sense I have an Engineering degree but I will not call myself an Engineer. To become an Engineer you need practice, an art of applying the principles in your practical life.
If I look at software engineering and quality movement, I often think the industry is generally suffering from similar “Degree Syndrome”. CMM, CMMI and ISO are the standards which have brought excellent principles in life. Many companies have graduated and have passed the examinations; the certification process. Rarely companies have applied these principles fully and reaped benefits. All these standards give you short of curriculum. The practitioner has to understand the principles, pass the exam and practice the art of implementing in real life. First two things always happen but the practice is always a victim. That’s the reason; many companies having CMM level 5 certifications are not able to produce consistent results.
Malcom Gladwell in his book “Outliers” has talked about a practice 10,000 hours to become expert in any field. I think this principle applies perfectly in quality implementation as well. In order to make the process seamless with the workflow, the company needs a practice of 10,000 hours or more. Practice has to be in such a way that it can be synthesized and can create a learning experience too. Project Managers often tell, “Let me complete the work then we will do the documentation”. If you hear such words in any company then you should conclude that the company lacks many more hours of practice before it reaches the level of maturity in applying the principles which the degree; certification has provided. The result will never come until one has attained a perfect integration of process in work flow. The work and process have to be seen as a single entity and not two separate tasks. As long as they are seen as two separate tasks, the effectiveness of process rigor will be farfetched.
I would like to give a simple analogy of process integration with work. Let us take a payment transaction in a privately owned company. The payment assistant normally makes payment on authorization of the payment. There is a process of request, authorization, verification, payment and finally acknowledgement. The person making the payment considers all these as a single process of payment. Even if the owner asks for 10,000 rupees, the payment assistant creates a voucher and gets his signature or signature of his secretary before making any payment. This is a perfect integration of documentation with the workflow. You find such process implementation work flawlessly.
I therefore suggest implementation is a bigger task then getting certification. One needs to get out of “Degree Syndrome”. Getting a degree is the first step. Implementation of the principles needs understanding of the principle, putting them in simple steps and finally nitrating with the overall work. This simple principle can act as a guide for process implementation and therefore leads to success. Just ensure that the basics are being done, they are integrated with work, documentation is not separate than the work; you are bound to succeed.
If I look at software engineering and quality movement, I often think the industry is generally suffering from similar “Degree Syndrome”. CMM, CMMI and ISO are the standards which have brought excellent principles in life. Many companies have graduated and have passed the examinations; the certification process. Rarely companies have applied these principles fully and reaped benefits. All these standards give you short of curriculum. The practitioner has to understand the principles, pass the exam and practice the art of implementing in real life. First two things always happen but the practice is always a victim. That’s the reason; many companies having CMM level 5 certifications are not able to produce consistent results.
Malcom Gladwell in his book “Outliers” has talked about a practice 10,000 hours to become expert in any field. I think this principle applies perfectly in quality implementation as well. In order to make the process seamless with the workflow, the company needs a practice of 10,000 hours or more. Practice has to be in such a way that it can be synthesized and can create a learning experience too. Project Managers often tell, “Let me complete the work then we will do the documentation”. If you hear such words in any company then you should conclude that the company lacks many more hours of practice before it reaches the level of maturity in applying the principles which the degree; certification has provided. The result will never come until one has attained a perfect integration of process in work flow. The work and process have to be seen as a single entity and not two separate tasks. As long as they are seen as two separate tasks, the effectiveness of process rigor will be farfetched.
I would like to give a simple analogy of process integration with work. Let us take a payment transaction in a privately owned company. The payment assistant normally makes payment on authorization of the payment. There is a process of request, authorization, verification, payment and finally acknowledgement. The person making the payment considers all these as a single process of payment. Even if the owner asks for 10,000 rupees, the payment assistant creates a voucher and gets his signature or signature of his secretary before making any payment. This is a perfect integration of documentation with the workflow. You find such process implementation work flawlessly.
I therefore suggest implementation is a bigger task then getting certification. One needs to get out of “Degree Syndrome”. Getting a degree is the first step. Implementation of the principles needs understanding of the principle, putting them in simple steps and finally nitrating with the overall work. This simple principle can act as a guide for process implementation and therefore leads to success. Just ensure that the basics are being done, they are integrated with work, documentation is not separate than the work; you are bound to succeed.
Subscribe to:
Posts (Atom)