Category Archives: Delivery Methodology

  • 0

Risk Management – Risk Control

Risk Control

Once the risks are identified and prioritized, it becomes very clear which risks the project should handle in the order of priority.

Risk Control activities consist of the following activities-

  • Risk management planning and
  • Risk monitoring and tracking

Risk management planning consists of identifying strategies needed to minimize the risk consequences.

Risk monitoring and tracking consists of periodic review of risks and revision to the Risk Analysis and Management Plan (RAMP), if needed.

Risk management planning

For each risk, based on the risk priority, Project Manager identifies Mitigation strategy and Risk handling strategy.

Mitigation strategy identifies the actions to be taken before the risk occurs to minimize risk consequences. Mitigation Strategy would always be driven by Decision Analysis and Resolution process.

Risk handling strategy identifies the actions to be taken after the risk occurs, in spite of implementing the mitigation strategies.

Some of the potential risks being faced by the and possible risk mitigation plans and risk handling plans are given in the Table given below:



Risk Mitigation Plan 

Risk Handling Plan

Ambiguity/ Change in the requirements

Negotiate with the customer and document at the contract time itself how such situations will be handled.

Ask the customer to raise a change request, and negotiate the schedule and delivery dates.

Incorrect estimates

Ensure that no assumptions are made while estimating.

Re-estimate using the additional information available and re-plan.

Unavailability of required skills

Inform the customer. If possible, negotiate to get the team trained before the initiation of the project. Negotiate with the customer on schedule. If possible, obtain resources from the customer for consultancy and reviews.
Low skill level of team members Screening before allocation to the project to ensure presence of sufficient skills in the team. Plan training on weak areas to raise the skill level of the team. Assign repetitive tasks to improve the performance of the team members.
Manpower attrition Have backup team members ready for all the crucial activities in the project. In case of rare skills have the backup trained. Maintain good technical documentation to help in faster induction of new people into the team.

In cases where a single alternative is not available for backup, try to granulate the tasks being performed by a crucial team member and get a group of team members acquainted with the sub-tasks.


Delay in Customer feedback Negotiate before hand on the response time from the customer Communicate to the customer and add the delay to the schedule
Technical complexity in the project

Have adequate buffers in estimation for handling complexity and/or drop certain requirements in consultation with customer to reduce the complexity


Obtain support from experts in handling technical complexity

Use of new technology

Train the team on new technology. Include buffers for use of new technology.

Obtain support from Experts/Customer on the technology-based issues.

Tight schedule

Negotiate with the customer on schedule. Explore the possibility of increasing the manpower. (This may not always be possible and also works only when the tasks are fairly independent)


Negotiate with the customer on dropping some of the functionality / requirements to meet the schedule. Monitor the critical path closely.


Lack of process compliance

Identify the cause of non-compliance and train the team if necessary

Re-plan the reviews to improve the compliance


Risk monitoring and Tracking

The key to risk action planning is to consider the further consequences of a decision made. The RAMP is to be maintained as a part of the project plan and needs to be re-visited whenever changes occur in the project plan.

Contingency Planning can be used to monitor the risk and handle it when it occurs. The following sections gives guidelines in monitoring the risks.

The Project shall be continuously monitored for the risks that are identified and also for the occurrence of new risks. The identified risks and the mitigation plan are to be discussed in the Project review meetings/Project progress meetings. If required, transparency may be maintained with the customer so as to obtain support from the customer in monitoring the project for possible risks.


Whenever the project plan is modified, the risks shall be re-assessed and the RAMP shall be revised, if required. Whenever, risks occur in the project, the project plan and/or the project schedule shall be revised if necessary. Similarly, when new risks are identified during project execution, the RAMP shall be revised

Depending on the consequential impact or degree of customer dissatisfaction due to a risk, it probably needs to be brought to the notice of senior management. One may also decide to share some of the risks with the customer, to bring in transparency, especially where customer could decide to contribute in mitigating the risk.

Situations may arise in the project execution, when the occurrences of risks become inevitable. The project team needs to be prepared to handle such risks as and when they happen. If essential, the team may be trained to face the risks to have a minimal impact on the execution of the project and the quality of the work products in the course of events.


  • 0

