1

Project Management 101 By Dan Poliero

Email: dpoliero@gmail.com Mobile phone: 856-297-4579

Introduction

I would like to present Project Management and a number of its tools and techniques (TnT) from my

personal experience. I have decided to write extemporaneously, without referring to any books or

reference material. I will do so for two reasons. First, because this is an introduction to me, I want to

represent what tools and techniques I have used myself. Secondly, I want to keep it as brief as possible,

so the reader has a ready reference to some good tools and a better understanding of when to apply

them.

I have an exceptionally strong scheduling background and although this will be evident in much of what I

discuss, this discussion is not limited to scheduling. Many of the tools and techniques are transferable

and can be applied to other areas of project management such as cost and risk management. I have

also tried to simplify most of the topic areas, so it may seem that I haven’t explained some areas as

thoroughly as possible. I can cover each topic area more thoroughly on request. There are also, many

topic areas in which I have considerable experience and skills that I do not present he re. There is just too

much to cover. Please reach out to me to question or discuss any topics that I cover or any that I have

omitted.

Content

I’ll cover Project Management in sequential order of project lifecycle phases. Please note that I did not

say “The” Project Lifecycle because I am not referring to Project Lifecycle as defined by any specific

book, organization or industry. Also, while this is a general sequence, phases may start simultaneously

and continue in parallel with other phases. For each phase I will introduce a tool or technique that is first

applied in that phase, although the tool may be used later in the lifecycle. The phases and associated

TnT are as follows.

Project Lifecycle Phase Project Management Tool and Technique 1. Strategic Planning Cost/Benefit Analysis

2. Project Budgeting Cost Estimating 3. Project Initiation Scope definition, Staffing, Responsibility Matrices and Space Planning

4. Project Planning Planning & Scheduling, Resource Demand Forecasting, Cost Forecasting, Baselining, Risk Analysis, Integration

5. Project Execution Variance Analysis, Critical Path Analysis, Earned Value Analysis, Risk and Impact Mitigation, Performance Metrics and Reporting

6. Project Closure Lessons Learned, Final Report

2

Strategic Planning

Strategic planning requires all departments within an organization to identify and nominate all projects

for future consideration. This is most commonly 5 years, but should be done for at least a 3 year

horizon. While all departments may nominate, one department should be the gate keeper. One of the

key components of Strategic Planning is the Cost Benefit Analysis (CBA). Most projects go through a CBA

and a Return on Investment, ROI, is determined for each. Projects generally with the highest ROI are

planned to be implemented earliest.

Without going into details of a CBA, one component of the CBA is to determine the project cost. Because

the project has not been planned and designed in detail, it is difficult to get an accurate estimate of cost.

For this reason, the Cost Estimate for the CBA is commonly a Rough Order of Magnitude (ROM)

estimate. A ROM estimate simply compares the anticipated scope of the project to a project that has

been completed that was similar and only differed by its magnitude. For e xample a 2000 square foot

house that is built for $300,000 has a cost per square foot of $150. A ROM estimate for a 3000 square

foot house would be $450,000. The assumption is the cost is scalable on a linear scale. This type of

estimate is the least accurate, but it is the easiest to perform. For Strategic Planning, it is however

accurate enough to prioritize projects and assign them to budget years 2 to 5 years in the future. A more

detailed estimate which is more accurate will be performed prior to a budget year for the purpose of

establishing the budget for the upcoming year.

Project Budgeting

To prepare an organization’s budget for an upcoming year, each project should go through a more

detailed estimating process. This estimate may be referred to as a Budgetary or Intermediate Estimate.

A Budgetary Estimate generally requires some level of design completion. Often, organizations will

allocate funds in one year to complete a high level design for a project which is planned for the following

year. The high level design provides enough details of the components/materials of the project and the

design itself for this Budgetary Estimate to be performed. There is sufficient detail in the design for the

cost of labor, material and equipment to be estimated on an item for item basis. However, because the

design is not complete, and scope and risks not fully known, there is a margin of error in the estimate

that may be 25%. And so, cost could be 25% or more greater than the estimate. This should be

accounted for in reserve funding and added to the budget.

Since all projects for the upcoming year have completed a Budgetary Estimate, it provides a higher level

of confidence in the aggregate cost of all the projects planned for the upcoming year and will then

maximize the aggregate ROI for the organization maximizing performance and profit. The Budgetary

