Project Management Fundamentals

The following discussion about project management has been pulled together from various
sources including books, courses, presentations, and my own experiences. This is by no
means intended to be a complete treatment of the subject of project management. Nor is
it going to make you a project management professional. Instead, use it as an introduction
to this discipline perhaps while assessing whether it would be of interest for you to pursue
as a career.

What is a Project?
A project is a unique venture with specific start and end dates. This is different from an
ongoing task that doesn't have an end date. Projects are run by people and often involve
different parts of an organization. Constraints on project include cost, schedule, resources,
and quality. There's a give and taken between these items i.e. you can't have it all. Usually
projects are divisible in to stages or phases each with their own set of priorities and goals.

What is Project Management?

Project management is a combination of techniques, procedures, people, and systems
focused on the successful completion of a project. It is also a discipline that will support
the planning, implementation, tracking, and control of projects

What is a Program?
A group of related projects are called a program. They may have mutual dependencies that
may be complex. The key to their success is that they be managed in a coordinated
manner.

Typical Project Phases

There are many methodologies for running projects. Typically, they consist of the following
high-level phases:

Define the project

Plan the project

Get approval to proceed

Implement the project plan

Evaluate the project

Understanding and Managing Project Politics

Projects are rife with politics. Understandably so as everyone is jockeying to achieve the
goals they deem the most important. Managing these politics is an essential task for the
project manager and team members. It also falls to the project management to help
others navigate the political waters. Key to managing the politics is keeping people
informed. The bigger the project, the more time it will take to communicate with interested
parties.

Balancing Priorities
A project will consist of a set of priorities. These priorities can be classified in to what must
be achieved, what should be achieved if possible, and what would follow from the previous

choices. What's not so obvious sometimes is that the priorities of various stakeholders will
vary and they will vary over time. It is the project manager's job to manage the inevitable
conflict that arises from this situation.

Project Scope
The objective of this step is to define and agree on results that the customer expects.
There are project success criteria and personal success criteria to consider.
It is best to use various methods to understand what is really being asked for. This means
using words, pictures, graphics, and one-on-one discussions. Graphs, mock-ups, and
prototypes will also help. Consider using brainstorming sessions to get the ball rolling.
Formal methods and documentation help this process, but it's important to aim for clarity
and not just length. This step is also the start of the requirements capture process. Ideally,
the project team is involved as much as possible as it will help build their understanding.

Project Feasibility
The feasibility of the project should be assessed before the project proceeds. Consider
whether the project is technically feasible, has organizational support, and has the financial
backing to be completed. A business case can help with the feasibility analysis and should
at a minimum include a cost/benefit analysis. For some large projects, the feasibility study
could be a project in itself. The end result is a clear reason to proceed with a project or to
shelve it.

Project Risks
Risk management should start as early as possible. The goal is to identify and record the
major issues that may affect the project including uncertainties and assumptions. As the
project progresses, the list of risks should be reviewed to ensure it remains
comprehensive. Some items will disappear while others will need to be added.
The project objectives are a critical reference for the project. They act as the definition of
success for the project manager and the goals for the people involved in the project. This
document also serves to summarize the contract with the customer and therefore can be
used with the change control process to address new requests. The objectives document
should contain the project goal statement and a list of project deliverables.
A face-to-face meeting with stakeholders is a good way to build the objectives document.
During this meeting, the project manager should ensure that everyone's view is being
heard and that everyone is participating. After the meeting, craft the objectives document
and distribute for sign-off.

Project Goal Statement

This is a short statement (around 50 words or less) that accurately reflects what the
project is setting out to do. It also outlines the conditions in which it is being done and
defines constraints of the project. This statement should not get in to details of
implementation. It should just cover what is going to be implemented and when.

Defining Project Deliverables

