How to Plan a Project
Practical Guidance on Planning Projects:
Simply, effectively and increase your chances of success
The purpose of this article is to provide guidance on how to plan projects. It could easily take a whole book to cover this subject; in this article, we cover the fundamentals. We also include many lessons learned from practical experience and share tips based on this that will elevate the prospects of success.
There are widespread views on project management (PM), and many questions will never have one single answer. While there is broad agreement across continents 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 in this environment. 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 the majority of the following, always.
There are many types of projects, e.g.
- building a new bridge, computer system or an element of an internal change programme
and the ‘type’ and even its size will often have an impact on 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.
In order to conduct 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 is left 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 ‘shaping’ of the emerging specification of the deliverable to meet the need or requirement. In other words, the definition and agreement of the optimum solution that meets the business need (and requirements);
- 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. 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 sum of all activity necessary to complete a project;
- 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 definition of the processes that will be employed to execute all work streams. 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 key parties involved in specifying, 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, and risk management plan;
- workstream planning: – workstreams are discrete elements of the workscope used 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 term “project management function” clearly includes the project manager, and in some businesses, will also include other staff, such as planners and support staff as required. In short, their collective responsibility is to:
- facilitate the development of an achievable plan that demonstrates 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
- assess status against the plan and ensure corrective actions are implemented when necessary.
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. It must be developed with the participation of the full team, 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.
It allows us to confirm many key elements with key stakeholders and the sponsor, and then to develop and validate a plan, on time and within the budget as agreed with the sponsor or customer. It is often a huge mistake to assume we understand what others need or want. Many businesses have experienced severe consequences simply from making this assumption.
What do we mean by validating? We mean to model and confirm:
- all significant tasks are identified and scheduled to meet the timescales and targets;
- all major dependencies are recognised and reflected in the plan;
- all resources are defined and the resource requirement is fully analysed and confirmed as achievable (including resource provider commitment); and
- risks have been identified and the associated mitigation activities are embedded in the core plan.
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 start and/or completion of each stage should be aligned to major points of commitment within the life-cycle, e.g. to the delivery strategy, or the solution strategy or design. The most important phase is always the ‘definition and planning’ phase. These ‘event’ points also give us the opportunity to exercise Governance at key points, well before the deliverable is produced (and the cost of this incurred).
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.
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 of activities – this is often referred to as 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.
Within the planning process, it is fundamentally important to define the responsibilities (not just the roles) of all key parties relative to the plan. Not doing so, in a way that results in clarity is a major source of issues.
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 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.
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). Ideas can be explored or developed, by studies etc, and subsequently confirmed (approved and committed to) around a business case or equivalent. 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.
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 language and shared with and validated by all appropriate stakeholders (using the governance structure). 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 can be 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 deliverable or the chosen solution.
The other key input to the business case from are the planned benefits that it will deliver. This will determine whether it is a success or otherwise, and therefore they must be formalised within the business case. From that point onward there should be a specific work stream to optimise, plan for and realise the target benefits. This is a whole area itself 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.
At this stage, the team should start to also formalise the key requirements. 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’ at this stage – and therefore great discipline may need to be applied to this activity.
In truth, the delivery plan should only be produced once the delivery strategy has been agreed. 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 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 involved in the team – always a great source of potential for risk.
As a minimum, it should contain an analysed 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 PM– sadly, these 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, including risk mitigation and planning. Ideally, it should also be based upon estimates 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 – something we often refer to as the ‘happy 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 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. Risk mitigation strategies and actions should then be developed and incorporated (integrated) into 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.
Together, all the work streams or statements of work collectively define the scope of work. 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.
Whenever we plan, we always 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. 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.
Planning requires that we capture information, for example in 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 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 be readily 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
Email for more information on the above.
Click here for details of training courses from PMIS.
- 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 where there is reasonable flexibility around requirements, which can be addressed and prioritised around each iteration, and where product can be released incrementally,