Stop running project chaos and start planning for the unexpected…

Contingency plans are intended to handle situations in which things fail to go according to plan. They let you keep pursuing your project’s objectives with confidence even when everything appears to be going horribly wrong.

A contingency plan in project management is an important part of what you do.

During the course of any project, there are times when circumstances may change dramatically or even go out of control, requiring your project to be re-evaluated. As you make your initial plans for your project, it is recommended that you include both what should happen and what could go wrong and what you will do if the situation arises.

The steps for what to do when something goes wrong depend on the magnitude of the problem, and what’s causing it. This article aims to give you an idea of what steps to take, what considerations need to be made, and what the key elements are for creating a contingency plan.

All fields require a contingency plan

Contingency planning is essential for any endeavor. It’s what coaches do for their team when they are preparing for the next game, it’s what governments do when they build alternative bridges, and what hospitals do when they prepare for pandemics.

It’s what project managers do to plan for what happens if a team member gets sick, or if there is an emergency shutdown of the company’s building, or if the client isn’t happy with what you’re delivering.

What is a Contingency Plan?

A contingency plan is what you use when something unexpected happens to your project plan. Contingency planning ensures that your projects stay on course by helping you prepare for obstacles, making a way for better solutions to arise should you encounter difficulties along the way.

For example, what would you do if you client had to cancel the project in the middle? Or what if one of your team members doesn’t return from vacation on time, leading to a delay with completing certain parts of the project?

If you are not prepared you might have to abandon what you’re doing and come up with a different solution in a hurry. This is what contingency planning will help you avoid, so you can finish what’s been started.

Having a contingency plan in place for what to do when things go wrong ensures that your project won’t get derailed by what could have been prevented.

Purpose of a contingency plan.

When Apple did their IOS 14 update in the summer of 2021, it really put facebook in a bind. That update made it very difficult to retrieve users’ personal information. This made it more difficult for Facebook to track users behavior, resulting in less ad revenue.

Whatever your opinions are of whether this was a good thing, what it illustrates is how important contingency planning is.

Problems like this happen for all businesses of varied sizes. This is why it’s important for companies to have contingency plans in place. Contingency plans are born out of what is uncertain or what could happen that would be detrimental to your project.

Sometimes it’s not what you do but what you don’t do that puts your company in a bind.

Number of problems…

You can run into a number of problems when your team is executing a project. You could have a lack of deliverables, a lack of funding, or not enough time. The printer could break down, people could get sick, supply chains can get bogged down.

Many things can go wrong like:

• Your client’s not satisfied with your work.
• Your client decides to cancel the project leaving you without a source of income for your business.
• Significant changes in product requirements.
• Market changes.
• Even weather conditions could make it difficult for a collaborator to show up to perform what they have been contracted to do.

Whatever the case may be, you need to answer the question: what do you do when your project strategies are put in jeopardy? This is what contingency plans are for. They are meant to be the anticipatory steps in what to do when things break from the original plan.

Don’t fall into the trap…

Don’t fall into the trap of thinking that you don’t need a contingency plan because you’re certain your project strategy is solid.

Even what seems like the most foolproof project needs contingency plans in place, because what if your suppliers drop out? What if nobody shows up on time? What if you run out of supplies or money?

A project manager’s job is all about mitigating risks and preventing problems before they happen. If you don’t do this? Well, then by definition it’s what is known as a “risky project.”

All projects need contingency plans just in case something goes wrong, and what that will look like is different for every project.

How to write a contingency plan in 4 simple steps

It’s now time to create your project contingency plan.

Remember your contingency strategy should be placed within the broader context of your project plan. Which means, you should have answered the following questions: What is the scope of your project? Who’s going to do what? When are they going to start and finish what they’re doing? How much is this going to cost? What equipment is needed?

Remember, contingency plans should be developed before work starts, and should cover what you’ll do if things go wrong. So after your ideal plan is written it’s time to hedge it against the potential pitfalls.

Step 1: Sketch out your project flow.

Picture what’s going to happen throughout the life cycle of your project. The better you are able to identify and articulate what the project flow is, the easier it will be for your team to understand what contingency plans need to be made.

Answering the following questions will help you identify what could go wrong:

• What’s the project’s objective?
• What are the major milestones and the corresponding tasks needed to accomplish the project’s objective?
• What are the major tasks and their dependencies?
• Who are the project’s key personnel, and what talents or talents do they have in their roles on the project?
• What resources are required for the major tasks?
• Is there specialized-uncommon-equipment used to complete the project?
• Is the project dependent on a specific location?
• Is the project dependent on a specific time of the year?

These questions may seem tedious but many of them are basic questions that directly relate to your project. And once you get a handle on what the major project milestones are, you’ll be able to identify what your contingency plan should include.

Step 2: Create a list of risks for each major milestone.

Here is where you can get creative and try to think of what could go wrong.

Let’s use an example of a project that’s dedicated to adding a new and updated store page to your company’s website.

The milestones may look something like this:

