Project Planning A Step by Step Guide

By Duncan Haughey

The key to a successful project is in the planning. Creating a project plan is the first thing you should do when undertaking any kind of project.

Often project planning is ignored in favour of getting on with the work. However, many people fail to realise the value of a project plan in saving time, money and many problems.

This article looks at a simple practical approach to project planning. On completion of this guide you should have a sound project planning approach that you can use for future projects.

Step 1 Project Goals

A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody directly or indirectly impacted by the project.

As a first step it is important to identify the stakeholders in your project. It is not always easy to identify the stakeholders of a project, particularly those impacted indirectly. Examples of stakeholders are:

• The project sponsor
• The customer who receives the deliverables
• The users of the project outputs
• The project manager and project team

Once you understand who the stakeholders are, the next step is to establish their needs. The best way to do this is by conducting stakeholder interviews. Take time during the interviews to draw out the true needs that create real benefits. Often stakeholders will talk about needs that aren't relevant and don't deliver benefits. These can be recorded and set as a low priority.

The next step once you have conducted all the interviews and have a comprehensive list of needs is to prioritise them. From the prioritised list create a set of goals that can be easily measured. A technique for doing this is to review them against the SMART principle. This way it will be easy to know when a goal has been achieved.

Once you have established a clear set of goals they should be recorded in the project plan. It can be useful to also include the needs and expectations of your stakeholders.

This is the most difficult part of the planning process completed. It's time to move on and look at the project deliverables.

Step 2 Project Deliverables

Using the goals you have defined in step 1, create a list of things the project needs to deliver in order to meet those goals. Specify when and how each item must be delivered.

Add the deliverables to the project plan with an estimated delivery date. More accurate delivery dates will be established during the scheduling phase, which is next.

Step 3 Project Schedule

Create a list of tasks that need to be carried out for each deliverable identified in step 2. For each task identify the following:

• The amount of effort (hours or days) required to complete the task
• The resource who will carryout the task

Once you have established the amount of effort for each task, you can workout the effort required for each deliverable and an accurate delivery date. Update your deliverables section with the more accurate delivery dates.

At this point in the planning you could choose to use a software package such as Microsoft Project to create your project schedule. Alternatively use one of the many free templates available. Input all of the deliverables, tasks, durations and the resources who will complete each task.

A common problem discovered at this point is when a project has an imposed delivery deadline from the sponsor that is not realistic based on your estimates. If you discover that this is the case you must contact the sponsor immediately. The options you have in this situation are:

• Renegotiate the deadline (project delay)
• Employ additional resources (increased cost)
• Reduce the scope of the project (less delivered)

Use the project schedule to justify pursuing one of these options.

Step 4 Supporting Plans

This section deals with plans you should create as part of the planning process. These can be included directly in the plan.

Human Resource Plan

Identify by name the individuals and organisations with a leading role in the project. For each describe their roles and responsibilities on the project.

Next, describe the number and type of people needed to carryout the project. For each resource detail start dates, estimated duration and the method you will use for obtaining them.

Create a single sheet containing this information.

Communications Plan

Create a document showing who needs to be kept informed about the project and how they will receive the information. The most common mechanism is a weekly/monthly progress report, describing how the project is performing, milestones achieved and work planned for the next period.

Risk Management Plan

Risk management is an important part of project management. Although often overlooked, it is important to identify as many risks to your project as possible and be prepared if something bad happens.

Here are some examples of common project risks:

• Time and cost estimates too optimistic
• Customer review and feedback cycle too slow
• Unexpected budget cuts
• Unclear roles and responsibilities
• Stakeholder input is not sought or their needs are not properly understood
• Stakeholders changing requirements after the project has started
• Stakeholders adding new requirements after the project has started
• Poor communication resulting in misunderstandings, quality problems and rework
• Lack of resource commitment

Risks can be tracked using a simple risk log. Add each risk you have identified to your risk log and write down what you will do in the event it occurs and what you will do to prevent it from occurring. Review your risk log on a regular basis adding new risks as they occur during the life of the project. Remember, when risks are ignored they don't go away.

Congratulations. Having followed all the steps above you should have a good project plan. Remember to update your plan as the project progresses and measure progress against the plan.

Developing the Project Plan

By Talibah Adenouga

Whether you call it a project plan or a project timeline, it is absolutely imperative that you develop and maintain a document that clearly outlines the project milestones and major activities required to implement your project.

