The Scope Change That Could Have Derailed Our Launch

-

Six weeks before our product launch, the VP of Marketing walked into my office with what she called "a small request." She wanted to add a complete user onboarding flow to our mobile app. Small request. Right.

I'd seen this movie before. In my early days as a project manager, I would have smiled, nodded, and quietly absorbed the extra work into our timeline. The team would have worked nights and weekends, quality would have suffered, and I would have spent the launch week putting out fires instead of celebrating a successful delivery.

But I'd learned the hard way that scope changes, no matter how they're dressed up, follow the laws of physics. You can't create time and resources out of thin air.

The first thing I did was assess the real impact. This wasn't just adding a few screens. The onboarding flow required new API endpoints, database changes, additional testing scenarios, and integration with our analytics platform. My rough estimate put it at three weeks of development work across four team members.

Instead of keeping this analysis to myself, I immediately called a meeting with my lead engineer and the product owner. I've found that surfacing scope changes quickly prevents them from festering into bigger problems. When stakeholders understand the technical implications early, they make better decisions.

Next came the hard conversation with the VP. I laid out the tradeoff in simple terms: we could add the onboarding flow, but something had to give. We could either cut the advanced reporting features we'd planned, extend the launch date by three weeks, or significantly increase our budget to bring in contractors. There was no fourth option where we magically delivered everything on time.

This is where many project managers get squeamish. They want to be the person who says yes to everything. But your job isn't to be agreeable. It's to protect the project's success by making tradeoffs visible and forcing decisions.

The VP chose to push back the launch date rather than cut features. Not my preferred outcome, but it was her call to make. My job was to present the options clearly, not to make the business decision.

I documented everything in an email that same day. Not because I don't trust people, but because memory is unreliable and projects are long. Three months later, when someone wondered why we'd missed our original launch date, I had a clear record of the decision and who made it.

The final step was updating our project plan to reflect the new reality. I didn't just add three weeks to the end. I rebaselined the entire schedule, adjusting dependencies and resource allocations. The onboarding work affected our testing phase, our marketing timeline, and even our customer support training schedule.

The product launched successfully, and the onboarding flow became one of our most praised features. But the real victory wasn't the positive user feedback. It was that we delivered a quality product on our revised timeline without burning out the team.

Scope changes aren't project failures. They're business realities. The difference between projects that succeed and those that spiral is how you handle them when they arrive. You can't prevent scope changes, but you can control how transparently and systematically you manage them.

Popular posts from this blog

The Dual Faces of Technology: Enhancing and Replacing Jobs

-
Image
Automation has been on my mind a lot lately, more immediately due to a book I read , but also because of the looming reality of artificial intelligence. To understand what's involved, making the distinction between replacing technologies and enabling technologies is crucial. As we traverse the timeline of the 20th century, we observe how each type of technology has distinctly influenced employment. Automated technologies have transformed industries by replacing manual labor with machines. Consider the automated switchboards introduced in the early 20th century. Previously, telephone operators manually connected calls using physical connectors on a switchboard. With the advent of automated switchboards in the 1920s and 1930s, many of these jobs were eliminated as calls were routed through electromechanical systems. Similarly, in agriculture, the introduction of mechanical harvesters like the combine harvester in the 1930s drastically reduced the need for manual labor. These machine...
Read more

The Technology Trap: Capital, Labor and Power in the Age of Automation (Book Review)

-
Image
In his compelling book, " The Technology Trap: Capital, Labor, and Power in the Age of Automation ," Carl Benedikt Frey offers a sweeping examination of the historical and ongoing impact of mechanization and automation on society. Starting with the onset of the first Industrial Revolution, Frey deftly navigates through the evolution of technology up to the modern age of artificial intelligence, presenting a nuanced view of how technological innovations have reshaped labor markets and power dynamics. Frey categorizes technological innovations into two types: enabling technologies, like the typewriter, which enhance worker productivity without displacing the labor force, and replacing technologies, such as robotic machinery in factories, which eliminate certain job roles altogether. This distinction forms the backbone of Frey’s analysis, as he explores the varying implications of each type of technology on different segments of the workforce. The book traces a historical patter...
Read more

Deputy Product Owners

-
Image
"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner." - The Scrum Guide There are a lot of ways in which my approach to Scrum differs from what's in the official guide, and since that document refers to Scrum as 'immutable,' let's just call what I do 'Notscrum™.' In Scrum, there is only one product owner per team. That person is the sole person responsible for the product backlog, and the person who advocates for the work to be done. In Notscrum there is one product owner, but there can be multiple deputy product owners. Here's how it works. When my program at Viacom was first forming I met with the then-director of the Library & Archive group and learned that while he set the priorities on work done, the archivists were organized in three distinct areas with a team lead ...
Read more