Project is unique endeavor that has a specific goal, a beginning and an end, and usually a

budget.

Project is not operations. Operations is a work that is same day after day, producing the same
results. For example, I was in charge of a technical support group at a software company.
Every day our team opens and closes support requests. Each support request was unique, but
we basically perform same tasks day after day. This was operations. However, beside my
operations works, I was given a task of modifying our systems and taking advantage of our
international offices, so that we can begin providing 24/7 technical support. I was given a
specific goal, a beginning and an end date and a budget – this was clearly a project.

Project management can be summed up as answering few crucial questions:

 What problem are you solving?
 How are you going to solve this problem?
 What is your plan?
 How will you know when you’re done?
 How well did the project go?

Type of skills needed for a project manager:

 Technical skills – a quick goes into a project plan, how to build and fine-tune a project
schedule and how to measure progress;
 Business expertise – as a project manager it ups to you that your project delivers value;
you want to make sure that your project achieves the goal and objectives you’ve
indemnified during project panning; you also need to understand your business – what
it does and what it considers important;
 Interpersonal skills – projects typically use people from different groups, departments
and even organizations; you are the leader of these team, so it is your job to motivate
your people;
 Leadership – you must inspire your people – guide them to do the right things and
motivate them to do their best.

Project management can be categorized into 5 major processes to help guide project
successfully from beginning to end (classified by Project Management Institute):
 Initiating – getting a commitment to start a project; we answer question ‘what problem
are we solving’ and ‘how we are going to solve this problem’;
 Planning – we figure out how we are going to perform the project; we answer
questions ‘what is your plan’ and ‘how will you know when you’re done’
 Executing – starts with launching a project, you bring your resources on board and
explain the rules you will use to run the project.
 Monitoring & controlling – your ongoing responsibility to see if project is going
according to plan, and if it is not, you work out ways to get it back on track.
 Closing – you get the client to officially accept that the project is complete; you
document the project performance and get the lessons learned

2 common approaches top project management:

 Traditional project management (the waterfall approach) – each process occurs one
after another (after previous one is completed) – work well when the project is
relatively familiar, the goal and solution are easy to identify (i.e. clear goal &
solution), scope and deliverables are clear and you use familiar technology or tools.
 Because project is a known quantity, you can define it clearly, build a plan for
completing it; then you execute the project and perform the usual activities to make
sure that work is done and goal is achieved.
 With many projects today, you don’t know what the solution looks like, so you have to
figure it out as your goal along. Agile project management goes to iterations to get
closer to and eventually to reach a successful outcome. For example, you might know
the project goal, such as replacing the financial system, but your customer doesn’t
have these procedures and requirements documented in any way. In this case you can
iterate within the project management proces4s to get you closer to what you want. In
the initiating and planning processes you define the overall goal for the project and
build an overall plan to achieve that goal. With agile project management you also
define what you are trying to achieve with each iteration and develop a detailed plan
for the work in that iteration. The execution project is often easier in agile projects,
because it typically uses small teams of highly-skilled people, who work on the same
location. With agile project management you monitor & control the project more
closely, you communicate faster and more frequently. Finally, each iteration has its
own closing process for accepting its specific deliverables.

Initiating a project

The purpose of initiating process is to obtain a commitment to start a project. During the
initiating project you identify a problem the project is supposed to solve and you gather more
information to define the project. This information is presented and documented as a project
definition or a project summary. In many instances you, as a project manager, maybe assign
to the project after it’s been approved.

The problem statement clearly defines the problem you are attempting to solve, or opportunity
you are attempting to take advantage of. It doesn’t have to be long, if you spell out what the
problem is in one sentence, all the better.

Examples:
- Our company has 300 employees and needs another 100 people; the current office can
handle up to 320 people. Problem statement: we do not have enough space for all our
employees.
- We have new product that customers don’t know about, our sales have been declining.
Problem statement: we are losing sales to our competitors.

