Eighth Myth
Keeping backup/buffer in project schedule/plan is a bad practice.
It is bad if you make this buffer on fly without any concrete analysis and it is hidden to your clients/ management. Always maintain transparency with your client and each stakeholder of your project.
Please follow different techniques of reserve analysis and make it part of your contingency plan. Keep time and cost buffers/reserves, but after a thorough analysis and not on fly.
It is good to include contingency reserves into the overall project schedule to account for schedule uncertainty. The contingency reserve may be a percentage of the estimated activity duration, a fixed number of work duration or, may be developed by using quantitative methods. The contingency reserve may be used, reduced or, eliminated as per requirements. This should be clearly identified in the schedule document and should be known to each stakeholder of the project.
Reserve analysis compares the amount of the contingency reserves remaining to the amount of risk remaining at any time in the project in order to determine if the remaining reserve is adequate. Following are couple of methods/techniques you can use for your contingency plan:
1. What if scenario analysis
2. Reserve Analysis - Contingency reserves and management reserves
3. Proper use of Leads and lags in schedule
4. Expert Judgment, play a vital role in getting trust from management and stakeholders
5. Risk analysis and risk response planning, it gives better understanding on the reserves you need for your project.
6. Contingent Response Strategies, identifying predefined conditions where the reserves can be used.
Thursday, September 10, 2009
Wednesday, September 2, 2009
Seventh Myth (10 Myths of Software Project Planning)
Seventh Myth
I review/modify my plan frequently and it is up to date, I do not need to baseline my project plan?
Baseline is the point where you finalize your plan and believe that the plan will be used to track variations and slack in your project. We baseline a project plan or, part of project plan so that we can compare the progressive plan with baseline plan at any point of time.
The project can be baseline to compare (at any point of time):
1. The Start and End Date of a project plan or, any particular task.
2. The variance in actual work.
3. The variance in duration.
4. The BCWP (budgeted cost of work performed) or, BCWS (budgeted cost of work scheduled) or, to track the EV (earned value).
5. The schedule variance
6. The Cost Variance
7. The variance in project budget
8. We can also calculate various budget/forecast related variances such as BAC (Budget at Completion), ETC (Estimate to complete), EAC (Estimate at Completion), VAC (Variance at Completion), etc.
As a whole, baseline is used to compare your project plan at various stages of project execution and guide you to take preventive and corrective actions. It is also a kind of exercise where you learn through your mistakes, various scenarios/risks/errors during project execution and can use this knowledge to plan effectively in your future plans.
I review/modify my plan frequently and it is up to date, I do not need to baseline my project plan?
Baseline is the point where you finalize your plan and believe that the plan will be used to track variations and slack in your project. We baseline a project plan or, part of project plan so that we can compare the progressive plan with baseline plan at any point of time.
The project can be baseline to compare (at any point of time):
1. The Start and End Date of a project plan or, any particular task.
2. The variance in actual work.
3. The variance in duration.
4. The BCWP (budgeted cost of work performed) or, BCWS (budgeted cost of work scheduled) or, to track the EV (earned value).
5. The schedule variance
6. The Cost Variance
7. The variance in project budget
8. We can also calculate various budget/forecast related variances such as BAC (Budget at Completion), ETC (Estimate to complete), EAC (Estimate at Completion), VAC (Variance at Completion), etc.
As a whole, baseline is used to compare your project plan at various stages of project execution and guide you to take preventive and corrective actions. It is also a kind of exercise where you learn through your mistakes, various scenarios/risks/errors during project execution and can use this knowledge to plan effectively in your future plans.
Sunday, August 30, 2009
Sixth Myth (10 Myths of Software Project Planning)
Sixth Myth
I have executed 10 similar projects and I have idea on efforts for each task, I am going to build a plan which will be succeeded at any cost.
As I discussed in my earlier blogs also, project management planning is an art and not a task. You might have executed more than one similar project, but two projects can not be same in nature. Even PMBOK also says that “Every project creates a unique product, service or, result. Although repetitive elements may be present in some project deliverables, this repetition does not change the fundamental uniqueness of the project work".
The natures of your project always keep changing with:
1. Different environment,
2. Different client,
3. Different contract type,
4. Different resources available for work,
5. Different risks factors,
6. Different project dependencies,
7. Different scope changes
8. And other different scenarios.
So never ever try to be lethargic or, over confident in your project planning activities and always give your 100% even if you have plan/executed similar projects.
I have executed 10 similar projects and I have idea on efforts for each task, I am going to build a plan which will be succeeded at any cost.
As I discussed in my earlier blogs also, project management planning is an art and not a task. You might have executed more than one similar project, but two projects can not be same in nature. Even PMBOK also says that “Every project creates a unique product, service or, result. Although repetitive elements may be present in some project deliverables, this repetition does not change the fundamental uniqueness of the project work".
The natures of your project always keep changing with:
1. Different environment,
2. Different client,
3. Different contract type,
4. Different resources available for work,
5. Different risks factors,
6. Different project dependencies,
7. Different scope changes
8. And other different scenarios.
So never ever try to be lethargic or, over confident in your project planning activities and always give your 100% even if you have plan/executed similar projects.
Thursday, August 27, 2009
Fifth Myth (10 Myths of Software Project Management)
My project has taken more time than planned and I have project delivery soon, I think I need to put more resources to finish it on time.
You might be right, but have you analyzed other way around or it is your expectation that by putting more resources you will certainly be able to finish it faster.
Before taking any corrective action, analyze it properly with facts and figure, take expert judgment from your seniors/sub-ordinates, analyze other solutions and differentiate it with your decision. If you need to take any corrective action in your project, ensure that you have taken the best one and it would give you success in your project.
The method you selected is “Crashing” and there are several shortcomings of this method which should be analyze with the scenario you have before you take any decision. Crashing almost always adds cost to the project and it may add management time for the project manager. It has been seen that sometime putting more resource even add more time to project like you need to discuss the design, structure of code etc to make other resource comfortable to work for your project or, the resource you taken is not much experienced, etc.
So, I would suggest you to evaluate/analyzed your condition with both compression techniques i.e. “Crashing” and “Fast Tracking”. It is best to see all potential choices and then select the choice or, choices that have the least impact on the project.
You might be right, but have you analyzed other way around or it is your expectation that by putting more resources you will certainly be able to finish it faster.
Before taking any corrective action, analyze it properly with facts and figure, take expert judgment from your seniors/sub-ordinates, analyze other solutions and differentiate it with your decision. If you need to take any corrective action in your project, ensure that you have taken the best one and it would give you success in your project.
The method you selected is “Crashing” and there are several shortcomings of this method which should be analyze with the scenario you have before you take any decision. Crashing almost always adds cost to the project and it may add management time for the project manager. It has been seen that sometime putting more resource even add more time to project like you need to discuss the design, structure of code etc to make other resource comfortable to work for your project or, the resource you taken is not much experienced, etc.
So, I would suggest you to evaluate/analyzed your condition with both compression techniques i.e. “Crashing” and “Fast Tracking”. It is best to see all potential choices and then select the choice or, choices that have the least impact on the project.
Wednesday, August 26, 2009
Fourth Myth
My boss said me to decrease the estimates so that we can win the bid, I have no other way than reducing it to the time frame said by my boss.
It happened at times, but as a PM you are the person who can evaluate the change in plan and can communicate the reason why the plan/budget can not be minimized. You can evaluate it with two most schedule compression techniques i.e. Fast Tracking and Crashing.
Fast tracking is used to shrink the critical path by scheduling tasks in parallel which can help you finish your project faster whereas Crashing is the technique where we can use more resources to do a task so that it can be finished faster.
If you present proper analysis to your boss/manager, they can not deny the facts and figures. Don’t think that it will give bad impression to your boss rather he/she will be happy as you saved one more project from failure.
It happened at times, but as a PM you are the person who can evaluate the change in plan and can communicate the reason why the plan/budget can not be minimized. You can evaluate it with two most schedule compression techniques i.e. Fast Tracking and Crashing.
Fast tracking is used to shrink the critical path by scheduling tasks in parallel which can help you finish your project faster whereas Crashing is the technique where we can use more resources to do a task so that it can be finished faster.
If you present proper analysis to your boss/manager, they can not deny the facts and figures. Don’t think that it will give bad impression to your boss rather he/she will be happy as you saved one more project from failure.
Tuesday, August 25, 2009
Third Myth
"If you know MS Project, you know how to plan a project. Project Planning is nothing than putting a task list in MS project."
MS Project is a tool which can be learnt easily, but project planning is an art which comes through our experience and lessons learned during those experiences. Any tool like MS project gives you features to persist your planning data (schedule), but it doesn’t teach you various activities of planning which should be done to get a good and successful plan. Tool is a method to implement your planning concept, but you also need to know the inputs, outputs and other methods which give you good and efficient plan.
Project planning is not a task rather a process group with more than one task/activity and we need to exercise each activity of this process group if we want a really good plan. There are couples of activities we need to do for project planning:
1. Collect and study the requirements.
2. Scope Definition, also include non-functional requirements
3. Create WBS with work packages
4. Define and sequence activities
5. Estimate Activity Resources and Activity Durations
6. Develop schedule, MS project might be your tool here.
7. Estimate Costs and determine budget
8. Plan Quality
9. Plan Communication across project
10. Identify Risks and Plan Risk Responses
11. Review your plan with resources and other stakeholder
12. Finalize your project plan
13. Review your plan frequently and analyze the changes if any
14. Use your reserve wherever required
15. Support your project plan till the time project has been closed successfully
Notes: This is not an exhausted list and you should contact any book for the same.
MS Project is a tool which can be learnt easily, but project planning is an art which comes through our experience and lessons learned during those experiences. Any tool like MS project gives you features to persist your planning data (schedule), but it doesn’t teach you various activities of planning which should be done to get a good and successful plan. Tool is a method to implement your planning concept, but you also need to know the inputs, outputs and other methods which give you good and efficient plan.
Project planning is not a task rather a process group with more than one task/activity and we need to exercise each activity of this process group if we want a really good plan. There are couples of activities we need to do for project planning:
1. Collect and study the requirements.
2. Scope Definition, also include non-functional requirements
3. Create WBS with work packages
4. Define and sequence activities
5. Estimate Activity Resources and Activity Durations
6. Develop schedule, MS project might be your tool here.
7. Estimate Costs and determine budget
8. Plan Quality
9. Plan Communication across project
10. Identify Risks and Plan Risk Responses
11. Review your plan with resources and other stakeholder
12. Finalize your project plan
13. Review your plan frequently and analyze the changes if any
14. Use your reserve wherever required
15. Support your project plan till the time project has been closed successfully
Notes: This is not an exhausted list and you should contact any book for the same.
Sunday, August 23, 2009
10 Myths on software project planning
First Myth
I have a detailed technical requirements document, I don’t think I need anything else, I should create a plan in MS project directly now.
Don’t be in hurry to develop a project plan, there are several other activities which need to be done before you create schedule in MS project.
Once you have a requirements document, you need following steps to be followed before you develop a plan/schedule in MS project:
a. You need to brain storm on the document with your team mates and need to ask right questions from right person to define a detailed scope.
b. Not only concentrate on functional requirements but also consider non-functional requirements while you define your scope.
c. After you defined your scope, prepare a WBS (Work Breakdown Structure) with the help of work packages. Also divide your work packages to the extent (activities) which can be assigned and planned properly. You can either make this WBS and activity list manually or, in MS project.
d. There are also other activities/techniques (Activity Sequencing, Activity Resource Estimating, Resource leveling, etc.) which can be done depending upon the need and kind of project.
e. Don’t forget to review the plan with your team members before you baseline the plan.
Second Myth
Created my plan in MS project, all my responsibilities of project planning have been completed.
Even if you develop a good plan using standard techniques, your duty is continued till the time the project is closed.
a. You need to review your plan frequently for updates, new requirements, risks, dependencies to maintain your plan for better management of your project.
b. Frequent review exercise will not only give you a preventive environment but also give you proper time to plan your corrective actions.
c. Your effort in each process group (Initiation, Planning, Execution, Monitoring & Control and Closing process group) is equally important for you and you can not get success if you skip any or, give small weightage to any process group. You need to review your plan/schedule in each process group and need to take corrective actions in case of any mishappening.
d. Even if you have developed a very good plan, you can not get success if you have not executed and controlled it well.
e. Be open to any change in plan, but review the change(s) properly before you go for change. Also, use your reserves at right places.
I have a detailed technical requirements document, I don’t think I need anything else, I should create a plan in MS project directly now.
Don’t be in hurry to develop a project plan, there are several other activities which need to be done before you create schedule in MS project.
Once you have a requirements document, you need following steps to be followed before you develop a plan/schedule in MS project:
a. You need to brain storm on the document with your team mates and need to ask right questions from right person to define a detailed scope.
b. Not only concentrate on functional requirements but also consider non-functional requirements while you define your scope.
c. After you defined your scope, prepare a WBS (Work Breakdown Structure) with the help of work packages. Also divide your work packages to the extent (activities) which can be assigned and planned properly. You can either make this WBS and activity list manually or, in MS project.
d. There are also other activities/techniques (Activity Sequencing, Activity Resource Estimating, Resource leveling, etc.) which can be done depending upon the need and kind of project.
e. Don’t forget to review the plan with your team members before you baseline the plan.
Second Myth
Created my plan in MS project, all my responsibilities of project planning have been completed.
Even if you develop a good plan using standard techniques, your duty is continued till the time the project is closed.
a. You need to review your plan frequently for updates, new requirements, risks, dependencies to maintain your plan for better management of your project.
b. Frequent review exercise will not only give you a preventive environment but also give you proper time to plan your corrective actions.
c. Your effort in each process group (Initiation, Planning, Execution, Monitoring & Control and Closing process group) is equally important for you and you can not get success if you skip any or, give small weightage to any process group. You need to review your plan/schedule in each process group and need to take corrective actions in case of any mishappening.
d. Even if you have developed a very good plan, you can not get success if you have not executed and controlled it well.
e. Be open to any change in plan, but review the change(s) properly before you go for change. Also, use your reserves at right places.
Subscribe to:
Posts (Atom)
