Requirement management is the essence of Project’s Success. In simple words, it means that most of the problems that the projects encounter could have been avoided from the very begining by making it very simple and to understand the Customer’s expectations from the respective projects. Very often we hear the story of changing requirements. I was going through a project review; I came to know that the requirements were changing very often. May be that is a truth. But when we hear the customer’s side of the story you often get a different perspective. Customer often thinks that development teams lack the domain understanding and the ability to interpret requirements. There is always a fine line between understanding of requirement and seeking clarifications from customers. When you come across a story of frequent change in requirements and many requests for pending clarifications, it is time to look at your requirement elicitation process.
There are different stake holders in the Project. They view the requirements differently. They all may be right in their respective perceptions but collectively going by their understanding of requirements one cannot deliver a project to meet all their understanding.It reminds me of a very famous story of “Six Blind Men and the Elephant”.
Once upon a time, there lived six blind men in a village. One day an elephant came to the village. They had no idea what an elephant is. They decided, “Even though we would not be able to see the elephant, let us go and feel the elephant by touching it”. Each of the blind men touched the elephant. Perceptions emerged about the elephant. Hey, the elephant is a pillar," said the first man who touched his leg. "Oh, no! It is like a rope," said the second man who touched the tail. "Oh, no! It is like a thick branch of a tree," said the third man who touched the trunk of the elephant. "It is like a big hand fan" said the fourth man who touched the ear of the elephant. "It is like a huge wall," said the fifth man who touched the belly of the elephant. "It is like a solid pipe," Said the sixth man who touched the tusk of the elephant.
I think requirement process is very similar to the process of six blind men feeling the elephant. The designer, the developer, the tester and the user perceive the requirement differently. They are touching the requirements at a different point of time. They carry different perceptions and often get into a conflict about the requirement. Think of the situation where the six blind men had reconciled their respective observations. Obviously, a holistic picture about the elephant could have emerged.
Therefore it helps if different stakeholders sit together after their initial feel, reconcile their understanding and then come up with a unified view of the requirement. A simple three step process may be very useful in rationalizing requirements:
1. Every Stakeholder studies the requirement separately. They are Designer, Developer, Analyst, Tester etc
2. They come with their findings and questions and sit and discuss their understanding. Reconcile them and finally put a unified understanding to the customer.
3. Customer validates and rationalize the requirements.
These simple steps can avoid a confusion which crops in at a later state. Although these steps are simple and do not require great processes, we rarely implement them. These steps can be implemented in different flavor across different development methodologies.
These are Simple fundamentals but it works.
Thursday, April 29, 2010
Thursday, April 22, 2010
Finding Simple Answer to a Problem is the Solution for Project Success
Recently I finished reading a book “Outliers” by Malcom Gladwell. I found the book to be very thought-provoking. The author has attempted to identify some causes which leads to extraordinary performance by some great individuals like Bill Gates, Bill Joy, LN Mittal etc. The author opines that for a person to become an expert in any field one needs to do 10,000 hours of practice. It is impossible to achieve such practice level without dedication, hard work and focus. It goes without saying that one needs to have proper opportunity to practice and last but the not the least, one also needs the Grace of God – “luck”.
I was thinking about our –garden-fresh Software Industry. This industry is full of smart individuals who want to rise very fast. In that process the “Practice” of 10,000 hours gets missed. We have to run development organization with a set of individuals having an average industry experience of around 3 years. The Resource Mix is very popular in Indian IT industry and time and again Management looks for a reasonable RMI (Resource Mix Index) to optimize the profit margin. These have implications for quality delivery. You will not have an “EXPERT” in your team. The result is inconsistency in quality of the product delivered. CMM culture in software organization has brought the discipline of Root Cause Analysis (RCA) in the companies. Often RCA is done for improving the quality in a project. Beautiful Fishbone Diagram is prepared. {The Fishbone Diagram identifies many possible causes for an effect or problem. It can be used to structure a brainstorming session}. Everyone is “Happy” after identifying the root causes for substandard delivery. They follow these but the problem keeps shifting from the origin. The problem does not get resolved. This means something is not right.
I would like to pinpoint my experience in looking at Root Cause Analysis for reducing defect injection while development. You will get frustrating experience when you look at the causes recorded in the Defect Database. You will find that most of the recorded causes are irrelevant. They do not lead to simple solutions which can be tackled for improving the outcome. In some cases it might, but generally it does not. It’s not that the team does not understand the concept. It is because of the team’s ability to understand the problem in simple terms. I have spoken about lack of expertise in the team due to environmental issues.
Management has to put an effort to optimize the expertise available in the company. I recommend the following steps:
1. Within a group of 10 development resources, the team should have a person who has the following qualities.
· Ability to guide the team
· Ability to go to the root cause.
· Ability to break the defect reasons in a set of simple causes which can be acted upon.
2. Identifying the causes is a continuous exercise. We have to start with a set of well thought causes and club sundry under “Miscellaneous”. Miscellaneous should not account for more than 20% of the problems. If miscellaneous accounts for more than 20% of failure then you need to revisit the causes listed and get to the bottom of it.
3. Look at 80% defined causes. Remember they have to be simple like “Exception Failure” and “Cosmetic Defects”. Cosmetic defects sometimes appear generic but if you take up with the stake holders and define a set of guidelines then programmers can be trained on them. If you are able to identify simple common causes then you know that the solution is simple.
4. Once you come with remedial actions, do a mapping of actions with the causes. Remember actions cannot be 10 or -20.It has to be max 5 or preferably three.
5. Continue these steps. There is a very common saying, “It is easy to preach than to practice”. Similarly, Let us not forget preaching is simple but execution is the toughest. You have to keep an eye on the target and keep on trying until perfection is achieved.
Sometimes it could be a challenge to get a Key resource or a Kingpin. The PM or the trailblazer has to take the responsibility by helping the team to either identify a Key resource or to get one. If you do not have an ALL Set person then look for someone who has the passion and willingness to learn. Coach him\her. It works.
It reminds me of a Hindi couplet (stanza)
“Karat Karat Abhayas ke , Jad mati hot suzan
Rassi abbat jaat ke Shil per parat Nissan.”
“If one keeps on trying time and again one will succeed like a soft rope which creates a deep impression on rocky walls of water well.”
Theres an American proverb~ “Success is a ladder you cannot climb with your hands in your pockets”. It points to the Importance of Practice on Success as found by Gladwell without specifying the magical 10,000 hours mark.
Thursday, April 15, 2010
Metrics Implementation is a Journey and not a Destination
“Brushing the teeth” is a part and parcel of our life. It is very interesting to understand how all internalize this simple process. Unfortunately, we cannot remember the time when we got into the habit of “Brushing the teeth”. Let us take an example of a child being raised. I think we can learn a lot of sound management principles from a house wife or a mother. Once the child starts growing, mother makes it a point to help him brush the teeth daily. In the early stage the child resists; he eats the paste; does not clean his mouth properly etc. The mother diligently continues the process as she knows that the child needs to first pick up the habit of brushing the teeth daily. Any habit formation takes time. Once the habit is cultivated, the child will start brushing everyday on his own. This is the time to teach him about the correct way of brushing. The mother does it with a lot of patience. We all know how much effort goes behind developing a sound habit of brushing the teeth properly. Today we find this task to be very small and simple. However, an enormous amount of effort, patience and sincerity was put in to make this happen.
Software industry is relatively young. The industry is being raised. The practices are being internalized. Some companies in the industry are ahead of the others. But the fact is that this is a young industry. Raising and maturing this industry will require a very similar kind of patience like a mother in above case. We, sometimes ignore the basic facts of life. I very strongly believe that raising a child in a relatively young industry will need a long term focus; commitment, dedication and goal orientation on the part of management (the mother). Metrics implementation is one such habit like “Brushing the teeth”. It is a journey and not a destination.
I think the management needs to have a clarity of vision in Metrics Implementation. It needs to understand the long term goal, hiccups in the journey and its commitment towards its fulfillment. There are factors which certainly accelerate or retard the pace of implementation. I will touch upon them in subsequent paragraph. Let us look at the best practice in Metrics Implementation. The Management needs to decide a broader set of metrics which will meet the needs of various stake holders like Customers, Management (Proxy for Owners) & Employees. In the beginning of the program one may start off with customers because the existence of the company is due to the presence of the “Customers”. In the broader set I shall refer this as “Global Metrics for an Organization”. This needs to be customized to match the specific goals of the customer.
Let us look at the flow below which describes the metrics implementation process for meeting the needs of customers.
This process continues like a journey. First we need to get into the habit like a child gets into habit of brushing. Once that is done then we can talk about tweaking, mapping with goal and measuring (Proper way of brushing).
Finance and accounting is a more matured discipline. Therefore, the metrics related to ownership are normally found in most of the companies. These could be metrics like Gross Margin, EBITDA etc. However there are challenges in aligning these with Operative Managers. As a part of Metrics program, these should be aligned appropriately with other metrics. The purpose is to simplify so that action can be initiated at operating levels. For example Resource Mix Index may be proxy for Gross Profit and the same is easily controllable at Project Manager Level. One should look at three to four goals for Internal success (Internal Success Factors). We should work to define the ISFs for each engagement and map metrics to measure them accordingly.
Employees are very important elements in Software industry. They are our assets. They go home after finishing their daily tasks. Management has to ensure that they comeback the next day. This is a more complex process to implement. We will continue with our discussion without looking at this aspect. I think it is equally important to develop and manage employee related metrics using the framework discussed in foregoing paragraphs.
As one progresses on their journey; one can choose to improve the quality of these habits appropriately. The next step could be to bring alignment in three dimensions of metrics viz. Customer, Ownership and Employees.
Lastly, the child grows up in an environment which can be considered as germination of a seed in fertile soil (Here Environment is referred to soil). This results in a healthy plant. Similarly metrics program gets affected by some factors like:
1. Organizational Alignment & Focus: A company having a consistent program will have quicker success in the Metrics journey. It is very important to have Management focus, commitment, consistency and long term orientation.
2. Growth of Business: Nothing succeeds like success. I know the price of success: dedication, hard work, and an unremitting devotion to the things you want to see happen (Frank Lloyd Wright). One will see much better results with same efforts in a growing company.
In declining business, de-motivation at all levels; Cost pressure and other associated ills retard the pace of the implementation.
3. Education of the key participants: I believe this has to be top down.
There may be many more factors. But I consider the above 3 factors as important ones.
Metrics Implementation is a Journey. It is like raising a child. One has to have patience, interest in child and focus to make him an invaluable citizen in the long run. Let us not forget Environment which plays an important role in the growth of the child. One may not be able to control the environment. However, one should focus on areas under one’s control. You will definitely get the Results but it may be at a slower pace. William Shakespeare has rightly said that “Though patience be a tired mare, yet she will plod”.
Software industry is relatively young. The industry is being raised. The practices are being internalized. Some companies in the industry are ahead of the others. But the fact is that this is a young industry. Raising and maturing this industry will require a very similar kind of patience like a mother in above case. We, sometimes ignore the basic facts of life. I very strongly believe that raising a child in a relatively young industry will need a long term focus; commitment, dedication and goal orientation on the part of management (the mother). Metrics implementation is one such habit like “Brushing the teeth”. It is a journey and not a destination.
I think the management needs to have a clarity of vision in Metrics Implementation. It needs to understand the long term goal, hiccups in the journey and its commitment towards its fulfillment. There are factors which certainly accelerate or retard the pace of implementation. I will touch upon them in subsequent paragraph. Let us look at the best practice in Metrics Implementation. The Management needs to decide a broader set of metrics which will meet the needs of various stake holders like Customers, Management (Proxy for Owners) & Employees. In the beginning of the program one may start off with customers because the existence of the company is due to the presence of the “Customers”. In the broader set I shall refer this as “Global Metrics for an Organization”. This needs to be customized to match the specific goals of the customer.
Let us look at the flow below which describes the metrics implementation process for meeting the needs of customers.
This process continues like a journey. First we need to get into the habit like a child gets into habit of brushing. Once that is done then we can talk about tweaking, mapping with goal and measuring (Proper way of brushing).
Finance and accounting is a more matured discipline. Therefore, the metrics related to ownership are normally found in most of the companies. These could be metrics like Gross Margin, EBITDA etc. However there are challenges in aligning these with Operative Managers. As a part of Metrics program, these should be aligned appropriately with other metrics. The purpose is to simplify so that action can be initiated at operating levels. For example Resource Mix Index may be proxy for Gross Profit and the same is easily controllable at Project Manager Level. One should look at three to four goals for Internal success (Internal Success Factors). We should work to define the ISFs for each engagement and map metrics to measure them accordingly.
Employees are very important elements in Software industry. They are our assets. They go home after finishing their daily tasks. Management has to ensure that they comeback the next day. This is a more complex process to implement. We will continue with our discussion without looking at this aspect. I think it is equally important to develop and manage employee related metrics using the framework discussed in foregoing paragraphs.
As one progresses on their journey; one can choose to improve the quality of these habits appropriately. The next step could be to bring alignment in three dimensions of metrics viz. Customer, Ownership and Employees.
Lastly, the child grows up in an environment which can be considered as germination of a seed in fertile soil (Here Environment is referred to soil). This results in a healthy plant. Similarly metrics program gets affected by some factors like:
1. Organizational Alignment & Focus: A company having a consistent program will have quicker success in the Metrics journey. It is very important to have Management focus, commitment, consistency and long term orientation.
2. Growth of Business: Nothing succeeds like success. I know the price of success: dedication, hard work, and an unremitting devotion to the things you want to see happen (Frank Lloyd Wright). One will see much better results with same efforts in a growing company.
In declining business, de-motivation at all levels; Cost pressure and other associated ills retard the pace of the implementation.
3. Education of the key participants: I believe this has to be top down.
There may be many more factors. But I consider the above 3 factors as important ones.
Metrics Implementation is a Journey. It is like raising a child. One has to have patience, interest in child and focus to make him an invaluable citizen in the long run. Let us not forget Environment which plays an important role in the growth of the child. One may not be able to control the environment. However, one should focus on areas under one’s control. You will definitely get the Results but it may be at a slower pace. William Shakespeare has rightly said that “Though patience be a tired mare, yet she will plod”.
Thursday, April 8, 2010
Creating Meaning in Project Work
Associating Meaning with what you do is critical to your achievements on the project. Let us read a famous story about cleaning work in a Pharmaceutical Company.
This is a story about attitude towards work in a Public Sector and a Private Sector company. Large Public sectors are known for its bureaucracy whereas Private sector are known for its agility. A sweeper joins a Public sector. On his joining day, he goes to see the departmental head to understand the job responsibilities. When the new employee introduces himself, the boss says, “I know, you are XYZ joining this company as a grade IV employee”. Without offering him a chair, the boss continues: “Your duty is to sweep the floor and keep the toilets clean”.
Now imagine yourself in sweeper’s shoes. What could have happened to your pride? In Public sectors sweepers are known for absenteeism from their work. They are also looked upon as habitual drunkards.
Now, Lets take the case of a well managed Private sector. The same sweeper joins and reports to his department. As soon as he enters the cabin, the boss smilingly asks him to take a chair. He welcomes him with a cup of tea. He explains to him “We are in health care business. Even a small particle of dust might kill a patient. Your job is very important and you have to ensure that the drugs being manufactured here should not carry even a single dust particle. Your efficient work will save many lives. The ability to create meaning in the job makes a great impact that you get a sincere, devoted employee who takes extra precaution to maintain cleanliness around without being absent for a single day. If you go to a public sector the situation is totally different you need not ask where is the toilet?.
On a personal note, I do not believe in Public sector Vs Private Sector. Instead you have difference in attitude in a well managed company Vs a bureaucratic company. Let us look at the meaning behind the job. In the second case the manager was very successful in creating a meaning in the job of the sweeper. He could provide the purpose of his existence. The meaning in the job is the ultimate thing; it applies equally to all walks of life. Be it a software project, a construction project or a routine work of sweeping the floor.
Let’s take an example from the Software industry. The company got a project from the Head Quarter (i.e. an Internal work). The work was to build a Saas based system for core business of the company. The technology to be used was .NET and the database to be used was SQL. If you happen to ask a team member about his/her job profile, you will get a typical answer like “I am developing a software using .NET & SQL as database”. Don’t you think this member is doing same thing what the sweeper was doing in the first case? The answer is “Yes”. I think we rarely look at the project and work for creating a meaning in it. If you are able to create a meaning and the resources are able to correlate with that meaning, it gives a huge boost to the morale of the team. The motivation level of the resources working on the project also goes up, which contributes to project success.
Normally in Software Company people do not like working for an internal project. This product was being built first time in the world for Localization market. It is a Saas based product. The product is very core to Chairman’s vision. Let me attempt giving a meaning to the work the team was doing here. I am summarizing the same in two bullets:
• The team is creating history in the world in Localization space and empowering the users to have the best of the breed solutions for their problems.
• The team is working for Chairman of the company
I believe this meaning creation has tremendous impact on the team morale. When I discussed this with the team, I noticed the glow on the faces of the people. I saw a sense of importance among the team members. I would like to state that one of the KRA’s of a Project manager has to create meaning in the work the team does. This gives birth to a sense of Pride in all people. It brings empowerment and finally makes a project successful. It is simple and does not costs a thing but “It works”.
This is a story about attitude towards work in a Public Sector and a Private Sector company. Large Public sectors are known for its bureaucracy whereas Private sector are known for its agility. A sweeper joins a Public sector. On his joining day, he goes to see the departmental head to understand the job responsibilities. When the new employee introduces himself, the boss says, “I know, you are XYZ joining this company as a grade IV employee”. Without offering him a chair, the boss continues: “Your duty is to sweep the floor and keep the toilets clean”.
Now imagine yourself in sweeper’s shoes. What could have happened to your pride? In Public sectors sweepers are known for absenteeism from their work. They are also looked upon as habitual drunkards.
Now, Lets take the case of a well managed Private sector. The same sweeper joins and reports to his department. As soon as he enters the cabin, the boss smilingly asks him to take a chair. He welcomes him with a cup of tea. He explains to him “We are in health care business. Even a small particle of dust might kill a patient. Your job is very important and you have to ensure that the drugs being manufactured here should not carry even a single dust particle. Your efficient work will save many lives. The ability to create meaning in the job makes a great impact that you get a sincere, devoted employee who takes extra precaution to maintain cleanliness around without being absent for a single day. If you go to a public sector the situation is totally different you need not ask where is the toilet?.
On a personal note, I do not believe in Public sector Vs Private Sector. Instead you have difference in attitude in a well managed company Vs a bureaucratic company. Let us look at the meaning behind the job. In the second case the manager was very successful in creating a meaning in the job of the sweeper. He could provide the purpose of his existence. The meaning in the job is the ultimate thing; it applies equally to all walks of life. Be it a software project, a construction project or a routine work of sweeping the floor.
Let’s take an example from the Software industry. The company got a project from the Head Quarter (i.e. an Internal work). The work was to build a Saas based system for core business of the company. The technology to be used was .NET and the database to be used was SQL. If you happen to ask a team member about his/her job profile, you will get a typical answer like “I am developing a software using .NET & SQL as database”. Don’t you think this member is doing same thing what the sweeper was doing in the first case? The answer is “Yes”. I think we rarely look at the project and work for creating a meaning in it. If you are able to create a meaning and the resources are able to correlate with that meaning, it gives a huge boost to the morale of the team. The motivation level of the resources working on the project also goes up, which contributes to project success.
Normally in Software Company people do not like working for an internal project. This product was being built first time in the world for Localization market. It is a Saas based product. The product is very core to Chairman’s vision. Let me attempt giving a meaning to the work the team was doing here. I am summarizing the same in two bullets:
• The team is creating history in the world in Localization space and empowering the users to have the best of the breed solutions for their problems.
• The team is working for Chairman of the company
I believe this meaning creation has tremendous impact on the team morale. When I discussed this with the team, I noticed the glow on the faces of the people. I saw a sense of importance among the team members. I would like to state that one of the KRA’s of a Project manager has to create meaning in the work the team does. This gives birth to a sense of Pride in all people. It brings empowerment and finally makes a project successful. It is simple and does not costs a thing but “It works”.
Thursday, April 1, 2010
Sensing Gap in Requirement Process in Software Maintenance work
Gartner predicts highest CAGR of 8.9% in Application Software Support Services in next 3 years. For any Software company engaged in off shoring, application support services provide continuous revenue stream and is very important piece of work. We often come across situations like lack of understanding of domain of the client. Domain plays a very important role in understanding the requirements, and their effective elicitation and interpretation. I have seen many projects going down due to flaw in the requirement process particularly in maintenance space. Sensing gap in the process at the early stage helps in making project successful.
This reminds me of a famous story of a surgery by a qualified doctor. A patient signed a contract with doctor. The patient was operated to remove gall bladder stones from his stomach. The gall bladder stones were picked up and shown to the near and dear of the family, they all were excited. When the patient came out, he was dead. The Doctor had signed for removing gall bladder stones. That was the requirement. It was never discussed that patient should recover after the operation. Can we consider such operations successful? Certainly not. This explains the type of requirements namely Explicit Requirements and Implicit Requirements. During requirement elicitation process, the explicit requirements are spelled out and the implicit ones are often missed out if the requirement team is not experienced in domain and in art of requirement gathering. Such situations lead to troubled project & troubled relationship. The question comes how do you sense such gap at early stages?
I will share some symptoms which should alert a project manager and should remind him to focus his attention to details and bring the best practices in requirement gathering for software maintenance work.
1. Waiting for Clarifications: When you dive deep into project review and come across situations of “Waiting for Clarifications”, get alerted. There is a very fine line between “Seeking Clarifications” & “Lack of Understanding”. Look into some specific situations. You may get surprise in terms of lack of knowledge of your team on the subject.
2. Low First time Right: First time right is an excellent metrics for measuring your maintenance ticket delivery to the customer. If your first time right is lower than 70%, look into the requirement process.
3. Low productivity of the team: The low productivity may be due to various reasons. One of the most important reasons is wasting time in interpreting requirement and getting into a loop of understanding.
4. Disagreement on CR Vs Defect during defect washing process: Sometimes customer can be unreasonable. But most of the times such situations arise due to gap in requirement understanding.
These are some of the indications. The moment you come across one or few of them in your project, look at the requirement gathering process under microscope. You will come up with one which is most suitable to your company in the given situation. However, I would like to share a few best practices in this area.
1. Most of the outsourcing engagements are structured as onsite-offshore engagement. Often an onsite co-coordinator is linked to the engagement. Giving requirement gathering task to onsite coordinator or business analyst is a good practice. He/she captures the requirements, gets validated with the customer and then shares with offshore team for understanding and development work. This process saves a lot of time and takes care of some of the symptoms mentioned above.
2. As mentioned earlier, domain plays a very important role in requirement interpretation. Let us take a look at domain skills of our team. Some generic knowledge with each team member and presence of at least some domain specialists is a great help. This practice has helped me in some projects. It can be stated as taking your boat from troubled waters to safe waters.
3. In some of the cases you may not be able to put a coordinator who is able to elicit requirements. It may be a good practice to explain requirements to the team including testers. This helps in open discussion and understanding the requirements by all team members. If any requirement clarifications are referred to the customer by the onsite coordinator. This helps in reducing gaps in requirement accuracy. Involvement of test folks at an early stage helps in delivering a quality deliverable.
I would argue – one of the very important roles of a Project Manager is to sense gap at an early stage of the requirement process. If you happen to see gap (Smoke), work towards finding out the root of the fire. It helps in extinguishing the fire and makes the project successful by following simple steps.
This reminds me of a famous story of a surgery by a qualified doctor. A patient signed a contract with doctor. The patient was operated to remove gall bladder stones from his stomach. The gall bladder stones were picked up and shown to the near and dear of the family, they all were excited. When the patient came out, he was dead. The Doctor had signed for removing gall bladder stones. That was the requirement. It was never discussed that patient should recover after the operation. Can we consider such operations successful? Certainly not. This explains the type of requirements namely Explicit Requirements and Implicit Requirements. During requirement elicitation process, the explicit requirements are spelled out and the implicit ones are often missed out if the requirement team is not experienced in domain and in art of requirement gathering. Such situations lead to troubled project & troubled relationship. The question comes how do you sense such gap at early stages?
I will share some symptoms which should alert a project manager and should remind him to focus his attention to details and bring the best practices in requirement gathering for software maintenance work.
1. Waiting for Clarifications: When you dive deep into project review and come across situations of “Waiting for Clarifications”, get alerted. There is a very fine line between “Seeking Clarifications” & “Lack of Understanding”. Look into some specific situations. You may get surprise in terms of lack of knowledge of your team on the subject.
2. Low First time Right: First time right is an excellent metrics for measuring your maintenance ticket delivery to the customer. If your first time right is lower than 70%, look into the requirement process.
3. Low productivity of the team: The low productivity may be due to various reasons. One of the most important reasons is wasting time in interpreting requirement and getting into a loop of understanding.
4. Disagreement on CR Vs Defect during defect washing process: Sometimes customer can be unreasonable. But most of the times such situations arise due to gap in requirement understanding.
These are some of the indications. The moment you come across one or few of them in your project, look at the requirement gathering process under microscope. You will come up with one which is most suitable to your company in the given situation. However, I would like to share a few best practices in this area.
1. Most of the outsourcing engagements are structured as onsite-offshore engagement. Often an onsite co-coordinator is linked to the engagement. Giving requirement gathering task to onsite coordinator or business analyst is a good practice. He/she captures the requirements, gets validated with the customer and then shares with offshore team for understanding and development work. This process saves a lot of time and takes care of some of the symptoms mentioned above.
2. As mentioned earlier, domain plays a very important role in requirement interpretation. Let us take a look at domain skills of our team. Some generic knowledge with each team member and presence of at least some domain specialists is a great help. This practice has helped me in some projects. It can be stated as taking your boat from troubled waters to safe waters.
3. In some of the cases you may not be able to put a coordinator who is able to elicit requirements. It may be a good practice to explain requirements to the team including testers. This helps in open discussion and understanding the requirements by all team members. If any requirement clarifications are referred to the customer by the onsite coordinator. This helps in reducing gaps in requirement accuracy. Involvement of test folks at an early stage helps in delivering a quality deliverable.
I would argue – one of the very important roles of a Project Manager is to sense gap at an early stage of the requirement process. If you happen to see gap (Smoke), work towards finding out the root of the fire. It helps in extinguishing the fire and makes the project successful by following simple steps.
Subscribe to:
Posts (Atom)