BA 26/52: In Pursuit of the Perfect Project Plan

Big welcome to the… *looks carefully* … 119 new subscribers since my last piece! 👀 Ahhhhh…. was it something I said…😳

This is a huge milestone for me given I had set a goal for hitting 500 subscribers, organic, by the end of this year. Guess we are ahead of schedule.

This fills me with excitement, wonder, anxiety, nervousness. Clearly, there is an audience for what I am writing and now I feel the pressure to keep churning out “great” content on a weekly basis. So, I am kind of scared but I will stay focused on continuing to write from the heart about my experiences as a TPM.

Goal remains the same because subscribers will leave as quickly as they came as is the nature of newsletters - demystify the Art of Technical Program Management.

I am humbled you are here. So, for however long you stay, welcome and enjoy the articles. I hope they are useful + memorable + novel + empowering + transformational.

Here we go with this week’s piece.

---

I have spent my fair share of the early days in my career searching feverishly on Google for any article or content to help me build the perfect project plan.

After all, I was taught that the bread and butter of the Project Manager is their GANTT chart and how it can perfectly predict the future to come.

I remember the first time I saw the software development schedule for the Operating System that would eventually run on the Blackberry Playbook, I was in awe. Complex, comprehensive, multi-layered, GANTT in all its glory. That was my benchmark of how Project Plans should be. Blackberry was ISO 9XXX compliant so the need for documentation on our project plans was high. Yearly audits and pre audits; I thought this is normal for any company building something is complicated as a smartphone operating system.

Then, I joined Apple in February of 2012 and my world was turned upside down; my notion of Engineering Project Management was turned upside down.

I joined in the middle of development on iOS 6 as an iOS Engineering Project Manager. There were no GANTT charts or complex software schedules.

Our source of truth of work were tickets in Radar (Apple’s Internal Issue Management tool) and our schedules were email reports we rolled up to Scott Forstall and his staff every week. Our milestones were pretty straightforward:

• WWDC

• Zero P3/4

• Zero P2

• Zero P1

• Zero Bugs

• First Customer Ship

Every feature was either a tentpole or non-tentpole. Each cross-functional team built their own software schedules of when they would be Feature Complete. Even our definition of Feature Complete was “Scott Forstall can start using the feature”.

This real world is different than what I learned about of Software Project Management in university. This is a different world from even what I did at Blackberry.

I was at Apple for 5.5 years through 5 iOS releases and every release our project management methodology was different. Constantly evolving. Our approach to planning was different.

The last few years at Apple, post our merging with iOS and MacOS Program Offices, we settled on something that I believe is the ideal approach to building project plans for any software development effort: The Re-plan.

I won’t go into the details of how Apple plans its software releases because I have written about it in the past.

BA (22/52): How Apple Plans Software (A Visual Guide)

No one can see past a few months in the future for any software development project. That was the major failure of the waterfall approach. Roadmaps are at best North Star visions of where a company should head towards.

Project plans by their very nature are not perfect. Nor should we try to make them. There are plenty of blog content out there about “10 Steps to a Perfect Project Plan”. Every one of them revolves around:

• Know precisely what you’re building

• Get all your requirements

• Have start and end dates for every task.

• Etc etc etc

Anyone who has spent any time building software knows that is not how the real world works.

• You won’t have all the requirements figured day one.

• You won’t know the start and end dates to everything.

• You can plan for everything but the first schedule slip, your plan is lost.

• Life gets in the way of your engineers.

• Somethings take long than expected.

So, why do we insist on always making sure that we start every project with the perfect project plan with all the details figured out - Human nature.

We want to know everything. Ambiguity is not in our nature. It scares us. Building or writing out detailed lengthy plans gives us a false sense of control over the situation.

However, at the first sign of trouble, we don’t easily raise our hand and say “This is okay, lets figure out what happened and what we need to do next”. Our flight or fight brain takes over and ultimately we blame not having the plan right from the start.

However, at Apple, accepting that plans are imperfect and we should do our best to build enough of the plan to kick things off and make progress to our objectives. What was important is that all the involved teams understood the challenge and were ready to tackle it. We will replan as we go - that was the Apple software development mantra. Very agile.

Why should I care about this?

I believe that TPMs should focus less on the perfect baseline plan and focus instead on building affordances for replanning throughout software development.

At Apple, we didn’t aim for perfect plans, we perfected the art of replanning.

Every development milestone was spaced out by 1 week of replanning effort where the entire software organization and the numerous cross-functional teams (across design, engineering, marketing, program management) paused development to focus on:

• Evaluating their progress

• The work to be done

• Looking at the feature goals, the organizational goals, the release goals,

• The new information we acquired by building something

• At the end, we adjusted our plan.

So, what can you learn from the Apple approach; here is what you can do with your next development effort:

• Add deliberate replanning pauses between sprints. I am strongly against planning when teams are still wrapping up sprints. You need to have a clear mind to focus on adjusting plans.

• Don’t wait for perfection, aim for comprehension of the end goal. Any team only has the capacity to truly know the future no more than 6-12wks out into the future.

• The messy middle is and will be messy, don’t fight it, harness it to make forward progress. Replan is to a failure, it is an opportunity to course correct. Never a failure.

• Be careful not to confuse forgoing perfection with not enough requirements understood. Some will call it MVP other a POC but there is a threshold you must cross to know that you can kick off a project. You aren’t agile if you ignore the key requirements just so you can show progress to leadership.

• March your teams to releases, not calendars. Don’t march to quarters but have constantly shipping release trains lined up with versioning support so you know what changed where and if teams need to adjust plans, they have markers to tie them.

I will leave you with this important thought, if all your took away from this piece this is it - don’t see a replan as a failure.

I know many leaders will see the need to replan as a failure of the team to truly understand what the scope of the product is.

At Apple, we replanned on a regular cadence. Why?

Because in an ever complex software world there is only so much you know until you start building something. Even then, systems theory outlines that when you bring two complex systems together they will behave in ways you can never predict.

Embrace the replan, more than the original baseline plan.

So, given all that I said above, perhaps this piece’s title needs to be reworded - In Pursuit of the Perfect (Re)plan.

Until next time 👋!

-Aadil

---

How was this week’s newsletter?

🤯 Amazing | 😁 Good | 😊 Okay