Defining a problem could be a challenge, because people often jump straight to solutions.
Solutions describe the end result of a project, not the beginning motivation. Foer example, end
results would be we need a new building, we need to increase sales. These are not problem
statements, but solitons. One way to backtrack from a proposed solution to the original
problem is to ask why – why do we need a new building; why do we need to increase sales.

Now after the problem has been defined, we need to describe what the project is supposed to
achieve. We do this by defining a project goal. The project goal is a high-level target that
states the end result that the project will achieve. The goal should be a simple statement and
easy for everyone to understand.

Example: host a corporate sales event.

Objectives further define the goal by flashing out specific details (smaller, detailed goals).
Identifying objectives is important, because they help define the scope, your approach and
success criteria you have to meet. Business objectives are often strategies or tactics that
support your organizations goals. For example, increase traffic at our website, reduce return
rates on orders. Financial objectives are all about money (increase sales by 10%, cut costs by
5%). Quality objective classify how good results must be (decrease returns by 20%, increase
cust.satisfaction to 70%). Project can have technical objectives (use equipment designed for
environment, use computers with downtime under 2%). Performance objectives (project
finishes by release date, use current company members, duplicate features from current
system).

Objectives principles:
- Specific – host an event that reaches 80% of customers and costs not more than
80,000;
- Measurable – increase average customer satisfaction on web survey to 4.5 out of 5.
- Realistic
- Time-related – release to manufacturing by November 1.

Once you know the goal and objectives for project, you are likely to find that there is more
than one possible strategy from which to choose. Good practice is to assemble a small group
of people familiar with the project to brainstorm strategies. The group should read the
problem statement, the goal as well as the objectives and the begin generating possible
strategies. This should be a free flow of ideas, the point is to get as many ideas as possible
before you start criticizing or evaluating the strategies.

Questions you need to ask:

- Is this strategy feasible?
- Are the risks of this strategy acceptable?
- Does this strategy fit the culture of the organization?
The goal, objectives and solution to a project identify what you are trying to achieve and a
general approach to getting there. Requirements provide the details of what the outcome must
look like. They are the specific needs of the project. Gathering requirements is important,
because if you miss true requirements the customer won’t be satisfied with the project. On the
other hand, if you include requirements that are not really necessary, the project will last
longer and probably cost more than it should.

Example: (corporate sales event) showcase new and existing products\

Requirements:
- including all the sales points that the sales team identifies in each presentation;
- use brand terminology;

People expect to get something when project is done – there results are called deliverables.
Deliverables are products or services that are delivered. Deliverables can be tangible or
intangible.

Once your projects get under way, deliverables then help you measure progress. Write down
what deliverables of your project are – begin with the end deliverables, which are goods or the
services that your project delivers at the end of the project (for example for a corporate sales
event end deliverable would be printing 1000 brochures to be handed out at the event). Next,
document your intermediate deliverables – these are the items or services that arte delivered
in the course of project (for example sign a contract with a printing company). Try to define
deliverables that can be accomplished in the time frame between the status reports, that way
you can evaluate progress based on the deliverables completed since the last report.

So, now that you’ve defined your deliverables, how do you know that deliverables you
receive are what you wanted – you need some way to measure them. Success criteria are
definition of success. Summary you are easy to figure out like sign vendor contracts, or obtain
certificate of occupancy of a building. Write success criteria that are clear and quantifiable.
For the sales event you might want to write criteria that indicate the number of customers you
will attend, the number of product that will be sold at the event.

It is important that you protect your project by identifying assumptions and risks early one.
Assumption is something that is believed to be true, but it is not confirmed. The risk is a
situation or event, with some probability of occurring, that might negatively affect your
project. Early on on the project spent some time identifying risks that could affect a problem,
mainly so the management team can make an educated decision about whether or not to invest
in project. Document assumptions and risks as you flash out what your project is about. That
way the customer or the management team can consider all the pros and cons of the project
before they decide whether to give approval and proceed with planning.

The project scope actually describes the boundaries of the project. That is – what is included
in the scope of project and what is not included in scope of project. A scope statement helps
you evaluate whether the project is doing what it should – no more and no less.