1. Initial planning meeting with key personnel to determine what the project entails. For the sake of the example our key team members will be product suppliers, web designers, coders, copywriters, media buyers, and customer support.
2. Determine what products need to be included on the page.
3. Create a mockup of what the store’s new look will be like; using what was learned during step 2.
4. Order the products.
5. Research the marketing. What keywords are needed for the new page? What are the demographics of our current customers?
6. Design, code, and implement new webpage on companies website.
7. Launch website.
8. Start running ads for your store.
9. Check in with customer support.

There are several risks that could happen at each of these milestones. One of the risks is what if your supplier decides they don’t want to work on what you’re asking them to do? What’s your contingency plan for this problem?

Or let’s say your ads get great traffic, what happens if your servers can’t handle the amount of viewers?

What if your traffic source, for the sake of argument, is buying Google ads and gets rejected because of a bug in Google’s algorithm?

All of these problems can be mitigated with contingency plans.

Step 3: Determine what actions to take if problems occur.

This is where things get a little bit fuzzy and you may have to rely on your team member’s talents and expertise.

Once you know what normal project completion looks like and the potential risks, determine what the contingency plans should be for what could go wrong with each task, milestone, and dependency.

Example:

Let’s say because of supply chain issues in the wider market you run the risk of not being able to get what you need from your supplier. There are several things that could happen.

The supplier may not be able to give you what you’re looking for because of what they think the market is going to do.

Maybe there’s a chance they will, but it will cost significantly more money for them to do so. Maybe what you’re asking for can’t be done. Or what if what your supplier is telling might not be the only option?

Is there another product that has most of what you need and it won’t cost what they want for their products? Do you have to use this supplier at all, or could you find what you need somewhere else?

Creative solutions are what helps create contingency plans.

Once everything that might go wrong has been determined, the project’s necessary actions will be outlined. And once it’s clear what resources are needed for each stage and how long it’ll take, your contingency plans will be what helps you to execute what needs to happen.

Step 4: Share and periodically revisit your contingency plan.

The last step of contingency planning is to share what your plans are with both team members and any project stakeholders. This ensures everyone has the same information which means no one will be caught off guard if something goes wrong.

Then, after each milestone, revisit what you’ve done so far, what worked well, what could have gone better, what you can do to improve what’s going on in the project.

Have you ever written someone a letter and then it sat on your desk for a week because you didn’t get around to finding a stamp and putting it in the mailbox?

It’s so easy to mentally check something off as “done” before it’s “done done.”

Yet the intended purpose of something like a letter isn’t achieved until the other person receives it. In project management, these sort of tangible tasks are known as deliverables.

Every project involves completing them. Writing code, planning a budget and creating slides are all examples of deliverables. Service businesses like consulting have deliverables as well.

It’s only by handing these deliverables off to their intended recipient that a project can flow from one task to the next.

For this reason, creating good deliverables and bringing them to completion are integral to success in project management. In this post, we’re going to cover two methods for developing and completing deliverables. But first, let’s define just what deliverables are.

A Definition of Deliverables in Project Management

A deliverable is the completion of a specific and tangible amount of work that includes handing off the newly created increment to the appropriate person. For example, in software design, you might design some software, write it, debug it and do quality assurance, but the customer needs to receive it before it’s complete.

The Project Management glossary defines deliverables as:

“Any tangible outcome that is produced by the project. These can be documents, plans, computer systems, buildings, aircraft, etc. Internal deliverables are also produced as a consequence of executing the project, and are usually only needed by the project team. External deliverables are those that are created for customers and stakeholders.”

And so a deliverable, generally, is something that you can really touch and see. It’s a physical item or a file on a computer.

For many projects, the ultimate objective is a deliverable, such as a house or an airplane. However, smaller deliverables accrue throughout the entire project. They include things like reports, code repository and powerpoint slides.

Teams have deliverables they share amongst themselves. This could be something like debriefing the client, writing up a summary, then presenting the summary to the team.

Or at a retrospective, the team may create goals for the next sprint that are written up and shared with the project leader.

Examples of Deliverables

Deliverables look a lot different depending on the type of industry you’re in. Let’s look at some examples of deliverables within various types of projects.

Construction

Deliverables are easy to grasp in a visual, tangible setting. In construction, the final deliverable is whatever the project is set out to create: possibly a house, an office building or a parking lot.

But the team completes many smaller deliverables as it moves toward the end goal. In the initial stages, the architect submits plans to the client, and the contractor makes a bid. And throughout construction, each completed step is another deliverable. This includes laying the foundation, building the frame, adding wiring, electricity and insulation, mounting drywall, installing flooring and tiling, and finally things like appliances, cupboards and lights. Final deliverables are tests to ensure the building is up to code.

Software

The final deliverable in a software project is usually something like an app, a website or an e-commerce site.

Many software teams complete projects in an agile framework these days. This means they select small individual batches of work to complete in one iteration which takes around two weeks. At the end of this iteration, they’ve created a deliverable, called increment, which is one small portion of the final deliverable. This increment is passed onto the client for review.

The team has many internal deliverables throughout a project as well. For example, if the project is running over budget one person may be assigned with coming up with a plan to rein in costs, then write it up and present it to the rest of the team.

Consulting

Consulting, essentially, is giving advice. People come to a consultant when they have a pressing need and believe the consultant has more insight or expertise into the area than they do. The service, then, is the answers to questions that the consultant provides. Since advice isn’t tangible, this doesn’t qualify as a deliverable.

