CompTIA IT Project+ Notes

Domain II:     Preliminary/Project Planning (39%)

This domain covers the knowledge and skills required to create a project plan, analyze requirements, perform risk management, prepare project budgets, create a project schedule, develop a work breakdown structure (WBS), estimate project costs, develop a communication plan, organize a comprehensive project plan, and close out the planning phase of a project.

    • 2.1 Given an approved project scope document, detailed schedule, and budget information, demonstrate the ability to create a project management plan that illustrates understanding of the roles of stakeholders and includes establishing a project tracking mechanism.


A project plan includes much more than scope documents, schedule, and budget information. It is important to include information concerning the roles of various project stakeholders. Project plans can include a responsibility assignment matrix to help in clarifying these roles. Project plans should also include information on how project progress will be measured.

Stakeholder roles should be documented in a project management plan. There are several ways to document these roles:

  1. The plan can list the project stakeholders by organization or name, along with specific roles and responsibilities.
  2. The plan can include a responsibility assignment matrix, which maps the work of the project as described in the WBS to the people responsible for performing the work.

As stakeholders or work changes on the project, the project plan should be updated.

It is important to state clearly which stakeholders are responsible for performing specific work, reviewing work, approving work, and so on.

Tracking mechanisms include developing project metrics, using status and progress reports, and using earned value management.

  1. Metrics are ways of measuring performance. Examples of project metrics could include the number of lines of code developed per week, the number of computers installed to date, and so on.
  2. Status reports describe where the project team stands at a specific point in time. For example, halfway through a project, a status report would describe how much has been completed to date.
  3. Progress reports describe what the project team has accomplished during a certain period of time. For example, many projects require monthly progress reports that describe what work has been accomplished each month.
  4. Earned value management is a project performance measurement technique that integrates scope, time and cost data.

Make sure project plans include information that clearly describes stakeholders’ roles on the project. Also include detailed information on how progress will be measured and tracked.

    • 2.2 Given a scenario with necessary project documents and resource calendars, demonstrate the ability to develop an initial project schedule by defining and sequencing project tasks, estimating durations for tasks, specifying resource requirements, and determining appropriate schedule formats.


Developing a realistic and useful project schedule is a critical part of project planning. The project team must define and sequence project tasks, estimate their durations and resource requirements, and decide how to communicate schedule information.

A task or activity is an element of work, normally found on the WBS, that has an expected duration, a cost, and resource requirements.

In order to estimate duration and resources required for a task, the project team must first clearly define tasks by developing a more detailed WBS and supporting explanations.

A dependency or relationship shows the sequencing of project tasks. There are three basic types if dependencies:

  1. Mandatory dependencies are inherent in the nature of the work. For example, you cannot test code until after it is written.
  2. Discretionary dependencies are defined by the project team. For example, a project team might decide not to start a detailed design of a new system until users sign off on the analysis work.
  3. External dependencies involve relationships between project and nonproject tasks. For example, the installation of a new operating system and other software may depend on delivery of new hardware from an external supplier.

Project network diagrams display the sequencing of tasks. Most project management software displays project network diagrams using the precedence diagramming method where boxes represent tasks and arrows connect related tasks.

The longest path through a project network diagram is called the critical path. The length of the critical path is the minimum amount of time required to complete a project. If any task on the critical path takes longer than planned, the project completion date will be extended.

Take time to define project tasks and dependencies clearly. Task definitions and dependencies provide the basis for time, cost, and resource estimates. Use project network diagrams to display task sequencing and determine the critical path.

2.2       cont.   Given a scenario with necessary project documents and resource calendars, demonstrate the ability to develop an initial project schedule by defining and sequencing project tasks, estimating durations for tasks, specifying resource requirements, and determining appropriate schedule formats.


To develop a project schedule and cost estimate, you must estimate the durations of tasks and specify resource requirements. There are many ways to communicate schedule information, and it is important to determine what format is appropriate.

A duration is the amount of time worked on a task plus elapsed time. For example, if one project task is to develop a user guide and the person creating the guide thinks it will take forty hours to complete the task, but he or she only works twenty hours a week and must wait one week to receive comments, the duration estimate would be three weeks.

Resources assigned to tasks affect duration estimates. It is important to keep resource assignments in mind when making estimates.

There are several ways to communicate schedule information:

  1. A Gantt chart is a standard format for displaying project schedule information by listing project tasks and corresponding start and finish dates in a calendar format. Symbols on Gantt charts display summary tasks, milestones, and so on. Most project management software tools create Gantt charts. Gantt charts can be filtered to display all tasks, summary tasks, critical tasks, and so on. Many people like to see project schedules in a Gantt chart format.
  2. A network diagram or PERT chart shows task sequencing. PERT charts can be difficult to understand, so not all stakeholders like to see them.
  3. Milestones are significant project events with zero duration. They are represented by a diamond symbol on a Gantt chart. A milestone report lists milestones and their dates. Senior managers might only want to see milestone reports so that they can keep informed on high-level schedule information.

