Types of Estimating Techniques:
1. Scientific wildly assumed guess
2. Global efficiency factor Title -----------
3. Productivity adjustment percent
4. Program evaluation and review, or three-point estimating, technique
Search Your Query..
Custom Search
The Benefits and Challenges of Estimating Work Times
Estimating the work times provides several benefits for the project manager. It gives an idea of the level of effort required to complete a project. This information then enables the project manager to produce a realistic plan based upon that effort. Estimating also helps the project manager anticipate the budget for the project. Allocated funds are largely based on the effort, or labor, to produce the product or deliver the service. The estimate becomes the basis for developing a schedule. Hours are converted to flow time, which in turn is used, with the interrelationships among tasks, to calculate start and stop dates. Lastly, doing an estimate breeds commitment. If the people who will do the work also help make the estimates, they will feel more committed to their tasks and keep within the allotted time. While it offers many benefits, estimating is not easy, for two reasons. First, it takes time and effort to develop reliable estimates. Many people take the path of least resistance and generate either an extremely pessimistic or an overly optimistic estimate. Good estimating requires extensive calculation and research to avoid skewing the calculated values. Second, estimating requires dealing with ambiguity. By its very nature, estimating has both knowns and unknowns. The unknowns can generate fear or cause people to react out of ignorance. Either way, confidence in the resulting estimate is low.
PMP Prep Courses 2002 On Project Management Environment
2-1 Project Stakeholders are defined as:
A. Individuals and organizations that are actively involved in the project
B. Individuals and organizations who use the project's product
C. Individuals and organizations whose interest may be positively or negatively affected as a result of project execution or successful project completion
D. Individuals and organizations who provide the financial resources
E. All of the above
2-2 Fast Tracking is defined as:
A. A method of project scheduling
B. Linking of a project to the ongoing operations of the performing organization
C. The overlapping of project phases
D. A method of construction
E. A method of defining scope of work
2-3 A product life cycle is a series of phases whose name and number is determined by the control needs of the organization or organizations involved in the project.
A. True
B. False
2-4 General Management encompasses all except:
A. Finance and accounting
B. Strategic planning
C. Sales and marketing
D. Developing a new product or service
E. Organizational Behavior
2-5 The organization structure that provides the project manager with the most authority over the project team is:
A. Functional
B. Weak matrix
C. Balance matrix
D. Strong matrix
E. Projectized
2-6 Key Management skills include:
A. Leading
B. Communicating
C. Negotiating
D. Problem solving
E. All of the above
2-7 A regulation is a document that lays down provisions with which compliance is mandatory.
A. True
B. False
2-8 Problem solving addresses only the causes of problems on the project.
A. True
B. False
2-9 In the phase sequence defined by project life cycles, a phase is not begun until all deliverables are approved from the preceding phase.
A. True
B. False
2-10 Characteristics of project phases are:
A. Milestones
B. Objectives
C. Activities
D. Deliverables
E. All of the above
Answers
Question Answer Reference
2-1 E PMBOK page 16
2-2 C PMBOK page 12
2-3 B PMBOK page 205
2-4 D PMBOK page 21
2-5 E PMBOK page 19
2-6 E PMBOK page 24, 25
2-7 A PMBOK page 26
2-8 B PMBOK page 25
2-9 B PMBOK page 12
2-10 E PMBOK page 11, 12
A. Individuals and organizations that are actively involved in the project
B. Individuals and organizations who use the project's product
C. Individuals and organizations whose interest may be positively or negatively affected as a result of project execution or successful project completion
D. Individuals and organizations who provide the financial resources
E. All of the above
2-2 Fast Tracking is defined as:
A. A method of project scheduling
B. Linking of a project to the ongoing operations of the performing organization
C. The overlapping of project phases
D. A method of construction
E. A method of defining scope of work
2-3 A product life cycle is a series of phases whose name and number is determined by the control needs of the organization or organizations involved in the project.
A. True
B. False
2-4 General Management encompasses all except:
A. Finance and accounting
B. Strategic planning
C. Sales and marketing
D. Developing a new product or service
E. Organizational Behavior
2-5 The organization structure that provides the project manager with the most authority over the project team is:
A. Functional
B. Weak matrix
C. Balance matrix
D. Strong matrix
E. Projectized
2-6 Key Management skills include:
A. Leading
B. Communicating
C. Negotiating
D. Problem solving
E. All of the above
2-7 A regulation is a document that lays down provisions with which compliance is mandatory.
A. True
B. False
2-8 Problem solving addresses only the causes of problems on the project.
A. True
B. False
2-9 In the phase sequence defined by project life cycles, a phase is not begun until all deliverables are approved from the preceding phase.
A. True
B. False
2-10 Characteristics of project phases are:
A. Milestones
B. Objectives
C. Activities
D. Deliverables
E. All of the above
Answers
Question Answer Reference
2-1 E PMBOK page 16
2-2 C PMBOK page 12
2-3 B PMBOK page 205
2-4 D PMBOK page 21
2-5 E PMBOK page 19
2-6 E PMBOK page 24, 25
2-7 A PMBOK page 26
2-8 B PMBOK page 25
2-9 B PMBOK page 12
2-10 E PMBOK page 11, 12
PMP Prep Courses Question Paper
1-1 A project is defined in the PMBOK as:
A. A process of considerable scope that implements a plan
B. A group of ideas managed in a coordinated way to obtain a desired outcome
C. A temporary endeavor undertaken to create a unique product or service
D. A collection of activities with a beginning and an end
E. A series of tasks or functions that must be completed by a certain date
1-2 A program is defined in the PMBOK as:
A. A group of projects managed in a coordinated way to obtain benefits not available from managing them individually
B. A number of subprojects divided into manageable components enabling a project team to ensure the completion of a desired outcome
C. A project plan developed by key management personnel to obtain a desired outcome
D. The means to subdivide the project into manageable segments
E. The framework project management uses to ensure the completion of projects
1-3 Project Integration Management:
A. Describes the processes required to ensure that the project includes all the work required to complete the project successfully
B. Describes the processes required to ensure timely completion of the project
C. Describes the processes required to ensure that the project will satisfy the needs for which it was undertaken
D. Describes the processes required to ensure that the various elements of the project are properly coordinated
E. Describes the processes to acquire goods and services from outside the organization
1-4 Project Scope Management includes which processes:
A. Plan Development
B. Project Plan Execution
C. Overall Change Control
D. Performance Reporting
E. Initiation
1-5 The purpose of the PMBOK is to identify and describe knowledge and practices that must be applied uniformly on all projects.
A. True
B. False
1-6 An example of a project is:
A. Billing customers
B. Managing an organization
C. Constructing a building or facility
D. Providing technical support
E. Providing financial services
1-7 A process that is not part of Project Risk Management is:
A. Identification
B. Solicitation
C. Qualitative & Quantitative Analysis
D. Response Development
E. Monitoring and Control
1-8 Operations and projects share many characteristics.
A. True
B. False
1-9 Which process is not included in Project Cost Management?
A. Resource planning
B. Estimating
C. Budgeting
D. Control
E. Closeout
1-10 The process that is not a part of time management is:
A. Activity Definition
B. Resource Planning
C. Schedule Development
D. Activity Sequencing
E. Schedule Control
Answers
Question Answer Reference
1-1 C PMBOK page 4
1-2 A PMBOK page 10
1-3 D PMBOK page 7
1-4 E PMBOK page 8
1-5 B PMBOK page 3
1-6 C PMBOK page 4
1-7 B PMBOK page 8
1-8 A PMBOK page 4
1-9 E PMBOK page 8
1-10 B PMBOK page 8
A. A process of considerable scope that implements a plan
B. A group of ideas managed in a coordinated way to obtain a desired outcome
C. A temporary endeavor undertaken to create a unique product or service
D. A collection of activities with a beginning and an end
E. A series of tasks or functions that must be completed by a certain date
1-2 A program is defined in the PMBOK as:
A. A group of projects managed in a coordinated way to obtain benefits not available from managing them individually
B. A number of subprojects divided into manageable components enabling a project team to ensure the completion of a desired outcome
C. A project plan developed by key management personnel to obtain a desired outcome
D. The means to subdivide the project into manageable segments
E. The framework project management uses to ensure the completion of projects
1-3 Project Integration Management:
A. Describes the processes required to ensure that the project includes all the work required to complete the project successfully
B. Describes the processes required to ensure timely completion of the project
C. Describes the processes required to ensure that the project will satisfy the needs for which it was undertaken
D. Describes the processes required to ensure that the various elements of the project are properly coordinated
E. Describes the processes to acquire goods and services from outside the organization
1-4 Project Scope Management includes which processes:
A. Plan Development
B. Project Plan Execution
C. Overall Change Control
D. Performance Reporting
E. Initiation
1-5 The purpose of the PMBOK is to identify and describe knowledge and practices that must be applied uniformly on all projects.
A. True
B. False
1-6 An example of a project is:
A. Billing customers
B. Managing an organization
C. Constructing a building or facility
D. Providing technical support
E. Providing financial services
1-7 A process that is not part of Project Risk Management is:
A. Identification
B. Solicitation
C. Qualitative & Quantitative Analysis
D. Response Development
E. Monitoring and Control
1-8 Operations and projects share many characteristics.
A. True
B. False
1-9 Which process is not included in Project Cost Management?
A. Resource planning
B. Estimating
C. Budgeting
D. Control
E. Closeout
1-10 The process that is not a part of time management is:
A. Activity Definition
B. Resource Planning
C. Schedule Development
D. Activity Sequencing
E. Schedule Control
Answers
Question Answer Reference
1-1 C PMBOK page 4
1-2 A PMBOK page 10
1-3 D PMBOK page 7
1-4 E PMBOK page 8
1-5 B PMBOK page 3
1-6 C PMBOK page 4
1-7 B PMBOK page 8
1-8 A PMBOK page 4
1-9 E PMBOK page 8
1-10 B PMBOK page 8
Schedule of Exam
Workshop Schedule by Week
Tues. Wed. EMEA Topic Speaker Location
31 July,- 1, 3 Aug Overview Mark Hatten Plano TX
8 August 9 August Framework Linda Graves Arlington TX
15 August 16 August Risk Yves Munger Phoenix AZ
22 August 23 August Scope Ed Whitney Downers Grove IL
29 August 30 August Time Belinda Lefevre Colo. Spgs. CO
05 September 06 September Cost Steve Finnegan Rancho Cordova CA
12 September 13 September Quality Amanda Roberts High Wycombe UK
19 September 20 September Human Resources Anita Hollander Raleigh NC
26 September 27 September Communications Kaj Ostergaard Troy MI
03 October 04 October Integration to be announced
10 October 11 October Procurement William Ritchie Amstelveen NL
17 October 18 October Professional Resp. John Hunziker Sacramento CA
24 October 25 October Formulas Review Susan Faucheux Cerritos CA
31 October 01 November review or make-up to be announced
Tues. Wed. EMEA Topic Speaker Location
31 July,- 1, 3 Aug Overview Mark Hatten Plano TX
8 August 9 August Framework Linda Graves Arlington TX
15 August 16 August Risk Yves Munger Phoenix AZ
22 August 23 August Scope Ed Whitney Downers Grove IL
29 August 30 August Time Belinda Lefevre Colo. Spgs. CO
05 September 06 September Cost Steve Finnegan Rancho Cordova CA
12 September 13 September Quality Amanda Roberts High Wycombe UK
19 September 20 September Human Resources Anita Hollander Raleigh NC
26 September 27 September Communications Kaj Ostergaard Troy MI
03 October 04 October Integration to be announced
10 October 11 October Procurement William Ritchie Amstelveen NL
17 October 18 October Professional Resp. John Hunziker Sacramento CA
24 October 25 October Formulas Review Susan Faucheux Cerritos CA
31 October 01 November review or make-up to be announced
Questions on Project Life Cycle and Organization
11. Project managers or the organization can divide projects into phases. Collectively, these phases are known as the:
A. Project waterfall.
B. Project life cycle.
C. Project life stages.
D. Project life quality circle.
12. All of the following are true about project phases and the project life cycle EXCEPT:
A. The completion and approval of one or more deliverables characterizes a project phase.
B. The project life cycle defines the phases that connect the beginning of a project to its end.
C. The transition from one phase to another within a project’s life cycle generally involves, and is usually defined by, some form of technical transfer or handoff.
D. Cost and staffing levels are generally steady throughout the project life cycle.
13. Which of the following is not true about project stakeholders?
A. They are individuals and organizations that are actively supportive of the project.
B. They are individuals and organizations that are actively involved in the project.
C. They are individuals and organizations whose interests may be affected as a result of project execution or project completion.
D. They are individuals and organizations that may exert influence over the project’s objectives and outcomes.
14. In considering project stakeholders, the project management team must do all of the following EXCEPT:
A. As much as possible, create conflicts among stakeholders to allow the project team to get its work done.
B. Identify the stakeholders.
C. Determine stakeholders’ requirements and expectations.
D. To the extent possible, manage stakeholders’ influence in relation to the requirements to ensure a successful project.
15. Organizational cultures:
A. Are generally similar and indescribable.
B. Are generally unique and indescribable.
C. Have no impact on a clearly defined project.
D. Often have a direct influence on the project.
16. The project manager has the highest level of independence and authority ina organization.
A. Strong matrix
B. Weak matrix
C. Projectized
D. Functional
17. The project manager has the lowest level of authority in aorganization:
A. Functional
B. Weak matrix
C. Strong matrix
D. Projectized
18. A project coordinator may typically be found in a organization.
A. Projectized
B. Strong matrix
C. Weak matrix
D. Balanced matrix
19. The project manager is more likely to have a full-time role in aorganization:
A. Functional
B. Weak matrix
C. Projectized
D. Small capitalization
20. A common title for the project manager’s role in a projectized organization is:
A. Project Manager.
B. Project Coordinator.
C. Project Coach.
D. Project Expediter.
21. All of the following are generally true about the project management office (PMO) EXCEPT:
A. It may provide project management support functions.
B. It should be located in a bright, well-ventilated, centralized area.
C. It may provide training, software, standardized policies, and procedures.
D. It may be responsible for achieving the results of the project.
22. Different or conflicting objectives among project stakeholders:
A. Should be encouraged.
B. Should be ignored.
C. Can make it difficult for project managers to manage stakeholder expectations.
D. Generally makes it easy for project managers to manage stakeholder expectations.
23. For a large, complex project with cross-functional project needs, the following organizational structure gives considerable authority to the project manager:
A. A strong matrix organization.
B. A balanced matrix organization.
C. A weak matrix.
D. A functional organization.
24. All of the following statements about the level of authority of the project manager are true EXCEPT:
A. In a functional organization, the project manager has little or no authority.
B. In weak matrices, the project manager role is more that of a coordinator or expediter than that of a manager.
C. The balanced matrix organization does not provide the project manager with the full authority over the project and project funding.
D. Authority of the project manager is limited in a strong matrix organization.
25. All of the following statements about the project life cycle and the product life cycle are true EXCEPT:
A. The product life cycle generally starts with the business plan, and continues through idea, to product, ongoing operations, and product divestment.
B. The project life cycle also identifies the transitional actions at the end of the project to link the project to the ongoing operations of the performing organization.
C. Generally, a product life cycle is contained within the project life cycle.
D. Generally, a project life cycle is contained within one or more product life cycles.
A. Project waterfall.
B. Project life cycle.
C. Project life stages.
D. Project life quality circle.
12. All of the following are true about project phases and the project life cycle EXCEPT:
A. The completion and approval of one or more deliverables characterizes a project phase.
B. The project life cycle defines the phases that connect the beginning of a project to its end.
C. The transition from one phase to another within a project’s life cycle generally involves, and is usually defined by, some form of technical transfer or handoff.
D. Cost and staffing levels are generally steady throughout the project life cycle.
13. Which of the following is not true about project stakeholders?
A. They are individuals and organizations that are actively supportive of the project.
B. They are individuals and organizations that are actively involved in the project.
C. They are individuals and organizations whose interests may be affected as a result of project execution or project completion.
D. They are individuals and organizations that may exert influence over the project’s objectives and outcomes.
14. In considering project stakeholders, the project management team must do all of the following EXCEPT:
A. As much as possible, create conflicts among stakeholders to allow the project team to get its work done.
B. Identify the stakeholders.
C. Determine stakeholders’ requirements and expectations.
D. To the extent possible, manage stakeholders’ influence in relation to the requirements to ensure a successful project.
15. Organizational cultures:
A. Are generally similar and indescribable.
B. Are generally unique and indescribable.
C. Have no impact on a clearly defined project.
D. Often have a direct influence on the project.
16. The project manager has the highest level of independence and authority ina organization.
A. Strong matrix
B. Weak matrix
C. Projectized
D. Functional
17. The project manager has the lowest level of authority in aorganization:
A. Functional
B. Weak matrix
C. Strong matrix
D. Projectized
18. A project coordinator may typically be found in a organization.
A. Projectized
B. Strong matrix
C. Weak matrix
D. Balanced matrix
19. The project manager is more likely to have a full-time role in aorganization:
A. Functional
B. Weak matrix
C. Projectized
D. Small capitalization
20. A common title for the project manager’s role in a projectized organization is:
A. Project Manager.
B. Project Coordinator.
C. Project Coach.
D. Project Expediter.
21. All of the following are generally true about the project management office (PMO) EXCEPT:
A. It may provide project management support functions.
B. It should be located in a bright, well-ventilated, centralized area.
C. It may provide training, software, standardized policies, and procedures.
D. It may be responsible for achieving the results of the project.
22. Different or conflicting objectives among project stakeholders:
A. Should be encouraged.
B. Should be ignored.
C. Can make it difficult for project managers to manage stakeholder expectations.
D. Generally makes it easy for project managers to manage stakeholder expectations.
23. For a large, complex project with cross-functional project needs, the following organizational structure gives considerable authority to the project manager:
A. A strong matrix organization.
B. A balanced matrix organization.
C. A weak matrix.
D. A functional organization.
24. All of the following statements about the level of authority of the project manager are true EXCEPT:
A. In a functional organization, the project manager has little or no authority.
B. In weak matrices, the project manager role is more that of a coordinator or expediter than that of a manager.
C. The balanced matrix organization does not provide the project manager with the full authority over the project and project funding.
D. Authority of the project manager is limited in a strong matrix organization.
25. All of the following statements about the project life cycle and the product life cycle are true EXCEPT:
A. The product life cycle generally starts with the business plan, and continues through idea, to product, ongoing operations, and product divestment.
B. The project life cycle also identifies the transitional actions at the end of the project to link the project to the ongoing operations of the performing organization.
C. Generally, a product life cycle is contained within the project life cycle.
D. Generally, a project life cycle is contained within one or more product life cycles.
Role Of language..
You automatically are thinking "What you have a staff of individuals who don't speak English? "
Believe me, the team probably speaks better English than I do. What they don't do is work as loosely as most in the US. Because they know there are communication issues, most off shore teams look for VERY CLEAR specifications. We tend to make assumptions in our requirements documentation such as "Well the user will choose the provider as the selection criteria". If I read this, I would immediately assume that the user would choose either by Last Name, or some identifier such as the provider number. But, myoffshore counterparts don't make that assumption. They will put together a web page that has a spot for provider last Name and the rest of the identifying information and choose the records based on the exact criteria. The user has to put in ALL the information. After noticing this problem on almost every report front end, I finally asked why? I was told "You didn't say you wanted a combo box listing the Provider name or provider number in the specification documents." So, we gave you a simple screen. Well, my first thoughts were "Well, who in the world would NOT want the screen like that". But there point is, "If we make up what we think is correct, and it is not, then we are the ones that are wrong". "But, if we give you what you ask for, then we have provided our service".
Let me tell you, initially I was quite upset. "Of COURSE I wanted you to provide a list to select from!, that is just common sense!" was my reaction. But then as we got deeper into specification I began to see the wisdom of their approach. We cannot walk over to each other's desk and ask questions. Email takes 1-2 days to answer due to time zone issues. Phone calls require one or the other party take there personal time.
So, how do you resolve issues? By CLEAR and CONCISE directions. No guesswork, no assumptions, no "You should have KNOWN what I meant". Once I started approaching all requests from that standpoint, we at least stopped
Believe me, the team probably speaks better English than I do. What they don't do is work as loosely as most in the US. Because they know there are communication issues, most off shore teams look for VERY CLEAR specifications. We tend to make assumptions in our requirements documentation such as "Well the user will choose the provider as the selection criteria". If I read this, I would immediately assume that the user would choose either by Last Name, or some identifier such as the provider number. But, myoffshore counterparts don't make that assumption. They will put together a web page that has a spot for provider last Name and the rest of the identifying information and choose the records based on the exact criteria. The user has to put in ALL the information. After noticing this problem on almost every report front end, I finally asked why? I was told "You didn't say you wanted a combo box listing the Provider name or provider number in the specification documents." So, we gave you a simple screen. Well, my first thoughts were "Well, who in the world would NOT want the screen like that". But there point is, "If we make up what we think is correct, and it is not, then we are the ones that are wrong". "But, if we give you what you ask for, then we have provided our service".
Let me tell you, initially I was quite upset. "Of COURSE I wanted you to provide a list to select from!, that is just common sense!" was my reaction. But then as we got deeper into specification I began to see the wisdom of their approach. We cannot walk over to each other's desk and ask questions. Email takes 1-2 days to answer due to time zone issues. Phone calls require one or the other party take there personal time.
So, how do you resolve issues? By CLEAR and CONCISE directions. No guesswork, no assumptions, no "You should have KNOWN what I meant". Once I started approaching all requests from that standpoint, we at least stopped
Tools and Techniques
Project management brings together a set of tools and techniques, performed by people, to describe, organize, and monitor the work of project activities. Project managers are the people responsible for managing the project processes and applying the tools and techniques used to carry out the project activities. There are many advantages to organizing projects and teams who utilize these techniques.
Programs are groups of projects that are managed using the same techniques in a coordinated fashion. Sometimes, programs include aspects of ongoing operations as well. This would be the case where a very large program exists with many subprojects under it—for example, building a new shopping mall. Many subprojects exist underneath this program such as excavation, construction, interior design, store placement, marketing, facilities management, etc. Each of the subprojects is really a project unto itself. Each has its own project manager, who reports to a project manager with responsibility over several of the areas, who in turn reports to the head project manager over the entire program. After the structure itself is built, the management of the facility is considered the ongoing operations part of this program.
Project management involves many skills and techniques. According to the Guide to the PMBOK, “Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.” It is the responsibility of the project manager to ensure project management techniques are applied and followed.
Programs are groups of projects that are managed using the same techniques in a coordinated fashion. Sometimes, programs include aspects of ongoing operations as well. This would be the case where a very large program exists with many subprojects under it—for example, building a new shopping mall. Many subprojects exist underneath this program such as excavation, construction, interior design, store placement, marketing, facilities management, etc. Each of the subprojects is really a project unto itself. Each has its own project manager, who reports to a project manager with responsibility over several of the areas, who in turn reports to the head project manager over the entire program. After the structure itself is built, the management of the facility is considered the ongoing operations part of this program.
Project management involves many skills and techniques. According to the Guide to the PMBOK, “Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.” It is the responsibility of the project manager to ensure project management techniques are applied and followed.
What Is Project Management?
You’ve determined that you indeed have a project. What now?
The notes you scratched out on the back of a napkin at coffee break might get you started, but that’s not exactly good project management practice.
We have all witnessed this scenario—an assignment is made and the project team jumps directly into the project, busying them with building the product or service requested. Often, careful thought is not given to the project-planning process. I’m sure you’ve heard co-workers toss around statements like, “That would be a waste of valuable time” or “Why plan when you can just start building?” Project progress is rarely measured against the customer requirements. In the end, the delivered product or service doesn’t meet the expectations of the customer! This is a frustrating experience for all those involved. Unfortunately, many projects follow this poorly constructed path.
Project management is a process that involves several things including planning, putting the project plan into action, and measuring progress and performance. Planning is one of the most important functions you’ll perform during the course of a project. It sets the standard for the rest of the project’s life and is used to track future project performance. Before we begin the planning process, we’ll need to look at some of the skills needed to perform project management functions and some of the constraints found on all projects.
The notes you scratched out on the back of a napkin at coffee break might get you started, but that’s not exactly good project management practice.
We have all witnessed this scenario—an assignment is made and the project team jumps directly into the project, busying them with building the product or service requested. Often, careful thought is not given to the project-planning process. I’m sure you’ve heard co-workers toss around statements like, “That would be a waste of valuable time” or “Why plan when you can just start building?” Project progress is rarely measured against the customer requirements. In the end, the delivered product or service doesn’t meet the expectations of the customer! This is a frustrating experience for all those involved. Unfortunately, many projects follow this poorly constructed path.
Project management is a process that involves several things including planning, putting the project plan into action, and measuring progress and performance. Planning is one of the most important functions you’ll perform during the course of a project. It sets the standard for the rest of the project’s life and is used to track future project performance. Before we begin the planning process, we’ll need to look at some of the skills needed to perform project management functions and some of the constraints found on all projects.
The Work Breakdown Structure (WBS)
Of all the documents used in project management, none is more important than the Work Breakdown Structure (WBS). It is this document that determines how you will manage all the aspects of the project, and this document is absolutely necessary if you want to be a professional project manager.
The WBS comes after the Scope Statement, and it "decomposes" (sic) the scope statement into tasks that form the basis for all the work on the project. The breakdown structure actually takes the larger sections of a project and breaks them into smaller tasks so that the project manager can control and manage the project.
This is a very simple WBS for painting a room. The second task level begins to break down what the project manager will have to do to get the room painted. To more clearly establish the project needs, you will probably need breakdowns in the second level, too. For instance, under the task "Prep Walls," you could have the subtasks to "Clean Walls," "Sand Walls," and "Apply Primer."
The more detail you have for project tasks, the better off you are. I have worked with dozens, even hundreds of different people who prepared a WBS for a given project. One thing you should not do is to get too detailed. Usually four or five levels of tasks are sufficient to give the project manager a complete view of the work to be done. Detail beyond this level is usually not helpful. Using common sense is a good idea. Also using someone who has done WBS before can be helpful.
There are several different ways to develop the WBS with your team. One of the most common is to use yellow sticky notes on a board to make sure everyone has a chance to participate. Make people write down their ideas for tasks to be included in the WBS and get them up on the board. It doesn't matter at first pass how right or wrong the WBS is. You are certainly going to make several versions before putting the WBS under version control, so at the beginning, let everyone have input. If one dominant person is controlling the conversation, you can ask everyone to write down their ideas on the notes, put them up on the board in silence, and only then allow people to critique ideas. By doing this, everyone has an equal chance of showing their concepts about the project and the tasks in which they will be involved.
Here are the key parts so far of developing a WBS:
-
Everyone is involved.
-
No one person dominates.
-
The PM doesn't dominate but rather leads the group through the task at hand.
-
There are no bad ideas at the beginning.
-
In order to make sure tasks do not slip through the cracks, you need to get everyone thinking about their own tasks.
-
Doing this one time isn't enough.
This last point is extremely important. Some first-time PMs go through the WBS process with the team once and believe they have a complete, working WBS. This is usually not true, particularly if the project team hasn't worked together before. Many times, only the major tasks are identified. It may take several days until all of the subtasks are recognized and remembered. A project team with many veterans will probably be able to do a WBS in a shorter period than a team doing something like this for the first time.
One of the techniques is to develop the WBS on a whiteboard with the team and then let it sit for a day or two. Perhaps even have a scribe write out what is on the board and then take down the WBS. This means that any new ideas about tasks will be allowed to come out at the next meeting. Remember that each project is unique, so it is extremely important to think and rethink those tasks that will be unique to the project at hand. If everything on your new project is the same as one before it, you do not have a project at all. It is the changes that make the project a project.
Another major consideration is the final format of your WBS. People on the team should be able to see the WBS and request changes to it, and it should be portable enough so that people do not have to walk to the same place to look at it. The answer to this question is simple.
Microsoft Project is the program of choice for most people working on a breakdown structure. Other excellent ones are available for engineering and construction, such as Primavera. For the standard practicing PM, though, MS Project is the best choice.
So after you have had your team together to create a WBS and put it up on the board, the scribe needs to translate that into MS Project, which isn't a very hard task. Because this is electronic, you can email it to all of the team, changes can be recorded, and version control can be maintained. Not only can version control be maintainedit must be.
Planning Of Project
The Planning phase of a project is where a project manager can utilize guidance from the PMBOK in order to professionally control the overall planning of the project. This means learning what documents are needed as well as forming a cohesive project plan.
Because this phase is so important, we are going to look at it several times in the book. The other times will be in relationship to knowledge areas. In this section, we are going to examine some key documents you need to produce and the relationship between them. Without these key planning documents, it is almost impossible for a project manager to maintain control over time. It's possible to leave out a few of the documents we are going to discuss, but we will focus on the ones that absolutely, positively must be done for project success.
Scope Statement
The Charter is the first major document that is produced in the Initiation phase. After the Charter, the next important document in sequence is the Scope Statement. According to the PMBOK, "Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully." The key phrase in this definition is meant to ensure that you aren't adding anything to the project that shouldn't be there. When the definition says, "only the work required," it means that you as the project manager know the boundaries of the project, and in fact the scope of the project. The process is called Project Scope Management; the major document is the Scope Statement.
You should note that there are actually two types of scope: product scope and project scope. Product scope determines the features and functions of the output of the project. Project scope determines the work to be done in order to deliver that output. The exam will have questions on both, so it is necessary to have these two clear in your mind before you take it.
It's important to note that there are several different levels of deliverables. In a project lasting for six months, you may find that you have deliverables for each week or for every two weeks. Certainly you do not want to have only one big deliverable for the project because you can't manage six months of time without something against which to measure progress. So you should always manage deliverablesthat is, you should be focusing on intermediate deliverables that you can manage and measure. Doing this will make it easier on you as the project manager, and easier on the sponsor and the project team as well.
Initiation and Planning
The entire project management process can be divided up into five different phases: Initiation, Planning, Execution, Control, and Closing. The diagram shows that the different phases come at specific parts of the project. However, in reality there are many overlaps between the phases, and seldom do you see one phase completely finished before the next begins. For the purpose of studying for the exam, we will combine Initiation and Planning. Later we will look at the Planning and Execution phases together, the Execution and Control phases, and finally the Control and Closing phase.
Initiation and Planning occur before Execution and Control, and much of what you need to know about project management can be made simpler by combining two sections. The first of these phases, Initiation, is the time when someone or some organization specifically authorizes beginning and executing a project. Actually, Initiation is often the most overlooked of all the phases. Along with Closing, it seems to fall by the wayside in a lot of organizations.
Although the authorizing of resources may seem to be absolutely necessary, it is surprising how many times projects begin without specific authorization from one person. You must have one person to authorize all the resources, and that one person must have control of the project. This means that only one person is authorizing materials, money, and people. In many organizations, a department or a group of people approves projects. This can cause problems. Without a single point of responsibility for the project, there is a major issue of accountability floating through this process. Only when you have a single source for accountability can you be truly certain that one person is watching the project and is responsible in the end for the final outcome of the project.
Initiation and Planning occur before Execution and Control, and much of what you need to know about project management can be made simpler by combining two sections. The first of these phases, Initiation, is the time when someone or some organization specifically authorizes beginning and executing a project. Actually, Initiation is often the most overlooked of all the phases. Along with Closing, it seems to fall by the wayside in a lot of organizations.
Although the authorizing of resources may seem to be absolutely necessary, it is surprising how many times projects begin without specific authorization from one person. You must have one person to authorize all the resources, and that one person must have control of the project. This means that only one person is authorizing materials, money, and people. In many organizations, a department or a group of people approves projects. This can cause problems. Without a single point of responsibility for the project, there is a major issue of accountability floating through this process. Only when you have a single source for accountability can you be truly certain that one person is watching the project and is responsible in the end for the final outcome of the project.
Models of Approaching the Study of Project Management
The Phase Approach
Within the structure of a project, there are five phases: Initiation, Planning, Execution, Control, and Closing. Some people study for the exam by using each phase as a separate study area, looking at the key components from initiation, planning, and so on. Although this works well when looking at a project from its inception, it becomes very difficult to place management actions only in one phase. For instance, you will be doing project risk management throughout the entire project. You do not simply do a risk plan once and leave it. Risk is managed in every phase, and so are many other project plans.
What is helpful in managing a project with the phase approach as your model is that you can see the dependencies that occur throughout an entire phase as well as the entire project, and you are able to see the different ways in which certain things will interact during the project. Working through and planning the project phases is the best way to manage an actual project, and the phase approach of study will help to explain how the actual flow of a project occurs.
In this book, we will discuss the five phases, and we will tie two phases together because phases overlap during a project. So Initiation and Planning are the topic of one chapter, Planning and Execution are the topic of another, and so on. It is impossible to actually manage a project without overlapping phases.
One other reason that the phase approach is used is that some topics do not fit exactly into one knowledge area from the PMBOK. These are the topics that are discussed in the phase part of the book. Although there is some redundancy between phase topics and knowledge areas in terms of content, looking at the topics from different viewpoints will help you with the examination.
The Knowledge Area Approach
This is the way the PMBOK is structured. There are nine separate areas of study: Integration, Scope, Cost, Time, Quality, HR, Communications, Risk, and Procurement. Each knowledge area is given a chapter in the PMBOK that explains the facts that PMI thinks are important in the study of the particular topic. Most of the chapters are fairly short. The problem is not how long or short the knowledge area chapters are in the book; it's the fact that there is so much to learn in each topic that each chapter could be a doctoral dissertation area. This book will give you the knowledge that is required in a certain study area to satisfy testing requirements and also will link it to the rest of the areas because there are constant interactions between knowledge groups when a project is actually going on.
Because PMBOK is structured by knowledge areas, it would seem that you should study this model. Actually, if you only had one way to look at the exam and actual project management performances, that would be true. But the PMBOK doesn't give you everything you need to know about passing the test, nor does it have depth in more demanding project management practice areas. So it will be one of the learning models we will concentrate on for the test, but it is not the only model for preparing for the test.
How Is the Test Constructed?
The test consists of 200 questions over the nine knowledge areas and the five phases. According to PMI, here are the percentages of questions asked by phase.
Phase
Percentage
Initiation
4
Planning
37
Execution
24
Control
28
Closing
7
Note that the Planning/Execution/Control phases comprise 89% of the test and that Planning has the most questions of all on the examination. Concentrate on these areas because that is how the examination is written.
Why Do People Fail This Exam?
There are many reasons people fail an exam. The most common reason is that they didn't study enough. There are many good books available on the PMI examination that basically consist of a list of potential questions. These are very helpful in getting used to the styles of questions, and they help get the test taker more comfortable with the exam.
However, this type of studying comes apart if you memorize answers to specific questions instead of learning the content of the material. This book will give questions because questions are a good learning aide. But there will also be discussion about the answers so that the test taker understands what both the question and the answer mean. Do not just learn long lists of questions; learn the topic.
Another reason people fail a test of this type is that they fail to read all of the answers. There are several questions on the exam that have two answers that are very close. Your job is to understand the answer that PMI wants and use it. By failing to read all of the questions, your answer may not be the one that PMI is looking for. Within this book, we'll be looking at the questions through the eyes of the PMBOK.
People come up to me all the time and say, "I've been a project manager for more than 20 years. Do I need to study for the exam?" The answer is a resounding yes. I've known excellent PMs who weren't certified and who took the exam without a class and without using a book like this. Most of them failed to pass. It may be that the experience is there but learning the style of the PMBOK is critically important. So use this book as a platform to understand what is expected of you for the PMP exam.
When Should I Apply to Sit for the Exam?
As soon as you have finished studying and you feel ready. When teaching the exam for PMI, I wanted the students to have their test dates scheduled at least half way through the class so that they would be taking the exam only a week or two after finishing. This is the standard way you have tests scheduled in an academic setting. It would be highly unusual for a school to schedule an examination covering a course that you had a half a year ago. You do not need a lot of extra study time after you've taken a course. The time immediately after taking a course is the time when the information is at the front of your consciousness. Submit your request by email (not snail mail) and be ready to go and pass the exam.
Within the structure of a project, there are five phases: Initiation, Planning, Execution, Control, and Closing. Some people study for the exam by using each phase as a separate study area, looking at the key components from initiation, planning, and so on. Although this works well when looking at a project from its inception, it becomes very difficult to place management actions only in one phase. For instance, you will be doing project risk management throughout the entire project. You do not simply do a risk plan once and leave it. Risk is managed in every phase, and so are many other project plans.
What is helpful in managing a project with the phase approach as your model is that you can see the dependencies that occur throughout an entire phase as well as the entire project, and you are able to see the different ways in which certain things will interact during the project. Working through and planning the project phases is the best way to manage an actual project, and the phase approach of study will help to explain how the actual flow of a project occurs.
In this book, we will discuss the five phases, and we will tie two phases together because phases overlap during a project. So Initiation and Planning are the topic of one chapter, Planning and Execution are the topic of another, and so on. It is impossible to actually manage a project without overlapping phases.
One other reason that the phase approach is used is that some topics do not fit exactly into one knowledge area from the PMBOK. These are the topics that are discussed in the phase part of the book. Although there is some redundancy between phase topics and knowledge areas in terms of content, looking at the topics from different viewpoints will help you with the examination.
The Knowledge Area Approach
This is the way the PMBOK is structured. There are nine separate areas of study: Integration, Scope, Cost, Time, Quality, HR, Communications, Risk, and Procurement. Each knowledge area is given a chapter in the PMBOK that explains the facts that PMI thinks are important in the study of the particular topic. Most of the chapters are fairly short. The problem is not how long or short the knowledge area chapters are in the book; it's the fact that there is so much to learn in each topic that each chapter could be a doctoral dissertation area. This book will give you the knowledge that is required in a certain study area to satisfy testing requirements and also will link it to the rest of the areas because there are constant interactions between knowledge groups when a project is actually going on.
Because PMBOK is structured by knowledge areas, it would seem that you should study this model. Actually, if you only had one way to look at the exam and actual project management performances, that would be true. But the PMBOK doesn't give you everything you need to know about passing the test, nor does it have depth in more demanding project management practice areas. So it will be one of the learning models we will concentrate on for the test, but it is not the only model for preparing for the test.
How Is the Test Constructed?
The test consists of 200 questions over the nine knowledge areas and the five phases. According to PMI, here are the percentages of questions asked by phase.
Phase
Percentage
Initiation
4
Planning
37
Execution
24
Control
28
Closing
7
Note that the Planning/Execution/Control phases comprise 89% of the test and that Planning has the most questions of all on the examination. Concentrate on these areas because that is how the examination is written.
Why Do People Fail This Exam?
There are many reasons people fail an exam. The most common reason is that they didn't study enough. There are many good books available on the PMI examination that basically consist of a list of potential questions. These are very helpful in getting used to the styles of questions, and they help get the test taker more comfortable with the exam.
However, this type of studying comes apart if you memorize answers to specific questions instead of learning the content of the material. This book will give questions because questions are a good learning aide. But there will also be discussion about the answers so that the test taker understands what both the question and the answer mean. Do not just learn long lists of questions; learn the topic.
Another reason people fail a test of this type is that they fail to read all of the answers. There are several questions on the exam that have two answers that are very close. Your job is to understand the answer that PMI wants and use it. By failing to read all of the questions, your answer may not be the one that PMI is looking for. Within this book, we'll be looking at the questions through the eyes of the PMBOK.
People come up to me all the time and say, "I've been a project manager for more than 20 years. Do I need to study for the exam?" The answer is a resounding yes. I've known excellent PMs who weren't certified and who took the exam without a class and without using a book like this. Most of them failed to pass. It may be that the experience is there but learning the style of the PMBOK is critically important. So use this book as a platform to understand what is expected of you for the PMP exam.
When Should I Apply to Sit for the Exam?
As soon as you have finished studying and you feel ready. When teaching the exam for PMI, I wanted the students to have their test dates scheduled at least half way through the class so that they would be taking the exam only a week or two after finishing. This is the standard way you have tests scheduled in an academic setting. It would be highly unusual for a school to schedule an examination covering a course that you had a half a year ago. You do not need a lot of extra study time after you've taken a course. The time immediately after taking a course is the time when the information is at the front of your consciousness. Submit your request by email (not snail mail) and be ready to go and pass the exam.
Project Management and Projects
Many of the most famous projects in history involved construction or engineering of some sort. The pyramids of ancient Egypt were built over hundreds of years but are still considered projects. Notre Dame Cathedral in Paris took roughly 200 years to build and had dozens of what we would now call project managers, although that term was not in use during these two massive projects.
The important information concerning any project is in the definition we give for projects. PMBOK suggests that A project is a temporary endeavor undertaken to create a unique product, service, or result. Memorize this. You will certainly be asked about it on the exam.
Let's look at what this definition means to us as project managers. First, the fact that a project is temporary means that the management of the project is very different from managing a standard operating organization. Resource needs, financial considerations, quality concerns, risk management, and communication needs are all concerns that arise because a project has a specific beginning and ending.
Many organizations have difficulties in placing project managers because projects do not continue to be managed year after year as do the operations of a standard organization, so there may be slack or down time for the project manager. This "on the beach" or "on the bench" time is when project managers like you can help with other tasks in the organization such as responding to RFPs (Request for Proposal), or you can use the time to learn new skills that will help you on your next project. However, during this time, you are not actually project managing, and that is difficult for some organizations to defendhaving someone on the payroll who is not actually doing the job for which he or she was hired.
For the most part, project managers become project managers because the organization needs someone to manage a project, and that need is often filled with someone who did not come to the organization as a project manager. There are very, very few organizations that have planned paths that lead to project management positions as a part of their overall HR strategy. Before 1969, there was no governing body to define the role of a project manager and no tests that could certify someone as a project manager. There were many good project managers working in a variety of industries, but there was no single certification or examination that would be accepted universally. The Department of Defense was one of the leaders in this area because it needed project managers for much of the construction it did as well as major projects such as those done by NASA. But the training given in the DoD was not the single international standard for project management, and that changed in 1969.
In 1969, the Project Management Institute was formed, and topics were discussed and material was written on the topic of project management. These early offerings gave way to the Project Management Body of Knowledge, the PMBOK. The PMBOK that we are referencing in this book is one that has gone through major revisions as project management becomes more and more a major type of management in our modern era.
A second event further codified the standards for project management when in 2000 ANSI (American National Standards Institute) declared that the standard for project management literature would be the PMBOK. This action changed the project management world. The PMBOK is now the official book to read, and the materials from it make up the official exam that qualifies the test taker as a Project Management Professional, or PMP.
One of the problems, albeit a small one, with the PMBOK is that there are several different writing styles within the book because it has multiple authors. This means that you will see slightly different styles of explanation. Throughout this book, we'll make sure that the questions and explanations you see conform to PMI and are explained as clearly as possible.
The important information concerning any project is in the definition we give for projects. PMBOK suggests that A project is a temporary endeavor undertaken to create a unique product, service, or result. Memorize this. You will certainly be asked about it on the exam.
Let's look at what this definition means to us as project managers. First, the fact that a project is temporary means that the management of the project is very different from managing a standard operating organization. Resource needs, financial considerations, quality concerns, risk management, and communication needs are all concerns that arise because a project has a specific beginning and ending.
Many organizations have difficulties in placing project managers because projects do not continue to be managed year after year as do the operations of a standard organization, so there may be slack or down time for the project manager. This "on the beach" or "on the bench" time is when project managers like you can help with other tasks in the organization such as responding to RFPs (Request for Proposal), or you can use the time to learn new skills that will help you on your next project. However, during this time, you are not actually project managing, and that is difficult for some organizations to defendhaving someone on the payroll who is not actually doing the job for which he or she was hired.
For the most part, project managers become project managers because the organization needs someone to manage a project, and that need is often filled with someone who did not come to the organization as a project manager. There are very, very few organizations that have planned paths that lead to project management positions as a part of their overall HR strategy. Before 1969, there was no governing body to define the role of a project manager and no tests that could certify someone as a project manager. There were many good project managers working in a variety of industries, but there was no single certification or examination that would be accepted universally. The Department of Defense was one of the leaders in this area because it needed project managers for much of the construction it did as well as major projects such as those done by NASA. But the training given in the DoD was not the single international standard for project management, and that changed in 1969.
In 1969, the Project Management Institute was formed, and topics were discussed and material was written on the topic of project management. These early offerings gave way to the Project Management Body of Knowledge, the PMBOK. The PMBOK that we are referencing in this book is one that has gone through major revisions as project management becomes more and more a major type of management in our modern era.
A second event further codified the standards for project management when in 2000 ANSI (American National Standards Institute) declared that the standard for project management literature would be the PMBOK. This action changed the project management world. The PMBOK is now the official book to read, and the materials from it make up the official exam that qualifies the test taker as a Project Management Professional, or PMP.
One of the problems, albeit a small one, with the PMBOK is that there are several different writing styles within the book because it has multiple authors. This means that you will see slightly different styles of explanation. Throughout this book, we'll make sure that the questions and explanations you see conform to PMI and are explained as clearly as possible.
Interview Quesitions for Project Management Professional(PMP)?
· How many projects you handled in the past? Deadlines met? On time/ within budget? Obstacles you had to overcome?
· Do you understand milestones, interdependencies? Resource allocation?
· Do you know what Project Software they use and is there training for it?
· Tell me about yourself. (To avoid rambling or becoming flustered, plan your answer.)
· What are your strengths? (Make an exhaustive list and review it exhaustively before the interview.)
· What are your weaknesses?(What you say here can and will be used against you!)
· How would your current (or last) boss describe you?*
· What were your boss's responsibilities? (Interviewers sometimes ask this question to prevent you from having the chance to claim that you did your boss's job. Be ready for it!)
· What's your opinion of them? (Never criticize your past or present boss in an interview. It just makes you look bad!)
· How would your co-workers or subordinates describe you professionally?* (Remember, now is not the time for modesty! Brag a little bit.)
· Why do you want to work for us?
· Why do you want to leave your present employer?
· Why should we hire you over the other finalists?
· What qualities or talents would you bring to the job?*
· Tell me about your accomplishments.
· What is your most important contribution to your last (or current) employer?
· How do you perform under deadline pressure? Give me an example.
· How do you react to criticism? (You try to learn from it, of course!)
· Describe a conflict or disagreement at work in which you were involved. How was it resolved?
· What are two of the biggest problems you've encountered at your job and how did you overcome them?
· Think of a major crisis you've faced at work and explain how you handled it.
· Give me an example of a risk that you took at your job (past or present) and how it turned out.
· What's your managerial style like?
· Have you ever hired employees; and, if so, have they lived up to your expectations?
· What type of performance problems have you encountered in people who report to you, and how did you motivate them to improve?
· Describe a typical day at your present (or last) job.
· What do you see yourself doing five years from now?
1. Standard EDS COE technology will be utilized for schedule management
Overall/Structure Standards
1. Standard EDS COE technology will be utilized for schedule management. This implies that all projects will be managed using MS Project or equivalent (i.e. PIV).
Keyword: COE
2. Project schedules will be managed and controlled according to your projects defined Configuration Management practices.
3. Project schedules will have a Work Breakdown Structure that is deliverable based versus methodology/process based.
WBS Level 0 will contain a meaningful Project name.
WBS Level 1 will contain 4 major life cycle phases: Start Up, Planning, Execution, and Close Down. It will also have a 5th element called Manage and Control which will summarize non-direct activities (i.e. meetings, oversight, reporting, re-planning, etc.) The duration of Manage and Control will span the entire life of the project using recurring tasks
WBS Level 2 will contain high level deliverables, such as contract deliverables or deliverables required to satisfy high level requirements.
WBS Level 3 and lower will contain further breakdown of deliverables or contain the identity of tasks necessary to create deliverables.
For production support schedules, each client work request should be treated as a deliverable. Related client work requests could be bundled as a deliverable whenever possible. Decompose deliverables until you can effectively identify the tasks necessary to create the deliverable. Decompose tasks until you can effectively estimate the effort (work) and resources required.
4. If the project is following an iterative approach, the number of iterations will be determined within Planning. The detail of each iteration will be defined in the Execution phase.
5. Once the Planning Phase is complete and the project is in the execution phase, any re-planning tasks that are needed should be included within Manage and Control.
6. There is one required minimum review at the end of the Planning Phase which is a prerequisite to establishing the project execution and Close Down baseline.
7. The minimum standard project milestones are:
Project Start and Project Finish
Start Up Start and Start Up Finish
Planning Start and Planning Finish
Execution Start and Execution Finish
Close Down Start and Close Down Finish
These are the minimum set of project milestones that are reported up to the programme level. These dates will be derived from the dates of the corresponding summary tasks. No milestones are required for Manage and Control since it spans the life cycle of the project.
8. All schedules will contain the following minimum high level PM deliverables:
Start Up and Planning Phase: Project Plan (components are driven by environmental characteristics. This may require one or more tasks to produce)
Execution Phase: Client defined deliverables
Close Down Phase: Post Project Review (programme/organizational format is discretionary, ongoing projects must have a minimum of one annually)
Manage and Control: Communications (projects are expected to deliver what was defined within the communication plan)
9. Deliverables will be given clear, meaningful names. This standard applies to deliverables at any WBS level. i.e. “Baselined Project Plan”.
10. Schedules names and schedule tasks will not contain special characters:
/ “ ; : < > | [ ] , . ? ~ ‘ ! $ % ^ & * ( ) + = { } \
11. Schedule Quality Analyzer will be run on project schedules on a monthly basis and the schedule must be green or yellow. Red schedules must be corrected. The use of Schedule Quality Analyzer does not apply to roll up schedules, linkage schedules, or milestone schedules. Production support schedules will use the production support weighting option. Evidence must be retained by using the option to store the most current results in Number10 and Date10 on the Project Summary Task. This tool can be installed at any time.
12. All projects will capture and evaluate effort expenditure and schedule performance using Earned Value (EV) measurement. The recommended method is the 0/100 approach. The approach to be used is left to the discretion of the Project Manager. Groups should consider using the EV Analyzer tool. The EV Analyzer tool can be installed at any time. Production Support projects are exempt from EV measurement.
13. In additional to standard schedule fields that come with scheduling tools, all projects will also contain the following custom attributes:
a. Schedule Quality Score (Number10-assigned by the SQA Analyzer tool)
b. Schedule Quality Date (Date10-assigned by the SQA Analyzer tool)
1. Standard EDS COE technology will be utilized for schedule management. This implies that all projects will be managed using MS Project or equivalent (i.e. PIV).
Keyword: COE
2. Project schedules will be managed and controlled according to your projects defined Configuration Management practices.
3. Project schedules will have a Work Breakdown Structure that is deliverable based versus methodology/process based.
WBS Level 0 will contain a meaningful Project name.
WBS Level 1 will contain 4 major life cycle phases: Start Up, Planning, Execution, and Close Down. It will also have a 5th element called Manage and Control which will summarize non-direct activities (i.e. meetings, oversight, reporting, re-planning, etc.) The duration of Manage and Control will span the entire life of the project using recurring tasks
WBS Level 2 will contain high level deliverables, such as contract deliverables or deliverables required to satisfy high level requirements.
WBS Level 3 and lower will contain further breakdown of deliverables or contain the identity of tasks necessary to create deliverables.
For production support schedules, each client work request should be treated as a deliverable. Related client work requests could be bundled as a deliverable whenever possible. Decompose deliverables until you can effectively identify the tasks necessary to create the deliverable. Decompose tasks until you can effectively estimate the effort (work) and resources required.
4. If the project is following an iterative approach, the number of iterations will be determined within Planning. The detail of each iteration will be defined in the Execution phase.
5. Once the Planning Phase is complete and the project is in the execution phase, any re-planning tasks that are needed should be included within Manage and Control.
6. There is one required minimum review at the end of the Planning Phase which is a prerequisite to establishing the project execution and Close Down baseline.
7. The minimum standard project milestones are:
Project Start and Project Finish
Start Up Start and Start Up Finish
Planning Start and Planning Finish
Execution Start and Execution Finish
Close Down Start and Close Down Finish
These are the minimum set of project milestones that are reported up to the programme level. These dates will be derived from the dates of the corresponding summary tasks. No milestones are required for Manage and Control since it spans the life cycle of the project.
8. All schedules will contain the following minimum high level PM deliverables:
Start Up and Planning Phase: Project Plan (components are driven by environmental characteristics. This may require one or more tasks to produce)
Execution Phase: Client defined deliverables
Close Down Phase: Post Project Review (programme/organizational format is discretionary, ongoing projects must have a minimum of one annually)
Manage and Control: Communications (projects are expected to deliver what was defined within the communication plan)
9. Deliverables will be given clear, meaningful names. This standard applies to deliverables at any WBS level. i.e. “Baselined Project Plan”.
10. Schedules names and schedule tasks will not contain special characters:
/ “ ; : < > | [ ] , . ? ~ ‘ ! $ % ^ & * ( ) + = { } \
11. Schedule Quality Analyzer will be run on project schedules on a monthly basis and the schedule must be green or yellow. Red schedules must be corrected. The use of Schedule Quality Analyzer does not apply to roll up schedules, linkage schedules, or milestone schedules. Production support schedules will use the production support weighting option. Evidence must be retained by using the option to store the most current results in Number10 and Date10 on the Project Summary Task. This tool can be installed at any time.
12. All projects will capture and evaluate effort expenditure and schedule performance using Earned Value (EV) measurement. The recommended method is the 0/100 approach. The approach to be used is left to the discretion of the Project Manager. Groups should consider using the EV Analyzer tool. The EV Analyzer tool can be installed at any time. Production Support projects are exempt from EV measurement.
13. In additional to standard schedule fields that come with scheduling tools, all projects will also contain the following custom attributes:
a. Schedule Quality Score (Number10-assigned by the SQA Analyzer tool)
b. Schedule Quality Date (Date10-assigned by the SQA Analyzer tool)
Project Management Effectiveness Criteria
Individual project management effectiveness metrics may depend upon the nature of the particular software development project, but the following criteria can be used to design the proper ones.
1. Business Goals Effectiveness
One of the primary functions of project management is to translate the business goals of a software development effort to a set of technical goals. The entire effort will be successful only if the business goals are effectively translated.
2. Responsiveness to Changes in Business Goals
Changes in business goals are inescapable, especially in projects that have long development cycles. The project manager needs to make sure that these changes in business goals are effectively translated into appropriate adjustments in the technical direction. Many projects may meet every milestone and deliverable on time and on budget, but if business goals have changed, the efficiency achievements may not mean much. The software developed will be off the mark because of changes in business goals.
3. Development Team Facilitation
One of the key functions of the project manager is to remove obstacles in the way of the development effort and the team members. How well the project manager facilitates the work of the team makes a lot of difference in the eventual success of the project.
4. Stakeholder Responsiveness
The project manager needs to be responsive to a number of stakeholders, the development team, business sponsors, peers, partners such as sales, marketing, human resources, end users (if it is an internal application) and customers (if it is a software product). All of these stakeholders may have different priorities, and the project manager has to juggle all of these priorities effectively.
5. Outside Contractor Facilitation
This is particularly relevant when parts of or the whole development effort is outsourced. Project management effectiveness takes on additional complexity when it involves another organization with its own priorities.
6. Project Leadership
Project leadership consists of a variety of skills and qualities: communication. leadership, ability to motivate, ability to negotiate, organizational skills and conflict resolution skills. Projects can be successful only in as much as the project manager uses all of these skills.
7. Problem Resolution Effectiveness
Problem resolution skills will be called upon on a daily basis in any software development project. Good project management depends upon proactive and quick resolution of these problems, greasing the skids for the development teams to do their jobs properly.
8. Diplomacy
Any experienced project manager will tell you that effective project management deals primarily with people, not with software tools or hardware or project schedules. It takes a diplomatic project manager to smooth out the people problems that invariably arise among team members and among all stakeholders, in general.
9. Persistence
Persistence is essential when managing the various obstacles in a software development effort and is often overlooked as a contributing factor in the success of a project.
A badly planned project will take three times longer than expected – a well-planned project only twice as long as expected! Experienced project managers will tell you that this popular quote is only half in jest. Project management effectiveness is as much needed as meeting milestones and deliverables on time. There are many factors that make a project manager effective, and paying attention to all of them is essential in ensuring the success of software development efforts, particularly when they're outsourced.
1. Business Goals Effectiveness
One of the primary functions of project management is to translate the business goals of a software development effort to a set of technical goals. The entire effort will be successful only if the business goals are effectively translated.
2. Responsiveness to Changes in Business Goals
Changes in business goals are inescapable, especially in projects that have long development cycles. The project manager needs to make sure that these changes in business goals are effectively translated into appropriate adjustments in the technical direction. Many projects may meet every milestone and deliverable on time and on budget, but if business goals have changed, the efficiency achievements may not mean much. The software developed will be off the mark because of changes in business goals.
3. Development Team Facilitation
One of the key functions of the project manager is to remove obstacles in the way of the development effort and the team members. How well the project manager facilitates the work of the team makes a lot of difference in the eventual success of the project.
4. Stakeholder Responsiveness
The project manager needs to be responsive to a number of stakeholders, the development team, business sponsors, peers, partners such as sales, marketing, human resources, end users (if it is an internal application) and customers (if it is a software product). All of these stakeholders may have different priorities, and the project manager has to juggle all of these priorities effectively.
5. Outside Contractor Facilitation
This is particularly relevant when parts of or the whole development effort is outsourced. Project management effectiveness takes on additional complexity when it involves another organization with its own priorities.
6. Project Leadership
Project leadership consists of a variety of skills and qualities: communication. leadership, ability to motivate, ability to negotiate, organizational skills and conflict resolution skills. Projects can be successful only in as much as the project manager uses all of these skills.
7. Problem Resolution Effectiveness
Problem resolution skills will be called upon on a daily basis in any software development project. Good project management depends upon proactive and quick resolution of these problems, greasing the skids for the development teams to do their jobs properly.
8. Diplomacy
Any experienced project manager will tell you that effective project management deals primarily with people, not with software tools or hardware or project schedules. It takes a diplomatic project manager to smooth out the people problems that invariably arise among team members and among all stakeholders, in general.
9. Persistence
Persistence is essential when managing the various obstacles in a software development effort and is often overlooked as a contributing factor in the success of a project.
A badly planned project will take three times longer than expected – a well-planned project only twice as long as expected! Experienced project managers will tell you that this popular quote is only half in jest. Project management effectiveness is as much needed as meeting milestones and deliverables on time. There are many factors that make a project manager effective, and paying attention to all of them is essential in ensuring the success of software development efforts, particularly when they're outsourced.
Subscribe to:
Posts (Atom)
