Project management is the art of getting things done.
“So what?” you may ask, “I have been getting things done all my life!” Well, that’s probably true, but the use of project management techniques can help ensure that you get things done on time and at the cost you allocated for the work. We all have more demands on our time than we have time available to accomplish those demands. Sometimes there are also external factors, such as weather, expiration of permits, and others, that can impact our need to get things done in a timely manner and to get them done right the first time.
The use of project management techniques can help you mitigate the impact of these external factors. The truth is you are probably using project management techniques today. Things like making to-do lists, scheduling delivery of materials like concrete or fencing, creating a planting schedule for your garden, and so on are all examples of what we group into project management techniques. Learning more about project management will provide you with a broader set of tools that can make things easier for you.
Project management is not a cure-all. Various studies that look at the success of projects come up with numbers for the percentage of projects that fail, ranging anywhere from 40% to 80%. You do need to read a little into those studies to understand better. Some of them are true failures, but some of them count failure as a change of the project deliverable. For example, if you started a project to build a barn and during the project realized you really needed a tool shed, then some studies would call that a failure, even if you built the tool shed.
I always like to address why am I am qualified to write an article. In addition to using project management techniques during the time I spent in the Army as a Combat Engineer officer, I have been a project manager, program manager, and portfolio manager in the business world for over 25 years. For a while, I also taught project management to MBA students as an adjunct professor at a local university. I am currently managing several Information Technology projects with resources in five U.S. locations as well as Costa Rico, Singapore, and two locations in India. Just scheduling a conference call across all those time zones can seem like a project in and of itself!
What is a project and how does project management apply to prepping?
The Project Management Institute (PMI) defines a project as “a temporary endeavor undertaken to create a unique product, service or result.”
The key here is that a project is “temporary” in nature. For example, a project may have as its goal building up a one year supply of food for a family of four. The project would not include maintaining, using, rotating, and routinely restocking that supply. This is not to say that project management techniques can’t be used in routine day-to-day work, just that such use does not make the activity a project
Whether or not something is a project can also depend on the related infrastructure. Two of the IT systems that I work with currently store data for analytical purposes. One is a data warehouse, the other an operational data store. Because of the design, loading new data into one of them is a routine activity; loading new data into the other requires a project.
A similar prepping analogy might be filling a cistern with water for the first time. If the cistern is connected to a well with an electric pump and has controls to stop, or an outlet to redirect, overflow, then filling it up is routine. If you, instead, need to use a vehicle with a water tank or other means of physically (manually) moving water from one or more sources to your cistern, that is more like a project.
Some ideas where Preppers can use project management include:
- Building up a supply of food and medicine,
- Building or major repairs to retreat structures,
- Designing and implementing a retreat defense plan, and
- Building and upgrading a class of prep, such as weapons, tools, vehicles, barter supplies, et cetera.
Let’s start with learning some project terminology.
If you want to, you can jump ahead to the section on project management techniques and just refer back to this section if I use a term you are unsure of.
We have already defined the term project. Let’s talk about some other terms you will need to understand. I’ll try to give examples in terms of a project that is designed to build a storage shed. Other terms are:
Deliverable – what the project is intended to do. For example, a project to build a storage shed has as its deliverable a completed shed. Projects can have more than one deliverable. In addition to the shed, you may want a cold frame on the south wall for starting plants early. The cold frame is a second deliverable for the project. If instead the cold frame is something you will build next year after the shed is completed, then it is not a deliverable of this project but is a part of a new project.
Requirements – the list of needs that the project is to address. For example, how much do you want to store in the shed? How big do the doors need to be? It is important to express the requirements in terms of the need and not the solution; saying I need the door big enough I can drive the garden tractor through is better than saying I need a door four feet ten inches wide. Knowing that the door needs to support a garden tractor driving through it allows you to consider solutions that include double doors or a regular door for people and a roll-up door for larger implements. You can also consider whether or not you may acquire a larger tractor in the future. Separating possible solutions from the true need can be one of the hardest things to do. I frequently have to remind folks that it is hard to solve a problem before you know what it is.
Assumption – a baseline decision that the project design and estimate is based on. Sometimes I like to document an important requirement as a (frequently wrong) assumption so that we can be sure that it is addressed. For example, in building a storage shed, we would document the assumption that it is one story with limited room in the rafters for storage. If the sponsor was unsure whether or not there was a need for attic storage, then this is the opportunity for them to change the assumption. Changes to assumptions will likely result in a change to schedule, cost, and/or quality.
Customer – the people or organizations that benefit from or use the deliverables. Customers are frequently broken down to different levels or roles and can include the project sponsor, stakeholders, users, and others. This will be talked about more below, when we discuss the RACI chart. Customers for the shed would likely be anyone living at the retreat, although perhaps to varying degrees.
Constraint – rules or other limitations on resources or project components. A constraint for a shed may be the county permitting and inspections board regulations, or possibly the time available for construction due to the weather.
Task – pieces of work divided into meaningful sizes of work activity. For building a shed, the task called “build a shed” may be overly broad, just as a task “nail two boards together” would be too granular, particularly if broken down to the detail (or granularity) of “pick up a 16d nail with your left hand, hold it at the spot where you wish to drive it, using a 22-ounce hammer with your right hand, repeatedly strike the nail until it is flush with the surface of the board, repeat”. A challenge is that the work needs to be broken down to the level that is meaningful to the consumer of the project plan, thus a task may be “build the south wall” for one level of consumer, while it may be more along the lines of “cut studs to seven feet, measure and mark top and bottom plates at 24 inch centers, nail wall together, sheath, and erect” for another consumer.
Critical path – once the project plan is developed, the series of tasks that will delay the entire project if any one of them is delayed. For example, you have to pour the foundation before you can build the shed. You also need to acquire materials. Although both of these are important activities, a delay in pouring the foundation and letting it cure will delay the entire project, while gathering materials can be done at any time up until the materials are needed. There will be more on the critical path later.
Risk – something that might happen that would potentially impact the project if it did happen. A risk relating to the shed we are building might be that the county has a new building inspector who may substitute his or her opinion in place of the actual regulation. If risks are substantial, then you may work out a mitigation plan to minimize the possible impact of the risk, for example acquiring a printed copy of the building guidelines from the county department of inspections. You don’t need to document every bad thing that could possibly happen as a risk, just those that in your judgment might happen, and that if they did happen could impact the project.
Issue – a risk that occurred. You now need to address the issue and either resolve it or accept the impact to the plan and move on.
Estimating Risk – the risk that the estimate for a task or series of tasks might be wrong. Usually, it results in a degree of “slop” being added to the estimate. For example, if you truly believe it will take 20 hours to apply felt and shingle a roof and you estimate it at 25 hours, then the extra five hours is the estimating risk. This is not a bad thing in and of itself, however the PM needs to know that you did it. There are numerous examples of several levels of management adding estimating risk to a task “just in case” without knowing that the manager below them already did the same. This could result in something simple like a ten-hour task being estimated at 100 hours by the time the estimate finally made it back to the PM, who might be also inclined to add some estimating risk. Not having an accurate understanding of what makes up an estimate, including estimating risk, can result in bad decision making about scope and project changes.
Project Lifecycle (waterfall, iterative) – Projects progress according to a lifecycle. One of the most common is called the “Waterfall” lifecycle. You can visualize this as a stream flowing down hill, going over a series of waterfalls. Each waterfall represents a stage of the project, and the water only flows one way. Another common one is the Iterative lifecycle. In this one, you deliver smaller pieces of the overall project, and you deliver more than once at each stage. Building a storage shed is normally considered an example of a waterfall project. You start with the foundation, build the walls, put up the rafters, sheath the roof, shingle, hang doors and windows, and paint. If you were building a group of four storage sheds, you might want to follow the iterative approach, especially if you were fairly inexperienced at shed building. In this approach you would build the first shed, see how it turned out, and apply any design changes or lessons learned to the second shed that you build next.
Project stages – Typical stages that make up a project are:
- Pre-initiate – coming up with the idea, selling it to decision makers, acquiring funds. Usually the project manager is not involved at this point.
- Initiate – enlist the project manager, begin to assemble the project team, conduct formal requirements gathering.
- Planning – now that you have the requirements, decide how you will solve the problem or meet the needs.
- Execution – do the work according to the design. Also includes testing.
- Monitoring and controlling – runs through the entire project and includes the work the PM does as well as sponsor and project team status meetings.
- Closing – usually includes turning the deliverables over to the customer and may include training.
Milestone – a task that has no duration. It may be a marker for a certain event. A birthday is an example of a milestone.
Objective – a clear statement describing what the project is supposed to achieve. This should be written from the user’s point of view. A project normally has several objectives. In the case of the shed, objectives may include:
- Provide storage out of the weather for garden implements,
- Create a work station for potting plants, and
- Allow for the separation of flammable supplies from other important items that are currently stored together.
Program – a grouping of projects that are related to each other, while being large enough for each project to be managed separately. A program usually has one sponsor and may have a program manager in addition to project managers. Programs are frequently multi-year activities. Projects do not have to be part of a program. In the example used so far, the project is building a storage shed, the program may be building a retreat location. There would be other projects in the retreat program, such as start a garden, create and implement a defense plan, build housing, et cetera. However, each of those can be executed as a separate project.
Project charter – a document that is produced during the pre-initiate phase. It provides instruction on what the project is to deliver and is the authority for the project manager to kick off the project and begin spending resources.
Scope – A list of clear, easy to understand items that the project is to deliver (or in the case of out-of-scope not deliver). One of the biggest responsibilities a project manager has is to defend scope. This should not mean the project manager is saying “no” to requestors, although it often does, rather it should mean that the PM will ensure that a person requesting a scope change cannot do so without obtaining approval from the project sponsor, ensuring that additional resources are funded and that any impact to the timeline is understood and agreed to. A scope change to our shed project might include adding a basement and fireplace. Both of these can be done, however they will increase the cost and extend the delivery date, so the sponsor must agree to the changes.
Change Management – the process of moving users and their acceptance from the old way of doing things to the new way. Depending on the change, this may just include training or it may require using the full host of CM tools available to obtain and manage buy in, including communicating clear messages, creating a sense of ownership, dealing with cultural expectations, et cetera. It’s probably not a major consideration for our shed project, although things like letting children who are living at the retreat pick the colors for the paint can help get them involved and excited about the new shed. On the other hand, change management may be exactly what is needed to help convince a reluctant spouse to embrace preparedness as a way of life. Thinking of that. I may have to break out my old manuals from when I went through CM certification the next time I talk to my wife about prepping.
Stakeholder – groups or people who have a stake in the outcome of a project. This need not include everyone touched by the project; for example, the county building inspector is not a stakeholder for our project, even though he or she is involved. Stakeholders are often the people you need to meet with to gather requirements. One problem that frequently arises on projects is having one stakeholder speak for another. You may have a manager who used to be a sales agent wanting to speak for the agent because the manager used to do that job years ago. That is one of the surest ways to the wrong results. Insist on the person who will be the actual user giving you the requirements. For the shed, I would not want to determine the work surface height for the potting station myself, since my wife will be the one using it.
Sponsor – the person who has ultimate authority over and responsibility for the project. A large project (or program) may have an executive sponsor who provides funding and resolves issues that arise across organizational lines. The executive sponsor may delegate to a project sponsor the authority to deal with the project on a day-to-day basis. For our shed building project, the sponsor, stakeholders, project manager, carpenter, and chief cook and bottle washer are all probably the same person. That does not mean that applying project management techniques and principals don’t apply; it’s just that it may be easier (maybe too easy) to change scope.
Schedule (or work plan) – a document that lays out the tasks to be accomplished and the timeline and resources needed to accomplish those tasks. A work plan is frequently shown as a Gantt chart (see below).
Now that we have a common understanding of terminology, in the next installment we will get into using project management techniques.