Be careful in estimating task durations. Consider resource assignments and elapsed time in making duration estimates. Communicate project schedule information in various ways to meet differing stakeholder needs.

    • 2.3 Demonstrate understanding of important budgeting concepts, techniques, and issues, including bottom-up cost estimates, standard engineering estimate techniques, and issues to consider when transforming a project cost estimate into a budget.


There are several ways to develop cost estimates, and it is important to understand which approach to use for specific projects. Estimates provide the basis for project budgets, which allocate project funds over time.

Cost estimating involves developing an approximation of the costs needed to complete a project. Costs often include salaries, hardware, and software.

There are several types of cost estimates:

  1. A bottom-up estimate is based on estimating individual work items and summing them to get a project total.
  2. Analogous or top-down estimates use the actual cost of a previous, similar project as the basis for estimating the cost of the current project.
  3. Parametric modelling uses project characteristics in a mathematical model to estimate project costs.
  4. A rough order of magnitude (ROM) estimate is prepared early in the life of a project to provide a general idea of what a project will cost. Experts in a field can often create ROM estimates in a short period of time.

There are several techniques for developing standard engineering estimates. Many software development estimates, for example, are based on an estimate of the number of lines of code and a cost per line of code.

Project cost budgeting involves allocating the project cost estimate to individual work items, and they are usually allocated over time, such as months or years.

Organizations have their own ways of budgeting. It is important to translate the project cost estimate into an appropriate format for the organization’s budget.

It is important to have people who understand the project well help in creating the cost estimates. It is also important to understand how to translate the cost estimate into the organization’s budgeting process.

    • 2.4 Identify the characteristics of a formal project quality management plan (e.g., measured quality checkpoints, assignments for architectural control, systems test, unit tests, user sign-off, etc.).


A quality management plan is intended to document important quality standards that apply to the project and methods by which quality will be assured and controlled. On information technology projects, it is important to give one person responsibility for architectural control, so as to ensure quality throughout the enterprise. There are also numerous tests to ensure quality on projects.

Quality planning involves identifying relevant quality standards for each unique project and designing quality into the products of the project. It also involves communicating the correct methods for ensuring quality in a form that is understandable and complete.

Quality assurance involves satisfying the relevant quality standards for a project and promoting continual quality improvement.

Quality control involves accepting decisions, reworking, and process adjustments.

Quality checkpoints are specific points at which quality can be checked. For example, users could test specific functionality or features of a new system to make sure it meets their needs as the project progresses. Users often sign off on specific checkpoints to show their acceptance of work.

Because most information technology projects must work within a larger organizational context, it is important to have someone responsible for ensuring that new systems fit into the overall architecture.

There are several types of tests to ensure quality on information technology projects:

  1. A unit test is done to assess each individual component (often a program) to ensure it is as defect-free as possible.
  2. Integration testing occurs between unit and system testing to test functionally grouped components. It ensures that subset(s) of the entire system work together.
  3. System testing tests the entire system as one entity.
  4. User acceptance testing is an independent test performed by end users prior to accepting the delivered system.

Document quality requirements and plans for projects in a quality management plan. Be sure to define quality checkpoints and tests required for the project.

    • 2.5 Given a team-building scenario, including a scope definition and WBS, identify selection criteria for particular team members and demonstrate the ability to ask interview questions that will assist the team selection process.


People make or break projects. It is important to select team members who can contribute to successful completion of a project and to spend time building a cohesive, productive team.

People must work together to complete projects successfully. In addition to having strong individuals on a team, project teams must set aside time for team-building activities in order to work together effectively.

After determining the initial scope of a project and developing a WBS, it is important to decide which individuals will do the tasks of the project. The skills required for the task should be defined so that appropriate resources can be assigned.

The most effective way to select new team members or to determine specific resource assignments is by interviewing people. The goal is to match the work to the people most suited for each task.

It is important to develop good interview questions. In addition to asking technical questions to make sure someone knows how to do the work, it is important to ask behavioural questions, also. For example, the following questions provide insight into how someone works in a team environment:

  1. Describe a situation where you had to do a very challenging task that you could not figure out on your own. What did you do?
  2. Describe a situation where one of your project team members was not pulling his or her weight. What did you do?
  3. Describe a project you worked on where the team really clicked. What factors do you think contributed to the team’s synergy?

One cannot overemphasize the importance of people on projects. Try to pick the right people to work on project teams and assign appropriate tasks to the right people. Take time to work on team building throughout the life of a project.

    • 2.6 Identify methods for resolving disagreements among team members when evaluating the suitability of deliverables at each point in their evolution.


