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: