How to Plan a Project
Practical Guidance on Planning Projects: Simply and Effectively
Making this task more effective and your Project far more successful!
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 of any project.
There are widespread views on project management, 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 debate on some of what follows. Project management (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 size of project 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 all projects; there are though fundamentals or principles that are key to planning all projects 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 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 ‘shaping’ of the emerging specification of the deliverable to meet the need or requirement behind the project. In other words, the defintion 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 to deliver a project. 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 work streams of the project. The format can take many shapes, but we believe that, ideally, a project plan should 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 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 project work scope. They can be very similar to work packages or may organise work packages into groups or the work of single disciplines within a project.
The term “project management function” clearly includes the project manager, and in some businesses, will also include other project 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 project 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 to any project. With the full participation of the right people, we should first define and then plan the project.
It allows us to confirm key elements of the project with stakeholders or the sponsor, and then to develop and validate a plan to deliver the project, on time and within the budget agreed with the sponsor or customer. It can be a huge mistake to assume we understand what others need or want.
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 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 project work (to avoid nugatory effort or re-work). The life-cycle 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 life-cycle, e.g. to the delivery strategy, or the solution strategy or design. The most important phase in every project is always the ‘definition and planning’ phase. These ‘event’ points also give us the opportunity to exercise Governance of the project at key points, well before the deliverable is produced (and the cost of this incurred).
To plan a project successfully we must do three major things (later we discuss each step in more detail):
- define and capture the project: 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 of the project – using methods such as a work breakdown structure;
- then plan the delivery of the project in 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 to the project 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 the project, no matter obvious some things may seem.
If you examine a sample of project 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 to any project, which happens when people attempt to ‘shortcut’ the real planning work on projects, 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 on projects.
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.
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 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 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. Key note: the objectives of the project are what the project is looking to achieve for the owning or sponsoring organisation; they is 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 the project will deliver. This will determine whether the project 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 of the project. This is a whole area itself needs to be an integral part of the project from start to beyond the production of the project’s 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 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’ 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 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, 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 project. 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 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.
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.
Planning projects 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 project 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 is 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 upon projects. We should hold them in a format that can be readily shared and understood by all.
If you follow the above on your project, it should mean you get off to a great start.
Email us today to find on how we can help.
Email for more information on planning business projects.
Click here for details of Project Management 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,
Contact Us Now
Email us today to find out more on how we can help you.