It is human nature for people to disagree. There are different types of conflict, and it is important to manage conflict in the best interest of meeting project objectives.

There are several conflict handling modes that project managers can use:

  1. In confrontation mode, project managers directly face a conflict, using a problem-solving approach that allows affected parties to work through their disagreements. This approach is normally most effective.
  2. In compromise mode, you use a give-and-take approach to resolving conflicts. People bargain and search for a solutions that bring some degree of satisfaction to all the parties in a dispute.
  3. Smoothing mode is used to de-emphasize or avoid areas of differences and emphasize areas of agreement. This approach is often used when two people have severe personality clashes.
  4. The forcing mode is the same as taking a win-lose approach to conflict resolution. Managers who are very competitive or autocratic might favour this approach.
  5. In withdrawal mode, is when you withdraw from an actual or potential disagreement. Little gets accomplished using this mode.

Not all conflict is bad. Task-related conflict often improves team performance because team members discuss different approaches to producing project deliverables and often come up with even better solutions. If team members disagree on how to produce deliverables, the project manager should help them get all options out in the open, brainstorm new ideas, and discuss the best way to proceed.

Emotional conflicts or personality clashes and misunderstandings often depress team performance. Project teams should develop group ground rules, including one to avoid emotional conflict. Team members should focus on fixing problems instead of blaming people.

Realize that people will have differences of opinion on many aspects of projects. Focus on solving problems, not blaming people.

    • 2.7 Given a project description/overview and list of project requirements; Decide if the project is defined well enough to achieve a measurable outcome and metrics for success. Determine if the requirements include the necessary range of inputs, are related to the project at hand, and are complete, accurate and valid. Recognize the role poorly detailed requirements play in a situation where project outcomes are not possible to verify. Identify the value of the project to the sponsor and users of the outcome. Describe the role of project value and its importance to individual and team effectiveness.


Having clear requirements is crucial for project success. It is important for project teams to review project requirements to make sure they are clear and complete. It is also important for requirements to describe measurable outcomes and a product or service that is valuable to the organization. Organizations often determine project value in terms of financial success.

It is important to review requirements and assess whether or not they can help the project team have measurable outcomes and metrics for success. For example, a requirement to provide reports for a system is not specific enough. How many reports? What information is required in the reports? What types of queries will be run to generate the reports? How many simultaneous users will be running the reports? All of these factors should be part of the written requirements for a project.

Requirements should include several characteristics:

  1. They should include a necessary range of inputs. For example, if a project involves upgrading a new system, the requirements should state what inputs are required for properly testing and operating the new system.
  2. It is easy for scope creep to occur, so it is essential to make sure that requirements are related to the project at hand. New or questionable requirements should be carefully evaluated by the project team.
  3. Requirements must be complete, accurate, and valid. Users of the products of the project must be heavily involved in defining requirements to ensure their completeness and accuracy. Testing can help ensure validity of requirements.

Many information technology projects are expensive and resource intensive. It is important to understand and communicate the value of the project to the organization and project team.

Carefully review project requirements to make sure they describe measurable outcomes and will lead to developing products or services that are valuable to the organization.

    • 2.8 Describe the goals of a useful program requirements review with the client (e.g., verify mutual understanding of client’s product delivery, product performance, and budget requirements, etc.) and describe when it is important to have such reviews.


One of the most effective ways to keep projects on track is by having requirements reviews. A project should successfully pass through various phases before continuing to the next. Phases vary by product, but many information technology projects include phases for planning, analysis, design, implementation, and support. Reviews should be held periodically (i.e., monthly or quarterly) and at critical decision points. For example, if requirements are not clear, products are delivered late, or the budget changes, a special review is needed.

It is important to take time to review program requirements and the way the project is going.

Most reviews are held face-to-face with affected stakeholders in attendance. Face-to-face reviews allow people to communicate most effectively. Some reviews can be done using other methods.

Reviews should emphasize important project goals:

  1. Does everyone understand the main goals of the project?
  2. Are products being delivered on time?
  3. Is the quality of the products acceptable?
  4. Is the project proceeding according to budget?

Most project plans include a requirement to hold reviews. Reviews are often scheduled on a periodic basis, such as monthly or quarterly. Reviews can also be held as needed when important decisions must be made. Some reasons to hold non-periodic reviews include:

  1. The organization has gone through major changes that may affect the need for the project or requirements of the deliverables.
  2. There are misunderstandings related to what the client wants in project deliverables.
  3. Products produced during the project do not meet client expectations.
  4. The project is significantly over or under budget.

Make sure projects include periodic reviews of requirements. Also hold reviews as needed to help ensure the project meets organizational needs.

    • 2.9 Given the client’s approved project requirements and the input of stakeholders, decompose these requirements into business and functional requirements while maintaining traceability within strict configuration control.