Example scope of corporate sales event:

 attend trade shows;
 use existing booth;
 produce sales materials;
 host party;
  set-up booth.

In this case the scope statement covers the work and deliverables, for which the team is
responsible. The scope statement can also include an out of scope section, which indicate the
work that is not the responsibility of the team. The scope statement also helps to prevent the
project from expanding. Scope creep is the well-known hazard in the project world.
Customers and team members might come up with these little things to add to the project, but
those little things add up and before you know it the scope has expanded beyond your budget,
beyond your resources and past the due date.

The term stakeholder means someone, who has a stake in the outcome of the project – this
includes the customer, the departments affected by the project and even the people who work
on project tasks. Major stakeholder roles in project management process:
 Project customer – a person or group, who has a problem to solve; project customer
brings 3 crucial things to the project – funds the project, influences project
(determining what the project will do), approves deliverables from start to finish;
 Project sponsor – sponsors are people who want to see the project succeeded and have
enough formal authority to help make that happen (they champion the project);
sponsor can help prioritize the objectives, talk to stakeholder who aren’t being
supportive, suggest improvement to the plan;
 Functional (line) manager – run departments and are accountable for achieving their
department’s goals; manage people in their departments;
 Team members – perform tasks;

After the project is defined, you need to get approval from stakeholders to proceed the
planning. Obtaining approval is important, because you need commitment form project
stakeholders to make the project a success. Once you have the initial project summary, you
might think of getting approval by mail and asking them to sign on the dotted line. I do not
recommend you doing this. The problem with this approach is that people don’t read through
the package, they might sign their names, but if they find something they disagree with later,
their commitment disappears and you are back where you started.

A face-to-face sign-off meeting is much more effective, the agenda for the meeting is
straightforward: 1- review the project summary in order to make sure that stakeholders agree
with it; 2 – obtain signatures. Signing a project summary is not like signing a legal document.

After the project is approved the final step of the project initiating process is writing a project
charter. Project managers don’t have that kind of authority that managers in a structured
organizations do. Project manager’s authority lasts as long as the project stays managed and
plies only to those project. For that reason, it is important team members to understand what
the project manager is authorized to do. The project charter is the vehicle for doing this.
Typically, the project sponsor publishes the project charter to formally announce the project
and to communicate the responsibility and authority you have as the assigned project
manager.

Items of typical project charter:

 Project name
 Project purpose (summary of goals & objectives)
 Project manager (name)
 Responsibilities of project manager
 Extent of project manager’s authority (requesting resources, signing contracts, etc.)
 Formal declaration regarding sponsor’s support on project (think as PoA given to the
PM by the sponsor or the customer)

When the project manager is ready to go, the project sponsor distributes it to everyone
affected by, or some way involved in project.

Planning a project

During the planning process you identify the work that must be done, who is going to do it,
how long will everything take, when things will happen and how much it will cost. You also
plan how will run the project – such as how will you communicate; manage, changing risk
and ensure quality. All of this information goes into documents that together represent the
project plan, you use the plan once the project gets started to: direct the people working on
your project, to keep track how the project is going, to correct course if needed and to
communicate the team members and management.

After you start planning your project, the first thing you do is identifying the work that needs
to be done. A work breakdown structure (WBS) is the tool you use for breaking down the
work into pieces, so you can plan, track and manage your project effectively.

Creating WBS helps the project in several ways – it is easier to estimate the work and cost, it
is easier to assign the work to team members, you build checkpoints into your project that
allows you to measure progress.
WBS contains 2 types of tasks:
 Summary tasks – the higher level tasks that summarize the project work in some way;
they can describe each process of the project

You can have many levels of summary tasks

 Work packages – lowest levels tasks that spell out the details of the work that needs to
be done.

How to define if the work is broken down to the right level?

 Time and cost are easy to estimate
 Status is easy to measure
 Task duration is shorter than your reporting period
 The detail is at the level you can and you want to manage

