Project Management All-in-One For Dummies book cover

Project Management All-in-One For Dummies

Published: October 13, 2020


Your ultimate go-to project management bible

Perform Be Agile! Time-crunch! Right now, the business world has never moved so fast and project managers have never been so much in demand—the Project Management Institute has estimated that industries will need at least 87 million employees with the full spectrum of PM skills by 2027. To help you meet those needs and expectations in time, Project Management All-in-One For Dummies provides with all the hands-on information and advice you need to take your organizational, planning, and execution skills to new heights.

Packed with on-point PM wisdom, these  7 mini-books—including the bestselling Project Management and Agile Project Management For Dummies—help you  and your team  hit maximum productivity by razor-honing your skills in sizing, organizing, and scheduling projects for ultimate effectiveness. You’ll also find everything you need to overdeliver in a good way when choosing the right tech and software, assessing risk, and dodging the pitfalls that can snarl up even the best-laid plans.

  • Apply formats and formulas and checklists
  • Manage Continuous Process Improvement
  • Resolve conflict in teams and hierarchies
  • Rescue distressed projects


Your ultimate go-to project management bible

Perform Be Agile! Time-crunch! Right now, the business world has never moved so fast and project managers have never been so much in demand—the Project Management Institute has estimated that industries will need at least 87 million employees with the full spectrum of PM skills by 2027. To help you meet those needs and expectations in time, Project Management All-in-One For Dummies provides with all the hands-on information and advice you need to take your organizational, planning, and execution skills to new heights.

Packed with on-point PM wisdom, these  7 mini-books—including

the bestselling Project Management and Agile Project Management For Dummies—help you  and your team  hit maximum productivity by razor-honing your skills in sizing, organizing, and scheduling projects for ultimate effectiveness. You’ll also find everything you need to overdeliver in a good way when choosing the right tech and software, assessing risk, and dodging the pitfalls that can snarl up even the best-laid plans.

  • Apply formats and formulas and checklists
  • Manage Continuous Process Improvement
  • Resolve conflict in teams and hierarchies
  • Rescue distressed projects


Project Management All-in-One For Dummies Cheat Sheet

Successful organizations create projects that produce desired results in established time frames with assigned resources. As a result, businesses are increasingly driven to find project managers who can excel in this type of work environment. To get started in project management, you should understand the phases of a project’s life cycle, processes involved in project management, and the basic tasks you’re expected to perform. [caption id="attachment_273434" align="alignnone" width="556"] © Michail Petrov /[/caption]

Articles From The Book

9 results

Project Management Articles

4 Values of the Agile Manifesto

Product development teams and project managers need to evaluate whether teams are following agile principles and whether their actions and behaviors are consistent with agile values. The Agile Manifesto was generated from experience, not from theory. As you review the values described in the following discussion, consider what they would mean if you put them into practice. How do these values support meeting time-to-market goals, dealing with change, and valuing human innovation?

Although the agile values and principles are not usually numbered, they are numbered here for ease of reference. The numbering matches their order in the manifesto.

Value 1: Individuals and interactions over processes and tools

When you allow each person to contribute his or her unique value to a product, the result can be powerful. When these human interactions focus on solving problems, a unified purpose can emerge. Moreover, the agreements come about through processes and tools that are much simpler than conventional ones.

A simple conversation in which you talk through a product issue can solve many problems in a relatively short time. Trying to emulate the power of a direct conversation with email, spreadsheets, and documents results in significant overhead costs and delays. Instead of adding clarity, these types of managed, controlled communications are often ambiguous and time-consuming and distract the development team from the work of creating a product.

Consider what it means if you value individuals and interactions highly. The table shows some differences between valuing individuals and interactions and valuing processes and tools.

If processes and tools are seen as the way to manage product development and everything associated with it, people and the way they approach the work must conform to the processes and tools. Conformity makes it hard to accommodate new ideas, new requirements, and new thinking. Agile approaches, however, value people over process. This emphasis on individuals and teams puts the focus on their energy, innovation, and ability to solve problems. You use processes and tools in agile product management, but they’re intentionally streamlined and directly support product creation. The more robust a process or tool, the more you spend on its care and feeding and the more you defer to it. With people front and center, however, the result is a leap in productivity. An agile environment is human-centric and participatory and can be readily adapted to new ideas and innovations.

Value 2: Working software over comprehensive documentation

