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 Jenkin's 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 Jenkin's 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 over-promised!

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.