Deliverables are always tangible and measurable. They are the things that external project
stakeholders are going to receive when the project is complete or at the completion of
each phase in the project. These deliverables can be equipment, completion of a report,
installation of new hardware, etc.
Before implementation work on a project can begin, it is necessary to define project tasks.
The most common way to do this is through a work breakdown structure (WBS). Other
methods include the Product Breakdown Structure, Organization Breakdown Structure, and
the Cost Breakdown Structure. Regardless of the process used, the idea is to break large
projects in to many smaller components. These smaller components should be small
enough such that accurate estimates and costs can be determined. Aim for the amount of
time per component to be around 40 hours for a person or group. Anything bigger and
there's a good change the item can be broken down further. However, the ordering
shouldn't be determined at this point.
Good estimates are necessary for the success of a project. They can help with obtaining
approval to start or continue a project. They're also useful for setting priorities based on
expected ROI. There is no one-size-fits-all approach to estimates. A lot will depend on
where the make up of the project team and the project itself. Exploratory projects are
going to be much harder to estimate for than a project that has been done several times
before. The most important thing is to try and provide estimates as the act of doing do can
help with everyone's understanding of the requirements.
Some other things to keep in mind include:

Do not accept poor quality estimates. Try to get the person who will actually do the
work also provide the estimate.

Provide enough time to come up with estimates i.e. give people enough time to
think.

Don't haggle over estimates.

Provide estimates using a range, but avoid the temptation to arbitrarily pad
estimates. If clients detect this tactic, it will result in ill-will.

If an estimate seems particularly fuzzy, consider breaking the task down further so
that it it's components are easier to understand.

Make it clear that estimates will be noted and compared to when the project
completes. This is part of the ongoing project management improvement process.

A well-informed team will provide better estimates.

Don't forget to take in to account different skill levels of different team members.
Junior team members will likely be slower than senior team members.
Once the project tasks have been identified and the time required for each estimated, it is
necessary to create a schedule and determine the sequence of events. The key to
sequencing is looking at all the tasks and figuring out dependencies. Those that are
dependent on others will need to be done in sequence. When a task has no dependencies it
can be worked on in parallel assuming there are sufficient resources.
Once the sequence has been figured out, the critical path, the longest sequence of time

through a network of tasks, will become apparent. This path will then form the basis of the
project schedule since, by definition, the project can't be completed in less time than what
the critical path requires. By laying out the tasks end-to-end on a timeline, you will, in
effect, create a Gantt chart, which is the most common project planning chart. In large
projects, there may be too many tasks to plot so they should be grouped together to ease
the work.
It's part of the project manager's job to try and find the best fit between a task and a
resource. The better the match, the more likely the estimate will turn out to be accurate.
In an ideal world resources are available whenever you want them. In reality, resources
are often coming from a shared pool. This is one of the first things that can impact a
schedule right.
Once work has begun, it is important to review the resource issue regularly. You want to
detect as soon as possible. You want to determine if there are problems so that you can
request more resources or, in some rare cases, release resources because there isn't as
much work as expected. There are many tools that can be used to level resources, but
don't aim for perfection. Instead, aim for good enough and focus on getting the project
done.
Other things to consider when building and managing a team include:

Trust Be Open and Honest

Projects, like offices, can often be secretive places with various levels of disclosure due to
commercial or political pressures. However the project grapevine works just as fast as the
office kind and you can be assured that if you are keeping someone in the dark or
deceiving them, you will be on the short end of office gossip faster than you can say
"voluntary redundancy".
Be as open and honest with your team mates as you can. Answer their questions directly
and act as a conduit of information for them, not a barrier. If you feel you cannot divulge
something, say so. Your team will appreciate your honestly and reciprocate by relaying
information and producing honest and accurate estimates for you.

Equality Be Fair and Even Handed

One of the maxims I have lived with as a manager is "individuals can succeed but only the
team can fail". Essentially this means that in public you should dish out credit wherever it
is due but never criticism. Being criticized in public, in front of your peers, is not a
motivating force for anyone.
If there is a project issue that needs to be addressed you can normally broach it as a
subject for the whole team to address. By sharing the burden for issues, most teams pull
together to solve the problem. By landing it on the shoulders of one or more individuals
you often split the team and cause conflict. Open discussion of the problem will encourage
the team to take ownership for the problem and solve it themselves.

Loyalty Protect Your Team

