Stakeholders Want to Plan a Year Out

It is common that business stakeholders have a list of things that they want built. If allowed, they will fill up the backlog of work items for years into the future.

This is problematic for these reasons:

If something goes wrong—which it will—there is no spare capacity to fix the root cause of the problem.
When building technology products, it is not possible to determine an exact timeline. Product development is full of unknowns, and one cannot task it out ahead of time the way that one would task out factory work like packing boxes. Product development is a creative process—not a repeatable process. Therefore, timelines will be wrong, and so one should not create plans that are too detailed too far out.
In the course of product development, it is almost always the case that the product concept changes, due to early feedback or due to a growing understanding of the product’s features. If the development plan is filled up into the future, there is no room to make tactical adjustments without redoing all of the future plans, which is burdensome.

In his groundbreaking book Leading the Transformation, former head of software development for the Laserjet printer at Hewlett Packard spends almost the entire first half of the book explaining how he needed to persuade business stakeholders to leave 50% of capacity unassigned. That was necessary in order to avoid the above problems. That is the only way that he was able to have capacity to make improvements to the development and testing processes, so that their speed of development could increase.

During the 2000s a paradigm emerged in which internal IT groups viewed themselves as a service, sometimes even set up as a profit center, that business areas would contract with. This was a very unhealthy trend, because it resulted in these kinds of situations:

IT became an order-taker, unable to make its own case for improvements to how it does its work.
IT funding came from their internal customers. But those customers never want to be the ones to pay for improvements to how IT does its work. The result is that IT was starved and its processes became stagnant.

IT needs to be viewed as a business partner. It provides strategic digital capabilities, and it knows how those can be utilized well. It needs to co-define the work to be done, so that priorities between product features and process improvements can be balanced.

For that to be realistic, two things are needed:

These are actually two principles from Agile 2, and they are hyperlinked to those principles. These shared understandings are necessary in order to be able to have partner-like conversations that jointly consider business and technical work tradeoffs. Business and IT stakeholders do not need to be experts in each other’s areas, but they need to take and interest, and need a basic understanding.

Just as business stakeholders expect that IT leaders (and staff) understand the product’s intended usage and the business context, business stakeholders need to understand the technology context. They need to ask how the product will be built, and take an interest in that. Just as NASA takes an interest in how SpaceX builds the vehicles that NASA contracts to fly crew on missions, business stakeholders must always take an interest in “how the sausage is made”. Otherwise, you are unable to have holistic discussions that integrate what the product does and what can and should be built. Building today’s tech products is difficult and risky and there are lots of tradeoffs: if you don’t understand the way the tech will be built, then you are in the dark about the tradeoffs, and will make very bad choices.