However, oftentimes this advice is presented in a tangible way. If you’re laying out a migration plan for a company to go from an old system to a new one, a deliverable may be a flow chart that visually represents the path and timeline you recommend the team follow.

In another instance, a consultant might advise a company on how to go mobile. This assignment would require a lot of research and interviews, and so the deliverable would be a report which summarizes the research and concludes with a recommendation.

And so even a project like consulting includes deliverables in its project planning.

In sum, deliverables look a lot different depending on the type of industry and the nature of the service provided. However, deliverables are always a tangible product. Many deliverables are completed in a short time frame of a week or two. And a large project is the compilation of a long series of deliverables.

Checklists for Deliverables

In its simplest form, a project is a list of tasks that leads to a desired outcome. Project management is about creating this list and developing a strategy to complete everything within the project’s budget and timeline.

This isn’t an easy job. When a task is too vague and includes only a few specifications, a team may create something different from what the client had in mind. It’s also easy for a team to mark something off as done before it’s really complete. This prevents a project from moving onto the next item on the list.

In order to prevent these two scenarios from occurring, it’s good to have some systems in place. Let’s look at two list exercises to assist with this; one for creating deliverables and another for completing them.

The “Is-is not” List

Have you ever asked someone to pick something up for you at the store, and what they brought back was the wrong brand or the wrong flavor? At this point, you realize that you needed to have explained your request more clearly.

The same thing happens in projects all the time. The client or project manager communicates a deliverable, but the team hears something completely different.

In order to keep a project on track, the parameters of a deliverable need to be outlined so that everyone understands the expectation. One easy way to do this is with an “is-is not” list.

This list entails making two columns on a sheet of paper, with “is” and “is not” written at the top of each column. The stakeholders in this particular deliverable then each contribute to determine what the deliverable will and won’t be.

If the deliverable is a marketing plan, for example, then some items in the “is” column might include: “under 30 pages,” “organized with headers to be readable and scannable,” “uses photos alongside text,” and “include a social media plan.”

The “is not” column might include: “no long paragraphs,” “no passive voice” and “no magazine ads.”

This list is useful in defining all sorts of deliverables. Even though it’s a simple exercise, it really gets everyone clear on the expectations.

The Done Checklist

Have you ever walked around an office looking for a report, and then someone pulls it from below a pile of papers and says they finished it last week?

If so, you’re not alone. It’s easy for all of us to think we’ve finished something, mentally check it off as done, and move on to another task entirely. However, as mentioned earlier, the deliverable isn’t complete until it’s been received by the intended recipient.

The Scrum methodology has created something called the “Definition of Done” to address this issue. Here is how Ken Schwaber’s organization, The Home of Scrum, defines it:

“Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.”

(In this definition, “increment” means the same thing as “deliverable.”)

The Definition of Done, essentially, is a list of all the criteria that must be accomplished to mark a deliverable off as complete.

To this end, many teams create a “done checklist” around a deliverable, to ensure that everyone understands the hoops that need to be jumped through before calling it a day.

For example, on a software team, the “done checklist” might include: writing code, testing, debugging and quality assurance. The final item on this list always includes presenting the deliverable to the end user, who is either someone in the office or the client. The value really hasn’t been added until this final step is “done”!

In sum, deliverables need to be created with a lot of TLC, and it takes stick-to-itiveness to bring them over the finish line. Having processes in place helps to achieve this.

Final Thoughts on Deliverables

A deliverable is easy to see and touch and measure. For this reason, clients like to see deliverables in a project. For example, it adds some weight to include things like slide decks or reports to a consulting proposal.

This leads to a tendency for a team to define success around the deliverable. This isn’t always the best bullseye to aim for, however. The real objective in any project is adding value to the client. That’s ultimately what you’re working to deliver.

To this end, it’s usually good to plan small deliverables around shorter time frames. Clients may not entirely understand what they want in terms of a final deliverable at the beginning of a project. They may only be able to clarify their overall objective.

When a project is completed piecemeal, it creates an opportunity for the client to look at what has been developed and assess how the project is going.

And so rather than look at a deliverable as one enormous task, it’s generally much safer for the team to get into the practice of decomposing projects into smaller units that can be completed in a short time frame. Based on the feedback from the client, the team can then determine its next plan for deliverables.

Have you ever had a requirement that was so vague it almost seemed pointless? And the team had to do all sorts of work trying to figure out what it meant. At other times, though, a requirement is so lengthy and specific it’s like reading a textbook.

When gathering requirements is done well, it leads to a fruitful project. Everyone has clarity on the end goal and the client ultimately is satisfied.

But it’s hard to find the right balance between making requirements too dictatorial or too flimsy.

And there’s all sorts of challenges to gathering them. If there’s not equal contribution from all stakeholders, they end up being too business oriented or too tech oriented and they don’t consider the end user.

The point of a requirement gathering session is to unlock the power of the team. It’s about combining everyone’s expertise, and then brainstorming around the project goals. Finding the right requirement gathering technique is key. It allows each person to equally contribute their insight, and the team is able to create a thorough list of requirements with the right balance of specificity and openness.