Now that you’ve built the WBS, you need to make sure that your team understands it. A short
name in the WBS typically is not enough tell people exactly what they are supposed to do. To
make sure your team knows what to do, create work package documents that describes the
work identified in the WBS in detail.
The level of detail you include in the work package document depends on things like how
familiar the work is and perhaps – the experience of the person assigned the task. For
example, a work package document might include a check list of things need to do, which
helps less experienced people to understand their assignment, but serves as a reminder for a
more experienced individual. You don’t need to include every piece of detail in the work
package document. If the specifics of the work are described somewhere else, you can refer to
other document that contains the information.

A work package document does more than describe the work. It also identifies how you know
that task is complete and whether it was completed correctly. For some tasks you may include
the corresponding deliverable and success criteria in the work package document. Otherwise,
write up a description of what you will have when the task is complete and what it should
look like.

Finally, you’ve probably figured out that you, the project manager, don’t know enough about
every aspect of the work to produce this detailed description for every task. Turn to people,
who helped you to build the WBS to help fill in the details. If you get the details right, your
team is more likely to know exactly what to do.

The WBS identifies the work people have to do to complete the project, but doesn’t tell you
how long the work will take or when it can be performed. To do that you need to turn your list
of tasks into a schedule.
 1) Put the tasks into the right sequential order – you have to classify which tasks have to
finish before other tasks can start, which tasks state or finish at the same time and so
on. To get tasks into order you specify the dependencies, also called links between
your tasks in the project. The most common is finish-to-start, but you can choose from
several types of dependencies.
2) Estimate the time each task will take – you need to estimate as accurately as you can,
because underestimating and overestimating both lead the project problems.
3) Identify the people in your project team and assign them to tasks

As a project manager, you should understand each person’s role and responsibility on a
project. Likewise, your team members should understand their own personal role and
responsibilities within that project.

First, create a responsibility matrix. Responsibility matrix spells out who can make or approve
decisions, the group’s performing work and which group need to be consulted or informed
about what is going on.

The responsibility matrix includes four different categories of responsibility:

 R – means group is responsible for performing work;
 I – represents “informed”; group needs to be informed; group gets information;
 C – consult as group about (before a) decision; however, they are not accountable for
the decision that is made;
 A – group makes or approves decision and delegates work; group is accountable for
decisions and delegations

Next, create a project organization chart, which shows the hierarchy and reporting structure
for people involved with or working on the project. Your project organization chart identifies
the chain of command, so you know who to talk to if you need to escalate a request or
decision.
Finally, identify the type and number of skilled team members that project requires. Skill
matrix is the tool you use to determine these requirements. To build a skill matrix, first
examine your work packages and identify the skills that each packages requires. Second,
create a matrix with your project tasks in rows and skills you need in columns.
As a project manager, you estimate the project cost by calculating the cost to complete all the
work. In some cases, you present that budget to management and they decide whether the
project makes financial sense. In many instances, however, you receive a target cost from the
management team, then it is your responsibility to figure out how to plan the project to stay
within that budget.

Types of costs in a project:

 Labor cost;
 Time-based cost (rental equipment, office space rent, etc.)
 Material cost (paper, toner, etc.);
 Ancillary costs (travel, training, registration fees, etc.)

Money is almost always a consideration with projects – you might need to know only if
whether the price tag is within your budget, or you might have to show that project delivers
the financial benefits your organizations expects.
Every project faces risks. If you don’t plan how you’ll deal with them, you end up putting out
fires, which can cost your project time and money and increase the pressure on your people.
The risk management plan is the tool you use to plan for the risks you might encounter. With
the risk management plan in place, you have already decided how to respond when a risks
becomes reality, so you are ready to make informed decisions.
To build the risk management plan, first identify the risks your project faces. Risks you are
aware of are called known unknowns (risks that can be predicted) – cancelled flights;
cancelled shipments; technology might not work in the way it is supposed to be, costs more
than you expect; team member, located in different areas can increase risk, such as delays,
due to time zone differences, miscommunication due to different languages, or cultural
differences; lack of detail, such as specific on the deliverables, deliverables, due dates, or how
will work on your project; limited options, such as needing people with rare skills increase
risk, because you don’t have alternatives if a problem arises.

