Ignore Constraints

/

Question

Most of the time, when we talk about a constraint, people will be thinking about resources (human resource, machine/equipment, software license constraint), which are real and need to be factored in during planning.

  • How do we practice the "Planning with no constraints" philosophy during the build/model session?

  • It seems counterintuitive not to consider constraints when planning.

  • Constraints are real and should be a factor, shouldn't they?

Response

image.png

A core principal behind FTTM is to initially plan without constraints. Fast teams plan without constraints, slow teams plan using constraints. So why does this counterintuitive idea work?

If I told you to make a plan to deliver something and I told you to do it in 6 months with five people and $1M. You would start from these constraints and try to figure out how to do it in 6 months, with five people, and not spend more than a million dollars. By starting with the constraint you are almost certain to fail. Why?

Because you started with the constraint! These constraints are usually arbitrary or they become limitations that stop people from thinking creatively about the best way to do something. This is true of the way many people think, they stop solving problems because the constraints overcome them. They stop thinking.

So in my little example, I may know that it can’t be done in 6 months, I may need more people and I may need more budget, but I do what I’m told and make a plan that fits inside the constraint, even though I know it will fail.

This is the first step in a team de-committing to the outcome, when they stop think and accept the constraints. Yet they will make a plan that says on paper it can be done. I would say this is 95% of the projects we see. Same is true when solving technical problems. When you start from the constraint you have already taken away possible solutions because the mind tends to work inside the constraints/boundaries. Most good solutions come from going outside the boundaries.

The alternative approach is FTTM thinking. I ignore the 6 months, the five people and 1 million dollars they say I have to do the project and approach it from the other perspective; what is the goal and desired outcome (start with the end in mind, not the limitations I’m given)? how will we measure success? what is the best way to achieve that outcome without compromising the product? what is needed to do the job right, regardless of the budget and time? how much money and people/skills do I really need to achieve the goal? is this the right goal then?

Another way to put it, I may want a Mercedes, but I only have a KIA budget. No matter how much I want that German car, it isn’t going to happen if I approach it from the constraint of the budget. If ignore the budget and describe what I am trying to do with the car, it may become clear that I could do a short term lease of the Mercedes to achieve my goal and stay inside the budget. The assumption that I had to buy the car was false, but I never would have challenged it had I not stepped out of the budget constraint and looked at the problem differently.

Once I answer these questions I can make a plan to achieve success. Then I have two points for comparison; 1) the original target/budget and 2) my plan that is based on the desired outcome. I now have a gap that permits comparisons. My best-case plan comes out at 10 months, requires twice the budget. I use the gap to force a review of the project objectives.Maybe we release a prototype in 6 months and a final design in 10? I may use this to change the outcomes or redefine how they may be achieved. Showing that plan can be in six months for the budget takes away the opportunity to change the project is being done.

The point is that by planning without constraints I now have a plan the team believes in and can get behind to find a way to close the gap. Rather than ignoring the gap and in doing so ignoring their input. When people’s ideas are ignored they disengage and they don’t participate in the solution. When I can get them participate then I can use their collective brain power to find the solution to close the gap.

If at the end of the day we can’t find a way to get the project back closer to the 6 month target then maybe we should kill the project before it starts, rather than start something that will fail and suck of valuable resources from projects that might have a better chance of success. This then transitions to the pull-the-pain-forward practice and to force resolution early, while there it time to correct it/find a solution.