Let’s consider the characteristics of good requirements in agile, the various types of requirements a team needs for a project and then explore some methods for gathering requirements.

Requirements in Agile

When a team gets excited about an idea, it’s easy to jump right into the design phase. However, without a good plan in place they’ll probably find themselves backtracking over and over again.

Gathering requirements is about developing a good understanding of what the job is before you break ground. It defines the scope of the project, and clarifies to all the stakeholders what the project is working toward.

• Benefits of Requirements

  Taking the time to gather requirements gives the team a clear idea of where they’re headed, so they save time and money by not going down any rabbit holes.

  Additionally, the development team is able to quickly move past the discovery phase and into design and development. And creating good requirements leads to the best possible product for the client.

• Agile Requirements

  One of the principles in the Agile Manifesto states: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s advantage.”

  There was a time when requirements were presented like a textbook for the team to follow, and the objective was simply to read the instructions and get the job done.

  In agile, however, the orientation is on providing a valuable product to the customer. This entails having an ongoing conversation with the customer and updating requirements throughout the project. First and foremost, the requirements consider the client’s overall objective; they’re not focused around simply fulfilling a list of specifications.

• Characteristics of Good Requirements

  Two areas to focus on when developing requirements are the project goals and tech stack. The goal, at the beginning stage, is defined as the problem you’re trying to solve. Usually, it’s not a specific feature at this point. When the team brings together its collective knowledge and skill set, they’re able to determine which coding frameworks and languages would bring about the best possible user-friendly product.

  A requirement quickly and effectively communicates its acceptance criteria. They say that a picture tells a thousand words, and this is so true in the case of requirements. Oftentimes, by including a photo with the requirement in lieu of text, everyone understands exactly what is expected of them.

4 Phases for Gathering Requirements

As discussed, requirements in agile are never set in stone. Collecting and revising requirements continues until the project’s completion.

However, taking a thorough approach to gathering requirements at the project’s beginning establishes a strong foundation. Here are four key phases a team goes through in order to gather a comprehensive list of requirements.

1. Preparation Phase

   The preparation phase is about learning the basics. The team researches the client and their industry. It researches similar products already on the market, and understands their features.

   The team looks at what the client has already outlined as requirements and brainstorms any questions they have around it.

   They prepare for a meeting with the client by assigning everyone roles, including note taker, moderator and interviewer.

2. Gathering Phase

   The gathering phase entails speaking closely with the client to further understand their perspective and the product goals. Meeting in person is ideal, as it creates a space for everyone to share, and eliminates misunderstandings.

   Develop further clarity around the product goals by asking how the client came up with the idea. This session isn’t always about finding clarity around a specific feature, but more about understanding the desired outcome.

   Determine the project’s budget, scope and timeline. Also, come to a deeper understanding of the company and its structure, and identify a contact person for the team. Create some protocol around changing requirements.

   Documenting everything makes it easy to reference this information later on in the project.

3. Follow-up

   When all the requirements have been gathered and documented, communicate them to all project stakeholders. Finding agreement around the priorities and goals allows the team to move into the design and development phases.

4. Revisit

   Finally, the team is committed to continually re-visiting the requirements. At the end of each iteration, the increment is shared with the client for feedback. Depending on how the process is going, the requirements may, and probably will, change from time to time.

   Updating requirements entails gaining approval from the client’s contact, then coming to an agreement around budget and timeline changes.

   As you can see, gathering requirements is an ongoing process. Properly setting the stage at the beginning of a project ensures that the goals are clear and that upcoming changes take place easily.

3 Classifications of Requirements

Requirements need to be thorough, meaning they represent all the facets of a project. When they’re too siloed, it creates blindspots. For example, requirements that are tech-heavy may not really address user needs. A majority of business-oriented requirements may not delve into the technical capacity of the team.

Requirements generally are grouped into three key areas: business, user and technology. Let’s look at the characteristics of each of these.

• Business Requirements

  Business requirements clarify questions such as: Why would a customer buy the product? What problem does it aim to solve? How does the company plan to earn revenue with the product?

  Addressing the business side of a project entails having a keen understanding of the client’s industry, and the competitive advantage they offer.

• User Requirements

  User requirements focus around the customer experience. The aim is to find a solution that entices the customer, is easy to use and that serves a needs not formerly found on the market. These requirements are similar to business requirements, but they’re focused entirely on the user.

  The expertise of the product manager is essential in creating these requirements, as they’ve researched the market and understand the customer and his or her problems.

• Technical Requirements

  Technical requirements look at things like the backhand functionality of the product, its features and the platform where it’s developed.

  The client may not understand everything about the technical aspect of the product and so visuals are oftentimes helpful here. By effectively communicating all the features the client wants on the product, the development team is able to come up with a tech stack that best serves the customer’s objective.

  In sum, a project has a rounded approach when it creates business, user and technical requirements. This means carefully considering the project from all angles, which in turn leads to a well-developed product.

4 Requirements Gathering Techniques

Once you’ve completed the preparation phase and have developed a good idea about the client and their vision, it’s time to gather requirements from all stakeholders. An in-person meeting is the ideal context for gathering requirements. But it’s still possible for remote teams.

Here are four approaches for gathering requirements.

1. User Story Creation Session

