How to create great project plans
The really great project plans tell a wonderful story.
Hey Tribe, It’s Aadil.
In my career, I have been lucky to have worked and learned from some amazing people. My favourite are Product Managers.
Why? The really excellent ones are amazing storytellers.
Their slide decks, 6-pagers, explanations, solutions, conversations, they all strive to build a certain narrative.
I believe Project Managers should also learn the art of storytelling.
Why? The really great project plans tell a wonderful story of how our heroes (the cross-functional team) will overcome pivotal moments and challenges (features and tasks) to reach our final goal (final product or feature).
The common problem I see is that project plans are treated merely as a list of tasks to be completed. Think of it this way - if you as the Project Manager decide to quit tomorrow, the next Project Manager shouldn’t need to redo all your efforts and can understand the work right away by reading through the project plan(s).
Like all good narratives, there are a few key elements every great project plan must have:
Non-negotiable milestones - common milestones who labels don’t change and represent critical gates during development.
Work breakdown - this is the heart of the plan; represents & varies for each team based on the actual work needed to be done.
Hand offs - critical work transfer points especially during complex projects with numerous dependencies.
What are Non-negotiable milestones?
These milestones are your organizations common lexicon to indicate when a project has crossed certain critical gates. They help as landmarks for development teams and stakeholders.
The reason they are non-negotiable is they must mean and are written the same to every team within an organization. At Apple, we had 4 non-negotiable milestones:
Technical Scope Complete - technical discovery on what we need to build is understood to begin development (frontend, backend etc) is complete.
Design Scope Complete - low fidelity wireframes and general UI design is understood to proceed with development.
Hand off to QA - all active development is complete and we are ready for testing.
Feature Complete - QA has blessed the main user scenarios, ready for demo and any development work will be optimization or bug fixing.
How to approach work breakdown?
Taking a page from systems thinking, all modern technology is a combination of many smaller systems working together towards a common purpose or function. A system is composed of the following characteristics:
Inputs / Outputs - think APIs.
Processing & Storage - the ultimate purpose of a system, how it handles and processes inputs and outputs.
Error Handling - what do you do if something goes wrong ex: timeouts, retries, etc.
When developing a project plan for say a new backend system - develop your work breakdown tasks based on what key features, functions, or systems you are building and what their inputs, outputs, processing & storage, and error handling functionality is.
For example - lets look at a simple identity system for checking account management:
CredentialCheck API Complete (Input/Output)
NewAccountAPI Complete (Input/Output)
Add Credentials in ProfileDB Complete (Storage)
Credential Check Function Complete (Processing)
Error Messaging for failed credential check. (Error Handling)
Of course the above example is a gross oversimplification but you get my point. 🙃
What are Hand Offs?
Explicitly calling out on your project plan as to when you unblock or enable a dependency allows other teams to prepare, align their resources but also sets better expectations with stakeholders.
For example:
Hand off to QA - QA know exactly when they need to have resources available to run tests.
Frontend Mobile Team Unblocked with stub-APIs
Frontend Mobile Team Unblocked with production-APIs
Developing project plans can at times seem daunting; are you including the right information, did you skip a task, is this too granular of a breakdown? Over time, you will develop your own set of characteristics of what makes a great project plan. Always remember - does your project plan tell the right story of what the lies ahead and the gravity of the work involved.
That’s it for now. 🙏🏽👋🏽
-Aadil
Was this edition useful? Relevant? Pointless? Help me to improve!
