1. Plan A, Plan B, Plan C……how far?
A new methodology for preparing Alternate Plans
Author: Paramita Mukerji

2. Index
Abstract
Objective
Prologue
Alt-PM (Alternate Planning Methodology)
Prelude
Methodology
Critical factors for success
Benefits
Conclusion
Figures
Fig 1: Basis of Initial Plan
Fig 2: Reasons for change in plan
Fig 3: Root Causes behind change in plans
Fig 4: Project Managers' opinion on preparation of alternate plans
Tables
Table 1: Factors
Table 2: Phases
Table 3: Benchmark Table
Table 4: Calculation of Total Weight
Table 5: Number of Alternate Plans

3. Abstract
The success of a project is highly dependent on how well the Project Manager is able to steer the project
through various challenges. As a seasoned Project Manager, being proactive, mitigating risks & having
contingency plans in place are some basic things which will help him sail through difficult situations. An
experienced Project Manager should have Plan B ready if Plan A fails or show signs of failure. Going by
the same logic, Plan B can also fail and thus he should be ready with Plan C, Plan D and so on. But how
far? Theoretically it may be good to be fool proof but practically every plan will have its own reason to fail.
So how many plans should the Project Manager have to mitigate risks, ensure on time delivery, high
CSAT scores etc.
The answer to this question cannot be mathematically calculated. A veteran Project Manager may have
an intuitive answer. But that is not a reasonable and sustainable expectation from every Project Manager.
We try to find a model, which provides a framework to allow easy decision making during planning. This
should allow every Project Manager with a model driven second opinion to base his fallback plans. With
inputs received from brainstorming, Q&As, surveys and discussions with project team members, we
develop this model.
This model uses generic factors applicable across all types of IT projects. It will help the Project Manager
arrive at an optimal number of alternative plans to have. This will enable success by design and not by
chance!
Keywords: IT Project types, Project Plans, Fall back Plans, Project Constraints, Project Variables,
Project Resources
Objective
Why have Alternate Plans?
Planning is something which we require to do in every aspect of our lives. A kid is told to make a plan on
how he will utilize his time in preparing for exams. A teenager is expected to make a plan towards
building a good career for himself. If we decide to go on a vacation, we need to plan on how we will make
full use of the time available for sightseeing. A project manager prepares a plan for project execution.
Every job requires the worker to prepare a plan before he starts working on it. The kid wants to score
good marks, the teenager wants to be successful in choosing the right career, the traveler wants to visit
all tourist spots and not leave out any place. The Project Manager wants to successfully deliver and
satisfy the customer along with making profits. To summarize everyone wants to be successful. Thus we
spend a good amount of time & efforts in making the plan. We all believe that better the plans are, better
are the chances of success. But how far do we use the initial plans?
Very often we find that we are not able to stick to the plans which we made initially. We are forced to
make changes on the fly. We don’t get enough time to think and we move over to a different plan. This
leads to the vicious cycle of making & changing plans. Experience tells that we always need to make

4. frequent modifications in our plans and use alternate ones. Would it be useful to have some alternate
plans with us from the beginning? This study is towards finding out whether there is any benefit in having
alternate plans before the previous one fails. What is the optimum number of such alternate plans one
should be ready with?
I have used my experience in managing various IT projects and also gathered information from people
working in various types of IT projects to analyze the situation, infer and come up with suggestions on
preparing alternate plans.
Prologue
Current scenario in IT projects
Inputs were gathered from people working in various types of IT projects like Development Projects,
System Enhancement Projects, Support & Maintenance Projects, Infrastructure Projects, Package
Implementation Projects, System Integration Projects and Validation & Verification Projects. They were
majorly Project Managers and some in various types of other roles like Project Lead, Analyst, Architect,
Tester, Quality Assurance, Developer, vendor side SPOC across organizations. 70% of them were of the
opinion that they always felt that the plan on which they were working could fail any time and 90% of them
did not have any alternate fall back plan ready with them.
Fig 1: Basis of Initial Plan
In majority of projects the plans are prepared by the project managers during the project planning phase.
0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00% 35.00%
Others
Proposal
Contract
Requirements
Resources
Past Experience
On what basis initial plan is prepared?

