• Continuous Learning
  • Posts
  • Feb 4 2019 - Fixed time, fixed scope projects always end in 1 of 3 ways. None of them good.

Feb 4 2019 - Fixed time, fixed scope projects always end in 1 of 3 ways. None of them good.

Fixed time, fixed scope projects always end in 1 of 3 ways. None of them good.

Fixed time, fixed scope projects always end in 1 of 3 ways. None of them good.

We’re delighted to announce that we've partnered with Lean Startup Summit for their next event: a two-day innovation gathering in Berlin on Feb. 11 & 12. We’ll kick things off on Feb. 11 by taking part in a day of Unconference sessions before heading to the official summit opening party and Sense & Respond Press book launch for Tim Herbig's new book Lateral leadership. Feb. 12 is the main summit day full of interactive formats like keynotes, workshops, roundtable discussions and mentoring sessions.

Want to join us there? Grab your ticket with a special 10% discount on all pass levels using the code ‘jeff10. See you in Berlin!

Late last month, after a particularly frustrating meeting I posted the following tweet: 

It turned out, not surprisingly, that I wasn’t the only one dealing with this failed project management approach. Many people reached out with virtual “high 5’s” and, more importantly, questions about how this could be so obvious to those of us who have been and are currently in the trenches and still such a commonly-used tactic to those in positions of leadership. The answer to the former seems obvious. Fixed time, fixed scope initiatives give managers the perception of predictability and control. With a clear timeline, milestones, dates and scope-based commitments they can provide answers to questions like “When will it be done?” and “When can we start selling it to our customers?”

And so the process begins anew. The features get decided up front. Estimates are given. The gantt charts get written. The launch date is determined. The project manager then works backwards from the launch date to determine the milestones from now until then and the team is off to work. And that’s when the trouble begins.

The team quickly learns that some of their assumptions were wrong. A feature that seemed simple to implement presents problems the team didn’t expect. An integration required to join a modern system with a legacy system fails forcing a re-think of the approach. Early customer feedback reveals that they can’t figure out how to use it and would be hard-pressed to abandon their existing solution in favour of this new one. Nevertheless, the team presses on…because deadlines.

When it becomes clear that neither the deadline nor the scope are going to be met, project managers resort to one of the 3 options I listed in my tweet. They start to rethink their dates first while at the same time wondering what they could cut from the scope. If these edited projections fail to gain managerial approval, the team initiates “crunch mode.” Everyone puts in long days and weeks to ensure something ships by the deadline, burning themselves out in the process. If this is a regular occurrence, some of those burned-out folks are going to quit and work somewhere else. Interestingly, one of the comments to my tweet noted that in many orgs, these burned-out folks get lauded as heroes so that the next time crunch mode is needed, more are eager to take part. And the cycle begins again.

This is a failure of product management.

It’s an abdication of the responsibilities of the product manager to lead an initiative in a Sense & Respond way that embraces the uncertainty of modern product development, respects customer feedback and adjusts course based on what the team is learning along the way. It’s a failure to push back on the demands of often-arbitrary deadlines and sales-driven desires to compete based strictly on “features” rather than respecting the needs of your customers. Finally, it’s a failure to truly understand the nature and power of modern product development.

The Sense & Respond Process (courtesy of our friends at Xplane)

Here are 3 things to keep in mind as you approach your next product initiative to ensure your team is sensing and responding:

Systems, not projects

We’re not building static products any more. There is no fixed scope because these initiatives will continue to operate well beyond their launch date. Instead, we’re building continuous systems that provide us the opportunity to learn quickly and adjust our offering just as fast. This means that we should always question not only what we should build, but also what we should


from the system. The more focused and lean the system, the easier it is to maintain and make customers successful.

Shipping to market is the beginning of the conversation with your customer

Deadlines imply that if we don’t get the product right on the day we launch, we’re doomed. This is an antiquated point of view. Launching publicly simply begins the process of learning how right (or wrong) our assumptions were. It is the start of a continuous conversation with your target audience and the fastest way to learn how to optimise your system. The sooner you can get something to market, the sooner you can make the system better. By the time you get to your deadline, your product should have been in market for multiple cycles.

Good product management should be celebrated, not self-destructive ‘heroism’

Too often we celebrate the martyrs at work. Good product management means that no one has to be a martyr. By building in feedback loops, transparently and honestly reflecting on what you’re learning and adjusting the course of your initiative based on evidence, the best work will see the light of day incrementally without anyone having to put in an 80-hour week.

As we continue to evolve our agile ways of working we have to let go of the historical inertia of management processes invented over a century ago. It’s not easy but the more we can expose good product management practices to our organisations the better we get at building products customers love and teams that love building those products.



Upcoming EventsSmart Scrum Product Ownership - New York City - April 22-23, 2019 - Jeff Patton and I are back in NYC to teach our 2-day class. Early bird rates are on sale now and the event is 50% sold out already.Smart Scrum Product Ownership - Denver - April 25-26, 2019 - Please join us in Denver for our first class together west of the Mississippi.

As always, if you want me to work directly with your company on training, coaching or workshops on the topics of organizational agility, digital transformation, product discovery and agile leadership, don’t hesitate to reach out.Like this newsletter? Forward it to a friend.

Join the conversation

or to participate.