A development team’s focus should be on producing working functionality. With agile development, the only way to measure whether you are truly finished with a product requirement is to produce the working functionality associated with that requirement. For software products, working software means the software meets the definition of done: at the very least, developed, tested, integrated, and documented. After all, the working product is the reason for the investment. Have you ever been in a status meeting where you reported that you were, say, 75 percent done with your project? What would happen if your customer told you, “We ran out of money. Can we have our 75 percent now?” On a traditional project, you wouldn’t have any working software to give the customer; 75 percent done traditionally means you are 75 percent in progress and 0 percent done. With agile product development, however, by using the definition of done, you would have working, potentially shippable functionality for 75 percent of your product requirements — the highest-priority 75 percent of requirements.

Although agile approaches have roots in software development, you can use them for other types of products. This second agile value can easily read, “Working functionality over comprehensive documentation.”

Tasks that distract from producing valuable functionality must be evaluated to see whether they support or undermine the job of creating a working product. Table 1-2 shows a few examples of traditional project documents and their usefulness. Think about whether documents produced on a recent project you were involved in added value to the functionality being delivered to your customer.

With agile product development, barely sufficient is a positive description, meaning that a task, document, meeting, or almost anything created includes only what it needs to achieve the goal. Being barely sufficient is practical and efficient — it’s sufficient, just enough. The opposite of barely sufficient is gold-plating, or adding unnecessary frivolity — and effort — to a feature, task, document, meeting, or anything else.

All development requires some documentation. With agile product development, documents are useful only if they support development and are barely sufficient to serve the design, delivery, and deployment of a working product in the most direct, unceremonious way. Agile approaches dramatically simplify the administrative paperwork relating to time, cost control, scope control, or reporting.

Stop producing a document and see who complains. After you know the requester of the document, strive to better understand why the document is necessary. The five whys work great in this situation — ask “why” after each successive answer to get to the root reason cause for the document. After you know the core reason for the document, see how you can satisfy that need with an agile artifact or streamlined process.

Agile teams produce fewer, more streamlined documents that take less time to maintain and provide better visibility into potential issues. You can create and use simple tools (such as a product backlog, a sprint backlog, and a task board) that allow teams to understand requirements and assess real-time status daily. With agile approaches, teams spend more time on development and less time on documentation, resulting in a more efficient delivery of a working product.

Value 3: Customer collaboration over contract negotiation

The customer is not the enemy. Really. Historical project management approaches usually limit customer involvement to a few development stages:
  • Start of a project: When the customer and the project team negotiate contract details.
  • Any time the scope changes during the project: When the customer and the project team negotiate changes to the contract.
  • End of a project: When the project team delivers a completed product to the customer. If the product doesn’t meet the customer’s expectations, the project team and the customer negotiate additional changes to the contract.
This historical focus on negotiation, avoidance of scope change, and limitation of direct customer involvement discourages potentially valuable customer input and can even create an adversarial relationship between customers and project teams.

You will never know less about a product than at its start. Locking product details into a contract at the beginning of development means you have to make decisions based on incomplete knowledge. If you have flexibility for change as you learn more about a product and the customer the product is serving, you’ll ultimately create better products.

The agile pioneers understood that collaboration, rather than confrontation, produced better, leaner, more useful products. As a result of this understanding, agile methods make the customer part of the product development on an ongoing basis. Using an agile approach in practice, you’ll experience a partnership between the customer and the development team in which discovery, questioning, learning, and adjusting during the course of product development are routine, acceptable, and systematic.

Value 4: Responding to change over following a plan

Change is a valuable tool for creating great products. Teams that can respond quickly to customers, product users, and the market are able to develop relevant, helpful products that people want to use. Unfortunately, traditional project management approaches attempt to wrestle the change monster and pin it to the ground so it goes out for the count. Rigorous change management procedures and budget structures that can’t accommodate new product requirements make changes difficult. Traditional project teams often find themselves blindly following a plan, missing opportunities to create more valuable products or, even worse, unable to react timely to changing market conditions. The figure shows the relationship between time, opportunity for change, and the cost of change on a traditional project. As time — and knowledge about your product — increases, the ability to make changes decrease, and costs more. By contrast, agile development accommodates change systematically. The flexibility of agile approaches increases stability because product changes are predictable and manageable — in other words, it’s expected and non-disruptive to an agile team. In the rest of Book 4, you discover how agile approaches to planning, working, and prioritization allow teams to respond quickly to change. As new events unfold, the team incorporates these realities into the ongoing work. Any new item becomes an opportunity to provide additional value instead of an obstacle to avoid, giving development teams a greater opportunity for success.

