Profile PictureKahlil Corazo

[Atomic PM Book] Chapter 4: When to Use (And Not Use) These Project Management Tools

Here's an updated draft of Chapter 4. As always, feedback and questions are appreciated!

Chapter 4: When to Use (And Not Use) These Project Management Tools

Work transforms ideas to reality. At the beginning of the pandemic, Project Accessible Genomics was just a germ of an idea. It took 10 months of work to turn it to a reality.

Different projects, however, require different kinds of work.

Some projects require consistent and expert repetition of the same kind of work—for instance, writing, coding and painting. Let's call this deep work.

Other projects require the coordination of many kinds of work (including deep work)—for instance, organizing a large event, building a house, implementing a business plan and Project Accessible Genomics. Let's call this expansive work.

You need mastery of a craft to get deep work done well. You need mastery of project management to get expansive work done well.


If you're looking for a playbook for deep work, here I some I recommend:

  • Big Magic by Liz Gilbert (this is my playbook)
  • Maker's Schedule, Manager's Schedule by Paul Graham
  • The Artist's Way by Julia Cameron
  • Deep Work by Cal Newport
  • The War of Art by Steven Pressfield

Project management is for complex orchestration of work

The more moving parts a project has, the more project management tools you should use. "More moving parts" means more complexity in the work required to bring your idea to reality, or more constraints in how project success is defined. Here are some examples:

More project complexity:

  • More coordination of tasks required
  • More people involved
  • More risks

More constraints in how project success is defined:

  • Tight budget
  • Tight deadline
  • The expected product has very precise specifications

We will revisit these ideas in Chapter 8: Aligning Your Stakeholders, Your Team and Your Future Selves: The Project Charter and Chapter 11: Designing Serendipity: How to Systematically Get Lucky.

Complexity and constrained definitions of success are situations you face, not something you seek. If you want less headaches, you'd want a broad definition of success and less project complexity. This is a principle to keep in mind when defining a project.

Project management may be overkill for simple projects. Task management systems may be more appropriate for these. You'd also want to adjust the number of tools you use depending on the complexity of the project.


If you don't have a playbook on task management yet, check out Getting Things Done (GTD) by David Allen. It is one of the most commonly used task management systems.

I present an alternative to GTD in Chapter 14: Project-driven Stallion-Rider Productivity.


The special case of software development

The project management tools introduced in this book are from the age-old practice of orchestrating atoms: launching new businesses, constructing buildings, organizing events (another reason for the title of this book). In software development, project teams orchestrate bits instead.

From the perspective of project management, the main difference is the cost of changing the material output, both in money and time. Changing business processes, buildings and events are costly. Changing software costs practically zero. To change a building you need to pay both for the civil engineer and the cement. To change a program, you pay the software engineer—and that's practically it. And the changes are instantaneous.

Because of this property, products of software development can be designed through iteration, more than planning, prototyping and building. Orchestrating the work of creating a product through iteration has produced a new kind of project management: Agile.

This is a book about classical project management, not Agile. However, even software development has aspects that would benefit from classical project management. For instance:

  • Capturing user needs
  • Adhering to regulatory requirements
  • Managing stakeholders
  • Hiring engineers

The project management tools and frameworks in this book can be used for these aspects of software development.

What are these project management tools that we selectively use based on project complexity? In the next chapter, we will look at ten of them as solutions to ten problems that project managers are tasked to face.


Chapters previously posted:

0 comments

Current user avatar

Chapter 5: 10 Project Management Problems and 10 Project Management Tools

[Atomic PM Book] Table of Contents and v1 of Chapter 3

I've started writing Atomic Project Management! Here's Chapter 1.

The Game Plan: Professional Project Management With Roam rBook

See all posts from Kahlil Corazo

Powered by