5. Figure 1 gives us an overview on the aspects based on which the plan is built. These plans are approved
by senior team members and then by the customer. On an average, in a span of one year the plans get
changed 1-2 times in 55% of the projects, 3-4 times in 35% of the projects and more than 4 times in 10%
projects. The project teams take into consideration all relevant information to prepare the project plans
and get customer approvals, still these plans stand a high chance of failure. Theoretically we may say
that the success of the plan is dependent on the clarity of information available and the experience of the
person making the plan but, it is practically not possible to prepare a fail proof plan at the start of the
project and use it throughout the life of the project.
It is essential for the project teams to be ready with alternate plans which they can immediately start using
once the current plan fails. In majority of projects, the alternate plans are not created in advance. They
are created just after the current plan fails.
Common reasons for failure
Issues like lack of skilled resources, lack of experience, lack of technical competence and processes
which are either not defined or not followed are considered reasons internal to the team. These can be
controlled internally within the organization. It is not surprising if there are changes in the project plans
due to these reasons but there are factors beyond the control of the project teams which are externally
driven, which definitely lead to change in plans.
Fig 2: Reasons for change in plan
Most common external factors which lead to need for alternate plans are:
0% 5% 10% 15% 20% 25% 30% 35% 40% 45% 50%
Others
Change in scope
Change in budget
Change in timelines
Change in target quality parameters
What were the reasons which led to the failure
of the plan you were following earlier?

6. Change in scope
It is the era for dynamism. No project can have fixed scope which was defined in the start of the project
and has remained the same till the end of the project. New ideas, improvements are suggested
frequently. This causes increase or decrease of scope which need to be accommodated in the projects
being executed. Competition or a statutory body may bring in a new twist in the form of a new feature or
policy which impacts the scope of the project. All this forces the project to make changes in plans.
Change in budget
The financial position of the customer may change anytime. This impacts the availability of resources in
the projects. The projects may have to closed before time or may have to be ramped down to
accommodate the budget of the customer. All this forces the project to make changes in plans.
Change in timelines
Company X and Company Y are competitors. Company X wants to launch a product with exclusive
features and capture the market before Company Y launches its product. While Company X is still
developing the product, it is known from reliable sources that Company Y is also close to developing &
launching a similar product. In order to capture the market and get the maximum business benefit,
Company X will push for a launch before the date decided earlier. This is a typical example of how
change in timelines is not deliberate but driven by many factors beyond the control of any project team or
customer himself.
Change in final product quality/specifications
While eliciting requirements if we follow proper techniques and have experience we can be sure on
capturing all the functional requirements (features) but it is not easy to capture all the non functional
(quality related) requirements. In a project where a web form is to be developed, the number of fields,
number of drop downs and number of submit buttons required by the user can be documented from the
beginning. The user expectation on the time it should take to show the acknowledgement screen when
the user clicks the submit button may change once the user starts using the form. Implementing this
change effects everything from design to code. This causes change in plans!
In a project there may not be only one reason for failure of a plan. Many reasons contribute differently
towards the failure and together give rise to the need for changing the course of the project. The root
cause of failure of plans across different types of projects based on inputs from project managers across
projects is listed below. The data below also gives us the % distribution across these causes.

7. Fig 3: Root Causes behind failure of plans
Timing of alternate planning
Organizations which have well defined quality processes mandate the project teams to practice proactive
project management. The Project Managers to proactively analyze the situations (as listed in Figure 2)
and are ready with the alternate plans. They need to prioritize based on project dynamics and decide on
the plans they need to be ready with. This is taken care under Risk Management. The Project Managers
along with all stakeholders evaluate the project variables, have internal discussions / brainstorming
sessions and prepare a prioritized list of risks. Based on the priority they decide on the mitigation plans.
Some of the mitigation activities do include preparation of alternate project plans to be used in case of
eventuality.
After discussion with many project managers it is found that 60% of the projects did not prepare alternate
plans whereas 40% projects prepared them. In the projects where they used the alternate plans, a good
proportion of the plans were prepared after the current plans failed. Majority of the project managers feel
that it would be better if the alternate plans were prepared beforehand.
9%
11%
43%
4%
4%
22%
7%
What was the root cause of failure?
In capability of the delivery team
Unavailability of resources
Customer driven
Competition driven
Statutory regulations
Technology related
Others

