How do you Plan a Project?
Practical Guidance on Planning Projects:
How do you Plan a Project? It could easily take a whole book to cover this question. In this article, we cover the most important things we always need to do. We also include many lessons learned from practical experience and share many tips that will increase the prospects of success.
An important note – a variety of ways to plan projects:
There are widespread views on project management (PM), and many questions will never have one single answer.
While there is broad agreement on the principles of (good) project management, there will always be a debate on some of what follows. PM is not a binary science. It’s a branch of management. Qualities like experience, judgement and competence are of huge value when planning projects.
This article covers elements that are important whether you are using traditional methods or Agile. If you are using Agile it will impact how you do some of what follows. Whatever terminology and process we use, we still need to do much of the following, always.
Type of project and its effect on the planning process
There are many types of projects, e.g.
- building a new bridge, computer system, or internal change programme
and the ‘type’ and even its size will often impact aspects of the project management methods.
Sadly, there will never be a ‘one size fits all’ method for planning; there are though fundamentals or principles that are key to planning successfully.
Key terminology: why does this matter?
In order to have a discussion successfully, we need a common understanding of certain terms:
requirements:
an agreed and structured set of statements that define the functions, operations or capabilities that the ‘solution’ must perform;
deliverable:
this is what the project leaves behind (e.g. new bridge or computer system). The deliverable is often formally accepted. It should always be tested for robustness and compliance with requirements;
solution:
very similar to the deliverable but, this is the ‘shaping’ of the emerging design of the deliverable to meet the need or requirement. In other words, the agreement of the optimum solution that meets the business need (and requirements);
scope:
(aka work scope) the origins of this term stem from work scope or scope of work. The term originally referred (only) to the collective work (tasks) to be done. Today many people in business use this term more broadly (some would say incorrectly), encompassing, for example, the project’s aims or objectives. Its original meaning was a collective term referring to the total statement of all activity needed to complete a project. Not the project’s objectives;
plan:
in truth, there are many interpretations of this term. To some, it means no more than a ‘schedule’ of tasks. To others, it includes the processes to execute all workstreams.
The format can take many shapes, but we believe that, ideally, a plan should contain: a clear definition of key objectives, the main deliverable; a validated timeline of the key activities to meet all schedule targets; the organisational responsibilities of all those involved in specifying, developing or reviewing all the outputs or deliverables; an analysed statement of the resources and skills required to do all work in the plan (this will be by resource provider).
It can also contain many other elements, e.g. the quality plan and risk management plan;
workstream planning:
workstreams are discrete elements of the work scope. They help to optimise the way work is organised. Workstreams can be led by one person and will usually collectively cover the most important elements of the work scope. They can be very similar to work packages or may organise work packages into groups or the work of single disciplines.
The main responsibility of the project management function
The term “project management function” clearly includes the project manager, and in some businesses, will also include other staff, such as planners and support staff. In short, their collective responsibility is to:
- facilitate the development of an achievable plan that shows the activities and resources required to deliver the project within all key targets and constraints, as agreed with customers and key stakeholders;
- communicate and share the plan clearly and regularly with all members of the team; and
- assessing status against the plan and ensuring corrective actions are implemented as necessary.
Developing ‘ownership’ of the plan: you cannot emphasise the importance of this enough
A key aim must be for the broader team to understand the plan thoroughly and show real commitment towards and even belief in the plan. This never occurs if the project manager develops the plan on their own. The full team must develop the plan, including key suppliers.
Failing to develop a plan in this way is a major risk. With the full participation of the right people, we should first define and then plan the project.
Why define and then plan the project?
It allows us to confirm many key elements with key stakeholders and the sponsor. Only, then should we develop and validate a full plan to deliver the project on time and within the budget.
It is often a huge mistake to assume we understand what others need or want, before doing this. Many businesses have experienced severe consequences simply from making this assumption.
What do we mean by validating? We mean to model and confirm that all:
- significant tasks are clearly in the schedule;
- all major dependencies are in the plan;
- resource requirements are quantified and confirmed as achievable (including resource provider commitment); and
- risks mitigation activities are in the core plan.
How do we bring discipline and ensure success?
Understand the lifecycle of your project
All projects should follow a life cycle. The major purpose of the life cycle is to ensure that we bring discipline and in particular the correct order to all work (to avoid nugatory effort or re-work). The life cycle will split all work into major stages/phases.
The most important phase is always the ‘definition and planning’ phase.
The start and/or completion of each stage should align with major points of commitment within the life cycle, e.g. the solution strategy or design.
These ‘event’ points also give us the opportunity to exercise Governance, well before the deliverable is produced (and the budget starts to be spent).
Define and then plan the project
To plan all work successfully we must do three major things (later we discuss each step in more detail):
- define and capture: the need, objectives, benefits and outcomes; delivery strategy; all strategic decisions regarding the solution (to the need), make or buy and then, once we have validated these decisions with the appropriate stakeholders;
- develop and capture the full scope of work – using methods such as a work breakdown structure;
- then plan the work in sufficient detail – using either traditional or Agile (iterative) methods (¹).
The above tasks do not need to happen completely sequentially, but there are obvious dependencies between them.
In short, we need to do the above as efficiently as possible, without bringing major risk by not conducting this phase itself in a disciplined manner or by not allowing enough time to share (and confirm) the results of this phase with the appropriate stakeholders. It is also crucial to capture and communicate anything that is critical to success, no matter obvious some things may seem.
Develop a plan that has ‘integrity’
If you examine a sample of plans, there is always a world of difference between them, from little more than a high-level schedule to a plan that has real substance and integrity.
For example, it is fundamentally useful if the analysis of resource requirements is strictly linked to or driven by the schedule. This is often called one of the first principles of PM. Another way of saying this is that ignoring this principle is in itself a significant risk, which happens when people attempt to ‘shortcut’ the real planning work, often with consequences that can be measured in both cost and time.
Organisation, roles and responsibilities
Within the planning process, it is fundamentally important to define the responsibilities (not just the roles) of all key parties. Not doing so, in a way that results in clarity is a major source of issues.
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. Key events (such as the formalisation of the delivery 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 it is to be delivered on schedule.
Major Task 1 – ‘Project Definition’ in more detail
All projects start out as an idea, opportunity or need (e.g. a business problem). 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). Ideas and proposals should be explored or developed, by studies etc, and confirmed (approved) around a business case or similar. Where we have a business case it should contain much of the vital definition of the project, and may also address the delivery strategy in order to validate the claims made in the business case relating to the financial return (or benefits) that the business case will deliver.
Goal, Objectives and Benefits:
Ensure clarity and agreement around the objectives
All projects that include change or business improvement should have explicitly stated and documented goals, objectives and planned benefits. These should be captured using simple language and shared with and validated by all appropriate stakeholders. 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 objectives etc. until an optimised set is supported by all the key stakeholders. Moving forward with this question either untested or with unresolved issues will (at least) cost far more to resolve downstream. At worst it can have a much more damaging impact.
Keynote: the objectives are what the project is looking to achieve for the owning or sponsoring organisation. They are not the deliverable (i.e. produce a new system) that is simply the chosen solution.
Crystal clear benefits
The other key element in the business case is the planned benefits that it will deliver. This will determine whether it is a success or otherwise, and therefore they must be clear within the business case. From that point onward there should be a specific workstream to optimise, plan for and realise the target benefits.
Bringing structure to the management of expected benefits needs to be an integral part of the work from start to beyond the production of the main deliverable. 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 team should start to also formalise the key requirements. Key requirements should be limited to those without which, the deliverable is useless to the users/owner. The goal is to not include ‘nice to haves’ at this stage. Therefore, this activity must be done with great discipline.
Major Task 2 – developing the delivery plan
In truth, the delivery plan should only be produced once the delivery strategy has been agreed. In some environments, the appropriate authority must approve the plan.
It must also be reviewed rigorously from the perspective of risk. Key strategic decisions are the most important we make and have the maximum capacity to influence risk, both positively and negatively. An example could include the partners or suppliers we involve in the team. Always a great source of potential for risk.
The Delivery Schedule
As a minimum, it should contain a fully analysed schedule and a resource plan that is driven by the schedule. These elements are often referred to as the first principles of PM. Sadly, these first principles are too often overlooked.
The output of this phase should summarise the results of all planning decisions, including risk mitigation and planning. Ideally, it should also be based on estimates that do not rely upon single-point estimates of time and effort. Such approaches typically produce plans that have a limited probability of being achieved. Something that we often refer to as the ‘happy plan’.
Risk Management Plan
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. It is typically a sign of weakness in the application of risk management if the only risks that have been identified are technical. There are often many risks outside of the technical aspects of the deliverable. We should develop risk mitigation strategies and actions and include them in the mainstream plan.
The plan must also contain relevant processes and activities to assure that all quality targets are achieved. Again in many circumstances, this will result in an important work stream in itself.
Statement of Work
Together, all the work streams or statements of work collectively define the scope of work. This will be managed via formal change control in many environments.
The Baseline Plan
The plan should be formally reviewed by all core team members and relevant stakeholders, for completeness and validity. The plan is then published and is often referred to as the baseline plan.
Power of assumptions: the most important lesson
Whenever we plan, we always make assumptions. This is because we are developing something new or are making a 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. They are a significant source of risk.
If you ignore this principle it can result in downstream issues of scale, the impact of which will be measured in cost and schedule terms.
A word on formality – v – bureaucracy
Planning requires that we capture information, for example in the Business Case. Other documents may also be required, e.g. specifications etc. These are all a necessary part of defining and delivering projects. However, some methodologies attempt to add weight to the volume of paperwork – especially in the planning phase. This does not always reflect best practice but is prevalent in some environments. We should have no more documents than necessary.
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 on projects. We should hold them in a format that can easily bed shared and understood by all.
If you follow the above, it should mean you get off to a great start.
Need help planning your next project?
Email us today to find out how we can help you
Related Pages
Email for more information on the above.
Click here for details of training courses from PMIS.
Notes:
- Some projects may never suit Agile methods (e.g Construction) – these will always follow a more traditional waterfall-type planning approach. Agile should only be used when there is reasonable flexibility around requirements, which can be addressed and prioritised around each iteration, and where the product can be released incrementally,
Share this:
Contact Us Now
EMAIL us today.
Or call ++44 (0)1865 784040