SurvivalBlog.com

Let’s focus on techniques you can use.

Project management is sometimes compared to a three legged stool. The legs are Time, Cost, and Quality. All three need to be kept in balance so that the stool doesn’t fall over. Another way of saying this is that you can have a project good, fast, or cheap; pick any two.

There are a lot of tools available for your use, when you want to design a project. Many are computer based, some are free, and some are expensive. Projects and project management has been around for quite a while, even before we had computers everywhere. While computer based tools can be great to use, you don’t have to have a computer to use these techniques.

If you do want to download some of the free PM tools for your computer, remember the old adage– if you are not paying for the product, you are the product. Not necessarily a bad thing, this is attributed to various people about free Internet services, but it goes back to work done by Richard Serra in the early 1970s referring to the economics of free television. I wouldn’t be surprised if someone didn’t use the concept to describe Roman circuses back in the BC era.

Something you probably do today is make a list of work to be done. Often you arrange this in the order the tasks need to be started in and you may even write down (or have an idea in your head) about how long each task will take. In the project management world, this is called a work plan or schedule.

Work plans can include many different levels of detail and can be viewed at those levels or rolled up to a higher level. A high level work plan for building a shed might have just a few tasks, such as:

• Prepare site
• Acquire materials
• Dig and pour foundation and slab
• Erect shed
• Run electricity
• Paint and insulate
• Move in

Each of these tasks can be broken down further into sub-tasks. Erect shed can be broken down into tasks such as:

• Build and erect stud walls
• Sheath walls
• Place and attach roof trusses
• Sheath roof
• Hang windows and doors
• Attach siding
• Shingle roof

Each of those sub-tasks can be broken down further as needed. After you get to the lowest level of task you need, arrange the tasks in the sequence they need to happen and figure out how long each task will take. At this stage, you want to track mainly the amount of effort. Later you will figure out the duration of the task based on the availability of people and other resources to help with the work.

Scheduling the work is the next part. Some of the work to be done on the shed depends on other work being done first, some of the work does not. You can have overlapping or parallel tasks on the work plan where there is no dependency. For example while you cannot erect the walls until the foundation is set and cured, you could build the stud walls and have them waiting to be erected, if you have the resources available. Likewise with acquiring material, this is a task that has to be done before the particular materials are needed, but it can be done almost any time before they are needed.

The amount of time between when you can start a task and when the task needs to be done so a dependent task can be started next is considered the duration of the task. The amount of time it actually takes to do the work is the task effort. The difference between the effort and the duration is referred to a slack or float time. Think of it this way; if you can’t build and erect the walls of a shed until after the foundation is poured and cured, then there is a dependency between completing the foundation and building the walls. So let’s say it takes five days to pour the foundation and let it cure. While you can’t build the walls yet, you can go ahead and cut the lumber to size. If cutting the lumber takes one day, and you can do it any time after you start on the foundation, then the lumber cutting task has four days of slack (five days of work for the foundation minus one day of work cutting the lumber). That slack is time your carpentry crew (if you had separate crews) could be doing something else.

The sequence of tasks that has no slack time is called the critical path. This is the set of tasks where a delay in completion of any of them extends the duration of the project. For example, if your foundation work is delayed by two days due to rain, then the project completion date moves ahead by two days.

You can try to make up delays on the critical path either by changing scope or design or by allocating or acquiring additional resources; for example, you may want to make up for the delay in digging the foundation by hand by renting a back hoe. This can get you back on track for on time project completion. However, it does so at added cost. (Remember the three legged stool.)

A resource list is another tool that can come in handy for preppers. Sticking with the shed example, you may have based your construction time estimates on how long it would take your best carpenter to do the job. If that person is only available for part of the time you need him or her, then you will need to slot in a less experienced person (resource) and understand how much longer the carpentry tasks will take with that resource. Again, this can be used to understand impacts to cost and schedule.

More tools include the risk and issue log. A risk is something that might happen to impact the project; an issue is something that did happen and impacted the project. This impact could be to schedule, cost, or quality.

• List out potential risks, such as weather delays, et cetera.
• Next to the risk, list strategies that can help eliminate or reduce the risk. (This is called mitigation.)
• If a risk does not come to be, then cancel the risk and note why.
• If a risk occurs, then it becomes an issue. You need to track the impact of the issue and document how you resolved (or failed to resolve) the issue.

A risk to building the foundation might be freezing weather impacting the strength of the concrete as it cures. Mitigation might be to add lime or another curing agent to the mix, which will add to the cost. Another mitigation for the risk might be to wait until warmer weather, which does not directly add cost but can impact the scheduled completion date.

Risk and issue logs not only help you manage the current project, they are an excellent source to use when planning your next project.

Another tool I want to mention is the RACI (sometimes called ARCI) chart. This is a grid that lists tasks or activities down the side and has at its top columns indicating people. At the intersection of the row and the column, you would indicate who is Responsible, Accountable, Consulted or Informed. Let’s say you had a family member coming to live with you and you had been storing miscellaneous stuff in the spare bedroom. The person who is accountable for cleaning out the room is you. The person who is responsible for cleaning out the room is your thirteen year old son, the people who are consulted before anything is thrown away is the owner of the item in question, and the person who is informed is the relative who will be moving in to the room.

The parking lot is probably one of the most useful tools out there. As you are dealing with stakeholders and trying to move forward to a particular result, frequently a conversation will pop up that is valuable information but may not be directly related to the discussion under way. In order to move forward and accomplish the goals for the meeting, you document the item on a parking lot so it doesn’t get lost, but then move forward with the topic at hand. This allows people to understand they have been heard and their discussion will be noted and acted upon, while reducing the risk of losing time by chasing something down a bunny hole.

Other PM tools that you can consider using should the project warrant are:

• Status reports – Periodic reports usually provided to stakeholders and the project team to keep everyone on the same page about the project and schedule
• Project status meetings – Usually with the project sponsor to bring him or her up to date on progress and to discuss issues the sponsor needs to help resolve
• Team meetings – Standing meetings held on a regular schedule (weekly, et cetera) with the people who are actually doing the work on the project. May include decision makers as necessary, if that is the only way you can get decisions made
• Budget – updated regularly (weekly or monthly) to track the project spending and ensure that you are still on track for cost or resource use

The important thing about using these tools is the purpose they serve, not the form they take. For instance, the team meeting might just be updating the family about progress on the shed Friday night at supper. The sponsor meeting might go something like “Hon, I don’t think this paint looks the way you thought it would. Can you come look?” Rather than include a bunch of images or attachments with this article, I would suggest you do some google searches and just browse around a bit to get some examples. I did include a few links to get you started.

Remember, you can build them with paper and pencil as well as with a computer.

• If this Gantt chart of a garden included a column for resource assigned, then it could double as a work plan.
• Sample Project status meeting agenda
• Sample risk log
• RACI Chart example

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.