Project Planning: a Guide for Executing Your Game Plan
Overview
How Do I Create a Good Project Plan?
Creating a project plan is relatively easy, as long as it does not have to be implemented afterwards! The challenge is making sure that what we plan can be realistically implemented later.
In this article, I have compiled some best practices and some risks (that people tend to ignore) into a recipe for a resilient project plan. Here’s the structure:
- Create Prerequisites
- Create a Work Breakdown Structure
- Estimate Effort
- Sequence Planning
- Create Schedule
- Resource Planning
- Create Cost Plan
1. Create Prerequisites
Defining Requirements and Project Goals
From the beginning of a project, it must be clear what is to be done. Unfortunately, Mark Twain’s famous saying, “Having lost sight of our goals, we redoubled our efforts” often pops up in our workday. Any lack of clarity increases the risk of getting an unintended result at the end of a project. This could also involve higher costs and delays.
System Concept as Project Goal Definition
Describing the project result is an essential basis for every project plan. In practice, it’s a lot better to make a single system concept or requirements plan that is jointly prepared by the client and contractor than just basing a plan off of requirements documents.
Experienced authors are necessary for creating a system concept or requirements plan. The description of the project goal requires a clear inner vision from the author. The more concrete and detailed this is, the more reliably it can be planned later. An inexperienced author can oversee important things. Thus, he or she will not deliver when it comes to planning.
Twin Peaks Model Proven in Practice
In practice, the Twin Peaks model has proven helpful for developing requirements and a system concept. It makes it clear that one must consider a project’s goal while writing the requirements. Otherwise, one does not recognize many open questions within the problem space. We want a solution concept that describes the desired project result in an appropriate form (e.g. tables, text, diagrams) that both the client and the contractor can understand.
Gathering Experience
When we want to create a project plan, we need to remember: There is no substitute for experience! There are many methods for estimating effort. All of them are based on the assumption that the new project can be adequately described by an existing, empirically proven model. This doesn’t work 100% of the time. Let’s think about a house and a church. Both are buildings. If you have built enough houses, you know quite well how long it will take and how much it will cost to build the next one. If you took the same figures for a church, you’d be way off. Even though both are buildings, they require different things.
If we don’t have experience with certain kinds of projects, then effort and schedule planning is highly speculative, and one should expect serious deviations. “More expensive” and “later” is usually what we’ll say when we compare planning and implementation phases for an unfamiliar project. This is probably also due to the fact that many clients do not want to know how expensive it will really be and are happy to award the contract to those who tell them what they want to hear.
2. Create a Work Breakdown Structure
In the second step of project planning, you create a work breakdown structure (WBS) based on the requirements or, better, a system concept. We structure a WBS according to three types of elements:
- Subprojects
- Subtasks
- Work packages
Subprojects make it possible for us to use different process models within an overall project. For example, when we are making a computer, it may make sense to use a classic waterfall method for the development of electronics in one subproject. Then, in another subproject, it would make more sense to work with agile methods for the associated software development.
Sometimes, it makes sense to break tasks down into subtasks. For example, if your task is writing a report, but your colleague has the meeting minutes with updated requirements, you will need to email your colleague before you can write the report.
Work packages are the lowest level of a work breakdown structure. We can break them down into activities or tasks in the further planning process.
3. Effort Estimation
An essential element of project planning is the estimation of effort. There are numerous methods and approaches for estimation. Unfortunately, none of these methods can replace experience with a similar project. Many effort estimation models have parameters that must first be calibrated. However, without recourse to previous projects, one does not have these parameters and thus the models are of little use.
Similar Previous Projects
The most reliable planning and estimates are based on similar previous projects. They do not assume that general technical progress will halve the effort in the new project.
Estimation by Later Responsible Person
It is important that those who are responsible for implementation give the effort estimate. In some technology areas, the performance of the individual team member plays an essential role. One cannot expect that each person will complete tasks in the same amount of time. For example, in the area of knowledge work, productivity differences of 500% are not uncommon. Except for very large teams, where these differences average out, you should know your team members and include them in the effort estimation.
Do not Negotiate Down Expenses
Don’t downplay the amount of work your team members say they need to do. Usually, your employees underestimate the frictions that occur and overestimate their productivity. Always assume your project will take longer than people say it will.
Categorize Operations into Effort Classes
It can help to divide processes into effort categories. In the agile context, people like to use so-called “story points” with relative efforts that roughly correspond to a Fibonacci series. You can also define simpler categories, e.g. low, medium, high.
You will achieve a special profit if you calculate the average of the actual effort at the end of each project and merge it with the averages of previous projects to a new average value. Thus, next time you need to plan a project, it will only be about categorizing the tasks. You can determine the actual effort by using the key figures from previous similar projects.
Do not Assume a Productivity Gain
If you think that this time it will be much faster than last time, you should have solid justifications. New tools and methods are not a solid justification.
If you introduce new procedures to increase productivity, remember that your team needs to learn how to do these things, which takes time.
Estimate with Planning Poker
Planning poker is an interesting method for arriving at reliable effort estimates. For this purpose, the estimators meet under the guidance of a moderator. Each estimator receives an identical stack of cards. You can buy such cards; one provider uses the numbers 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 on them, for example, as well as a ? for the statement that an estimator does not feel able to give an estimate. The numbers can mean effort in terms of days, or they can be in some other predetermined constant ratio to the real effort.
At the beginning, a product manager presents the project deliverables. The team can ask if anything seems unclear to them.
Then, each team member places the card with his or her estimate face down on the table in front of him. When everyone has placed down their cards, they turn over their cards at the same time.
The estimators with the highest and lowest estimate are given the opportunity to explain and justify their estimate. The group may discuss what they have presented. Discussion time may be limited by the facilitator or project manager.
The estimation process followed by discussion is repeated until the group reaches consensus. The estimator responsible for delivering a partial result always has greater weight in this process than the other participants.
The numbering of the cards takes into account that the larger the estimate, the greater the estimation precision. Thus, the estimator cannot pretend to be accurate for larger values, but instead has to choose between a pessimistic or optimistic value.
Effort and Duration
A frequent cause of confusion is the difference between “effort” and “duration”.
Effort, or “work effort,” is the total amount of time one spends on the operation from its beginning to its end. If you spend two hours per day for five days on a given task, then your effort is ten hours.
The “duration” is the length of the time interval between the start of an operation and its end. Using the example above, your duration is five days. Duration does not take into account weekends, holidays, etc.
4. Sequence Planning
With sequence planning, you put work packages into a logical order. You have to make sure that you consider dependencies, e.g. that certain work packages have to be completed before others can start.
Sequencing is done with the help of an operation list, in which the sequence of the work packages is determined. The operation list contains the work package number, the name of the work package (operation), the estimated duration of the operation and possibly already the person responsible for its
Bottom-up and Top-down Planning
Creating a project plan is, in many organizations, a repetitive process in which desired or required dates and budgets are initially set from the top. Those responsible for execution set their own time and effort estimates against this. In such cases, it is good to distinguish between the required or desired dates and available budgets, as well as the dates and effort to which a processor commits.
5. Scheduling
Most operations require resources (agents) to take care of their completion. These resources must be available between the start date and the finish date of an operation. Scheduling and resource planning are therefore strongly coupled with each other.
Whether one first assigns resources to operations and thus determines efforts and then obtains dates or one assigns resources based on fixed dates depends on which one is most flexible. If you cannot change either the resource availability or the dates, you will not get a working project plan.
Backward Planning with Milestones
Often, the delivery date for the project result is already fixed at the beginning, e.g. due to trade fair dates, customer obligations, or legal requirements. In such a case, it is advisable to plan backwards. In other words, start from the last deadline and organize activities going towards the beginning.
For example, if your deadline is May 21, start your plan by writing “May 21: Deadline” and then plan your tasks going towards the beginning of May, e.g. “May 20: Finalize Reports,” and so on.
6. Resource Planning
Resources are all the people and objects you need to execute a project plan. Theoretically, it would be more efficient if each employee could dedicate him or herself to one project at a time without being repeatedly disturbed in his workflow by other tasks. However, in many cases, this is not realistic.
It should also be noted that employees can typically devote less than 80% of their time to actual project work.
Project Manager View and Team Leader View
In many organizations, employees are organized into teams and departments, and are assigned to projects in accordance to their departments.
In order to keep track of employee workload, it is necessary to display the resources from the perspective of the line organization and from the perspective of the respective project management, as it is realized in the Allegra project management software.
7. Cost Planning
No project should be started without a profitability analysis. For this purpose, all expenses and costs must be known. The workloads result from the work breakdown structure, external costs and material costs from the resource planning at the latest.
The cost plan is thus based on the estimates on which the project plan is based. This underscores the importance of estimates of effort that are as accurate as possible, since they have a direct influence on the outcome of a performance audit.
More Information on Creating a Project Plan
If you want to learn more about creating project plans, check out our article on the 7 project management methods you should know.