8. Fig 4: Project Managers' opinion on preparation of alternate plans
Constraints in proactive planning
Maximum numbers of managers want the alternate plans to be prepared in advance but this is hardly
practiced in reality. There are many constraints which the managers faces because of which the alternate
plans are not prepared. Some of the major constraints are:
Inability to look ahead
The Project Manager’s experience should enable him to think ahead of time which will help him preparing
alternate plans. A seasoned project manager along with inputs from his team should be able to
understand the dynamics of the project and the environment and be prepared with alternate plans. The
Project Manager should be well prepared for any eventuality. He should be connected to the business to
foresee disruptions. In the absence of this capability preparing alternate plans proactively is difficult.
Unavailability of time (budget)
When the initial plan is prepared, Project Manager invests good amount to time & effort in preparing it.
Managers don’t put in enough thought and efforts while preparing the alternate plans assuming that they
will not be required to use them. In terms of budget, less than 2% of it is used in preparing alternate
plans. Most times this effort is not billed to customer. Creating alternate plans is considered a trivial
activity and not given its due importance in terms of time & effort.
0% 10% 20% 30% 40% 50% 60% 70% 80%
Can't say
After the earlier plan failed
Before the earlier plan failed
No need to prepare alternate plans
When do you think the alternate plan should be
prepared?

9. Unavailability of data required to prepare the plan
Due to disconnect between the various teams and also between the vendor & the customer, relevant data
does not reach the Project Manager. The Project Manager is not aware of many contractual agreements
which they come to know later on in the project leading to unplanned changes in the plans.
Not part of process to be followed
Following the defined policy, processes & guidelines ensures that the basic hygiene factors are not
overlooked. Preparing alternate plans should be mandated in the form of strict policy and not left on
choice which is the situation at present.
There is some key information needed by the managers which are helpful in overcoming the above
constraints and prepare the alternate plans. These include clarity on the revised scope, revised budget,
revised timelines and available resources (skill & tenure). This information is easily available once the
changes actually happen in the project. Thus preparing the alternate plans after the change has
happened is comparatively easier than preparing it before hand. We need to equip the project managers
with information which will enable him to think ahead and prepare the alternate plans proactively.
Constraints in implementing plans
In situations where alternate plans are available we find that there is apprehension in the teams towards
shifting to a new plan or unavailability of resources required. The teams tend to have inertia in moving
over to something different. The reasons for such inertia can be classified under the following categories:
Tendency to revert to earlier plan
Unavailability of a detailed revised plan
Unavailability of resources (Human, Hard or Software)
Lack of faith in the revised plan
Frequent changes in the revised plan
Delay in getting Customer Approval
Delay is getting Senior Management Approval
The managers need to overcome the above constraints for success of the project. It is an established fact
that all projects will undergo changes. To take care of the changes, effective alternate plans need to
available and also be followed. Without successful implementation of alternate plans the projects cannot
be successful. The best of plans will not work if not used by the team. We need to equip the project
managers with guidelines on how this can be achieved.
Alt-PM (Alternate Planning Methodology)
This is reference tool to help projects identify the optimum number of alternate plans required
under varying project conditions.
Based on what we have discussed so far in the document above, we can summarize it as:

10.  Initial Plans are designed to be more robust as teams spend more efforts in building them.
 There is 90% probability that the project will have to change the plan. There are many reasons to
support this cause.
 Even though it is known, rarely the alternative plans are prepared beforehand.
 Majority of the alternate plans are prepared at the spur of the moment when the previous plan
fails. The effort spent in this is much less than what was spent for making the initial plan.
 There is challenge in shifting from one plan to the other.