One method for gathering requirements entails having all the stakeholders gather together and each individually contribute requirement ideas in the shape of user stories.

Each stakeholder, including the development team, the client, the product manager, the project manager and ideally a customer, contribute as many ideas as they can come up with. The user story format assures that the requirements are oriented around the end goal.

These requirements are added to the product backlog. At this stage, many of them will be quite large. The product owner reviews and prioritizes them according to the product goal, and the team collectively decomposes the stories and organizes them into features and themes, and eventually items small enough to be included in a single sprint.

2. Solo Requirement Creation Before Collaboration

Each stakeholder in a project has a particular area of expertise, and another area they know very little about. For example, a developer has a sophisticated understanding of the technological possibilities of the product, but may have a poor understanding of the market and the customer.

On the other hand, the product manager is usually the opposite. They have thoroughly researched the customer and the market, and know just what sort of products would suit their needs. However, their technological knowledge is limited.

And so various stakeholders, naturally, focus requirements around their area of expertise.

When a team isn’t able to meet in person to gather requirements, then another effective method is to communicate the basic project goals to everyone. Then, each stakeholder individually writes whatever requirements they think of. Later, these requirements are presented to other team members, perhaps in a video conference platform, for others to provide feedback and further refine the requirements.

For example, the project manager would outline basic issues related to scope, budget and timeline, while the client and product manager requirements would be more focused around user and business requirements. The development and engineering teams outline mostly technical requirements.

The objective is to reap the benefits of each persons’ expertise. At the same, it’s important that each requirement complements the others, and so the secondary meeting is instrumental in rounding out the list of requirements.

3. 9-Step Brainstorming Session

This method for gathering requirements is courtesy of Agile Coach Scott Killan. It’s a fun exercise that draws on the power of anonymity and continual brainstorming to unleash the power of a team. It’s a highly collaborative, yet structured process for generating a thorough list of requirements.

One great feature of this technique is that it’s versatile; it works for groups as large as seventy and as small as six. It has nine distinct steps and each can be time-boxed to suit your time frame.

This method must be in-person, and it works especially well when it includes a variety of stakeholders, including customers.

• Prep Work
  Find a room with smooth walls and tables and chairs. Ideally, have a projector in the front of the room to broadcast the goals to the whole group. Send an email to all participants beforehand, outlining the objectives of the session.

• Supplies
  For this activity you’ll need sharpie marking pens, small stickers with red dots, and 3×5 sticky notes, some yellow and some another color.

The 9 Steps:

1. Introduce the Idea

   Introduce the project and any key stakeholders. Clarify the overall project objective (not specific features), then provide examples. Ask the audience to give ideas of other examples.

2. Brainstorm Requirements

   With a good understanding of the project and its objectives, everyone uses the sticky notes to write down as many requirements as they can think of, using one sticky note per idea. The facilitator collects these as they are written, in random order. This way, no one knows who wrote the idea.

3. Announce All Requirements

   When all the requirements have been collected, the leader and an assistant read them aloud to the room alternately. As they read the ideas, they place them onto the wall in random places around the room. If people come up with additional ideas, they write these down and bring them to the leader.

4. Categorize Requirements

   The next step involves categorizing the requirements. Working in groups of 2 to 4, the group mingles and rearranges the requirements into various categories. This usually generates a lot of enthusiasm as people mill around and discuss. People can continue to add requirements at this stage.

5. Label Each Topic

   The second color of sticky notes comes out at this stage. Continuing to work in small groups, each category receives a label. People may choose to work around a category that most interests them, such as quality assurance or testing.

6. Simplify and Clarify

   At this step, everyone looks through all of the requirements and removes duplicates by wadding up the piece of paper and throwing them across the room. This is where things start to get fun (and a bit messy)!

   If two requirements sound the same but really represent two distinct ideas, they’re re-written to clarify the meaning more precisely.

7. Prioritize Categories and Requirements

   The small groups prioritize the requirements in each category, and the most important categories are identified as well.

8. Discuss the Top Three Items

   At this point, people return to their tables to discuss the top three requirements in each category. This keeps everyone thinking and brainstorming around the most important topics.

9. Vote on the Best Requirements

   As a final step, everyone goes around the room and votes on the most important requirement per category. Some surprising winners may emerge: even the fourth requirement sometimes ends up receiving the most votes.

   And so that’s a summary of a requirements gathering exercise. The anonymity of this project is a great strength, as it levels the playing field and everyone’s contribution has equal weight. Additionally, everyone leaves with a good understanding of the project, and they’re focused around the most important requirements. The sticky notes can be used to form the product backlog.

   At the same time, this activity has its limitations in that it must be in-person, and the coverage of requirements, though broad, is somewhat superficial. There isn’t any drilling down on one concept. This fine tuning would occur at a later meeting.

4. Storyboarding

A picture oftentimes says more than what ten pages of text could communicate. Visual learners especially benefit from the storyboarding technique for gathering requirements.

With this requirements gathering technique, the team draws images of the final product, and the stakeholders and the client contribute suggestions and ideas.

The pictures include all the product’s basic requirements. If the team is developing an e-commerce store, for example, they’d present images of the sign-in page, the individual listing page, the cart and checkout.