The project team must decompose requirements into more detail, describing both business and functional needs. It is important to be able to trace requirements as products are developed and to ensure configuration control.

Decomposing requirements means breaking them down into logical groups, then breaking those groups into more detail. A WBS is used for this decomposition.

Business requirements emphasize business needs. For example, a business requirement might require delivering a product by a certain date so it is available for a preplanned event that is important to the business.

Functional requirements emphasize what products or services work. For example, a project might require use of a specific programming language or hardware platform as a technical requirement.

Technical requirements emphasize how products or services work. For example, a project might require use of a specific programming language or hardware platform as a technical requirement.

Traceability means that you can track a requirement back to documented needs. Some work may be questioned, so it is important to be able to trace the work back to the documented requirements.

Configuration management ensures that the descriptions of the project’s products are correct and complete. It emphasizes management of technology by identifying and controlling the functional and physical design characteristics of products and their support documentation.

Configuration management specialists identify and document the functional and physical characteristics of products, control any changes to such characteristics, record and report the changes, and audit the products to verify conformance to requirements.

Break down requirements to describe business and functional requirements. Provide processes for traceability and configuration control.

    • 2.10 Demonstrate the ability to perform risk assessment and mitigation by indentifying and prioritizing risks, evaluating the severity of risks, identifying risk on the project’s critical path, and determining procedures to reduce potential impacts on schedule.


Risk is inherent in projects. Project teams should identify the potential risks on their projects and develop a plan for managing those risks.

Risk management planning involves deciding how to approach and plan the risk management activities of a project.

There are several ways to identify potential risks. Reviewing historical information, analyzing the nature of the project or products, and using various information gathering techniques can help in identifying potential risks.

Qualitative risk analysis involves assessing the likelihood and impact of identified risks to determine their magnitude and priority. For example, there is always a risk that fire may destroy a building. The project team might identify this risk and note that it would have severe consequences if it occurred but that it is highly unlikely to occur.

Risks can be prioritized as high, medium, or low. They can also be prioritized in rank order or by determining risk factors.

If any tasks on the critical path take longer than planned, the project will not meet its target schedule date. It is very important, therefore, to understand potential schedule risks for critical tasks.

There are several ways to reduce potential impacts of risk on the schedule. Project teams can include buffers or additional time before the project completion date to reduce the likelihood of a schedule overrun. Project managers can increase monitoring of critical tasks to help ensure timely completion.

Risk mitigation is reducing the impact of a risk event by reducing the probability of its occurrence. For example, a project team might decide to use a current version of an operating system instead of planning to use a soon-to-be-released version.

Information technology projects often neglect risk management. Be sure to identify potential risks on projects and plan how to manage those risks.

    • 2.11 Given a project scope, timeline, cost, project team, and dependencies, demonstrate the ability to create and manage a high-level top-down budget or a detailed bottom-up budget, identify and budget resources, budget for project trade-offs, and install and maintain systems for tracking budgetary expense against the plan based on existing enterprise systems.


All projects need some sort of funding, and budgets provide the basis for managing funds. Project managers must be well versed in creating budgets, making budgetary trade-offs, and tracking budgetary expenses.

A budget is a financial report that documents income and expenses over time.

After reviewing other project documentation, such as scope statements, schedules, cost estimates, and resource information, the project team must develop a budget for the project. It is important to understand how the specific organization does budgeting when creating the project budget.

Budgets can be developed using a top-down or bottom-up approach, similar to that used in developing cost estimates.

  1. A bottom-up budget is based on estimating individual work items and summing them to get a project total.
  2. A top-down budget uses the actual budget of a previous, similar project as the basis for estimating the budget of the current project.

It is important to get input from the project team in developing budgets.

Human resources are a major part of most project budgets. Funds for personnel must include compensation, benefits, overhead, overtime, and so on. Fully loaded amounts include compensation, benefits, and overhead.

Projects often involve several trade-offs that must be made during the course of the project. For example, many projects use goods and services from suppliers, but the specific goods and suppliers may not be known when the budget is created. The project manager can include additional funds in the budget to provide some flexibility.

It is very important to track a project’s budgetary expenses against the plan and to understand the entire organization’s budget. Organizations often take budgets very seriously. For example, a company may limit travel expenses to reduce overall costs, and there may not be funds available if a project team is already over its travel budget.

Take budgeting seriously. Develop a realistic budget and follow it as carefully as possible.

    • 2.12 Identify and list the components needed to generate a workable project schedule. Create appropriate project schedules which meet the approved project start and finish dates, given a detailed list of project deliverables (both interim and finish), a detailed estimate of project tasks, a list of activities and phases, a detailed estimate of the time and resources required to complete all project tasks, and information about the preferences of the project team regarding schedule format.