Fill out a risk information form with what you know of each risk you identify, document
specifics about the risk, for example which tasks are affected, what objectives are endangered,
what the consequences are and so on.

Unknown unknowns (unpredictable risks) – for example, prior to the invention of personal
computer, manufacturers of typewriters probably didn’t foresee the risk to their business;
because you can’t identify those risks you handle them by setting aside a contingency funds
for dealing with them (like having a insurance policy). Contingency funds are commonly used
method for responding to small risks and the unknown unknown risks you can’t foresee, the
question is how much you should set aside. Many companies use a percentage of the project
budget, but the percentage used is typically based on past experience.

After you identify risks, the next step is to assess each risk you’ve identified. To assess risks
you ask 2 questions:
 What is the likelihood that risk will occur;
 How big is the impact if the risk does occur;

After you’ve assessed all risks, the next step is to prioritize the risks and decide which
ones you will manage.
The next step in the risk management plan is to decide how you will respond to each risk in
your plan. The easiest option is simply to accept the consequences (that’s fine for risks with
low probability and impact). Another option for less significant risks is to use contingency
funds to address the issue. Avoiding risk is another option, for instance, changing the project
scope to remove risky part of the project, or fly the sales team out 2 days early. Mitigating
risk means taking steps to reduce consequences, for example, you can ship backup computers
to the trade show in case some of them doesn’t work. Transferring risk simply means handing
off the risk to someone else, like you do when you purchase insurance.

The final step in the risk management plan is defining how you will monitor risks and
measure responses. You create a risk log with information about each risk you plan to
manage. This log summarizes your plan for the risk – the description of the risk, the events or
circumstances that trigger the risk, the response you’ve chosen, who will monitor the risk and
the result you expect from the response, if you use it.

You create the risk management plan during the planning process, then you implement that
plan once the project is under way.

Good communication is crucial to the success of a project. If your project is large and
complex with people working around the globe, good communication is even more important.
During planning you put together a communication plan that helps you get the right
information to the right people in the most effective way.

First, identify your audiences – the responsibility matrix is a good place to look. Second,
identify what your audience needs and wants to know:
 Management stakeholders

 Sponsor is more tightly connected with the project, so you will probably
communicate with the sponsor more often

 Functional managers – when are on assignment, these managers want to know

whether the assignments are going according to plan and how long the people are
going to be on assignment
  Team members – need to know what they are supposed to do and ideally, how this
fits into the big picture

When you plan a project, you also have to consider the quality stakeholders want from
the project deliverables or final product. You develop a quality plan in order to help your
project meet that quality standard. For a project, quality translates to meeting the
customer’s requirements and delivering on time and within budget. If your project
includes deliverables (a products) quality also means those products or deliverables
conform to these specifications.

The quality management plan is made of 3 processes:

 Identify the quality standards for deliverables

Obviously you don’t want quality that is below the standard (unhappy customer, customer
might ask for additional work, might refuse to pay). However, you don’t want quality that is
higher than required either (other aspect of the project can suffer – schedule lengthening or
costs expanding)
 Define a quality assurance plan – document how you will demonstrate that the
quality standards have been met

 Define a quality control process – how you will monitor and measure the quality of
your results (inspection, peer review, walkthrough, audit)

Continuous improvement is big part of quality management – if you find quality issues, you
also analyze the problems to see how to prevent them or at least reduce their frequency. For
example, cost & effect diagrams (also called fishbone diagrams) help identify factors that
could lead problems, which intern helps you figure out ways to prevent the problems.
Another tool is the Parretto Diagram, which shows how many defects are generated by each
cause, the diagram lists the causes by # of defect they generate, so you address the causes that
generate the most defects first.

One at the time, request for changes can seem small, but those small changes add up and can
completely derail your project schedule or budget. Changes are unavoidable, so the only
solution is to manage them. First, you want to know the items you want to control, such as the
project scope, requirements, or the entire project plan. The versions you control are called
baseline documents. For example, if you have an approved list of requirements, that’s your
baseline. If new requirements are suggested, you can use your change management process to
decide whether or not to add them to the project plan. Keep in mind, you don’t use change
management on draft version of the documents, /change management process is for approved
documents/. When stakeholders sign off on them, that’s when they’ve gone under change
management. Next, you need a group that reviews the change requests and decides whether to
approve them. This group is called the change review board and it is usually made up of key
stakeholders, such as the customer, functional managers and team leaders. Then you need to
define a change management process to use when someone requests a change. Typically, the
change request form includes details regarding the request of change, the reason for the
change, the business justification and the results it should produce. In the second step the
change review board reviews submitted change requests.

If the board accepts the request, it moves to the evaluation step. In this step someone has to
evaluate the impact of the change. The evaluator looks at different ways to handle the request
and determines the impact of each alternative. The result of the evaluation is the change
request impact statement, which outlines the alternatives and their impact, and might include a
recommendation for how to proceed.

The forth step is when the impact statement comes back to the review board – if the board
approves the impact statement, you add the request to the project plan. Whether the decision
is yes or no, be sure to notify the person, who requested the change. If necessary, you perform
a fit step, in which you update the baseline documents – project schedule, etc.

Finally, you trach if change requests are part of your process – you can use a change request
log to record the status of submitted change requests.
You don’t have to send every change requests through the change request through the change
management process. I recommend you set a threshold, so team leaders decide what to do
with smaller requests. Finally, it is also a good idea to create a process for emergency
changes, that need a rapid decision, between meetings of the change review board.

Building a project schedule

Estimating time and money accurately is important, because those estimates affect your
project schedule and budget, which can determine whether it makes sense to run the project. If
your estimates are low, a project may get approved, when other project would deliver better
result, in addition low estimates make meeting expectations almost impossible. If your
estimate is too high, a worthwhile project may be rejected, or the project could take longer or
cost more.

Estimating accurately is challenging, because estimates are nothing more than educated
guesses. There are 2 things that you estimate in projects – time and cost. For time, you need to
estimate hours of work, because labor cost is based on the amount of time people work. In
addition, other time-based resources affect your cost, such as how long you rent your
equipment, or lease office space. Second, you estimate costs that are not time-bases, like
martials you need or travel required.

When possible, base your estimates on the results from similar projects that are complete. If
that is not possible, there are several techniques you can use for estimating.
1) Parametric models – you calculate work and cost based on some measure.
Disadvantage is that you can only build a parametric model if you have many similar
projects in your database.

2) Program evaluation and review technique (abbreviated to PER) uses the best,
worst and most likely result – it is a good approach is your project is unfamiliar, of has
a lot of uncertainty. Estimate those things like what can go wrong or right with tasks
helps you produce better estimates.
 3) Delphi technique – count a several heads being better than one. First, you ask several
experts to produce estimates independent of one another. You then share the results
with the group keeping the estimate anonymous. You keep them anonymous as you
don’t want anyone to be influenced by the reputation or authority of the co-expert.
You then ask each expert to estimate again. Repeat this step a few more times and then
use the average of the las round as your final estimated value.

You can estimate from the top down or the bottom up. Top down estimating is effective for
large projects or early rough estimates – you estimate phases or major components and then
break these estimates into smaller pieces.

Estimating from the bottom up means you estimate each task and you add them up until you
have the estimate for the entire project.

For large or complex projects add time for complexity – communication, interaction, travel,
management, etc. There is no good rule of thumb how much to add, so you have to base your
increases on experience. On the other hand, watch out people adding time to their estimates as
a safety margin. The best way to prevent this issue is to set aside a time and money than
everyone can share - contingency funds and contingency time. Contingency funds can be
used is a task needs more people to finish on time, for example.