This document needs to include the date each milestone or major activity is to be completed, and the owner of each. Your project plan also needs to be created at the beginning of the project, and a baseline version approved by the team as soon as possible.

Although you will probably not know all of the major activities required to implement your project in the beginning, it is important that you create a draft of the activities you think may need to be tracked via a formal document.

Take some time and really think through what you know about the objective of your project. Look at some historical data from similar projects. You can even have a few informal meetings with knowledgeable individuals you can use as a sounding board to make sure you aren't completely off base. You'll be surprised how good a draft you can develop if you put in a little effort.

With this draft you will be able to speak with subject matter experts (SMEs) and stakeholders to flesh out the project plan. If you don't make some level of effort to develop a rough draft, you may give a bad impression which will make it harder for you to obtain the support of the persons you need to implement the project.

After you have fleshed out your draft with your core team, and some other SMEs that may not be a part of your team, you should give the document a baseline status. Your timeline / project plan should not undergo many edits, if any, after it achieves baseline status.

You should document the actual date your project activities are completed. If the actual completion date differs from your baseline date at anytime, you'll still have documented the date it was supposed to be completed for historical purposes.

It is also a good idea to notate where things are deleted or added, and why. That way you aren't standing there looking crazy, trying to go through the crevices of your memory, when someone asks you why something you deleted isn't in the document...and trust me, someone will ask.

A few key items to include in your timeline are:

• A unique ID that your team can reference when giving an update
• The name of the task
• When the task should start
• When the task should finish
• The actual date the task was completed
• Any tasks that need to happen before other tasks can begin
• The owner of the task
• Percent complete of each task

You or the Project Sponsor you represent may decide to track or maintain more than what has been outlined above in your project plan. This is absolutely fine. These are just the items I have found to be vital, and a good foundation to build upon.

It is completely possible to run a project without a project plan or timeline; it's just not very smart. So, do yourself and your project team a favor... document milestones and important tasks, keep up with the status, and you'll be that much closer to a well managed project.

Remember, it doesn't matter what you call it, it just matters that you develop it.

Project Planning: The First Line of Defence for Preventing Failed Projects

By Matthew Sheaff

Every year thousands of projects are completed over budget, out of scope and past deadline. Still, with each passing year, project managers continue to rush into projects without due diligence in defining the project and creating a plan for project execution. By lightly addressing these critical components they are, in essence, failing their projects before any work has even commenced. So how can project managers efficiently execute a project plan while at the same time meeting the deadlines and expectations of senior management? Here are three simple but critical tips for any project manager to improve project results.

1. Ensure all stakeholders are identified

When beginning any project it is important to meet with all potential stakeholders and understand their interests with respect to the project. Many projects fail when the project manager doesn't realise how a special interest group (ex., unions, environmental groups, etc.) can delay or stop a project. The project manager must represent all such interests in defining the project. In many cases project managers only have a general understanding of the project definition as per the project sponsor (i.e., customer) and do not adequately understand the needs of the target audience/end-users of the project deliverables. Remember that a stakeholder is defined as a person or organisation that is either actively involved in the project, or whose interests may be positively or negatively affected by the execution or completion of the project. A stakeholder may also exert influence over the project and its deliverables.

2. Define, describe and validate the project definition

Most projects fail due to poor definition. This is the leading cause of scope creep, which leads to unavailable resources and more time and budget necessary to completely satisfy scope. Since the plan reflects the work, resources, budget, and time necessary to satisfy the scope it is easy to see the critical importance of understanding the project definition and description. It is also necessary to ensure agreement from all stakeholders before planning. Let stakeholders review the draft of the project definition document, and get their sign-off, before moving to the planning phase of the project. Also, ensure stakeholders understand that agreement with the project definition only means we all agree with the definition, not that we can satisfy scope, schedule and budget targets. In order to commit to achieving the project's objectives, detailed bottoms-up planning needs to be completed by the subject matter experts who will be performing the project work. It is only through this detailed planning that we can confirm that the project definition is realistic and achievable.

In translating the project scope statement, it is necessary to identify the major deliverables that will satisfy the scope. In addition the team should identify what is in scope and out of scope for each of the major deliverables. It is often a challenge to ensure implicit expectations are surfaced and are made explicit by documenting them in the project definition document.

