How do you plan a project?

How to plan a Business Project

Purpose of this article:

The purpose of this article is to provide an overview of how to plan projects. The subject could easily take up a whole book (it is a very broad topic) – in this article we have tried to cover a number of the fundamentals of the topic.

An important note – variety of views on project management:

There are many views on project management, and some debates will never have one single possible answer (a great example is should you ever re-baseline a project plan?). While there is broad agreement across continents on the principles of effective project management, there will always be debate on some of what follows.

Types of projects:

In part, this is because there are many types of projects, e.g.

• A new bridge, computer system or a change programme

and the ‘type' will have an impact on the definition and planning process – sadly, there is no ‘one size fits all' methodology for planning all projects; there are though, fundamentals or principles that are key to planning all projects successfully.

Key terminology:

In order to conduct a discussion successfully, we need a common understanding of key terms:

• requirements : a documented and structured set of statements that define the functions, operations or capabilities that the project ‘solution' must perform
• deliverable : this is what the project leaves behind (e.g. new bridge or computer system) – often it needs to be formally accepted and always needs to be tested for robustness and compliance with requirements.
• solution : very similar to the deliverable but in truth this is the emerging ‘shaping' or specification of the deliverable to meet the need or requirement behind the project, in other words the development of the optimum solution that meets the ‘business' need.
• scope – (aka workscope) the origins of this term stems from workscope or scope of work – the original use of the term focused more on the collective activity (work) to be undertaken to deliver a project. Today many people in business use this term more broadly (some would say incorrectly), encompassing for example aims or objectives when using the term. Its original meaning was a collective term referring to the total sum of all activity to be performed on a project.
• plan - In truth there are many interpretations of this term – to some it means a ‘schedule' of tasks – to others it includes definition of the processes that will be employed to execute work streams of the project. We believe that, as a minimum, a project plan must contain: a clear definition of the project objectives, the main deliverable; a validated timeline of the key activities to meet all schedule targets; the organisational responsibilities of all key parties involved in developing or reviewing all the outputs or deliverables; an analysed statement of the resources and skills required to perform all work in the plan (this will be by resource provider). It can also contain many other elements, for example, the quality plan.

What is the fundamental responsibility of the project management function?

In short it is to develop achievable plan that demonstrates the activities and resources required to deliver the project.

What are the objectives during the planning phase?

They are to define the project, and then to develop and validate a plan to deliver the project, on time and within the budgetary targets agreed with the sponsor or customer.

What do we mean by validate? It is to model and validate, for example, that:

• all tasks are identified and scheduled to meet the timescales needs and targets
• all major dependencies are recognised and reflected in the plan
• all resources (types and required quantities) are defined and the resulting resource requirement is fully analysed and achievable (including resource provider commitment – this is absolutely key), and
• risks have been identified and the associated mitigation activities are included in the plan.

Breaking down the planning task: define the project and then plan the project

All projects must follow a lifecycle – the major purpose of the lifecycle is to ensure that we bring discipline and in particular the correct order to project work (to avoid nugatory effort or unwanted re-work) – the lifecycle will split the project into major stages / phases. The start and / or completion of each stage should be aligned to major points of commitment within the project lifecycle, e.g. to the delivery strategy, or the solution strategy or design. The first and most important phase in every project is always the ‘definition and planning' phase.

To plan a project successfully we must do two major things:

1. define the project: need and objectives; determine and confirm the delivery strategy; and make strategic decisions regarding the solution (to the need), and then, only once we have validated these decisions with the appropriate stakeholders
2. plan the delivery of the project in detail.

The above tasks do not need to happen completely sequentially, but there are obvious relationships between them that will influence sequencing. In short, we need to do the above as effectively and efficiently as possible, without bringing major risk to the project by not conducting this activity itself in a disciplined manner or by not allowing enough time and resource to conduct these tasks and share (confirm) the results with the appropriate stakeholders.

An Integrated Plan

It is fundamentally useful if the analysis of resource requirements is strictly aligned to or driven by the schedule of activities – in the past this was often referred to as an integrated planning process – another way of putting this is that ignoring this principle is in itself a significant risk to any project, which is often done when people attempt to ‘shortcut' the real work of planning projects, often for the wrong reasons and typically with consequences that can be measured in cost and time.

Organisation, roles and responsibilities

Within the planning process, it is also fundamentally important to define the responsibilities (not just the roles) of all key parties relative to the plan – not doing so to a level of detail that results in clarity is a major source of issues on projects.

Responsibilities of Governance

A task that relates to organisation, is that of defining and communicating the Governance structure. This should define all roles and authorities in relation to governance of the project. Key events (such as formalisation of the project strategy) should be examined against the governance structure, to ensure that the right parties are responsible for and involved in key planning decisions. This structure should also provide the natural route for escalating and managing issues - something that must be done with minimum delay if a project is to be delivered on schedule.

Major Task 1 – define what the project is intended to a) achieve or b) deliver