A key part of building a schedule is getting tasks into right order. The task dependency is
when one task controls the timing of another task. Because each task has start and finish, there
are 4 types of task dependencies:
 Finish-to start – they are most common; the finish of one task controls when the
next task starts.
 Start-to-start – the start of one task triggers the start of another.
  Finish-to-finish – the finish of one task controls the finish of another

 Start-to-finish – don’t occur very often. Start of one task triggers the finish of
another (the task in control occurs after the one it controls).

By understanding the duration between work, duration and units, you can assign people to
work on tasks to get the schedule the way you want.

Work, also called effort, is the number of hours or days someone works on a task. Duration is
the length of time between when the task starts and when it ends.

The term for percentage of time a person spends is often called units. In a project world units
are based on a typical workday – 8 hours in a lot of cases. So, if someone works 8 hours a
day, units are 100%.
Some tasks cannot be shortened by adding workers – for example meetings – a one-day
meeting is one day, no matter if 3 people attend of 10.

Because of the duration between duration, work and units you can assign people in different
ways to make the schedule do what you want.

The critical path is the sequence of tasks in your schedule with the longest duration. The
critical path is important, because any delay on that path delays the finish date of the project.
Tasks are critical if they have no slack. Critical tasks have no leeway to move without
affecting the schedule.

Conversely, if a task has slag, it can start latter without delaying task that come after it.
Stakeholders often ask you to deliver project earlier than the first finish date you calculate.
There are 2 techniques for reducing the time schedule:
 Fast-tracking – you overlap tasks that should come one after another (whit finish-to-
start dependency).

The best tasks to fast-track are the tasks on the critical path – that’s because you
shorten the project schedule by shortening the critical path. The disadvantage is that
fast-tracking increases risk
 Crashing – increases the cost of your project, because you spend additional money
to shorten the schedule. Usually the increased cost is for additional you put on your
tasks. Apply crashing to tasks on the critical path, you don’t want spending money on
shortening tasks that don’t shorten your overall schedule. The key to successful
crashing is finding the alternative that shortens the schedule up to the amount you
need for the least amount of money. A crash table makes it easy to see which tasks
you should crash.

The crash table includes how much it costs to crash each task on the critical path and
the duration you will eliminate by crashing them. Crash the tasks with lower crash cost
per week. If the tasks have same crash cost per week, crash the longer tasks first. In
some point, adding new people won’t shorten the duration – people start interfering
with one another, new people are often less productive and may slow down the
existing team members, who have to help them the get oriented.

Once the customer and stakeholders approve the project plan it is time to save your
project baseline. A baseline is a collection of your approved documents, budget and
schedule. The baseline is important, because you compare your progress to the
baseline to see how the project is doing. Everything that you include in the plan
baseline goes under your change control process, so that any changes to the baseline
show up as change requests.
Running a project
The project execution process is like launching a boat – the project finally gets under way.
The executing process starts with lining up the people and other resources you need to
perform the project. Once you get team members on board, you help them get familiar with
their assignments and the overall project environment. You also set-up a place to store project
information and save a baseline of your plan that will use to compare with actual
performance. Monitoring represents collecting information about where the project stands.
Since projects never stick to the plans you’ve so carefully prepared, you have to figure out
how to respond to the changes, crisis and problems that arise. Controlling is when you
implement cross corrections to get your project back on track.

The executing process starts whet the project plan has been approved and project work can
finally begin. The first step in the executing process is usually procurement. You might work
with a core team for the initiating and planning processes, but executing is when you bring on
the rest of the team, acquire equipment and materials the project requires. The project sponsor
and customer describe the mission and get everyone motivated. You can review the project
plan with team and explain how the things will work, such as how to communicate, or how
change requests will be handled. During executing you also designate a depositary for
information, generating while you are running the project. Although it is usually electronic,
this depositary is called the project notebook.

Developing your project team into a finely tuned machine is important. Bruce Tuckman
(1965) – development sequence in small groups (typical phases that teams go through):
 Forming – the individuals are just starting to form a team, they are not yet sure of