Estimate also provides sufficient information on the level of effort to execute the project, which may

support early decisions about staffing levels and the need to outsource work.

3

Project Initiation

Initiating a project is primarily about securing resources to plan and execute the project. To do so, one

of the very first steps is to develop a scope statement and a scope document. This defines what the

project is and to some extent what it is not. The scope documents are important for the organization to

begin thinking about what skills and the level of effort that is required to support the project. Resource

Allocation can begin.

The next document that should be prepared is the Project Charter. The Charter captures that the project

is funded and endorsed by a single person, the Project Sponsor. The Project Sponsor is usually an

executive from the organization that will ensure that the project is delivered. The charter also captures

the organizational agreements that have been established for support of the project and it gives the

Project Manager the authority to act in the interest of the Sponsor. The Project Charter should also

define the Role and Responsibility of all resources committed to the project. This is commonly

accomplished using a Responsibility Matrix or RACI Chart that defines all the key tasks or roles and the

responsibility of each resource and organization in performing the tasks (Responsible,

Accountable/Approval, Contribute/Council or Informed). The RACI chart is one of the most important

tools of project management and it is often not used, not thorough, or does not have the buy-in of the

project team. Below is an example of a RACI chart that I put together previously for a generic project

using typical Time Management project deliverables as identified by the Project Management Book of

Knowledge (PMBOK).

4

Project Planning

Planning and Scheduling

First, planning and scheduling are often used interchangeably. They can be differentiated by saying that

scheduling is the most essential component of planning. There are two major deliverables that are

outputs of the planning process. The major deliverables of planning are a Project Management Plan

(Plan) and a Project Schedule (Schedule). The table below shows the difference between Planning and

Scheduling.

Project Management Plan (Plan) Project Schedule (Schedule)

Is commonly a word document that provides all the details of how the project will be managed or governed, who is responsible and when

The schedule is developed using scheduling software such as Microsoft Project or Primavera

The Plan provides direction to the personnel that will manage the project

The schedule provides direction to the personnel that will deliver the project product such as a building or software.

The Plan commonly is broken down into the major functions of Project Management. Some of these might be:

1. Schedule Management 2. Risk Management 3. Cost Control 4. Change Control 5. Communications Plan 6. Deliverables 7. Resource Management 8. Quality Management 9. Contract Management 10. Procurement Management

The schedule is a time phased, hierarchal list of all tasks that need to be performed, products that must be delivered and milestones that must be achieved; in the sequence they must be executed. The schedule includes:

1. Tasks, deliverables and milestones 2. All have duration and are sequenced using

dependencies to determine the start and finish of each item

3. The schedule is generally organized so the details can be summarized into phases

4. Schedules are baselined to record the start and finish of task so that variance analysis can be monitored and controlled

5. Codes are assigned to tasks so that data may be extracted and analyzed

6. Resources, rates and cost may be assigned to the tasks for resource demand and cost forecasting

There are much more, but these are the most important elements of the schedule.

I consider the items in bold in each list to be essential to any project regardless of size or risk to assure

project success. For smaller or low risk projects, it is possible and may be preferable to simplify the

content of each section of the project plan and each section of the schedule, but these key elements

should remain, even if simplified. There is additional detail that I can add to this section from my

personal experience and I can provide that detail on request.

5

Integration

Program Integration, for the purpose of this discussion, is limited to managing the needs and deliverables, between and among separate projects within a program of related projects. The purpose of this integration is to ensure that external needs of each project within a program are identified and managed to ensure that the external needs are well defined, communicated, and delivered on time and meet the requirements of the receiving project that is dependent on the external deliverable. Performing integration well produces the capability to,

1. More accurately forecast the completion of the program level products and deliverables beginning in the planning phase and continuing through the execution phase.

2. Identify what each project is delivering to external stakeholders and when it must be delivered. 3. Identify program schedule risk, variance and impacts 4. Pre-identify and prioritize risk and impact avoidance and mitigation strategies 5. Use scheduling software to identify true critical and near critical path across all projects within

the program

Integration is an essential component of Project Planning and Execution. Most organizations do not have

an established integration process or a process to assure and control the quality of integration. This is a

common problem and often causes projects to be in a continuous reactionary mode to recover from

unanticipated impacts. Integration during Project Planning is the identi fication of Needs (deliverables

and work products) that one stakeholder (Ex: work groups, work streams, teams and task owners) has

