How to create a phased project plan
Project managers struggle to divide a deliverable into milestones. I hear this from junior folks all the time: How do we separate a big project into chunks of work? Especially if the type of work is unfamiliar to you, it's challenging to conceptualize a phased approach to a long-term goal.
But there are methodical, repeatable approaches you can take into defining project phases. Let's talk about it.
Why do we define phases?
I'm going to outline the why, because it may help clarify the how. When you're tackling a complex project, it likely engages many teams, requires a timeline that comprises months, and engages significant organizational resources. You'll need to have markers that help you understand and communicate your progress. These phases are essential for:
Adjusting the project equation: Throughout the lifecycle of a project, you'll likely be adjusting the requirements, resources, and timeline to reflect the evolving realities of your team. Understanding how far along you are in a project in a way others can understand will help you make (and drive others to make) tough decisions to tweak the resources, requirements, or timeline.
Communicating progress and managing expectations: Defining concrete phases at the beginning of a project empowers you to communicate project progress in a transparent, mutually agreed way from the beginning. Specific phases will help you manage expectations with other teams and prepare them for scheduling their own work.
Good energy: Marking significant milestones along the way to a major deliverable will help you create positive team vibes. You'll celebrate accomplishments and recognize each other along the way towards a major goal, boosting energy and helping folks feel appreciated.
How do you define phases?
Let's jump into the how. Think about projects as products (even if they aren't product projects). A marketing campaign is a product, a new business process or HR process can be a product, and a major change in a product or way of doing things inside your organization is a product, too. When you're planning, creating, and shipping a product, there are common milestones you'll run into that can help you define those phases:
Defining a concept and business rules: Before you start building a project, you'll outline the approach you're taking to building it. This likely engages project stakeholders and leaders in discussion around what they're trying to build, and for whom. This happens before folks start developing a work product.
Development: Development reflects folks who are creators developing work product. For example, this can be engineers writing code, designers drafting graphics, HR managers outlining a new process, or sales enablement folks developing a new script for selling a product.
Development handoff points: Commonly, one team will create a work product and then it gets handed off to another team for next steps. These handoff points are useful demarcations of project progress as well.
User testing: Just what it sounds like. As work products approach readiness, you'll want to have folks who are consumers of the work product review and/or use it to give you feedback.
A minimum viable product: Once you've completed user testing/review, you'll be ready to ship a basic version of the product to end users. Generally, it's helpful to take an approach of shipping a small, usable version of a product to get feedback from users to build a more complex version. This avoids building large work products in a vacuum.
Iterative versions of the MVP: Once you've shipped your MVP, you're ready to start collecting user feedback and continuously improving your product. This can be part of the project, or can be handed off to a long term owner for more operational management.
Scenario: creating a new onboarding process
Let's walk through how this approach might work in a real-world project. Let's say you're an HR manager and you've been asked to develop a consistent onboarding process for new hires. The overall deliverable is a guide that managers throughout the organization will use to onboard their new hires. As you reflect on a project plan, you identify:
Phase 1: Kickoff: You'll define a project goal with underlying requirements, build cross-functional project team that includes folks from across the organization, and estimate a timeline.
Phase 2: Concept: You'll work collaboratively with the project team to outline an onboarding process, including what each person should experience on an organizational and team level. You'll create a draft guide to drive a pilot project.
Phase 2: Pilot project: You'll engage a group of managers in onboarding new hires in a defined period of time using the draft onboarding process. You'll coach them in using the process, and you'll have a defined approach to soliciting their feedback and organizing it.
Phase 4: Incorporating feedback and delivery: You'll consolidate feedback from the pilot testers, and work collaboratively with the project team to prioritize incorporating feedback, dividing it into urgent/pre-launch updates and post-launch improvements. You'll implement the urgent feedback, and ship the project organization-wide, including a communications plan that helps other folks adopt the new approach.
Take this approach into your work, and let me know how it goes.