There is strong need to equip the project managers with a frame work which will help them identify the
need of the alternate plans, overcome the constraints in developing the alternate plans proactively and
also overcome the constraints in implementing these plans. No two projects are same. Each project will
have something unique about it. The challenges faced by one project are different from the ones faced by
the other. Each project has its own set of data with respect to scope, budget, timelines, resources, quality
and the customer. The requirement for alternate plans will also vary accordingly.
Prelude
Alt-PM is a methodology aimed towards helping the managers in identifying the alternate plans they
should prepare at the beginning of each phase proactively based on information available. It also factors
in the challenges with respect to implementation of these plans. This methodology leverages on the
experience of managers and the information available from successfully implemented past projects. It
provides the flexibility to users to define their own project constraints based on their project information. It
captures the experience gained by project managers during execution of previous projects which were of
similar type and had similar constraints. This experience is used in building a guideline. Data from similar
types of past projects is then used in benchmarking the number of alternate plans to be prepared so that
they can be prepared and successfully implemented.
Methodology
Guidelines are prepared by experienced project managers with the inputs from the data from past
projects of similar type. Guidelines once prepared are reusable by projects with similar constraints. These
guidelines can be progressively evolved with usage. The usage of this methodology is a two step
process.
Step 1: Preparation of the Guidelines & Benchmarks
Preparation of the Guidelines
Factors: List the constraints which are generally faced by projects of a particular type. Assign weight to
each of this factor based on how strongly this constraint will affect the project plan. This is done in the
scale of 0-5 where 0 means least effect and 5 means maximum effect. Table 1 below is a sample Factor
Table which is prepared for development projects of similar characteristics.
Phases: List the various phases of the project in a chorological order and assign weight to each phase.
Assign weights based on how any change in this phase will affect the project plan. The weight is higher

11. for phases where any change during that phase high effect on the plan. Table 2 below is a sample Phase
Table which is prepared for development projects of similar characteristics.
S. No.
Factors due to which changes can happen in any
project
Weights based on impact of
this factor on project plans in
scale of 0-5 (A)
1 Team not experienced in the domain 3
2 Team not experienced in the technology 4
3 Team not skilled for gathering requirements 2
4 Team not clear on the requirements 2
5 Team resists any change 4
6 Team does not follow processes 1
7 Team is not aware of the overall project objective 1
8 Less experienced Project Manager 3
9 Delay in taking decisions by senior management 2
10 Customer not clear on the requirements 4
11 Multiple stakeholders 4
12 Delay in approvals from customer 4
13 Delay in query resolution by customer 3
14 Budget changes due to customer 2
15 Delay due to vendor 3
16 Competitors launching similar product 5
17 Human Resources not available 3
18 Software/Hardware resources not available 2
19 Required tools not available with the team 1
20 Prone to changes through regulatory policies 5
Table 1: Factors
Phases in the project Weight (B)
Initiation 0.25

12. Table 2: Phases
Defining the Benchmarks (Benchmark Table)
Identify completed projects of similar characteristics. Identify the constraints that were faced by these
projects during the various phases of implementation. For each of the factor, note the corresponding
weights as mentioned in the Factor Table (A). For each of the factor note the phase in which they were
identified and the corresponding weight from Phase Table (B). Take the product of A&B as the final
weight. Since the projects are already completed, the team is able to count the number of alternate plans
which were actually prepared during the execution of these projects. Using this information prepare the
Benchmark Table. More the number of completed projects analyzed better will be the benchmarks.
Consider the average value for the benchmarks as every project may not have prepared the same
number of alternate plans even if the weights were same. Table 3 shows a sample Benchmark Table
which is prepared for development projects of similar characteristics.
Weight
Range
Recommended number of Alternate Plans
Initiation Planning Requirements Design CUT Testing
0-1 0 0 0 0 0 0
2 to10 1 1 2 2 3 3
11 to 20 2 2 3 3 4 4
>20 3 3 4 4 5 5
Table 3: Benchmark Table
Step 2: Calculating the number of Alternate Plans for a new project
When a new project or task is assigned to the team the project manager should follow these steps to
derive the optimum number of alternate plans:
Calculating total weight
List the constraints in the new project. These constraints should be already present in the list of the
factors identified in the Factor Table. Take the corresponding weights from this table (A). For each of the
factor identify the phase of the project when these constraints have maximum probability of identification
and get the corresponding weight using the Phase Table (B). Calculate the final weight as (A*B). Table 4
below gives an example on how the total weight is calculated for a development project.
Planning 0.25
Requirements 1
Design 2
CUT 2
Testing 3