from other project stakeholders. Integration during Project Execution works to ensure that those

Deliverables are completed on time to prevent impact to the downstream or receiving project

stakeholder. Integration requires execution of a detailed process, extensive communications,

stakeholder training, team building and time commitment. There are 10 key steps or elements of

integration.

1. Create all projects as sub projects to a master project that represents the entire program. This

is done in a server environment such as MS Project Server (MSPS) or Primavera P6 Enterprise

Project Portfolio Management (EPPM) Oracle server.

2. Project stakeholders self-identify their external Needs, i.e.,

a. what they need,

b. from whom it is needed and

c. by when it is needed.

3. Add the Needs to the project schedule and identify it as a Need using a program level code

4. Assign an integration unique identifier (IUI) to the Need that pairs it with the Deliverable

5. Create the corresponding Deliverable in the other project schedule, code it as a Deliverable and

assign the same IUI.

6. Stakeholders work together to,

a. Align the Deliverable to be ready in time to support the Need or

b. Negotiate changes to the Need date.

7. Establish links/dependencies between the Deliverables and the Needs

8. Establish predecessors to all Deliverables and successors to all Needs

6

9. Ensure the Needs, Deliverables and dependencies are maintained. This is done using a report

generated from the master project for each component project of the program.

10. Establish the protocols for preventing or managing impacts if Deliverables are forecasted or

actually late and impact the Need

Risk

If Risk identification did not begin in Budget Development, it should begin in the planning phase and be

largely complete by the end of the planning phase. All contributors to the project as identified in the

Project Charter should have input to risks. Risk has two components, Probability and Impact. Probability

is the likelihood as in the percent chance that something will occur. Impact is usually measured as a cost.

Even a delay to the schedule can be quantified as a cost. The product of the Probability and Impact

produces a Risk score, also measured as a cost. Risks with either a high probability or a high risk score

should be accounted for in the Project Schedule.

Risks that have contingency plans built in the schedule should be managed using the schedule.

Risks that are not captured in the schedule, may either have separate contingency plans that

can be “pulled into” the schedule if the risk occurs or

Risks may simply be tracked in a Risk Register.

A best practice would be to have Risk Score thresholds that determine in which of these 3 ways the Risk

Contingency is tracked. Risks that are built into the schedule or have a separate contingency plan should

have their cost reserved in the Budget as Contingency Reserves. I f these Risks occur during project

execution, funds should be drawn from the Contingency Reserve.

Project Execution

After planning is complete, the next step is to execute the plan. For this discussion Execution includes

(but not limited to) the following project phases. These represent all phases except Initiation and

Planning

Design Construction Testing Turnover Commissioning Analysis Development Testing Cutover Close

Although the work that is performed in each of these phases differs significantly, the project

management tools and techniques that are applied are the same. There are 3 basic Project Management

Processes that are applied during project execution.

1. Schedule execution

2. Schedule updating to reflect actual and forecast start and finish of all tasks

3. Identify and Assess variances, risks and impacts to schedule, resources and cost

Schedule Execution

The best way to ensure that the work is performed as scheduled is to have routine coordination

meetings. These may be daily, weekly, bi-weekly or even monthly. The frequency depends on the

amount of control that is needed. In these meetings, it is best to review the schedule looking at all

tasks in a near term horizon. For example: If the coordination meeting is weekly, it is best to review

7

the schedule showing completions in the past week, in progress and upcoming work in the current

and following week. This keeps the focus on the current week but adds perspective of what is

recently completed and what is upcoming. All task owners should report on their progress. The

Project Manager may lead the discussion by highlighting the most important tasks. Important tasks

may be those that are most critical to the project end date, integration points between work groups

or other projects, or potentially tasks that are impacting a high level milestone or deliverable. Tasks

with variances from baseline should be highlighted and the task owner should provide assurance

that there is a plan to recover or that a downstream impact has been discussed and mitigated. The

Project Manager should allow some measure of discussion that does not cause the greater audience

to become disengaged. Complex issues should be resolved in small groups of impacted parties

immediately following the meeting or soon after.

The coordination meeting should also be used to provide all stakeholders with a view of the

upcoming high level milestones and deliverables that may be just outside the near term horizon. In

the example of a weekly coordination meeting, this might be milestones that are coming up in the

next one to two months.

Schedule Updating

The coordination meeting should not be the means of statusing the schedule. Statusing should be

performed by the task owners, whenever possible by either direct access to the schedule or web

