Successfully reported this slideshow.
Upcoming SlideShare
×

# Paramita mukerji

278 views

Published on

• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

• Be the first to like this

### Paramita mukerji

1. 1. Plan A, Plan B, Plan C……how far? A new methodology for preparing Alternate Plans Author: Paramita Mukerji
2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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/