Scope Creep

In my more than two decades of product management experience, with many different engineering and development organizations. Regardless of how great the teams are/were, there are always slips in schedule.

I am puzzled by this. Even when with a great team, populated with hugely talented, and highly productive engineers, programs take longer than planned. Perhaps it is because most of his products are hardware and software, and both have different development cadences?

[mks_pullquote align=”right” width=”320″ size=”20″ bg_color=”#8224e3″ txt_color=”#ffffff”]Delays in the program invariably lead to the need to add to the initial requirements, and the cycle begins..[/mks_pullquote]Nah, that isn’t it. Even with complete latitude, and no interference to planning, the programs are late. And not just measured in weeks, but usually quarters or worse.

This leads to the inevitable scope creep, the bane of all programs. I truly try to resist this, but alas, as time goes on, the market and the competition do not hold still. They are adding capabilities, features, and changing the game. So the requirements change. Somethings get de-prioritized, some are added. All cause heartburn for the development team.

The scenarios:

• Your program is to replace a current product, and it is constantly being improved. Good practices are to continuously improve your product. Standing still is a sure way to be destroyed in the market. Your competitors aren’t obliging you by not changing their products, so neither can you. Of course, this creates a “Moving Target” for development. The end goals are constantly being redrawn.
• A new product, or new to you. If you are lucky, you may not have any competition, or you may be defining a market. Yet, a product definition, and a market entry plan always has some time sensitive nature to it. Hopefully, your marketing person (often the product manager) has factored the “time to market“, and the market window timing into the original plan. Miss that, and the game changes, as will the requirements.

Sidebar: In the case of a delay causing a missed market window, one of the responses should be to cancel the program. If you miss it, you may never gain the traction that you expected at the start of the program. Yet this has never happened. See my post on “sunk costs”

Regardless of the cause of the delay, when schedules slip by “quarters", it is nearly inevitable that the scope creeps. Product Management does fight this, knowing that feature is the death of programs. That said, the pressure exerted by management who has made commitments to his leadership, the urgent demands of sales who needs just one more feature added to the product, you know, since you are late, you have time to add their pet widget (multiply this by all regions and all sales people and bam, you are outta control).

My commitment to My Team

I don’t enjoy changing program parameters. I don’t do it willy-nilly, or on a whim.

Up front, my requirements will be clear. They will have enough detail to be actionable, yet not so much detail that it is too constraining. I will justify the market segments we are targeting. I will answer your questions about marketing (contrary to popular belief, I do want you to understand the why). I will define what is in, and almost as importantly, what is NOT in a product. I will negotiate with you in good faith. I will apply some Kentucky Windage to your estimates (to give you some wiggle room).

But if you blow the schedule by a lot, then the requirements will change. Deal with it, or get better at estimating, and meeting milestones.