This method is helpful for people who don’t have a lot of technical knowledge; they’re able to still offer advice and ideas.

Including an image of the end user is a strong reminder to keep the final product user-focused as the team develops all the specifications.

And so there are some ideas for gathering requirements. When determining what method works for your team, consider its size, the dynamic on the team and the various learning styles of those involved.

Have you ever had one of those days where you had around ten hours of work to do, and only four hours in which to do it? Even if you wear yourself out by going into speed-mo, there’s seemingly no way to get it all done.

At times like these, it’s easy to just throw your hands in the air and give up.

We all wish, from time to time, that we had a few more hours in the day, or an extra week or two in a big project.

Although we can’t create more time, there often is a way to meet a big project deadline, or complete all the errands on our to-do list. It has to do with carefully arranging work in the most time-efficient way possible.

Utilizing a project management technique called laddering helps to find the wiggle room in a tight schedule. How does it work? That’s what we’re about to lay out.

Key Terms

Before looking at how laddering improves project efficiency, let’s first define some key project management concepts and terms.

Project Sequencing:

This is identifying all the steps in a project, and arranging them in their proper sequential order. For example, in a building project, first you build the frame, then add insulation, then put in drywall, then paint and finally add appliances.

Work Breakdown Structure (WBS):

This is breaking down projects into smaller components of work, from beginning to end, and then arranging them according to the project sequencing.

Work Packages:

Work packages are individual components of work on the work breakdown structure. For a construction project, “installing drywall” and “painting” would be individual work packages.

Hammocks:

Hammocks are the smaller individual tasks that make up one work package. For example if “buying land” is the work package, the hammock activities are to research properties, view properties, secure a loan and close on the property.

Critical Path:

This is the order in which work packages need to happen for the project to be completed on time. The critical path is the longest path on the work breakdown structure. It is measured in units of work packages.

Lead Time:

Lead time is the minimum necessary time between the start of one activity and the start of a related one.

For example, let’s say you have two tasks: digging a ditch then laying pipe. The ditch digging takes eight hours, and laying the pipe takes four hours. You can start laying pipe four hours after the ditch digging has started, so the ditch’s lead time is four hours.

Lag Time:

Lag time is the required time between two jobs. For example when painting a wall, there is lag time between applying the first and second coat of paint, so that the first coat has time to dry.

Laddering:

Laddering is when activities proceed in lockstep with each other, so as to keep the project on schedule. The activities are linked to one another like rungs on a ladder.

How to Use Laddering in Project Management

In order to schedule a project in the most efficient way possible, it’s necessary to understand how all of the tasks relate to one another, and identify any lead and lag time between tasks. Once you know this information, it’s possible to scrutinize a schedule and apply the laddering technique. Here are the steps to take:

1. Select two work packages adjacent to each other on the critical path.
2. Break each work package down into smaller hammock activities. Determine the order in which the hammock activities need to happen, and whether they have any lead or lag time.
3. Arrange the hammock activities in such a way that they are completed in lockstep with each other and decrease the total units on the critical path.

In order to select work packages suitable for the laddering technique, identify those that can be broken down into hammock activities, and especially those with lead time.

An Example of Laddering

We use the laddering technique all the time in our daily life. Here is an example of typical errands on a Saturday afternoon. Let’s say you have five hours, and a list of errands and chores that take six hours. Each item on this list represents a work package:

1. Purchase Groceries – Half an hour
2. Get a haircut – One hour
3. Visit the Dentist – One hour
4. Do Laundry – 2 hours
5. Make Dinner – 1.5 hours

How can we fit the six hours of work into only five hours?

Let’s start by selecting two adjacent work packages and determining their hammock activities. In this example, the first three activities cannot easily be broken down, so let’s focus on the last two.

Laundry Hammock Activities

Washing – 30 minutes

Drying – 60 minutes

Folding – 30 minutes

Dinner Hammock Activities:

Preparation – 30 minutes

Cooking – 45 minutes

Serving – 15 minutes

Here is how to arrange these hammock activities in order to save time:

• Prepare dinner at the same time that laundry is drying. This saves 30 minutes.
• Fold laundry while dinner is cooking. This saves another 30 minutes.
• Now the laundry is complete, and the cooking is finished. Time to serve dinner!

Viola, you’ve saved an hour by laddering the tasks within the work packages of “laundry” and “making dinner.” Notice how these tasks were completed in lock step with each other—you needed to be folding the laundry at the same time as dinner was cooking, and to prepare dinner while drying laundry, otherwise the time wouldn’t have been saved.

Laddering works in all sorts of projects where work packages can be broken down. In software design, for example, design usually precedes development, and development precedes testing. However, when you identify the project sequence, work packages and the critical path, it’s possible to identify where to break packages into hammocks and ladder to save time.

What is the one thing most project managers lack? Right! A chance to lift their heads from the day-to-day routine and see if others know a better way of managing projects.

Surfing the net to find the exact book you need may take hours of your precious time. The good news is – we’ve done the work for you.

In this article, you’ll find the eight best project management books to give you a solid understanding of what works well and what should be done differently in your next project.

Pick the books you need most. Read them. Apply them. Chances are, your success is only a book away.

1. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Seventh Edition