Risk Management – Risk Assessment

Risk Assessment

Risk Assessment consists of two components –

  • Risk identification and
  • Risk analysis & prioritization

Risk identification focuses on enumerating possible risks to the project. The basic activity is to try to envision all situations that might go wrong in the project execution.

Risk analysis and prioritization activity considers all aspects (need to specify the aspects) of the risks and prioritizes them for purpose of risk management.

Although these two are distinct activities, they are often carried out simultaneously. All the relevant stakeholders need to be involved during the Risk identification and analysis process.

Risk identification

At the time of project initiation, Project Manager identifies the project risks. Risk identification is an exercise in envisioning what can go wrong.  Risks are identified under different categories.

The categories of risks are:

  • Business risk
  • Technology risk
  • Process risks
  • Resource risks
  • Customer risks
  • Schedule risk
  • Others

These risks are identified along with the category to which that belongs.

Some examples of risks under different categories are –

Category of risk Classification of Risks
Business risk
  •  Competitor may introduce the product early
  • Loss of market opportunities if project is delayed
Technology risk
  • Technology is new and not proven
  • Project is complex
Process risks
  • Process needs to be defined for the project
  • Lack of process compliance
Resource risks
  • Required skills not available
  • Manpower attrition
Customer risks
  • Delay in customer feedback
  • Changes to requirements
  • Tight schedules
  • Estimates are not scientific

Project Manager identifies the category of risk and the risk

Risk Analysis and Prioritization

The risks identified for the project indicate the possible events that can hinder the project in meeting its goals. The consequences of different risks may be different. While identifying strategies for risk management, it is beneficial to analyze and priorities the risks, so that appropriate strategies can be identified and management energies can be focused on high priority risks.

Risk analysis consists of –

  • Assessment of the probability of occurrence the risk and
  • Level of consequences of the risk.

For each risk identify the probability of risk occurrence as – Low, Medium and High. Risks are prioritized based on the Decision Analysis and Resolution (DAR) identified.

For each risk identify the level of consequence of the risk as – Low, Medium, High and Very High.

Based on the combination of probability of occurrence and level of consequence the risk priority (in terms of impact on the project) is determined. An example for identification of the risk priority is given below

Risk priority (impact on the project) is this table, which is going to be part of our PMP. If so, this should be an annexure.


Probability of occurrence of risk

Level of consequences

Low Medium High Very high 


Negligible Negligible Marginal Critical


Negligible Marginal Critical Catastrophic
High Marginal Critical Catastrophic Catastrophic


The risk priorities are only indicative. Based on the project specific risks, the Project Manager needs to identify the risk priority and assign impact values as per the guidance given below.

  • Catastrophic (Value: 1)
  • Critical (Value: 2)
  • Marginal       (Value: 3)
  • Negligible       (Value: 4) 


The Project manager provides impact values in the Risk Analysis and Management Plan for each risk.


Risk occurrence thresholds are defined to decide majorly based on the below mentioned factors.

    • Risk avoidance
    • Risk control
    • Risk transfer
    • Risk monitor
    • Risk acceptance

  • 0

Time-Cost-Quality Model

Build it fast and good. Build it fast and cheap. Build it good and cheap.


  • Time – Refers to the actual time required to complete a project and in production.
  • Cost – Refers to the amount of money that will be required to complete the project.
  • Quality – Refers to the functional elements that, when completed, make up the end deliverable for the project.
Achieving the right balance of quality, time and cost for your project is key to the success of your project.


  • Time + Cost = a project done quickly and cheaply … but the Quality may suffer
  • Quality + Time = an outstanding project delivered quickly … but it will Cost more
  • Cost + Quality = great work at a reasonable cost … but leave plenty of Time to complete it
Taguchi’s Philosophy
  • We cannot reduce cost without affecting quality
  • We can improve quality without increasing cost
  • We can reduce cost by improving quality
  • We can reduce cost by reducing variations. When we do so, performance and quality will automatically improve.

  • 0

Development Delivery Methodologies



The Waterfall flavour of development methodology is adopted where the requirements can be frozen during the requirements gathering phase of the project. When there are changes required, the change management process is invoked.