access. The coordination meeting should occur within a day or two of task owner’s statusing their

tasks. Task owners are often unfamiliar with the schedule software and how to accurately apply

status. The Project Manager must provide the necessary training and written guidance, such as a

quick reference guide, for all task owners to reference as needed. The Project Manager should use

some method of Red, Yellow and Green (RYG) status indicator on all tasks to alert the task owners

when a task is tracking behind. Typically this might be when the finish date is later than the baseline

finish and completion percentage is lagging behind the original plan.

Identify and Assess variances, risks and impacts to schedule, resources and cost

Variances

All variances result from the current forecast differing from the expected value as captured in a

baseline. To understand variances, it is important to first understand baselines.

Capturing a baseline saves all the schedule data at a specific point in time. Schedule data such as the

start date and finish date of a task, the total work of a task and the cost of a task are all save d in a

baseline. MS Project and Primavera have the ability to save multiple baselines. For this discussion

we will consider three important baselines; The Original Baseline, Initial Baseline and the Control

Baseline.

Original Baseline – is a baseline that is saved after the Project Schedule is fully developed.

The schedule is developed in the planning phase and at the end of the planning phase, just

prior to the start of execution, the original baseline is saved. This becomes a reference point

to compare variances between items like current and original finish dates, current and

8

original cost and between current and original resource forecast. The Original baseline is

never changed.

Initial Baseline – often a Project Schedule is built and execution begins before Project

Schedule is finalized. In such cases, an initial baseline can be saved to begin tracking

variance until the project plan is finalized. It provides the opportunity to stay on track until

the schedule is finalized.

Control Baseline – once the Original Baseline is saved, Project Change Control begins. At the

same time the Original baseline is saved, the Control baseline is saved. The difference

between the two is that the Original Baseline never changes while the control Baseline does

change. Changes to task completion dates, project scope and cost projections all result in

variances. The change causing the variances can be submitted for review by a Change

Control Board (CCB) and if the change is found to be acceptable, the impacted tasks in the

schedule can be “Re-baselined”. Since the change was determined to be an acceptable

impact, re-baselining the impacted tasks in the Control Baseline makes it possible to track

variance against the new reference point. For this reason, the Control Baseline is always the

baseline against which variances are tracked.

Risks

As mentioned previously, Risks may be realized in the execution phase. If they are, the

contingency plan should be executed. The Contingency Plan represents a level of effort to

prevent an impact from occurring. High level risks may already be captured in the schedule

while mid-level risks may be in a separate contingency schedule that will need to be inserted

into the project schedule. Low level risks that are realized during project execution may need

contingency plans developed. If any level risk is identified during project execution they will

need funding to be allocated. Contingency funds should be allocated through the Change

Control Process.

Schedule Risk Analysis

Much can be written about schedule risk identification and assessment. The core to schedule

risk assessment is Critical Path Analysis (CPA). CPA can be performed with both of the most

frequently used scheduling software, Primavera and MS Project. Some basic scheduling

practices must be followed to perform CPA. In summary all tasks must have predecessors and

successors and constraint dates should be minimized or completely avoided. To perform CPA,

the software tool calculates “Float” or “Slack”. This is calculated for every task in the schedule in

time units of days or hours. The Float or Slack value indicates how long task can delay be fore it

impacts the project completion date. In essence, all tasks with zero slack are in a sequence that

defines the completion date. Zero float tasks are referred to as “Critical”. In CPA, the schedule

can be filtered to show all tasks with zero float and the grouped and sorted to clearly display

the path or paths. Similarly, paths can be displayed of each incremental float or slack value so

the “Near Critical Path(s)” can be displayed. The lower the Float or Slack value, the higher the

risk is to the project end date. These critical and near critical tasks should be managed more

closely and variance or slippage should be kept at a minimum.

9

CPA is not the only tool for managing schedule risks, there are tools that calculate probabilistic

risk. These tools look at every path through the schedule and based on the number of tasks and

the optimistic and pessimistic durations of each task and calculate the most likely paths to

impact the project completion. Whether CPA or probabilistic analysis software, the most likely

paths to delay the project are identified and additional controls can be applied to effectively

manage these risks.

Earned Value and Earned Schedule

Earned Value and Earned Schedule are additional techniques used to better forecast project

completion date and cost at completion, based on performance to date. To use either

technique, good project baselines must have been developed, actual completion to date must