their goal as a team and they don’t know who goes what. During the forming stage
you have to define team goals clearly, define responsibilities; teams in the forming
stage tend to resist and challenge authority, so be prepared to answer their questions
and earn their respect;
 Storming – as team members start to wore out the relationships with each other,
power struggles often occur. Storming teams have difficulties in making decisions
because of disagreements. At the same time these disagreements lead to
communication, which helps members grow as a team. When a team is storming, you
have to help the team members stay focused on the goals and guide them to make the
decisions.
 Norming
 Performing

Methods to use for strengthen your working relationships and motivate team members:
 Communicate roles and responsibilities clearly;
 Give specific and achievable goals;
 Provide support and help remove obstacles;
 Respect your people;
 Provide feedback quickly;
 Consistently tell the truth;
 Communicate regularly – status and “lessons learned” meetings are to find out what
people are doing and how well they are doing it;
 Handle people problems quickly;
It is important to be up front while at the same time being respectful.
Earned value analysis evaluates how much of project was earned based on work that is was
completed. In other words, project earns value by completing work.
Basic project measures can be deceiving:

Earned value analysis can uncover problems – it presents your schedule and budget in
monetary terms. It is based on 3 measures: planned value (estimated budget to complete work
by status date), earned value (the amount of money you’ve earned by completing work),
actual cost (true cost of the completed work).
Communication isn’t just telling someone something, it is about getting your message across,
so the other people understands it and often – does something with it. Taylor your message to
your audience. Be positive and proactive. A good email is like a newspaper article – it
presents key information in the initial paragraphs.

Closing a project
The most important part of the closing process is getting the customer to agree that the project
completed successfully (obtain acceptance). You need to document the lessons learned during
the process. You produce final documentation and a closeout report for the project.

Lessons learned:
 Schedule time for regular “lessons learned” session – don’t wait until the end of the
project to ask about lessons learned, by then your team members have probably
forgotten a lot of them. Set aside a time in the agenda of your status meetings to ask
about lessons learned, or schedule dedicated meetings for the topic every few weeks.
 Keep “lessons learned” session positive and productive – start with what went right,
ask each member about a typo technique that helped them in work, such as: What
saved you the most time?; What was the difficult challenge you solved and how did
you do it?; the progress to lessons from the problems people faced – pose questions
regarding problems people faced, post questions about problems in a positive way,
for example, How can we make the sales presentation more compelling?, What
would you do differently next time? Ask team members to talk about themselves –
 that way it is easier to prevent people blaming others. Try scheduling meeting
without managers to see if the people will share information more freely. Consider
including an anonymous method for submitting the lessons learned, such as a
suggestion box –this approach can be helpful for sensitive issues, or when people are
afraid to admit mistakes for fear of losing their job.
 Document the lesson learned

Part of the closing process is creating a close-out report, which is like a final status report.
Close-out report is important, because it sums up the project in a concise, informative
document – what the project did, how it did it and how well it went. The first item in a close
out report is the bottom line – was the project a success – summarize the quantitative results
you achieved, include the final cost of the complete project. Depending on the stakeholders,
you might include cost for major portions of the project, cost variances, ROI and other
financial measures. Document the delivery dates and key milestones – if the project was
significantly early or late – include the variance and the reasons. Summarize any significant
changes – for example, if the project didn’t deliver everything in the scope statement, include
the scope that was and was not delivered. Consider including information that you want to
share with others – lessons learned, significant risks and how you’ve handled them. Finally,
end with a section about the effectiveness of your project management practices – similar to
lessons learned you can describe what worked well and how would you plan and manage
differently in future, that way other project can benefit from your experience.

Successful Project Management: Applying best practices and real-world techniques with
Microsoft Project – Bonnie Biafore (Book)

Project Planning, scheduling and control – James P. Lewis (Book)

Making Things Happen – Scott Berkun

www.pmi.org
www.prince2.com