This model is typically used for non-eBusiness development projects or when the functionality extension to existing application is smaller in scope, complexity and has minimal risks associated with it. Characteristics of projects that use the waterfall model include:

  • Clear requirements definition
  • Shorter project duration
  • Design / technology to be used are of a proven / mature nature




The Incremental development methodology is used in project situations where most of the project requirements are known upfront. In this model, organisation collects most of the requirements. The technical architecture is finalised up-front. The development is performed in increments, with each increment fine-tuning and fine-graining the requirements. The first increment incorporates part of the planned capabilities; the next build adds more capabilities, and so on, until the system is complete.

Characteristics of projects which use the Incremental model include:

  • Most of the requirements are well-understood but some TBDs (To Be Decided) requirements may exist
  • Total project duration is greater (7-8 months and upwards)
  • Initial increment may focus on validating architecture and key technical risks
  • Functionality built over increments, initial increment may focus on high-priority functionality, last increment may focus on nice-to-have
  • Mostly used for large projects where the design and technology are proven and mature




In this model, the initial definition phase focus on creating a domain model and architecture that satisfies the non-functional requirements of the proposed application. The definition phase focuses on arriving at a roadmap for development of various features, depicting dependencies and relationship between the various features. This serves as an input to a coarse-grained (roadmap) plan for the entire engagement.

As iteration approaches, the plan is revisited and a detailed plan is drawn. Any impact on the roadmap is assessed from time-to-time. Each iteration may deliver a functionally working code base that may be released to the customer independently; however production releases may combine one or more iterations as required by the business. This model integrates the best practices of evolutionary development models and agile best practices.

Characteristics of projects which use the Iterative/ feature driven Incremental model include:

  • Requirements are not clear
  • Initial planning broadly scopes the iterations and arrives at a roadmap
  • Initial iterations may evolve architecture, UI frameworks etc.
  • Subsequently, every iteration focuses on the set of requirements that need to be built into that iteration
  • Iterations may be individually delivered to the customer
  • A release to production can combine one or more iterations


Task List

  • Review Design Ready Requirements
  • Participate in the WPP to Prioritise Requirements
  • Define Storyboards and Use cases
  • Assimilate Features
  • Prepare detailed Plan by Feature
  • Design/Build and Release by Feature
  • Design/Execute/Wrap Test Cases
  • Perf Test Features
  • User Acceptance
  • Deployment into Production
  • Warranty Support7

Scrum Main concepts

  • Product backlog – Broken down into a list of features
  • Release backlog – Top priority backlog items / features
  • Sprint = Iteration – Usually 2-4 week cycles and backlog items.
  • Priorities – For backlog items (features)
  • Estimates – Rough estimate for backlog items. Estimate individual tasks. Backlog item estimates are revised being the sum of task estimates.
  • Team roles – Product owner (steers the product)  – Scrum master
  • Daily Scrum – Daily 15 min meeting – what was done? What will do? Impediments?
  • Metrics – Burn-down chart – project velocity

Key Benefits

  • Allows to accommodate changes and ensure predictability of the end date
  • At any point of time, there is a testable version of the product
  • Brings in Continuous Integration
  • Delivery on time and on budget with complete transparency
  • Embedded culture that embraces iteration, adopting a ‘learn fast’ mentality
  • Internal collaboration – break down silos and communicate across teams
  • Empowered workforce – unlocked latent talent and celebrated new behaviours
  • Improved efficiency by the challenging of legacy behaviours
  • Synchronising and automating of your business processes
  • Reduce delays, rework, and other problems during implementation with a detailed implementation plan and accurate estimation of the time and resource requirements
  • Support solution adoption by receiving post-implementation support and knowledge transfer throughout the engagement
  • Scalable development and support of your applications
  • Real-time communication, collaboration, transparency, and direct accountability

Value Proposition

  • End-to-end program control and management
  • High-impact value delivery to you identifying and mitigating business risks or dependency
  • Identifying and executing business benefit case for the program
  • Identifying and leveraging best practices across the program
  • Mitigating cross-project operational risk
  • Effective up-skilling and communication
  • Streamlining business-as-usual processes
  • Providing opportunity to standardise business processes
  • Addressing non-value-add activities and organisational restructure
  • Managing organisation change requirements