There are seven essential elements that need to be included in the project definition:

• A clear description of the business problem and the solution to that problem
• A description of the benefits of completing the project (the business case)
• A concise (25-30 word) definition of the project schedule, scope and budget)
• A list of the major deliverables (which, when delivered, completely satisfy the scope of the project), including what is in scope and out of scope for each
• A priority matrix which summarises the sponsor's priorities for the schedule, scope and budget parameters that define the project
• Target customers for the project deliverables
• Project dependencies (committed dates and commitments to/from other projects)

The above project definition components do not exclude other possibilities that can enhance understanding of the projects, for example:

• A milestone schedule that can document interim deliverables requested by the sponsor
• An impact statement that identifies what can or will be impacted by the project
• Strategic risks
• Constraints (ex., schedule, environmental, political, cultural, technological)

3. Create a Work Breakdown Structure (WBS)

The WBS is the foundation of the project plan. The WBS is a hierarchical logical structure that represents all the work necessary to produce all the project deliverables. By doing so it organises and defines the total scope of the project. Work that is not in the WBS is outside the scope of the project. The WBS must be broken down to a sufficient level of detail so that one owner can be assigned responsibility for planning and managing each activity at the lowest level. By understanding the deliverables for assigned activities, by having clear completion criteria, each activity owner can successfully develop realistic and defensible time and budget estimates.

Summary

In order to get the right resources at the right time project managers must have a clear definition and a good project plan. Best practice project management isn't an impediment to the project, it is critical to project success. As the saying goes, "Pain me now… or pain me later."

Demand a Strong Project Plan

What to look for to advance your consulting projects from contract to execution

By Michael Strange

You've engaged a reputable consulting firm to perform a large systems project. You've prepared an RFP, carefully reviewed the responses, scrutinised the consultancy's oral presentation, and ultimately negotiated and signed a well-written statement of work (SOW).

Don't stop there.

A clearly defined SOW may place you on the right path, but it doesn't ensure success. In reality, the project manager engaged to run your project may not even be the person who wrote the SOW.

As an IT leader, you can and should do more to help advance your consulting projects from contract to execution. A careful review of the project plan is one way to facilitate this transition, and it's an underused and surprisingly effective method of finding early warning signs. So spend time reviewing the project plan and asking questions. Here's what to look for:

1. Analysis, preparation and documentation tasks should be well defined.

Unless the requirements are 100 percent complete, most software projects require extensive analysis and planning in advance of design. For example, make sure there are tasks defined for process analysis, requirements definition and all related areas. Make sure there are tasks to discuss security, response times, user roles, data conversion, retention, reporting, preparation for testing (not just testing execution) and so on.

When evaluating the level of detail, many managers use the "40 hour" rule, which states that all tasks must take less than 40 hours. But it's more useful to include preparatory and documentation tasks. For example, look at how this project plan describes the steps for documenting requirements:

• Gather requirements, accounts payable (40 hours)
• Gather requirements, cash application (40 hours)
• Gather requirements, accounts receivable (40 hours)
• Finalise and get sign-off on requirements (40 hours)

The project team has two full-time people dedicated to documenting requirements, so they should be able to complete this segment in two weeks.

But consider rewriting the plan as follows:

• Eight meetings, accounts payable, two hours each (16 hours)
• Preparation, one hour per meeting (eight hours)
• Document results, four hours per meeting (32 hours)
• Repeat the pattern for the other functional areas

The new plan shows 56 hours of effort, rather than the 40 in the original. If this pattern holds throughout, you may be starting your project 40 percent over budget and not know it. With the rewritten plan, team members will see that the two weeks that had been allocated is not enough, especially given the difficulty of scheduling meetings. And if they can't tell you this kind of detail, they haven't thought the project through.

2. The allocation must make sense.

Check the high-level allocation of effort. If the project is "waterfall" style, calculate the percentage of hours spent on each phase (analysis, design, construction, testing and implementation). If the project is "prototype" style, calculate the percentage of hours spent getting to the first and subsequent milestones. Take project management tasks out. The percentages should correspond to the maturity of your project. If the requirements are already defined, then don't accept the plan if 30 percent of the hours are allocated to analysis. If the project is in early stages of definition (and may evolve as work progresses), then don't accept a plan with 5 percent analysis.

3. Milestones should come every 30 days or less.