This objective expands on Objective 2.2. After developing a detailed list of project tasks and deliverables, estimated durations, task resources, and preferences on schedule formats, project teams must create a schedule that serves as a guide for completing a project on time.

A good schedule is a key tool for guiding the completion of work. Many people are motivated by deadlines, and seeing their names attached to schedules clarifies accountability and progress. Project managers should work with their teams to create and maintain workable project schedules.

There are several ways to display schedule information. Most schedules list project tasks, deliverables, and completion dates as a minimum.

Many people like to see milestone reports, which list project milestones in one column and their planned completion dates in the next column.

The project team often needs more detailed schedule information, such as the resources assigned to specific tasks and the dependencies between tasks. A Gantt chart is a popular and effective tool for displaying detailed schedule information. The WBS provides the basis for the list of tasks and their hierarchy. Project network diagrams display task dependencies and provide automatic generation of task dates.

By using project management software to create Gantt charts and project network diagrams, you can easily create good project schedules and change the format and amount of detail displayed. For example, you can provide reports that list tasks by resource. However, remember the saying, “Garbage in means garbage out”. You must have good inputs to create good schedules.

You can also track planned versus actual information as the project progresses, using a tracking Gantt chart or similar tool. The project team should decide whether and how it wishes to track actual schedule information.

Project schedules should guide completion of work. Create and use them with this intent.

    • 2.13 Given a project planning scenario, demonstrate an understanding of and the ability to plan for iteration by identifying elements likely to require it and explicitly deciding to provide for iteration in the project plan (e.g., scope approval, plan approval, project design, final deliverable turnover, etc.).


Because of the unique nature of projects, plans are expected to become more defined as the project progresses. Project teams should plan for scope documents, design documents, and related information to go through an iterative process of development as detailed plans are set forth.

Projects are unique and temporary by definition. Project plans will become more detailed as time progresses, so it is important to plan for iteration.

Time and resources should be allocated to review, analyze, and improve project plans. People on the project team and other stakeholders, especially users of information technology products, should be actively involved in the iterative development of plans.

Items most likely to require careful iteration include scope documents, including definitions of product designs and project deliverables. For example, an original description of a deliverable might be fairly broad. As it comes closer to the time to create or acquire the deliverable, that description must be further elaborated.

Project plans should include a process for submitting preliminary documents, obtaining feedback on the, incorporating feedback, and receiving appropriate approval.

Iteration is also required when planning for turnover of final deliverables. For example, many changes can occur from the time a project begins to the time it ends. Preliminary plans can describe the turnover of final deliverables, but more detailed plans must be provided at the end of the project to ensure a smooth transition.

Iteration is an important part of project planning. Remember to allocate time and resources for updating plans during the life of the project.

    • 2.14 Given a scenario involving tasks, resources (fixed or variable), and dependencies for a multiphase IT project, demonstrate knowledge of the standards for creating a workable WBS. Recognize and explain the need to creatively visualize all deliverables (interim and finished) and thoroughly decompose the system into all potential hardware and software components.


A work breakdown structure (WBS) is a foundation document in project management. It provides the basis for planning and managing project schedules, costs, and changes. It is crucial to work with the team to create a good WBS.

A work breakdown structure is an outcome-orientated analysis of the work involved in a project that defines the total scope of the project.

A WBS should list all the work, and only the work, required to complete the project. It is important to include tasks related to creating the products of the project, as well as the process for developing them. A WBS is required for creating a Gantt chart.

A WBS shows tasks in a hierarchy format. Each WBS item is the sum of the WBS items below it. The highest level of the WBS, Level o, is the entire project. The next level, Level 1, lists major groupings for tasks. The next level breaks down those major groupings into more specific tasks, and the decomposition continues.

The lowest level in a WBS is called a work package. Experts suggest that work packages involve no more than eighty hours work, but there are wide variations in the number of levels and amount of detail in WBSs. The nature of the project should drive the structure of the WBS.

A WBS is often depicted in graphical format as a task-orientated family tree of tasks resembling an organizational chart. A WBS can also be displayed in tabular form with a numbering scheme and indentations depicting the hierarchy of tasks. For example, the structure below shows a tabular format for a WBS:

1.0 Main task 1

1.1 Subtask 1
1.2 Subtask 2

2.0 Main task 2
3.0 Main task 3

Work with the project team to create a good WBS. Take the time to do it well.

    • 2.15 Recognize and explain the need to obtain consensus among all stakeholders regarding project deliverables and other elements in the WBS, and obtain formal approval (sign-off) of project sponsor(s) regarding project deliverables and other elements of the WBS.


People who will do the work in a project should be involved in planning the work. People who are sponsoring or paying for the work should also have a say in what gets done. Plan to obtain formal approval on project deliverables, especially if you are under contract, which is legally binding.