Author: Project Management Institute
Year of publication: 2021

This is the go-to Guide to keep on your desk if you’re planning to start a professional career as a project manager.

Also known as PMBOK, it’s a must-read for the PMP (Project Management Professional) exam, so don’t expect to read it like a novel. It’s more of a comprehensive guide or an academic textbook. The book consists of two parts – the Guide and the Standards, which nicely complement each other.

The content of the book is detailed and well-presented. It sets out project management common terminology to help you build the foundation for entering the field and be able to communicate with your peer practitioners.

PMBOK seventh edition: how is it different from the previous versions?

The previous editions presented project management as a process (i.e., in its linear order), taking you through the stages of project planning, development, and execution. The seventh edition, on the other hand, is principle-based. And it’s much thinner, just in case books over 600 pages tend to threaten you.

PMBOK is more a project-oriented resource guide that you can read and use; it’s for putting project management into practice rather than passing an exam. That’s why you’ll find the essentials rather than the details in this version.

The latest edition is based on the premise that project managers often forget what they’re doing and why they’re doing it. One part you’ll find particularly interesting is the chapter about systems thinking and critical thinking – two crucial elements that are so often overlooked in project management.

By the way, you can still choose a previous version of PMBOK if you’re totally new to this field and want a structured view of the key processes.

The author of the book is the Project Management Institute (PMI), which is responsible for setting industry standards. No wonder this book is picked by those who are studying project management or want to deepen their knowledge in PM.

2. The Fast Forward MBA in Project Management- Sixth Edition

Author: Eric Verzuh
Year of publication: 2021

If PMBOK is the official guide, then “The Fast Forward MBA in Project Management” is the unofficial textbook – more user-friendly and readable that simplifies most of the jargon used in project management. It doesn’t replace PMBOK but comes to be a great supplement to it.

Through useful case studies, Eric Verzuh gives an excellent overview of key topics (from collaborative problem solving and problem analysis to building high-performance teams). Expect your copy to be filled with notes that’ll help you every step of the way – whether you want to pursue a certification or further refine your skills.

Many chapters have interactive elements – exam practice questions, an assignment matrix, or links to valuable resources to help you kick start your career. No more struggles about how to apply project management principles to real-world scenarios.

The author masters his craft. He has worked with major corporations like Adobe, Boeing, GE Capital, and Nordstrom for over twenty years. Obviously, he knows first-hand what he’s writing about.

The sixth edition: how is it different from the previous versions?

The latest edition of the book has an additional chapter to help a project manager to become a leader. Eric Verzuh believes that without leadership skills, managers lack two critical abilities – to bring all stakeholders together and transform project management into a platform for innovation.

The book is the right fit for new project managers, veterans, as well as instructors who teach project management.

3. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses

Author: Eric Ries
Year of publication: 2011

Have a new product idea? Want to navigate smartly in the Hi-Tech market?

Ideal for startups and entrepreneurs, this book will help you initiate and manage growth like a pro. You’re invited to take a well-documented methodology and apply it to the fast-paced, high uncertainty world of startups.

Among the best books on lean project management, this one by Eric Ries clearly stands out. The author gives a good overview of how lean and agile methods apply to the startup world. The real case studies put everything into perspective to help you learn from others and up your game in this field.

More and more organizations adopt lean practices because they “produce greater customer satisfaction and improved profit margin.”

The examples Eric Ries uses are more focused on software SaaS products; therefore, this book should be great for silicon valley practitioners and folks from tech companies. Furthermore, it’s a worthwhile read for those who are part of a large organization that has become stagnant and lost its way. “The Lean Startup” will instill a fresh breath of air into your vision and daily work. However, managers who are successfully running a business most probably are already doing what the book sings the praises of.

The author of the book has a solid career as an entrepreneur with quite a few startup successes and failures along the way. He is an Entrepreneur-in-Residence at Harvard Business School.

4. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

Author: Jake Knapp
Year of publication: 2016

It reads like a friendly guide that takes your hand and walks you through the process described as a sprint.

Jake Knapp spent ten years at Google and Google Ventures, where he created the methodology. The sessions last for a week, and the ideal size is seven people or fewer for a sprint. In the book, you’ll find the description of the entire process – from mapping your ideas to testing them. For your convenience, the author also included checklists at the end of the book to keep as reference.

The book is packed with useful details. The ‘no device’ rule, the ‘nobody knows everything’ approach, the ‘how might we’ method, the ‘prototype mindset’ – these and many more tools are provided to help you rephrase your business problems into questions and arrive at ingenious solutions.

You may find the practicality of the 5-day sprint process too challenging (depending on the business environment you’re in and the teams you’re working with), but still, there are some really great ideas that you can put into use. Why? Simply because sprints are all about focus. They teach you how to make the most out of your working hours.

The book is ideal for founders and top company management looking for unconventional methods to improve productivity. It’s also a nice choice for startups who need to take an idea, collect data, and launch the product without breaking the bank.

Jake Knapp has coached companies on the sprint process, including teams at Slack, Uber, the New York Times, and LEGO. Read the book to steal the wisdom these giants have been using to this day.

5. Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs

Author: John Doerr
Year of publication: 2018