One of the easiest and most effective ways of managing multi-month systems projects is to use well-defined milestones. Demand a formal presentation of the design at one milestone. Schedule a review of the first iteration of prototyping at another. For straightforward custom-development projects, the milestones should be self-evident, and with formal review, they can be early indicators of success or failure. For newer, more complex projects (such as business intelligence or master data management), make sure your consultants have the expertise to define practical milestones.

4. Contingency must be quantified, not buried.

Contingency should provide a "relief valve" for unknown problems or unplanned work, and it should be included in virtually every project plan. If the project manager tells you that no contingency is required, his inexperience with the unknowns of large projects is showing. In my experience, once a custom development project is designed and a plan is carefully prepared, a 10 percent to 15 percent contingency is still warranted. More or less may be required, depending on the maturity of the project and the organisation.

5. Project management steps should be defined, not assumed.

Project management is a series of tasks, and those tasks should be included in the plan. Tasks such as documentation review and preparation of presentations and status reports are easily quantified. Don't accept a plan that includes technical tasks only and then adds just one person to serve as the project manager.

If you follow these rules, the project should progress cleanly. And since the plan will clearly describe tasks to be performed, you'll be better able to spot problems before they get out of control.

Then follow through

Signing a consulting contract isn't enough. Follow these steps to help the consultants spend more time on expertise-driven analysis and less time on logistics.

1. Hold a kick-off meeting. Explain the goals, objectives and roles to everyone involved.
2. Be honest with your team. Clearly explain why outside help is needed.
3. Facilitate scheduling. Don't let the consultants flounder trying to schedule meetings.
4. Hold intermediate discussions. Help them focus on what's practical for your environment.
5. Help with formats. If your organisation has standards for presenting business cases, recommendations and ROI calculations, give these to the consultants in advance.

Planning a Project using a Work Breakdown Structure and Logic Network

Projects don't just happen they are planned. The whole project team should develop the plan not just the project manager. This ensures that the teams' experiences are taken into account and that everyone is fully committed and has ownership of the plan. A good project plan will provide the following:

• A roadmap everyone in the team can follow with clear milestones
• A realistic project timescale
• Details of resource requirements
• Validation of the estimated cost
• Identification of task slippage
• Early warning of problems

It pays to use previous experience (historical data) from similar projects.

• How long did it take?
• How much did it cost?
• What were the problem areas?
• What were the successful areas?

Running a project without a plan is foolish. Working without knowing where you are going is likely to lead to problems and possible failure. Running a project without a plan is like trying to find your way in a strange city without a map. As the saying has it, "If you fail to plan, you are planning to fail."

Work Breakdown Structure (WBS)

In order to identify the individual tasks in a project it is useful to create a Work Breakdown Structure. The WBS is the foundation for the detailed project plan. Get the team together and brainstorm all of the tasks and sub-tasks in the project, in no particular order. Write them down on sticky notes and put them on a whiteboard. Once everyone has thought of as many tasks as they can, arrange the sticky notes into groups under the major areas of activity. Add, modify, remove and shuffle the sticky notes until the WBS is accurate, complete and logical. The purpose of a WBS is to decompose the project into steps and sub-steps.

Logic Network (time chart)

A Logic Network shows the sequence of activities in a project across time. It shows which activity logically precedes or follows another activity. Create a start (left) and end (right) sticky note and put them on the board. Arrange the WBS sticky notes in the logical sequence of activities from left to right. Join the notes with an arrow in and out; some may have more than one arrow. All connecting lines on a network enter at the left (beginning) of the activity box (sticky note) and exit at the right (ending). Lines do not enter the top or exit the bottom of the activity box. No unconnected lines are allowed. All activities must connect to another activity or the start or end of the project. Add the amount of time every activity will take on each sticky note to calculate the project duration. You have created a Logic Network that will help you understand the dependencies in your project, timescale and its workflow. This technique can reveal important information that could otherwise be overlooked.

Milestones

Look for milestones in your Logic Network. A natural milestone may occur any time a series of parallel activities come together in a point. Control the project by defining a concrete deliverable for each milestone. A concrete deliverable is something you can see or touch such as a design specification, prototype, report, software module etc.

Using Project Management Software

The information from your WBS and Logic Network can be input into a software package such as Microsoft Project to provide a detailed plan. Enter the tasks, predecessors, resources and time estimates into the software. Once entered the software will create the charts and graphs automatically. Don't expect the software to plan or management the project; it's just a tool.