13. Deriving the number of alternate plans
Calculate the sum of the total weights for each of the phases separately. Look up in the Benchmark Table
and find the number of alternate plans corresponding to the total weight for that phase. Table 5 below
gives an example on how the phase wise optimum number of alternate plans is derived for a
development project.
S. No. Factors effecting the current project
Weight
based on
Table 1 (A)
Phase when
this factor may
be identified
Weight
based on
Table 2
(B)
Total
Weight
(A * B)
1 Team not experienced in the domain 3 Initiation 0.25 0.75
2 Team not clear on the requirements 2 Design 2 4
3 Team does not follow processes 1 Requirements 1 1
4 Multiple stakeholders 4 Planning 0.25 1
5 Delay in query resolution by customer 3 Planning 0.25 0.75
6 Budget changes due to customer 2 Design 2 4
7 Competitors launching similar product 5 Design 2 10
8 Human Resources not available 3 Planning 0.25 0.75
9
Software/Hardware resources not
available
2 Planning 0.25 0.5
10
Required tools not available with the
team
1 CUT 2 2
11
Prone to changes through regulatory
policies
5 Design 2 10
Table 4: Calculation of Total Weight
Phase(s)
Total weight
Calculated
from Table 4
Alternate Plans
to be prepared
Initiation 0.75 0
Planning 3 1
Requirements 1 0
Design 28 4
CUT 2 3
Testing 0 0
Table 5: Number of Alternate Plans
Critical factors for success
The success of this methodology depends on

14.  Experience of the person/team who is preparing the guidelines & benchmarks.
 Reliability of the data received from past projects.
 Clear understanding of the project constraints by the person/team making the guidelines.
 Updating & improving the guidelines after successful completion of each project in which these
guidelines were used in calculating the number the alternate plans.
 Proper understanding before using the guidelines & the benchmarks.
 Proper use of the guidelines & benchmarks.
 Same set of guidelines and benchmarks cannot be used for all types of projects. Only similar type of
projects can use the same set of guidelines & benchmarks. For other types of projects different set of
guidelines & benchmarks need to be prepared.
Benefits
This methodology is an attempt to help the Project Managers in managing the projects through proactive
planning. The industry is highly dynamic and very uncertain. Through this methodology we are using our
experience & knowledge gained through many years of project execution and trying to bring some
certainty in the area of project planning. The benefits can be measured by way of
 Planning for eventualities in advance and saving project effort & time leading to cost saving.
 Knowledge & experience available with few individuals is documented in the form of guidelines thus
enhancing knowledge sharing and reducing person dependency.
 Achieving higher customer satisfaction scores by showcasing proactive project management.
 Project team is open for changes as they have already planned for such situations. This makes them
very flexible which is a preferred attribute of vendors.
 Keeping the team members motivated as the project manager is able to plan and allocate work in a
more systematic manner even when the project undergoes changes.
Conclusion
The industry today is mature but very dynamic. There is no one way or one golden set of rules which can
resolve the issues. Through this methodology, project managers should be able to face the challenges in
a more structured & organized manner.

15. About the author
Paramita Mukerji is an IT professional with a proven track record of 13+ years in IT services. She is
currently working as Project Management Consultant with Wipro Technologies, one of the Top-4
companies in IT business in India. She possesses strong leadership capability. Using a system oriented
approach; she has guided many cross functional teams across different business verticals in project
management. She is an Electronics and Telecommunication Engineer by training, with several
professional certifications like PMP, Prince 2 and ITILV3. She specializes in the areas of Software Project
Management and Software Quality Management. She is a certified SEI Audit Team Member and KPMG
Certified Internal Auditor.
For further details please visit: in.linkedin.com/in/paramitamukerji/