be reported accurately with quantifiable measures and task durations must be no longer than

two reporting periods. Using either of these techniques requires additional project management

effort and the additional cost of implementing these techniques should be weighed against the

anticipated value of applying them. Projects that are less than 6 months in duration should

generally not use either technique. This is because reporting cycles are generally monthly and

there are not a sufficient number of cycles to identify performance issues and implement action

to correct them. These techniques are best implemented in projects exceeding one year in

duration in organizations that are mature in applying project management best practices. An

organization’s project management maturity can be measured using the Project Management

Maturity Model (PMMM). I would recommend that Earned Value and Earned Scheduling not be

attempted if the organization is not at PMMM level 3 or above.

Impacts

Impacts are either delays in the schedule, scope increases or cost increases that have occurred ,

or are imminent and cannot be avoided. The first thought when an impact occurs should be to

identify a way to mitigate the impact. If the impact is a schedule delay that cannot be accepted,

action should be taken to Crash, Compress or delete the work in the schedule that follows.

Crashing involves performing downstream work in parallel with the delayed tasks. Compressing

involves reducing the duration of the delayed task or downstream work. Whether Crashing or

Compressing the schedule, all impacted parties must be engaged and “buy-in” to the decision.

10

Performance Metrics

There are a number of performance metrics that may be used to effectively manage project

performance. All require actual performance to date to be measured against planned performance to

produce a variance. For this discussion on metrics, I will present three common metrics.

1. Milestone/Deliverable Performance

2. Red, yellow and green indicators

3. Incremental and Cumulative Graphs

Milestone/Deliverable Performance

One of the most basic and easily understood project performance metrics is a

milestone/deliverable performance spreadsheet. This requires the project manager to identify the

important milestones and key deliverables in the project. If it is a large project or involves the

integration of multiple projects, each of these milestones/deliverables should be tagged based on

their importance. For this discussion I will only discuss Level 1 and Level 2. Level 1 is the executive

level. These should be limited to 10-15 and represent major phase completions or achievements

across all projects. Level 2 milestones and deliverables should support the Level 1 and delays to

level 2 should provide early warning to potential impacts on the level 1. Level 2 milestones or

deliverables may also be integration points between projects. Below is an example Milestone

Status Report.

11

Red, Yellow, Green (RYG) Indicators

Schedule performance, for milestones, deliverables and all tasks, is best monitored with red, yellow

or green indicators. The RYG condition may be dependent on a number of variables. I have found

criticality, finish variance and percent complete variance to be the most important to monitor.

1. Criticality is the slack or the float value as calculated by the scheduling software. It is the

difference between the late finish and the early finish. The late finish is the latest the task

may finish before it will impact the project completion date. A task that has 10 days of slack

can delay 10 additional days before it delays the project completion.

2. Finish variance is the difference between the current finish date and the baseline finish

date for a task.

3. Percent complete variance is the difference between the planned percent complete to date

and the actual percent complete.

For the RYG indicator(s) to be of value, the conditions must cause the colors to change only when

there is a performance problem that must be addressed. If conditions cause yellow or red too early,

when no action needs to be taken, they will be ignored. Conversely, if conditions cause yellow or

red too late, there will not be time to implement corrective action. I have also found that the value

at which RYG indicator changes condition from green to yellow or red, should be dependent on the

criticality and the importance level of the task. The table below provides suggested values for RYG

status for a project of one year duration.

Importance Variance Slack > 45days 20 days<slack<45 days Slack <20 days

12

level type Y R Y R Y R

1

Finish 1-3 days >3 days 1-3 days >3 days 1-3 days >3 days

% Complete 20-30% >30% 10-15% >15% 5-10% >10%

2

Finish 5-10 days >10 days 1-5 days >5 days 1-3 days >3 days

% Complete 30-35% >35% 20-25% >25% 10-15% >15%

3 or greater Finish 15-20 days >20 days 5-10 days >10 days 3-5 days >5 days

% Complete 40-50% >50% 30-35% >35% 15-20% >20%

Each of these three measures may have their own RYG indicator or they may be combined into one

indicator. Note that if a single RYG indicator is used for Slack, finish variance and percent complete

variance, the variable that has the worst condition determines the color of the indicator. For

example, if slack is 30 days for a task, the indicator is yellow. But, if the task is a level 1 milestone

and the percent complete lags the planned percent complete by greater that 15%, the indicator

will be red.