Project Management Articles

Agile Planning with the Roadmap to Value

Agile planning happens at a number of points. A great way to look at planning activities is with the Roadmap to Value. The figure shows the roadmap as a whole.

The Roadmap to Value has seven stages:

  • In stage 1, the product owner identifies the product vision. The product vision is your product’s destination or end goal. The product vision includes the outer boundary of what your product will be, how the product is different than the competition, how the product will support your company or organization’s strategy, who will use the product, and why people will use the product. The product vision should be revisisted at least once a year.
  • In stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a general time frame for when you will develop those requirements. It also gives context to the vision by showing the tangible features that will be produced during development. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements allow you to establish requirement themes and identify requirement gaps. The product owner, with support from the development team, should revise the product roadmap at least biannually.
  • In stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working functionality to the customer. The release serves as a mid-term boundary against which the scrum team can mobilize. Many releases may be required to accomplish the product vision and the highest-priority features should appear first. You create a release plan at the beginning of each release, which according to Principle 3 should be “frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
  • In stage 4, the product owner, the development team, and the scrum master will plan iterations, also called sprints, and start creating the product functionality in those sprints. Sprint planning sessions take place at the start of each sprint. During sprint planning, the scrum team determines a sprint goal, which establishes the immediate boundary of work that the team forecasts to accomplish during the sprint, with requirements that support the goal and can be completed in the sprint. The scrum team also outlines how to complete those requirements.
  • In stage 5, the development team has daily scrum meetings during each sprint to coordinate the day’s priorities for accomplishing the sprint goal. In the daily scrum meeting, based on what was completed up to that point, you coordinate what you will work on today and any roadblocks, so that you can address issues immediately.
  • In stage 6, the scrum team holds a sprint review at the end of every sprint. In the sprint review, you demonstrate the working product to the product stakeholders.
  • In stage 7, the scrum team holds a sprint retrospective. The sprint retrospective is a meeting where the scrum team discusses the completed sprint with regard to their processes and environment and makes plans for process improvements in the next sprint. Like the sprint review for inspecting and adapting the product, a sprint retrospective is held at the end of every sprint to inspect and adapt your processes and environment.
Each stage of the Roadmap to Value is repeatable and contains planning activities. Agile planning, like agile development, is iterative and barely sufficient.

Progressive elaboration

During each stage of product development, you plan only as much as you need to plan. In the early stages of your work, you plan widely and holistically to create a broad outline of how the product will shape up over time. In later stages, you narrow your planning and add more details to ensure success in the immediate development effort. This process is called a progressive elaboration of requirements.

Planning broadly at first and in detail later, when necessary, prevents you from wasting time on planning lower-priority product requirements that may never be implemented. This model also lets you add high-value requirements during product development without disrupting the flow. The more just-in-time your detailed planning is, the more effective your planning becomes.

Standish Group studies show that customers rarely or never use as much as 80 percent of the features in an application. In the first few development cycles of an agile product development effort, you complete features that have the highest priority and that people will use. Typically, you release those groups of features as early as possible to gain market share through first-mover advantage; receive customer feedback for viability; monetize functionality early to optimize return on investment (ROI); and avoid internal and external obsolescence.

Inspect and adapt

Just-in-time planning brings into play two fundamental tenets of agile techniques: Inspect and adapt. At each stage of development, you need to look at the product and the process (inspect) and make changes as necessary (adapt). Agile planning is a rhythmic cycle of inspecting and adapting. Consider the following:
  • Each day during the sprint, the product owner provides feedback to help improve the product as the development team creates the product.
  • At the end of each sprint, in the sprint review, stakeholders provide feedback to further improve the product.
  • At the end of each sprint in the sprint retrospective, the scrum team discusses the lessons they learned during the past sprint to improve the development process.
  • After a release, the customers can provide feedback for improvement. Feedback might be direct, when a customer contacts the company about the product, or indirect, when potential customers either do or don’t purchase the product.
Together, inspect and adapt are fantastic tools for delivering the right product in the most efficient manner.

At the beginning of development, you know the least about the product you’re creating, so trying to plan fine details at that time just doesn’t work. Being agile means you do the detailed planning when you need it, and immediately develop the specific requirements you defined with that planning. Remember the Agile Manifesto value: “Responding to change over following a plan.”