Consensus means reaching agreement on a collective decision. It is very important to involve all affected stakeholders in identifying and describing the deliverables and other parts of a WBS. It often takes several formal and informal meetings and other forms of communication to reach consensus on the project scope.

Each WBS item must be documented to ensure accurate understanding of what is and is not included in that item. Each deliverable should be defined in detail. Information technology deliverables often require detailed specifications. It is important to keep descriptions of WBS items up-to-date as the project progresses.

Clarify who is responsible for performing specific tasks in the WBS. Each WBS item should be the responsibility of only one individual, even though many people may be working on it. If there are problems with a particular WBS item, the appropriate person should be contacted. Bigger problems should be elevated to the person in charge of the aggregated WBS item, and problems related to the entire project should be directed to the project manager.

In order to acknowledge consensus and follow the necessary chain of command, there should be formal approval of project deliverables and other elements of the WBS. Formal approval often occurs via signatures of the project sponsor(s) or appropriate managers.

Problems often result when the wrong people authorize work, so it is important to clarify who can sign off on what. As described in Objective 2.1, a responsibility assignment matrix can be used to clarify stakeholder roles on projects.

Clarify who is responsible for each WBS item and who can provide formal approval of project deliverables.

    • 2.16 Given a project scenario with many phases and activities, set realistic, measurable milestones, and demonstrate understanding that measurable targets are required in order to determine if the project is proceeding on time and within budget.

Project managers must keep the big picture in mind when managing projects. Setting realistic milestones and measuring progress on meeting them helps to keep the projects on track.

A milestone is a significant event on a project. For example, milestones might include awarding a contract to a supplier, completing the analysis phase of a project, freezing code, going live, delivering workstations, completing training, and so on.

By definition, milestones have no duration. They also do not require any resources or expenditures. Milestones are used on schedules to show significant events that are often the result of related work. For example, there might be several WBS items related to training on a project, but the milestones might only state when training activities begin and when they are completed.

Milestones are represented by a black diamond on a Gant chart. A slipped milestone is representing by a white diamond on a tracking Gantt chart.

Some people us the SMART criteria to help define milestones:

  1. Specific: It is important to define milestones in enough detail to clarify what they mean.
  2. Measurable: One of the main reasons for using milestones is to measure progress on a project, so milestones must be easy to measure.
  3. Assignable: Each milestone should be assigned to one person responsible for its completion.
  4. Realistic: Projects are much more likely to succeed when they have realistic goals. It is important to make sure that milestones make sense and are achievable.
  5. Time-framed: Since milestones are part of project schedules, they must be assigned a completion date.

Senior management and other project stakeholders often want to focus on high-level progress on projects. Project teams should develop a list of important events or milestones for their projects, using the SMART criteria. Focusing on meeting milestones can help everyone stay on track.

    • 2.17 Given a set of specific milestones and their descriptions, specify entry and exit criteria for each.


You cannot measure progress in meeting milestones if you do not define their entry and exit criteria. These criteria must be clearly defined by all affected stakeholders.

Milestones are determined on the basis of a project’s related WBS items. Each phase of a project (i.e., analysis, design, implementation) often has milestones associated with it. Milestones can be used to guide the beginning and end of important project phases.

In order to measure progress toward completing milestones, it is important to relate milestones to associated WBS tasks. For example, there may be several tasks for the analysis phase of a project, and a milestone called “analysis completed” could be placed at the end of the analysis tasks.

Milestones can also help to make sure the team is ready to progress on specific tasks. For example, a milestone called “funding approved” could be required before entering a new phase of a project.

Milestones can also be set to help ensure specific tasks are progressing as planned. For example, milestones related to developing software might be “completing Module 1”, “completing Module 2”, and so on.

As changes are made to a project, it is important to change milestones. There may be a need to modify or add additional milestones to meet changes in the business environment, changes in project design or technology, or changes in personnel.

Focusing on milestones helps everyone understand generally what needs toi be done when. Senior managers, in particular, like to focus on meeting milestones to make sure the project is on track.

Clarify entry and exit points for milestones. Use milestones to make sure the project is progressing toward successful completion.

    • 2.18 Recognize and explain the issues that must be considered in creating a project cost estimate, including project scope, various levels, task requirements, resource skill levels, resource availability, resource expense, and the need to target elapsed time to reconcile the original budget allocation.


You must consider many factors in developing project cost estimates. It s important to understand the nature of the project, organization, and team in order to develop and document realistic assumptions needed to estimate project costs.

