Plan A, Plan B, Plan C……how far?

A new methodology for preparing Alternate Plans

Author: Paramita Mukerji

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

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

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?

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?

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.

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

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?

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:

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

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

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

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

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.

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/