As software professionals, we often encounter questions on selection of development lifecycle for a given project. Ten years back the industry talked about Waterfall, and at most iterative as recommended model for software development. Today Agile is the talk of the town. Many companies are getting into the bandwagon of Agile. The client, development professionals, and sales professionals in the vendor company have picked buzz word of Agile world. It is good to understand the Agile principle but at times it could be costly to force-fit every situation into Agile. Since Agile is the buzz word today, very often we come across situation of force fitting any development work in Agile model. Is such force fitting beneficial?
Let us look at the Agile development model. Agile is based on 12 principles and six values. The values are Commitment, Focus, Openness, Respect, Courage, and Empowerment. The principles summarize the world of changing requirements, frequent deliveries, working software and bringing all stake holders like product manager, business user, analysts, programmer, and testers together towards the success of project. If you look at the values they can be implemented in any scenario. These values are great and bring unique advantages whenever applied. The principles help in differentiating Agile from life cycle model like Waterfall. For instance, changing requirement and frequent delivery is corner stone of Agile where as Water fall believes in frozen requirements and large delivery. There are situations where these models can have its advantages and can provide superior results. For instance if requirement is frozen, applying Agile will not be beneficial. At the same time if requirement changes are visualized frequently, going with Waterfall method will lead to confusion and mistrust between client and the vendor. Therefore it is useful to have a right Development Lifecycle for a given work.
Two important parameters for selecting a life cycle are Requirement Stability and Technology Maturity. If technology is evolving and so is the requirement, Agile will give the best results. If requirement is frozen or is likely to have minimal changes, technology is proven; it is better to adopt Waterfall.
In my early programming days, “C” was introduced as a programming language. I think the power of C was its simplicity. C has only few concepts (Chapters) unlike languages like COBOL or FORTRAN. Similarly the power of Agile is its simplicity and set of universal values which make the development environments vibrant, brings transparency in interaction. Let us not forget that one can implement these values irrespective of a life cycle chosen for a development work. I have seen these values are proved to be beneficial for project success.
I will recommend you to internalize these value set for your development team. Value is like a religion. It is hard to change as it takes a lot of time to change. So the companies should attempt internalizing these values. The values set should at least contain all the values prescribed by Agile Manifesto. There is no harm in having a larger superset of values specially suited to your organization. Once you are through with them, Agile life cycle implementation will become easier. The simple framework suggested above can be used for selecting a life cycle. These two things can go parallel as a maturity improves. If you have achieved maturity on values and did not get many opportunities for Agile life cycle implementation, you will be better off once a real Agile project appears in front of you. Even though you do not have a chance to have enough projects based on Agile life cycle, the maturity on values will pay for itself.
To sum up, Agile has a strong value set. It is useful to internalize them irrespective of you do Agile project or not. The life cycle should be selected at least based on the Requirement Stability and Technology Maturity. There could be other dimensions for selecting life cylcles besides these two. A right selection of life cycle helps in optimizing the Project value to the stake holders and makes the Project Successful.
Thursday, March 25, 2010
Thursday, March 18, 2010
Managing Requirements Risk is key to Project Success
In recent days the IT industry has seen strong companies becoming stronger and the tier II or tier III companies struggling for keeping its identity intact. For managing reasonable growth, particularly for listed companies it is important to show growth quarter on quarter to please the Shareholders, analysts and other stake holders. Such reporting brings accountability on Management. Accountability is highly correlated to ability to deliver results. Needless to say 10-15% companies have established ability to deliver, others struggle to define themselves, find unique place and establish differentiators. In absence of clear differentiators it is hard to manage growth. The market pressure puts a strain on sales engine and sales tend to get into a Pseudo Differentiator Syndrome. The company starts differentiating itself on Lower Fixed Price even for a relatively undefined set of requirements. Unfortunately customers tend to fall in the trap of lower price and committed delivery. At the end of the day as the requirement is relatively undefined, it leads to a series of commitment failures which leads to unsatisfied customers and loss of business. It does not help anyone; neither the vendor nor the customer.
Let us spend some time in understanding the Fixed Price work. Fixed price work brings accountability on part of the vendor and it gives a delivery commitment to the customer. Obviously, the requirement needs to be well defined and understood before such a deal is struck between the client and the vendor. Invariably, both the client and the vendor gets into a trap. Vendor gets a tendency to differentiate itself on Fixed lower price even though the requirement is not clearly outlined. The client gets into a trap of going with the vendor who gives a go-ahead all the time. This is dangerous as it leads to Project failure, unsatisfied customer and loss of business for the Vendor.
Risk is a part of any business. There is no reward without risk. Therefore, while accepting a job a reasonable level of risk is necessary. Any business cannot prosper without taking a risk. I suggest the following three factors framework which will arrest the situations described in foregoing para.
1. Requirements Uncertainty: Variations expected in requirements.
2. Skill unavailability: Measures if the vendor has right skill sets to deliver. High unavailability means lower delivery possibilities.
3. Time unavailability: This dimension measures the expected time duration by the client vis-à-vis available time to deliver the requirements. High time unavailability means high stretch being committed.
A project scenario should be evaluated either on High or Low parameters. Low on all three parameters is the best situation for a vendor and also for the project success. A High on all three is a “Death Trap”. Vendor should avoid such traps. Invariably vendors get into such traps following “Pseudo Differentiation Syndrome”. High on all three is not taking risk rather it is committing suicide. Other combinations of High and Low can be examined by decision taken based on the risk appetite of the vendor.
Similarly, the client should evaluate project scenario’s on above parameters and match its assessment with vendor’s offerings. A close match will lead to a healthy relationship and project success.
Requirement Risk Management is the key to project success. The three factors described above are three critical dimensions for evaluating risks associated with a requirement.
Needless to say understanding Requirement risk and managing them appropriately is the key to Project success.
Let us spend some time in understanding the Fixed Price work. Fixed price work brings accountability on part of the vendor and it gives a delivery commitment to the customer. Obviously, the requirement needs to be well defined and understood before such a deal is struck between the client and the vendor. Invariably, both the client and the vendor gets into a trap. Vendor gets a tendency to differentiate itself on Fixed lower price even though the requirement is not clearly outlined. The client gets into a trap of going with the vendor who gives a go-ahead all the time. This is dangerous as it leads to Project failure, unsatisfied customer and loss of business for the Vendor.
Risk is a part of any business. There is no reward without risk. Therefore, while accepting a job a reasonable level of risk is necessary. Any business cannot prosper without taking a risk. I suggest the following three factors framework which will arrest the situations described in foregoing para.
1. Requirements Uncertainty: Variations expected in requirements.
2. Skill unavailability: Measures if the vendor has right skill sets to deliver. High unavailability means lower delivery possibilities.
3. Time unavailability: This dimension measures the expected time duration by the client vis-à-vis available time to deliver the requirements. High time unavailability means high stretch being committed.
A project scenario should be evaluated either on High or Low parameters. Low on all three parameters is the best situation for a vendor and also for the project success. A High on all three is a “Death Trap”. Vendor should avoid such traps. Invariably vendors get into such traps following “Pseudo Differentiation Syndrome”. High on all three is not taking risk rather it is committing suicide. Other combinations of High and Low can be examined by decision taken based on the risk appetite of the vendor.
Similarly, the client should evaluate project scenario’s on above parameters and match its assessment with vendor’s offerings. A close match will lead to a healthy relationship and project success.
Requirement Risk Management is the key to project success. The three factors described above are three critical dimensions for evaluating risks associated with a requirement.
Needless to say understanding Requirement risk and managing them appropriately is the key to Project success.
Thursday, March 11, 2010
Metrics Mania
In Last 15 years a huge change is seen in Information Technology Industry in India. Many Indian companies undertook quality journey. India emerged as the country having largest number of level V certified company on CMM framework. Needless to say, CMM based Metrics based management at level IV and above. Many companies interpreted the provision loosely and achieved level V certification without having internalization of Metrics in the organization for managing and improving software projects. I remember once Ron Radice was participating in QAI seminar in India. He asked the audience to raise hands if they were from a company which was at level IV or higher. 50 odd hands went up. The second question was how many of them followed control chart; about 8-10 hands went up. That was an interesting observation. Technically all those who had raised their hands before should have raised hands again.
Since then Metrics based management has come up a long way. Many companies have adopted Metrics for reporting their performance. I have noticed a very interesting scenario. Metrics is collected, presented, beautiful charts, and trends are shown but project still limps. Many buzz words like “Defect Prevention” is a part of regular quality discussion in the companies. I have noticed that the Metrics program, very often are not connected with a set of parameters which can be used to meet customer expectations. I have seen that many times a schedule variance is computed in product release scenario with zero deviation. Whenever Product releases are planned, the release date is announced. If the release progress is not in line with the release date, the scope is adjusted to meet the release date. In such situation going with the traditional definition of schedule variance is elusive. What required here is a Metric which pin points the problem and leads towards the possible solution. In software companies you can find many such instances where all buzz words keep on floating without a real benefit to the organization. I call this syndrome a “METRICS MANIA”.
If you want to get out of this syndrome and do some concrete contribution towards success of your project, client satisfaction: you can follow a three step process:
1. Define Customer Success Factors (CSFs): Clearly define what will make customer successful. It could be Quality of deliverable, timeliness of delivery and cost. Just ensure you don’t have a huge laundry list. Keep the list simple and short.
2. Map against each CSF one or at most two Metrics. Look at their definition clearly. Ensure adjusting them will change the end result, leading to customer satisfaction.
3. Collect, analyze and adjust the Metrics periodically. Share with the customer, get their perspectives. Tweak your Metrics program to reflect on CSFs.
Metrics is a dashboard, a lever in your hand to manage the process for defined outcome. It has to be simple, and easily understandable in the organization. It should be percolated down the line. Each person should know how he is contributing and changing customer’s life with simple measurements. A successful Metrics program can be culture changing event in an organization. Keep it SIMPLE. It works.
Since then Metrics based management has come up a long way. Many companies have adopted Metrics for reporting their performance. I have noticed a very interesting scenario. Metrics is collected, presented, beautiful charts, and trends are shown but project still limps. Many buzz words like “Defect Prevention” is a part of regular quality discussion in the companies. I have noticed that the Metrics program, very often are not connected with a set of parameters which can be used to meet customer expectations. I have seen that many times a schedule variance is computed in product release scenario with zero deviation. Whenever Product releases are planned, the release date is announced. If the release progress is not in line with the release date, the scope is adjusted to meet the release date. In such situation going with the traditional definition of schedule variance is elusive. What required here is a Metric which pin points the problem and leads towards the possible solution. In software companies you can find many such instances where all buzz words keep on floating without a real benefit to the organization. I call this syndrome a “METRICS MANIA”.
If you want to get out of this syndrome and do some concrete contribution towards success of your project, client satisfaction: you can follow a three step process:
1. Define Customer Success Factors (CSFs): Clearly define what will make customer successful. It could be Quality of deliverable, timeliness of delivery and cost. Just ensure you don’t have a huge laundry list. Keep the list simple and short.
2. Map against each CSF one or at most two Metrics. Look at their definition clearly. Ensure adjusting them will change the end result, leading to customer satisfaction.
3. Collect, analyze and adjust the Metrics periodically. Share with the customer, get their perspectives. Tweak your Metrics program to reflect on CSFs.
Metrics is a dashboard, a lever in your hand to manage the process for defined outcome. It has to be simple, and easily understandable in the organization. It should be percolated down the line. Each person should know how he is contributing and changing customer’s life with simple measurements. A successful Metrics program can be culture changing event in an organization. Keep it SIMPLE. It works.
Thursday, March 4, 2010
Five Steps To avoid Project failure
In a competitive business world today, Project failure happens more frequently than we normally think. Some failure leads to analysis and learning, others initiate a blame wave in the organization. The failure is expensive; it costs time, energy, money and customer confidence. Too many failures can derail the growth engine from the track for ever.
One can avoid failure by following five simple steps:
1. Understand the customer:
It is said Customer is the king. Whenever we go to a king, we have to look at his long term success. King may be in hurry some times. Consultative selling demands to understand what the king is looking for, looking at his explicit and implicit requirements; provides a suitable solution. One should look at long term proposition and customer success. It is important to understand the Critical success Factors (CSF) of the engagement. Once you understand the CSF’s, work out your strategy to address all CSF’s. Sometimes, people get tempted to see money on the table and try to take what customer has budgeted even though the solution may be much lower than what is available on the table. This does not help in long run. If you want customer confidence, better be truthful to his purpose and long term goal, and help him realize his long term goals. You will emerge victorious and forge an everlasting relationship.
2. Manage Requirement effectively:
A solid Requirement elicitation is like constructing a solid foundation for a building. A tall building cannot stand unless the foundation is very strong. Many times we compromise on requirement capturing phase. Domain knowledge, skills in unearthing requirements and differentiating explicit and implicit requirements are important skills to be invested in requirement capturing phase. One may follow any suitable practice. It is important to capture, understand, communicate and validate requirements with customer. Any compromise at this stage costs heavily and contributes towards project failure.
3. Communicate Clearly:
Marriages break due to lack of communication. So is the project. It is important to identify stakeholders in any project and work out communication plan. The progress, challenges and successes should be communicated transparently. Communication helps in building confidence in project team, helps in identifying potential problem at an early stage and come up with appropriate solution. Communicate, communicate and communicate…
4. Manage by doing basics right:
I have done many project reviews. Whenever I get complicated answers for my questions, I assume that the guy has not understood the issues. He is shooting in dark. If you do the basics right, you will succeed. The basics have to be very simple and to be understood by each stake holders. Jargon complicates and basic solves. Just to give an example if you could set up simple processes for unit testing, code review, design and requirement review you are bound to succeed. Do not look for compliance, look for basic steps, are they being followed? Ask how reviews are done? If you get simple steps, you are done. Success will greet you.
5. Manage Team Skills:
Software Projects are resource intensive. They need skilled resources. In an ever growing market, getting resources with particular skill set is a herculean task. I have rarely seen a perfect fit for all required skills and team skills in any project. Therefore, it is important to follow a simple step of doing a skill gap and plan for bridging the gap. This helps immensely. You can’t have perfect situation. Work with what you have and deliver the best.
If these five simple steps are followed, the project failure can be avoided. It is simple, it works.
One can avoid failure by following five simple steps:
1. Understand the customer:
It is said Customer is the king. Whenever we go to a king, we have to look at his long term success. King may be in hurry some times. Consultative selling demands to understand what the king is looking for, looking at his explicit and implicit requirements; provides a suitable solution. One should look at long term proposition and customer success. It is important to understand the Critical success Factors (CSF) of the engagement. Once you understand the CSF’s, work out your strategy to address all CSF’s. Sometimes, people get tempted to see money on the table and try to take what customer has budgeted even though the solution may be much lower than what is available on the table. This does not help in long run. If you want customer confidence, better be truthful to his purpose and long term goal, and help him realize his long term goals. You will emerge victorious and forge an everlasting relationship.
2. Manage Requirement effectively:
A solid Requirement elicitation is like constructing a solid foundation for a building. A tall building cannot stand unless the foundation is very strong. Many times we compromise on requirement capturing phase. Domain knowledge, skills in unearthing requirements and differentiating explicit and implicit requirements are important skills to be invested in requirement capturing phase. One may follow any suitable practice. It is important to capture, understand, communicate and validate requirements with customer. Any compromise at this stage costs heavily and contributes towards project failure.
3. Communicate Clearly:
Marriages break due to lack of communication. So is the project. It is important to identify stakeholders in any project and work out communication plan. The progress, challenges and successes should be communicated transparently. Communication helps in building confidence in project team, helps in identifying potential problem at an early stage and come up with appropriate solution. Communicate, communicate and communicate…
4. Manage by doing basics right:
I have done many project reviews. Whenever I get complicated answers for my questions, I assume that the guy has not understood the issues. He is shooting in dark. If you do the basics right, you will succeed. The basics have to be very simple and to be understood by each stake holders. Jargon complicates and basic solves. Just to give an example if you could set up simple processes for unit testing, code review, design and requirement review you are bound to succeed. Do not look for compliance, look for basic steps, are they being followed? Ask how reviews are done? If you get simple steps, you are done. Success will greet you.
5. Manage Team Skills:
Software Projects are resource intensive. They need skilled resources. In an ever growing market, getting resources with particular skill set is a herculean task. I have rarely seen a perfect fit for all required skills and team skills in any project. Therefore, it is important to follow a simple step of doing a skill gap and plan for bridging the gap. This helps immensely. You can’t have perfect situation. Work with what you have and deliver the best.
If these five simple steps are followed, the project failure can be avoided. It is simple, it works.
Subscribe to:
Posts (Atom)