There are many issues to consider when creating a project cost estimate:

  1. Project scope: As previously discussed, it can be very difficult to nail down the scope of a project. Costs are directly related to how much work will be done on a project. The WBS should provide the basis for estimating project costs.
  2. Task requirements: It is important to understand specific requirement for tasks in order to estimate their costs.
  3. Resource skill levels: You must consider who will do the work when estimating costs. For example, a senior programmer may do some work more quickly than a junior programmer. The skill level of resources determines the duration estimates for tasks as well as the hourly rates to charge to those tasks.
  4. Resource availability: If you know the resources that will be on the project, you can create a better estimate. If you want certain resources on the project but they are unavailable, you must take that information into account. You might want to change the schedule to accommodate the availability of resources.
  5. Resource expense: People are the main resource on projects, and costs for human resources are normally based on hourly rates. These rates include compensation, benefits, overhead, and so on. If resources will be outsourced, you must consider the supplier’s costs in creating the cost estimates.
  6. Original budget allocation: It is very important to keep the budget up-to-date so that everyone is on track. If the original cost estimates are not close to the actuals, you should renegotiate the budget. You must also consider the budget allocation when making initial and revised cost estimates. Scope the work to match the budget.

Be sure to address factors that affect the project budget throughout the life of the project.

    • 2.19 Recognize and explain the issues that must be considered in creating a project time estimate, including project scope, various levels, task requirements, resource skill levels, resource availability, resource expense, and the need to reconcile with the original elapsed time estimation.


You must consider many factors in developing project time estimates. The issues related to developing project cost estimates are very similar to those for project time estimates. You must understand the nature of the project, organization, and team in order to develop and document realistic assumptions needed to prepare realistic time estimates.

There are many issues to consider when creating a project time estimate:

  1. Project scope: As previously discussed, it can be very difficult to nail down the scope of a project. Time estimates are directly related to how much work will be done on a project. The WBS and resource allocations provide the basis for preparing project time estimates.
  2. Task requirements: It is important to understand specific requirements for tasks in order to estimate how long it will take to do them. Recall that task durations include the amount of time actually spent performing the work plus elapsed time. There is normally some slack time where resources are not working directly on the project, but those resources are still on the payroll.
  3. Resource skill levels: You must consider who will do the work when estimating durations. You must also estimate the amount of elapsed time for each task.
  4. Resource availability: Just as resources drive cost estimates, they also drive schedule estimates. Some tasks require specific resources, so you may need to change the schedule to address the availability of resources.
  5. Resource expense: Time estimates for human resources are normally based on hours. You should not assume that people are productive 100% of the time, however. Many people assume about 75% productivity, meaning a task that is estimated at twelve hours would be allocated sixteen hours. You must also consider overtime and slack time in preparing time and cost estimates.
  6. Original elapsed time estimation: It is very important to keep the schedule up-to-date so that everyone stays on track. If the original time estimates are not close to the actuals, you should renegotiate the schedule. Also be aware of techniques to compress schedules, such as fast-tracking and crashing.

Be sure to address factors that affect the project schedule throughout the life of the project.

    • 2.20 Recognize and explain the issues that must be considered in creating an effort estimation (man hours, FTEs), including project scope, various levels, task requirements, resource skill levels, resource availability, resource expense, and the need to reconcile with the original staffing allocation.


You must consider many issues when developing an estimate of the number of labour hours and/or staff required to complete a project. It is important to consider the context of the project, organization, and resources in preparing effort estimates.

The amount of effort required to complete projects is normally done in terms of labour hours (or person hours) and full-time equivalent staff (FTE).

There are many issues to consider when creating an effort estimation:

  1. Project scope: Effort estimates are directly related to the project scope. You must know what work is to be done by whom when estimating labour hours or FTE.
  2. Task requirements: It is important to understand specific requirements for tasks in order to estimate how long it will take to do them.
  3. Resource skill levels: You must consider who will do the work when estimating labour hours and FTE. Junior employees often require more time to complete tasks. You must also determine whether work will be done in-house or outsourced. If work is outsourced, the in-house hours for administration may need to be increased to oversee the supplier’s work.
  4. Resource availability: Just as resources drive cost and schedule estimates, they also drive effort estimates. You may only need one FTE of a senior employee instead of two junior employees.
  5. Resource expense: You must consider the overall project budget when preparing effort estimates. Although you may prefer to use all experienced staff and external suppliers, you may be able to reduce expenses by using more junior staff and doing more work in-house. Likewise, you may think it’s better to work in-house when it is actually more economical to outsource the work.
  6. Original staffing allocation: Project plans should include staffing requirements. If your effort estimates vary from what has been planned, you must coordinate with human resources, functional managers, and other affected stakeholders.

Be sure to address factors that affect the effort estimates throughout the life of the project.

    • 2.21 Given a scenario involving project information, including timing, demonstrate the ability to clearly identify what needs to be communicated during a project, to whom, when, how (formal, informal), without creating unnecessary turmoil in the project team, in situations such as schedule changes, resource loss, personality clashes, budget changes, low morale, organizational changes, and project phase completion.


