Project management (PM) is tragically misunderstood, and the growing size and complexity of our software development projects demands mastery of this artform. Effective management of modern projects requires throwing out the old PM guidebooks in favor of an extreme approach that can make tenured leaders uneasy. When I was hired as a Technical Program Manager at Amazon, I had no idea what I was signing up for, nor did I have a framework for executing successfully. 

Through trial and error, I figured out how to be an awesome project manager, and I delivered five major products at Amazon before returning to engineering management. Those projects spanned every dimension of complexity including wide internal impact (33 engineering teams), bleeding edge technologies, and cross industry collaboration.

In the beginning, software development had two modes – cowboy and bulldog. The cowboys were independent, small groups, hyper focused on their specific domain, largely ignoring everyone outside of their silos. The bulldogs were the centralized, micro managed, do or die leaders. We always started a big project by flailing around with small groups of cowboys applying wildly different approaches to their areas of ownership and just getting something done for a while – sometimes for more than a year. There was little understanding of the relationship between scope, resources, and schedule.

At some point, leaders would experience that moment of clarity where they lost all hope of delivering the promised features on schedule, and they would start “bulldogging it”. That’s the pivot point where the slow exploration and lengthy debates about design patterns are completely dropped in favor of a painful march to launch a disappointing product. That’s the part of the project with mandatory daily meetings for more than a hundred developers and a rotating dinner schedule.

In 1996, the Project Management Institute published the now famous Project Management Body of Knowledge (PMBOK) Guide, and I joined a group of engineers in a series of workshops to learn project management. The guide codified the well-worn processes of project management from industries like manufacturing and construction. Sometime around 1999, I was asked to apply those planning mechanisms to a large software development project. After weeks of data collection and calculations, I reported to my senior leaders that the project would take years, plus or minus more years.

That was an unacceptable conclusion, of course, but it’s a function of the expectations of traditional project management. In manufacturing and construction, the product is well understood, and the development methods for producing it have been institutionalized. As a result, you can write a detailed plan and quantify risks with some accuracy.

In software development, it is rare that we start with detailed specifications for the end product, and in an environment like Amazon, we are never implementing solved problems. We’re always inventing a product by inventing a technology. Planning that kind of project is more art than math.

What works is described best by the Extreme Project Management framework. It assumes that “…speed and innovation are critical, and planning is chaotic and just-in-time.” That’s not the same as the old school flailing around that preceded PMBOK. It has a clear problem or opportunity framing that gives project leaders enough detail to make consistent decisions without surprising stakeholders with unexpected outcomes.

At Amazon, that framing is delivered as a document called a Press Release / Frequently Asked Questions (PR/FAQ). We literally write the press release we hope to use on launch day complete with fake quotes from an internal leader and a reference customer. The template for these press releases is exactly the same as the standard for all public relations professionals, and we treat the writing of them with the same importance as a press release we’re actually issuing.

Getting that press release right is an exercise in clearly defining the market position of a product or feature. That position represents your target market, status quo, and product differentiator, and we use it for decision making about whether to build and what to build.

In 2018, our mock press release for the machine learning category for AWS Marketplace described the democratization of machine learning by making advanced algorithms and models accessible to all AWS customers, but Amazon SageMaker had already delivered that. It was in the review of the mock press release that we were able to get super clear about the value proposition of the marketplace. It’s the same value of any marketplace – selection and convenience. This launch was about making ALL algorithms and models available to AWS customers – not just the ones Amazon has developed.

For software development, the target market and product differentiators translate into your target user personas and feature priorities, and we state them explicitly in the accompanying FAQ. The frequently asked questions are about the minimum viable product, and they ask specific things. What will someone tell their friends over coffee about this launch? What will customers be disappointed by when this launches?

Once you have your north star for the project, you can dig into your first steps. I like setting up mechanisms for projects, and the specific mechanisms depend significantly on the complexity of the project. I always have at least a weekly managers’ check in meeting (scrum of scrums) and a biweekly senior leadership meeting, and I’m fond of using those meetings as an opportunity to remind everyone that we have exactly the right amount of ambiguity for this moment in the project.

The goal is always to have a super crisp plan for the next 30 days, an outline for the next 90 days, and the “hard to change” dates for the balance of the project, like deadlines for partnership agreements, code completion, and tax analysis. The milestones in the 30 day period must deliver everything I need to have a super crisp plan for the following 30 days. In other words, I am spending this month figuring out what I’m doing next month.

I have the 90-day plan and my “hard to change” dates up to and beyond launch, so I am not exclusively focused on the 6 inches in front of my face. I need to have a view further out on the horizon too, because the urgency and start time of each workstream is a function of its relationship to dates out in the future. I’m working backwards from those dates to make sure we land them.

At every step along the way, I’m keeping an eye on the critical path and what other people call risks. My rule is that I never have risk; I have action items. I don’t write things like, “We may not have enough engineering capacity to complete the work on schedule.” Instead, I write, “We have an action item to identify additional engineers to onboard immediately and ensure we have enough engineering capacity to complete the work on schedule.” Action items in lieu of risks is one of the ways you keep projects in the green, and they communicate specific requests for help to stakeholders.

Another important principle is ruthless prioritization. The mechanisms of status reports, scrum of scrums meetings, and senior leadership reviews are not for reporting, they’re forcing functions for retrospectives and introspection. They’re points on the calendar for collecting the lessons learned during that period, for looking forward and checking that we’re still doing everything we need to do today to be ready for the deliverables of the future.

There have been times when I’ve used those moments to stand up a whole new team – immediately. In other cases, I’ve scheduled elaborate demonstrations to persuade senior leaders to cut scope. One of the pitfalls of highly complex new products is that it’s easy to lose the forest for the trees. When we were preparing to launch the teen shopping experience, that’s exactly what happened.

We had a stack of open bugs and a list of features that the product team still wanted built just weeks before launch. From my perspective, as the project manager, I could see that we needed to drop all feature development and focus every engineer on the bugs. The challenge was that each bug individually was a bit of a paper cut. The scenarios were all something like, because this isn’t working, the user has to do this awkward thing here.

Individually, no one of those issues sounded launch blocking, and that made prioritization of the outstanding important features feel like the right thing to do. The complexity of the experience made it hard to comprehend the cumulative impact of all those nuisance bugs. It was a classic example of “death by a thousand paper cuts.” To make that clearer for senior leaders, I arranged for a couple of QA engineers to act out the end-to-end experience in a rehearsed skit that strayed from the happy path to demonstrate the likely path for our customers. We came out of that meeting with a ruthless prioritization; we had strict instructions to stop all feature development and fix the bugs.

New leaders always want me to point them at the right tool for driving project management. Frameworks like PMBOK can work in use cases where there are proven technical solutions and a clear product definition. At Amazon, we say there really is no compression algorithm for experience, and that’s because you can’t learn certain lessons until you get to different milestones in scale and complexity. You can start with proven mechanisms like the PR/FAQ, scrum of scrums, and status reports. Ultimately though, like all mechanisms, the value is in the inspection and iteration.

Successful project management comes from a willingness to fail, to change, and to innovate. Treat your stakeholder review meetings and status reports like chess moves, and make every minute of those communications valuable inspections to gain insights into risks and opportunities and to ask for help. You’re never going to deliver on a plan, but if you follow this approach, your plan will deliver results.