You will have a split responsibility - on the one hand you have a duty to your client to see
the project succeeds - on the other you have a responsibility to represent your team and
to support each other. Usually these two aims should be neatly aligned but not always!
In a situation where you have to choose between the two you need to take the difficult
moral stance. Don't air your dirty laundry with the client. Discuss the situation with your
team mates and come up with a solution, present this to the client instead.

Learn to Delegate
The joke in armed forces often runs that the only order an officer ever need issue is "Carry
on Sergeant Major!" Officers are expected to lead and leave the actual getting of things
done to those more suited to the task, the troops. If you are dividing up work make sure
you delegate properly.
Proper delegation entails laying out the task so someone understand its, so that it has
reasonable and achievable goals and so that you give them all the support they require to
get the job done.
It also entails giving them enough room to get the task done on their own. If you leave the
execution of tasks to them they will, in return, leave you alone to get on with your job. If
you spend you time looking over their shoulders it will only annoy them and waste your
valuable time.
Note: Much of the above was taken from Nick Jenkins' A Primer for Project Management.
This primer was released under the creative commons license and as such the above
content is also subject to the licensing terms of the creative commons license.
During the life of a project, it is the project manager's responsibility to track and control
the progress.

Tracking
In the area of tracking, the project manager should make sure that the process isn't too
involved so as to slow down progress. At the same time, it should be effective enough to
identify issues early. It's also important to track only things that are actually important to
the success of the project. A lot of people fall in to the trap of tracking nice-to-know things
rather than need-to-know things. One commonly used tracking item is the idea of a
milestone. A milestone marks the completion of some set of tasks that are significant in
some way. Often, milestones mark good points in which to review progress with upper
management.
Be wary of the tendency to mark tasks as xx % complete. Such information may seem
useful, but more often than not the percentages are wrong. People have a tendency to be
optimistic about their progress which results in the % complete reported being much
higher than it really is. So a developer say, will spend as much time getting from 90% to
100% as it did to get from 0% to 90%.

Control

Change is inevitable with projects. Some advocate that change requests should not be
accepted once a project has started, but that's not a particularly useful way to operate.
Instead, it is better to listen to change requests and identify the impact on the project. If a
change request is going to add costs to the project, it should be noted. If a change is going
to force the schedule to expand, it should be noted. These items should then be reported
to the project stakeholders with the goal of getting approval to proceed with the change
request despite the impacts. In this way, the project manager controls the change without
derailing the project.
Project managers sometimes feel that they should be trusted to get the job done and
therefore status reports are just a waste of time. That line of thought misses the point of
status reports which is simply to keep people in the loop so that they don't need to make
assumptions about progress. The reports also keep the project up front and center in the
minds of those that are impacted by it.
Status reports can take many forms. The most effective ones seem to be short and to the
point. They list new or important items first. Issues, for instance, could be placed at the
top to ensure that the most number of people see them. Closed items could be put at the
end of the report since no further action is needed.
Sometimes the requests for status reports seem unreasonable. Perhaps they're requested
more frequently than you think is necessary or that different people get different reports.
In such cases, it is best to delicately question the underlying need of the request to find
out if there is perhaps a better communication vehicle. What you don't want to end up
doing is spending all of your time creating and distributing status reports.
Projects of significant size are rarely problem free. The project closure step is the time to
reflect on the bumps along the way so that they can be avoided in future projects. The
trick here is remembering what went wrong and correctly identifying why it went wrong
without letting the exercise degenerate in to a finger-pointing session.
Some ways to keep the meeting(s) productive include:

Keeping the number of people in the meeting small. Have a meeting for different
groups so that the atmosphere remains friendly and so that everyone has a chance to
contribute.

Wait for little time to pass after the deliverables have been completed. Give people
a chance to wind down.

Go in to the meeting with some thoughts of your own to get the discussion started.
Be sure to point out your own missteps.

When documenting the comments from the project team, reassure people that
their comments will be anonymous.

Include all stakeholders to get the full range of perspectives.

And once the project has been closed, consider a celebration to acknowledge everyone's
efforts.
The following are 10 axioms that I think you should keep in mind as your pursue your

project management goals. These were taken from Nick Jenkins' A Project Management
Primer. Nick's primer was released under the creative commons license which means that
this page is also subject to the licensing conditions of the creative commons license.