Good communications are crucial for project success, especially in stressful situations. Projects should have a communications plan for predictable situations, but project managers should also be prepared to communicate difficult information.

Even when things go well, it is difficult to communicate project information. When things don’t go well, it is even more difficult to communicate necessary information.

Project managers should strive to provide good communications without creating unnecessary turmoil in the project team. It is usually better to be honest and timely in communication potentially disruptive information.

Typical problems that may surface on projects include the following:

  1. Schedule, budget, and organizational changes: Because projects work in the broader context of organizations, they are subject to changes in the organization. If the project manager learns of potential changes to the project that may affect the schedule or budget, he/she should communicate the information as clearly as possible to affected stakeholders. It is also important to communicate organizational changes such as restructuring, that may affect the project.
  2. Resource loss: If a key project team member quits or is fired, it is best to communicate the information directly to the project team. Withholding information often results in confusion, rumors, and a reduction in team productivity.
  3. Personality clashes: Emotional conflict on projects hurts productivity. The project manager should set ground rules for team behaviour to minimize this problem. In the event that individuals simply cannot work together, the project manager should consider reassignment.
  4. Low morale: There are many causes for low morale. The project manager should make sure the project is important to the organization, well defined, and well managed to avoid low morale.

Project communications are even more important during stressful situations. Be open and honest.

    • 2.22 Identify the components of an adequate project plan and explain the function of each. Components include a table of contents, overview, sponsors, team members, requirements, scheduled tasks (WBS), expected resources, environmental issues, business requirements, implementation plans, support plans, and training plans.


It is much easier to execute a project when there is a comprehensive project plan. It is important to understand the contents of a project plan and to create one to guide project execution.

Project plans vary with the needs of a project. General components include the following:

  1. Table of contents: Project plans can be lengthy documents, so it is important to include a table of contents up front.
  2. Overview: An overview or executive summary is often included at the beginning of a project plan to provide a big-picture perspective on the project.
  3. Sponsors and team members: The project plan should clearly identify the key stakeholders, especially the sponsors and project team. Individual names and contact information should be included.
  4. Requirements: A large part of project plans is often related to requirements. The project plan should include a WBS, descriptions of WBS items, product specifications, business and technical requirements, and so on.
  5. Expected resources: Project plans should include staffing information and relevant resource information.
  6. Environmental issues: Because projects work in a broader organizational context, the plan should include issues related to the environment.
  7. Implementation plans: Many information technology projects require detailed implementation plans as part of the project plans. For example, if a project includes installing hardware and software in different locations, the implementation plan would describe these installations.
  8. Support plans and training plans: The project plan should include information related to supporting project deliverables and training people in using any new hardware or software resulting from the project.

Review potential contents of a project plan. Be sure your project has a good plan to make execution run smoothly.

    • 2.23 Identify the steps involved in organizing a comprehensive project plan and using it to close out the planning phase of a project. Steps include assembling all project planning elements, creating an outline or table of contents, reviewing the outline with the project sponsor and key stakeholders, writing the comprehensive project plan, circulating the plan, obtaining top management support, conducting a formal review, adjusting the plan, and obtaining formal approval of the project plan.


It is crucial to involve key project stakeholders in creating the project plan. Allow for time to receive input from stakeholders, gain top-management support for the project, review the plan, make changes, and obtain formal approval.

People who will do the work should be heavily involved in planning the work. A project is much more likely to succeed if careful thought is put into planning and the right people are involved in developing the project plan.

It is also crucial to have people who will review or receive the products of the project involved in the planning process. There are often many things that are subject to interpretation, so use an iterative planning process.

Steps in developing and receiving approval on a project plan include the following:

  1. Assembling all project planning elements: Be sure to identify relevant parts of a project plan that are applicable to your particular project.
  2. Creating an outline and reviewing it with key stakeholders: Involve key stakeholders early in the planning process. An outline helps to make sure everyone is on the same page in terms of what should be in the plan. Reviewing similar plans or templates for project plans can help.
  3. Writing the comprehensive project plan: The full plan often includes many pages of information, graphics, exhibits, and appendices.
  4. Circulating the plan to all stakeholders and obtaining top-management support: To obtain buy-in and commitment, be sure to send a good draft of the plan to all stakeholders, including relevant senior management.
  5. Conducting a formal review, adjusting the plan, and obtaining formal approval. The project team should incorporate feedback and hold a formal review meeting. Further adjustments may be made at or after the meeting. Then the project sponsor should formally sign off on the plan.

Follow a good process for developing and receiving approval on a project plan.



JamesGosling.Com © 2006 | Privacy Policy | Terms Of UseXHTML1.0 | CSS | MT