One line requirement
Potential Challenges:
1. Incorrect assessment of the impact – If one liner requirements are taken at face value, there is a risk on missing out very critical impacts.
2. The above situation can very easily translate into estimates way off the mark risking the entire initiative.
3. If estimates are arrived at based on high level requirements and communicated to the client, the client, at times, starts expecting the final cost in similar ranges. This can become an issue from financial sponsorship of the project.
4. In such situations where functional requirements can not available, it is very easy to loose focus of non functional requirements; mainly usability and performance needs
Mitigation Strategies:
1. Multiple Options – A short term, near term and a long term solution can be thought of and discussed with the client.
2. Knowledge Management – Knowing the domain of the customer / application is very important to assess the right impact.
E.g. In transportation domain a one line requirement saying that improve the visibility of shipment on web tracking system has a potential to translate into very high amount of impact. The change would be required to all operational systems to generate such information, processing it and persist it. The data services applications will need to retrieve it and finally the delivery channels will need to display it. This could well be a program of 6+ months
3. Client Education – It is necessary to make sure that the client understands the true complexity and extent of impact. This will help to make the client appreciate the budget and timelines.
4. Even if non functional requirements are not stated, the same can be derived based on past experience in same or similar domain / implementations. This can be shared with the client to ensure correctness of the information.
Thursday, July 19, 2007
Wednesday, July 18, 2007
Risk Management – Sharing the Learning - Scenario 4
Crunched schedule project
Potential Challenges:
1. If a project is crunched beyond a certain limit (say > 40% as per the COCOMO Model), there is a high risk for failing the timelines and or poor quality.
2. Resource utilization becomes a challenge when many tracks run in parallel. Result can be high effort over-run.
3. Team morale typically takes a hit in such project
4. Low tolerance for defects. Higher or in cases even normal DIR (defect injection
rate) can impact project timelines.
5. Crunched projects typically have a context at the client end e.g. come commitments to business, regulatory needs, etc. Hence it is important that such projects are done first time right and succeed in achieving its objective.
Mitigation Strategies:
1. Joint Application Development – Jointly working with the client is a good de-risking strategy. Issues are identified and resolved early. Also, this helps in creating a team spirit.
2. Modify team structure and reporting – The development team can be empowered to take certain decisions. Also the reporting structure can be changed to facilitate attention of the top most stakeholders and fast decision making
3. Leveraging GDM – Work can be carried out at various geographical locations. Roles and responsibilities of each and every team needs to be were well defined.
4. Improved communication – Top to bottom every one needs to be made aware of the objectives and implications. SPOC can be defined for all the teams. Stand-up meetings, daily handover meetings, weekly status meetings, Net Meetings and white-boarding – all possible means of communication can be leveraged to ensure that every information and change is communicated appropriately.
5. Process Tailoring – Can be done to suite the situation and potential risks of quality mitigated by better quality resource commitment.
Note - People are the single most factors that can make or break a project. If all the teams are driven by the single objecting of making it happen, the engagement can succeed. There is no prescription / mitigation step to motivate people but some things that can help are:
1. Common communication from the top most executive to all e.g. The IT CEO addressing all development teams in cafeteria.
2. Articulating the objective of the project, its need and criticality very clearly to all the teams
3. Team Leaders need to lead from front by example.
4. Usually the toughness of the challenge itself can tick ☺
Potential Challenges:
1. If a project is crunched beyond a certain limit (say > 40% as per the COCOMO Model), there is a high risk for failing the timelines and or poor quality.
2. Resource utilization becomes a challenge when many tracks run in parallel. Result can be high effort over-run.
3. Team morale typically takes a hit in such project
4. Low tolerance for defects. Higher or in cases even normal DIR (defect injection
rate) can impact project timelines.
5. Crunched projects typically have a context at the client end e.g. come commitments to business, regulatory needs, etc. Hence it is important that such projects are done first time right and succeed in achieving its objective.
Mitigation Strategies:
1. Joint Application Development – Jointly working with the client is a good de-risking strategy. Issues are identified and resolved early. Also, this helps in creating a team spirit.
2. Modify team structure and reporting – The development team can be empowered to take certain decisions. Also the reporting structure can be changed to facilitate attention of the top most stakeholders and fast decision making
3. Leveraging GDM – Work can be carried out at various geographical locations. Roles and responsibilities of each and every team needs to be were well defined.
4. Improved communication – Top to bottom every one needs to be made aware of the objectives and implications. SPOC can be defined for all the teams. Stand-up meetings, daily handover meetings, weekly status meetings, Net Meetings and white-boarding – all possible means of communication can be leveraged to ensure that every information and change is communicated appropriately.
5. Process Tailoring – Can be done to suite the situation and potential risks of quality mitigated by better quality resource commitment.
Note - People are the single most factors that can make or break a project. If all the teams are driven by the single objecting of making it happen, the engagement can succeed. There is no prescription / mitigation step to motivate people but some things that can help are:
1. Common communication from the top most executive to all e.g. The IT CEO addressing all development teams in cafeteria.
2. Articulating the objective of the project, its need and criticality very clearly to all the teams
3. Team Leaders need to lead from front by example.
4. Usually the toughness of the challenge itself can tick ☺
Tuesday, July 17, 2007
Rita Mulcahy's web site
Rita Mulcahy, world-renowned PM expert and best-selling author, has been teaching her innovative techniques for passing the PMP® exam on the first try since 1991. And most recently, she has used her thousands of hours of experience to develop exam training for the CAPM® certification as well. Now, project managers around the globe can study for either the PMP® exam or the CAPM® exam online—24 hours a day, 7 days a week.
You can also find some free stuff here:
http://www.rmcproject.com/
Risk Management – Sharing the Learning - Scenario 3
Programs with 3rd party vendor involvement
Potential Challenges:
• Dependency on other projects or parties whose outcome or working cannot be influenced by you.
• In case there are stringent SLA with penalty for SLA breach, multi party involvement can pose a potential financial risk
Mitigation Strategies:
• Joint risk planning and mitigation with the client and other stakeholders
• Well defined communication plan for client and also other stakeholders
• Enter into an agreement with the interfacing vendors (e.g. OLA – Operation Level Agreement). The agreement can define overall test requirements and gain commitment from interfacing systems to provide support during testing and implementation.
• Review of the SLA and other agreements from companies legal cell to ensure that we are not at financial risks due to some one else’s breach of contract / SLA.
Potential Challenges:
• Dependency on other projects or parties whose outcome or working cannot be influenced by you.
• In case there are stringent SLA with penalty for SLA breach, multi party involvement can pose a potential financial risk
Mitigation Strategies:
• Joint risk planning and mitigation with the client and other stakeholders
• Well defined communication plan for client and also other stakeholders
• Enter into an agreement with the interfacing vendors (e.g. OLA – Operation Level Agreement). The agreement can define overall test requirements and gain commitment from interfacing systems to provide support during testing and implementation.
• Review of the SLA and other agreements from companies legal cell to ensure that we are not at financial risks due to some one else’s breach of contract / SLA.
Monday, July 16, 2007
Risk Management – Sharing the Learning - Scenario 2
Complex Technology
Potential Challenges:
• No precedence – The technology landscape is changing on a daily basis with a new technology making to the market on a daily basis. It is likely that there would be no or less extensive know-how on a particular technology.
• Propitiatory products (typically from small time vendors) do not have much information in documentation and or public domain like mailing lists, discussion forum, “Googling”, etc. available. This increases the learning curve and dependency on 3rd party.
• Sometimes customers buy 3rd party products based on their marketing blurs without much due diligence on the technical information and need context. Fitness of use can get compromised in such cases.
• No estimation methodology, historic data or guidelines are available for such type of work.
• Immature products typically have defects that could get unearth during the development phase
Mitigation Strategies:
• Guide the client, as possible in selecting appropriate products that are fit for use. Adopting a structured approach to product selection is a good practice.
• Doing a proof of concept (POC) is recommended depending on the complexity and criticality of the requirements. Target the most risky scenario for this POC so that issues are identified early one.
• Obtain a formal support mechanism from product vendor during the Design & Build phase. This support should be available at both offshore and onsite.
• Work with the client to define a process for fixing issues in the 3rd party products identified during project execution.
• The contract can be a time and material kind in case the financial risks are considered high.
• Communicate the risk involved with using a complex technology and new product to the client before beginning the assignment.
• The learning from the engagement needs to be collated and made available in the internal knowledge portals for future engagements.
Potential Challenges:
• No precedence – The technology landscape is changing on a daily basis with a new technology making to the market on a daily basis. It is likely that there would be no or less extensive know-how on a particular technology.
• Propitiatory products (typically from small time vendors) do not have much information in documentation and or public domain like mailing lists, discussion forum, “Googling”, etc. available. This increases the learning curve and dependency on 3rd party.
• Sometimes customers buy 3rd party products based on their marketing blurs without much due diligence on the technical information and need context. Fitness of use can get compromised in such cases.
• No estimation methodology, historic data or guidelines are available for such type of work.
• Immature products typically have defects that could get unearth during the development phase
Mitigation Strategies:
• Guide the client, as possible in selecting appropriate products that are fit for use. Adopting a structured approach to product selection is a good practice.
• Doing a proof of concept (POC) is recommended depending on the complexity and criticality of the requirements. Target the most risky scenario for this POC so that issues are identified early one.
• Obtain a formal support mechanism from product vendor during the Design & Build phase. This support should be available at both offshore and onsite.
• Work with the client to define a process for fixing issues in the 3rd party products identified during project execution.
• The contract can be a time and material kind in case the financial risks are considered high.
• Communicate the risk involved with using a complex technology and new product to the client before beginning the assignment.
• The learning from the engagement needs to be collated and made available in the internal knowledge portals for future engagements.
Sunday, July 15, 2007
Risk Management – Sharing the Learning - Scenario 1
Let us see some hypothetical situations and the corresponding challenges which can be potential risks for the project. Also are accompanied mitigation strategies for these challenges.
First Time Customer / First Time Off-shoring
Potential Challenges:
• Low Confidence Level - Being the first engagement, it is very natural for the client to be apprehensive.
• Insecurity - Off-shoring is a paradigm shift for customers that are off-shoring first time customers. It is difficult to digest the fact that people, miles away can understand their requirements and deliver in time.
• Frequent changes – Typically customers engaging off-shore firms for the first time are not used to adhering processes. Frequent changes to the requirements are a common observation with such clients. Also many such clients have implicit requirements and expect the incorporation of the same in the project.
• Typically such clients find estimation as one of the issue areas of discontent.
All such issues manifest itself typically in risks like requirements issues, micromanagement from client and relationship endangerment.
Mitigation Strategies:
• Educate the client on offshore processes and practices. Arranging a client visit to the offshore development centre is a good way to boost the client confidence.
• Have elaborate communication plan with multiple and multi-level communication channel e.g. the project sponsor can have two or three points of contact. This redundancy in communication channel helps to foster the necessary confidence.
• The customer facing team needs to be oriented / trained in appropriate soft skills and have the client cultural sensitivity.
• During requirements elicitation phase adopt a process driven approach to ensure holistic information capture. Apart from functional requirements try to elicit the non functional requirements also e.g. performance, user interface, maintainability, etc.
• Try and adopt a top down and standard estimation approach such as Function Points. These are easy for the client to verify and accept.
• Transparency – Keep the client informed all the time. In case any critical issue is anticipated, share the same albeit with an appropriate mitigation strategy.
First Time Customer / First Time Off-shoring
Potential Challenges:
• Low Confidence Level - Being the first engagement, it is very natural for the client to be apprehensive.
• Insecurity - Off-shoring is a paradigm shift for customers that are off-shoring first time customers. It is difficult to digest the fact that people, miles away can understand their requirements and deliver in time.
• Frequent changes – Typically customers engaging off-shore firms for the first time are not used to adhering processes. Frequent changes to the requirements are a common observation with such clients. Also many such clients have implicit requirements and expect the incorporation of the same in the project.
• Typically such clients find estimation as one of the issue areas of discontent.
All such issues manifest itself typically in risks like requirements issues, micromanagement from client and relationship endangerment.
Mitigation Strategies:
• Educate the client on offshore processes and practices. Arranging a client visit to the offshore development centre is a good way to boost the client confidence.
• Have elaborate communication plan with multiple and multi-level communication channel e.g. the project sponsor can have two or three points of contact. This redundancy in communication channel helps to foster the necessary confidence.
• The customer facing team needs to be oriented / trained in appropriate soft skills and have the client cultural sensitivity.
• During requirements elicitation phase adopt a process driven approach to ensure holistic information capture. Apart from functional requirements try to elicit the non functional requirements also e.g. performance, user interface, maintainability, etc.
• Try and adopt a top down and standard estimation approach such as Function Points. These are easy for the client to verify and accept.
• Transparency – Keep the client informed all the time. In case any critical issue is anticipated, share the same albeit with an appropriate mitigation strategy.
Subscribe to:
Posts (Atom)