All projects start out as an idea, opportunity or need – an idea to improve or take advantage of something (e.g. a new market) or a need, for example to replace, upgrade or introduce something (e.g. a road or a system). In short, ideas can be explored or developed, by studies etc, and subsequently confirmed (approved and committed to) by a business case or equivalent, assuming the results of studies etc are positive and feasible. Where we have a business case it should contain much of the vital definition of the project, and may also address sufficient of the delivery strategy in order to validate the claims made in the business case relating to the financial return (or benefits) that the investment (business case) will deliver.

Goal, Objectives and Benefits:

All projects that include change or business improvement, should have explicitly stated and formalised goals, objectives and planned benefits. These should be captured, using simple business language, and shared with and validated by all appropriate stakeholders (subject to the governance structure of the project). The sponsor and project manager should expect iteration or even conflict to occur while engaged in this task – this is the time to understand and to rationalise the project's objectives etc until an optimised set can be supported by all the key stakeholders. Moving forward with this area either untested or with unresolved issues will, at best, cost far more to resolve downstream - at worst it can have a much larger impact. Key note: the objectives of the project are what the project is looking to achieve for the owning or sponsoring organisation; it is not the deliverable (i.e. produce a new system) that is simply the deliverable or the chosen solution .

Moving on, the other key input to the business case from this phase are the planned benefits that the project will deliver. This will determine whether the project is a success or otherwise, and therefore it must be formalised within the business case. From that point onwards there should be a specific work stream to optimise, plan for and manage (realise through structure and clear accountability) the target benefits associated with the project (this is a whole area in itself and needs to be an integral part of the project from start to end – in truth this is not a practice you see widely today although many organisations are trying to move in this direction).

Key requirements:

At this stage, the project team should start to also formalise the key requirements of the project. Key requirements should be limited to those, without which, the deliverable would be useless to the users / owner. The goal must be to not include ‘nice to haves' – and therefore great discipline may need to be applied to this activity.

Major Task 2 – develop and validate the complete delivery plan

This can comprise many elements, depending upon the project type and key project decisions, e.g. make or buy etc.

In truth, the delivery plan should only be produced once the delivery strategy has been developed. In some environments, this should be formally approved by the appropriate authority. It must also be examined rigorously from the perspective of risk . Key strategic project decisions are the most important we make on projects, and have the maximum capacity to influence risk, both positively and negatively. An example could include the partners or suppliers we involve on the project – always a great source of potential for risk.

As a minimum, it should contain an analysed project schedule, a resource plan that is driven by the schedule (i.e. changes to the schedule are automatically reflected in the resulting resource plan), not a ‘spreadsheet' type approach. These elements are often referred to as the first principles of project management – sadly, first principles are too often overlooked. The output of this phase should contain or in a sense summarise (auditably and quantitatively) the results of all planning decisions. This must include risk mitigation and planning. It should also be based upon appropriate methods for estimating, that do not rely upon single point estimates of time and effort alone. Such approaches typically produce a plan that has limited probability of being achieved.

Planning must include the identification of risks to any aspect of the delivery process or the planned benefits - these can be commercial, organisational, political or any other type of risk - there are often many risks outside of those that relate to the technical aspects of the project. It is typically as sign of weakness in terms of the management of risk if all the risks that have been identified are purely technical. Risk mitigation strategies and actions should be developed and incorporated (integrated) into the mainstream plan.

The plan must also contain relevant processes and activities to assure that all quality targets of the projects are achieved. Again, in many circumstances this will result in an important work stream in itself.

Together, all the work streams or statements of work collectively define the scope of work of the project. In many environments this will be managed via formal change control.

The plan should be formally reviewed by all core team members and relevant stakeholders, for completeness and validity. This is then published and often referred to as the baseline plan.

The power of assumptions when we plan:

Whenever we plan, we make assumptions. This is because we are developing something new or are making change. The assumptions can relate to any aspect - experienced project managers will recognise the instances of assumptions, and will evaluate them in terms of their criticality to the project - they are a significant source of risk.

Ignoring this principle can result in downstream issues of unlimited scale, the impact of which will be measured in cost and schedule terms.

A word on formality - v - bureaucracy

Planning projects requires that we capture information, in for example the Business Case. There will also be other documents that may be required, e.g. specifications etc. These are all a necessary part of defining and delivering projects. However, some project methodologies attempt to add weight to the volume of paperwork - especially those that demand 'reports' to be produced when other means may well be just as effective or perhaps even better. This does not always reflect best practice, but is prevalent is some environments.

This cautionary note does not however apply to the most important inputs to the planning process, including: goals; objectives; benefits; responsibilities; requirements; successes criteria and other elements. These are fundamentally important; we must share these widely as people come into contact with or work upon projects - in order to do so we need to hold them in a format that can be readily shared and communicated.

for more information on planning business projects.

Project Management Training Courses from PMIS.