Checklist

Here is a checklist to help you create a well thought out, detailed project plan while building a committed high performing team.

1. Define what needs to be done using a Work Breakdown Structure
2. Determine the best approach to get everything done by developing a Logic Network
3. Establish responsibilities and develop work and duration estimates of how long each team member requires for each task
4. Calculate how long the project will take to complete, its critical path and milestone schedule using the Logic Network
5. Calculate and chart how many people will be needed and the percentage of each team member's time for each phase of the project
6. Adjust and refine the project plan to level individual workloads and smooth the number of people needed during the project
7. Creatively optimise trade-offs to deliver the best results in the shortest time
8. Use the joint planning process to intensify team members' commitment and ownership

Microsoft Project (MSP)

Microsoft Project is the world's most popular project management software developed and sold by Microsoft.

The application is designed to assist project managers in developing plans, assigning resources to tasks, tracking progress, managing budgets and analysing workloads.

Microsoft Project creates critical path schedules, although a critical chain third-party add-ons is available from ProChain and Spherical Angle. Schedules can be resource levelled. The chain is visualised in a Gantt chart.

Resource definitions (people, equipment and materials) can be shared between projects using a shared resource pool. Each resource can have its own calendar which defines what days and shifts a resource is available. Resource rates are used to calculate resource assignment costs which are rolled up and summarised the resource level.

Each resource can be assigned to multiple tasks in multiple plans and each task can be assigned multiple resources. Microsoft Project schedules task work based on the resource availability as defined in the resource calendars. All resources can be defined in an enterprise resource pool.

Microsoft Project creates budgets based on assignment work and resource rates. As resources are assigned to tasks and assignment work estimated, Microsoft Project calculates the cost equals the work times the rate. This rolls up to the task level, then to any summary tasks and finally to the project level.

Microsoft Project has been extended with Microsoft Office Project Server and Microsoft Project Web Access. Project server stores Project data in a central database.

Project Web Access allows user to display and update this data over the Internet. Web Access allows authorised users to access a Project Server database across the Internet. Web Access includes timesheets, graphical analysis of resource workloads and administrative tools.

Microsoft recognises different classes of users. These different classes of users can have differing access levels to projects, views and other data.

Custom objects such as calendars, views, tables, filters and fields are stored in an enterprise global database, which is shared by all users.

For people who only need to view plans, commercial third party viewers exist, a less costly option than a full licence. A complete list of free and commercial viewers is available at microsoftprojectviewer.com A free viewer is available from Afinion

Project Management Tools

Definitions for common tools used when planning a project.

Gantt Chart

A Gantt chart is a popular type of bar chart that aims to show the timing of tasks or activities as they occur over time. Although the Gantt chart did not initially indicate the relationships between activities this has become more common in current usage as both timing and interdependencies between tasks can be identified.

Since the initial introduction of Gantt charts, they have become an industry standard as a key project management tool for representing the phases, tasks and activities that are scheduled as part of a project Work Breakdown Structure or timeline of activities.

Logic Network

A Logic Network shows the sequence of activities in a project across time. It shows which activity logically precedes or follows another activity. It can be used to identify the milestones and critical path of a project.

PERT Chart

The Programme Evaluation and Review Technique commonly abbreviated PERT is a model for project management invented by United States Department of Defense's US Navy Special Projects Office in 1958 as part of the Polaris mobile submarine launched ballistic missile project.

PERT is basically a method for analysing the tasks involved in completing a given project, especially the time needed to complete each task and identifying the minimum time needed to complete the total project.

Product Breakdown Structure (PBS)

In project management, a Product Breakdown Structure (PBS) is an exhaustive, hierarchical tree structure of components that make up a project deliverable, arranged in whole-part relationship.

A PBS can help clarify what is to be delivered by the project and can help build a work breakdown structure.

The PRINCE2 project management method mandates the use of product based planning, part of which is developing a product breakdown structure.

Work Breakdown Structure (WBS)

A Work Breakdown Structure (WBS) is an exhaustive, hierarchical tree structure of deliverables and tasks that need to be performed to complete a project. Work breakdown structure is a very common project management tool and the basis for much project planning.

source: http://www.projectsmart.co.uk/project-planning-step-by-step.html