OKRs is a management methodology that stands for Objectives and Key Results. As defined in the book, it ensures that the “company focuses efforts on the same important issues throughout the organization.”

Among the project management books to read, this one is a great introduction to the origins of OKRs and how to put it into practice. It provides valuable explanations for what can go wrong with top-down objectives and how companies can use OKRs to improve organizational effectiveness.

Loaded with interesting examples, the book does a great job outlining how to set up objectives that are measurable, boost accountability across teams, and align people’s work to bigger business objectives. In short, it’s about setting the right goals for the right reasons.

Those seeking advice on the what and the how of doing things in their business will find this book to be the perfect fit. It pulls the curtain aside to reveal the benefits of having a system for setting goals, choosing a direction, and mastering the art of execution.

John Doerr is a venture capitalist, investor, and board member at Google and Amazon. Probably that’s why you’ll relate to many descriptions presented in the book; the author actually lived the stories he’s telling.

6. The Phoenix Project (A Novel About IT, DevOps, and Helping Your Business Win)

Author: Gene Kim
Year of publication: 2018

Books on project management contain examples you’ll identify with. But while reading this one, you’ll start wondering: “Has the author been hiding in my office building and meetings?” The mistakes, the symptoms, the characters – everything is painfully familiar to anyone within the industry. The author, without a doubt, knows how you feel about failed software projects. The book will force you to stop and reflect on your own experiences and how your team handled DevOps.

“Every work center is made up of four things: the machine, the man, the method, and the measures,” states the author in the book and continues to explain how software development has moved from a traditional approach to DevOps. We all know the reason for this movement: to ensure a fast and uninterrupted flow of work and deliver on the strategic promises we make.

The Phoenix Project is frequently described as “The Goal” for IT, mainly because it uses a fictional plot (like the all-time classic) and provides good takeaways, which make it a fun read. Non-business people will get their feet wet with process improvements without having to decipher burdensome explanations. In addition, the author has walked the extra mile to revisit the presented concepts in a brief summary at the end.

This book is ideal for software development engineers (both senior and junior), managers, system admins, consultants, and executives. For high-level management, the book will draw the bigger picture of what software development is and how it relates to business. At the same time, the book will help junior staff to develop into more mature, well-rounded, and thoughtful engineers.

Gene Kim is the author of several books and has been studying high-performing technology organizations for over two decades now. He founded the DevOps Enterprise Summit back in 2014 which brings together thousands of technology leaders to network, share, and learn. Being a developer by training but having spent most of his professional career in operations, Gene Kim knows how to set shared goals between Dev and Ops teams and build the infrastructure (not only the code!) to achieve high performance.

If your IT department is swamped in work, scrambling to meet demands, cutting corners to release anything, sucking the souls of engineers, then something needs to be fixed. And this book is going to help you do exactly that.

7. Strategic Project Management Made Simple: Solution Tools for Leaders and Teams – Second Edition

Author: Terry Schmidt
Year of publication: 2021

All too often, we fail to do cause-and-effect thinking. We forget that we don’t do each separate project for the sake of merely accomplishing it. We accomplish each project for a reason.

“Strategic Project Management Made Simple” is a practical and accessible guide for project managers who lack hands-on experience and need recommendations from an expert who knows the game out there. Terry Schmidt will introduce the Logical Framework Approach (LFA), enabling you to take a systems-thinking view of project management.

Specific examples accompany the explanation of the framework, which makes the book an enjoyable read. LFA goes from inputs to outcomes, from outcomes to purpose, and from purpose to goals to help you get systematic about each and every project.

The author shows how to share ideas and concepts in an easy-to-understand manner to prepare your team for creating a project management plan that’s strategic, logical, and practical.

Project managers who have hard times managing people will find one of the chapters particularly helpful. It provides information on how to “manage your inner game” by adopting the right mindset and working effectively with many different personalities.

Terry Schmidt earned his MBA from Harvard Business School, worked for NASA and was a consultant for World Bank and USAID-funded projects. He also teaches at UCLA and MIT. He is yet another professional who offers great information on navigating the unfamiliar waters and finding success.

Before we finish, let’s shift the gears slightly.

Project managers often need to learn not only how to manage better, but also how to think better. That’s why a book by Ray Dalio sums up our list of project management books.

8. Principles: Life and Work

Author: Ray Dalio
Year of publication: 2017

Take a moment to think. What are your criteria for making decisions?

Not an easy question, huh?

Ray Dalio gives answers to complex questions; he provides recipes for dealing with situations that happen over and over again by showing the path of building a system that works. It’s extraordinary; by applying these techniques, you start thinking in a more principled way.

Pain plus reflection equals progress – here’s the formula the author suggests and takes you on a journey of setting goals, learning continuously, and making informed decisions.

The book should be great for managers seeking ways to sharpen the edges and step up projects for success. The tricky part of the described system could be the following – to put it into practice, you’ll most probably need a work environment with a strong corporate culture, as well as team members who are open to transparency, change, and experimentation.

Ray Dalio founded one of the world’s largest and best-performing hedge funds – Bridgewater Associates. With all of the tremendous success the author has had in business and investment, you can rest assured that the wisdom this book shares is applicable and will help you come to grips with your most pressing problems.