After you know a little more about how agile planning works, it’s time to complete the first step: defining the product vision.

Project Management Articles

How to Start Your Project Stakeholder Register

A project stakeholder is any person or group that supports, is affected by, or is interested in your project. Your project’s stakeholders can be inside or outside your organization, and knowing who they are helps you

  • Plan whether, when, and how to involve them.
  • Determine whether the scope of the project is bigger or smaller than you originally anticipated.
A project stakeholder register is a living document. You need to start developing your register as soon as you begin thinking about your project. Begin your project’s stakeholder register by considering the initial version of the register that’s generated upon completion of the development of the project charter. (This charter authorizes the existence of a project and provides the project manager with the authority to use organizational resources to support the performance of project activities.) Next, write down any other names that occur to you. When you discuss your project with other people, ask them who they think may be affected by or interested in your project. Then select a small group of the stakeholders you identify and conduct a formal brainstorming session. Continue to add and subtract names to your stakeholder register until you can’t think of anyone else.

Use specific categories

To increase your chances of identifying all appropriate people, develop your stakeholder register in categories. You’re less likely to overlook people when you consider them department by department or group by group instead of trying to identify everyone from the organization individually at the same time.

Start your stakeholder register by developing a hierarchical grouping of categories that covers the universe of people who may be affected by, be needed to support, or be interested in your project. You can start with the following groups:

  • Internal: People and groups inside your organization
    • Upper management: Executive-level management responsible for the general oversight of all organization operations
    • Requesters: The person who came up with the idea for your project and all the people through whom the request passed before you received it
    • Project manager: The person with overall responsibility for successfully completing the project
    • End users: People who will use the goods or services the project will produce
    • Team members: People assigned to the project whose work the project manager directs
    • Groups normally involved: Groups typically involved in most projects in the organization, such as the human resources, finance, contracts, and legal departments
    • Groups needed just for this project: Groups or people with special knowledge related to this project
  • External: People and groups outside your organization
    • Clients or customers: People or groups that buy or use your organization’s products or services
    • Collaborators: Groups or organizations with whom you may pursue joint ventures related to your project
    • Vendors, suppliers, and contractors: Organizations that provide personnel, raw materials, equipment, or other resources required to perform your project’s work
    • Regulators: Government agencies that establish regulations and guidelines that govern some aspect of your project work
    • Professional societies: Groups of professionals that may influence or be interested in your project
    • The public: The local, national, and international community of people who may be affected by or interested in your project

Continue to subdivide these categories further until you arrive at job titles (or position descriptions) and the names of the people who occupy them. (The process of systematically separating a whole into its component parts is called decomposition.)

Consider stakeholders that are often overlooked

As you develop your stakeholder register, be sure not to overlook the following potential stakeholders:
  • Support groups: These people don’t tell you what you should do (or help you deal with the trauma of project management); instead, they help you accomplish the project’s goals. If support groups know about your project early, they can fit you into their work schedules more readily. They can also tell you information about their capabilities and processes that may influence what your project can accomplish and by when. Such groups include
    • Facilities
    • Finance
    • Human resources
    • Information technology (IT)
    • Legal services
    • Procurement or contracting
    • Project management office
    • Quality
    • Security
    • Help desks
    • Call centers
  • End users of your project’s products: End users are people or groups who will use the goods and services your project produces. Involving end users at the beginning of and throughout your project helps ensure that the goods and services produced are as easy as possible to implement and use, and are most responsive to their true needs. It also confirms that you appreciate the fact that the people who will use a product may have important insights into what it should look like and do, which increases the chances that they’ll work to implement the products successfully.

In some cases, you may omit end users on your stakeholder register because you don’t know who they are. In other situations, you may think you have taken them into account through liaisons — people who represent the interests of the end users. (Check out the nearby sidebar “Discovering the real end users” for a costly example of what can happen when you depend solely on liaisons.)

  • People who will maintain or support the final product: People who will service your project’s final products affect the continuing success of these products. Involving these people throughout your project gives them a chance to make your project’s products easier to maintain and support. It also allows them to become familiar with the products and effectively build their maintenance into existing procedures.

Examine the beginning of a sample stakeholder register

Suppose you’re asked to coordinate your organization’s annual blood drive. The image below illustrates some of the groups and people you may include in your project’s stakeholder register as you prepare for your new project.