Incremental and Cumulative Graphs

Two of the most essential components of a project to measure are cost and schedule performance.

Both should be measured using data that is extracted from the project schedule. The “Planned”

data is contained in a project baseline that is saved at the end of the Planning phase, just prior to

Execution. The actual to date or current data is extracted from the current schedule. Data may be

looked at incrementally or cumulatively. Incremental review compares planned verses actual

performance for each time period, such as one month.

Below is an example of an Incremental schedule performance metric.

In this example, the actual project percent complete is lagging behind the planned percent

complete, each of the first 6 months of a 12 month project. The variance for each month is the

difference between planned and actual percent complete. For example, in the 5th month, the

variance is 4% (13-9). It can be easily assessed that because performance is lagging in the first 6

months that performance will need to improve to complete all of the project scope by the planned

23

7

10

13 13 13 1312

8

4

21

2

46

910

16 16 16

12

6

2

0

5

10

15

20

25

1 2 3 4 5 6 7 8 9 10 11 12

Planned Actual Forecast Original Plan Forecast Recovery Late Planned

Month

% C

om

ple

te

Incremental

Shortfall Period Recovery Period

13

completion date. However, the Incremental indicator does not provide insight into how much

performance needs to improve and for how long. While incremental data is useful to measure

performance for a previous month, it does not provide a view of trends and forecasts. Cumulative

variance analysis solves this problem.

The cumulative metric below provides a different look at the same data.

Here it can be clearly seen that the actual performance to date is 16% behind the original plan. If

monthly completion continues at this rate or even improves to the original planned completion

rate of 13% per month, the project will reach only 84% completion in the original 12 month

planned duration. Performance needs to improve to 16% per month during a recovery period,

representing a 23% improvement to complete all of the project scope, in the original 12 month

plan. With this data, decisions can be made about the achievability of 16% completion rate, the

cost that might be incurred in doing so or whether to extend the project duration or reduce the

work scope.

Note also that the completion rate that represents the latest completion of all tasks in the project

schedule has been plotted. By doing so, it can be seen that the actual completion rate to date falls

between the planned and the late data. As the cumulative actual percent complete approaches

the late completion rate line, it indicates that the schedule has been compressed as much as

possible and any additional delays cannot be recovered.

These are two examples of metrics that are commonly used and very effective. Planned verses

actual to date is variance analysis and this should be used to measure performance for a number of

project parameters such as cost and schedule. Variance analysis should be performed for all

participating groups or projects and there must be single point accountability for each performance

area.

35

48

74

84

32

80

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10 11 12

Planned Actual Forecast Original Plan Forecast Recovery Plan Late Planned

% C

om

ple

te

Month

16% Behind

Performance rate for recovery needs to be

16% per month for months 6-9

Planned performance rate during sustained period 13%/month

Forecast completion % at 12 months if perofrming at

original plan

Completion rate if all tasks complete as late as allowed (all tasks critical)

Recovery Period

Conclusion: Performance must improve from 13% to 16%/month, a 23%

increase to recover

Cumulative

14

Project Closure

At the completion of the project, it is important to identify what went well and what can be

improved so the lessons learned may be applied to future projects or even normal operations.

Much of the information can be gleaned from the Performance Metrics . However, it is very

important to solicit feedback from all stakeholders as this will provide a much more thorough

review and identify many more successes and opportunities for improvement. The data should

be collated into a list of lessons learned. The Project Team should review the input with the

stakeholders and ensure thorough understanding of the problem and any recommended

actions. When complete, the entire list should be sent to all stakeholders for review and

comment. Once again all comments and feedback should be collated and the project team

should prepare a final report. The conclusions of the report should be presented to all

stakeholders for a final review and open discussion. It is useful to break the meeting up into

smaller focus areas and assign stakeholders to areas where they have significant input. This will

serve to refine the conclusions and actions recommended by the project team. The end result is

a prioritized list of actions, owners and due dates. All actions should be implemented and

incorporated into the organization’s processes and future project management efforts.

Summary

As I mentioned at the beginning of this paper, my intent was to provide additional insight into

my Project Management experience. I am hopeful that readers will find some information

helpful and applicable to their work. There are a number of project management topic areas

that I have not covered that are valuable tools in managing projects. My goal was to showcase

those that I have used most frequently and that I have found to be very useful. I welcome the

opportunity to discuss any of these topics with you, the reader. Please contact me at any time.