Know your goal

It sounds obvious but if you don't have an end-point in mind, you'll never get there. You
must be able to clearly state the goal of your project so that anyone can understand it. If
you can't adequately describe your goal in a single sentence then your chances of
achieving it are pretty slim.

Know Your Team

Your team is the most important resource you have available and their enthusiastic
contribution will make or break your project. Look after them and make sure the team
operates as a unit and not as a collection of individuals. Communications are vital! Invest
time in promoting trust and ensuring that everyone knows what they have to contribute to
the bigger picture. Dish out reward as well as criticism, provide superior working conditions
and lead by example.

Know Your Stakeholders

Spend time with your stakeholders. Stakeholders will either contribute expert knowledge
to the project or will offer their political or commercial endorsement which will be essential
to success. Shake hands and kiss babies as necessary and grease the wheels of the
bureaucratic machine so that your project has the smoothest ride possible.

Spend Time on Planning and Design

A big mistake traditionally committed on projects is to leap before you're are ready. When
you're under pressure to deliver, the temptation is to 'get the ball rolling'. The ball
however, is big and heavy and it's very, very difficult to change its direction once it gets
moving. You need to spend time deciding exactly how you're going to solve your problem
in the most efficient and elegant way.

Promise Low and Deliver High

Try and deliver happy surprises and not unpleasant ones. By promising low (understating
your goals) and delivering high (delivering more than your promised) you :

Build confidence in yourself, the project and the team

Buy yourself contingency in the event that things go wrong

Generate a positive and receptive atmosphere

Consider this : if you finish early everyone will be happy; if something goes wrong you
might still finish on time and everyone will still be happy; if things goes really badly you
might still not deliver what you anticipated but it will still be better than if you overpromised!

Iterate! Increment! Evolve!

Most problems worth solving are too big to swallow in one lump. Any serious project will
require some kind of decomposition of the problem in order to solve it. This works but only

with close attention to how each piece is analyzed and resolved and how the whole fits
together. Without a systematic approach you end up with a hundred different solutions
instead of one big one.

Stay on Track
Presumably you have an end goal in mind. Maybe it's your job, maybe your business
depends upon it or maybe you're going to revolutionize the world with the next Google,
the next World Wide Web or the next Siebel/SAP/Oracle.
If this is the case you need to work methodically towards a goal and provide leadership
(make decisions). This applies whether you're a senior project manager running a team of
20 or you're a lone web developer. You need to learn to use tools like schedules and
budgets to keep on track.

Manage Change
We live in a changing world. As your project progresses the temptation to deviate from the
plan will become irresistible. Stakeholders will come up with new and 'interesting' ideas,
your team will bolt down all kinds of rat holes and your original goal will have all the
permanence of a snowflake in quicksand. Scope creep or drift is a major source of project
failure and you need to manage or control changes if you want to succeed.
This doesn't imply that there should be single, immutable plan which is written down and
all other ideas must be stifled. You need to build a flexible approach that allows you to
accommodate changes as they arise. It's a happy medium you're striving for - if you are
too flexible your project will meander like a horse without a rider and if you are too rigid
your project will shatter like a pane of glass the first time a stakeholder tosses you a new
requirement.
The best way to handle this is to have a plan, to update it regularly and make sure
everyone is following it and pointing in the same direction.

Test Early, Test Often

Project usually involve creative disciplines loaded with assumptions and mistakes. The only
way to eliminate errors is through testing. Sure you can do a lot of valuable work to
prevent these mistakes being introduced, but to err is human and some of those errors will
make it into your finished product code. Testing is the only way to find and eliminate
errors.

Keep an Open Mind!

Be flexible! The essential outcome is delivery of the finished project to a customer who is
satisfied with the result. Any means necessary can be used to achieve this and every rule
listed above can be broken in the right circumstances, for the right reasons.
Don't get locked into an ideology if the circumstances dictate otherwise.
Don't get blinded by methodology.
Focus on delivering the project and use all the tools and people available to you. Keep an
eye on the schedule and adjust your expectations and your plan to suit the conditions.

Deliver the finished product, promote its use, celebrate your success and then move on to
the next project.