Sometimes, of course, we'd fail to deliver something of use to our customer and miss the point entirely.

I remember one project I worked on where we were given ideal working conditions. The teams were offsite, in our own offices, which meant we could be dedicated to the project we were working on without being disturbed or shoulder-tapped by others. It felt like the perfect setup for success. 

We spent ten months painstakingly delivering precisely to requirements. Everything was built and tested out according to the detailed designs we were given. We were even on budget and time when we delivered. Unfortunately, when the software went live and was in the hands of the people using it, they reported back that it didn't do the job they needed it to do.

Why had we failed? We'd failed because we spent ten months building something in isolation from our customer. We hadn't involved them in the implementation, and too many assumptions had been made. Diagrammatically, this looked a little like the following:

We then spent the next six months reworking the software into something that was usable. Unfortunately, for the partner company working alongside our team, this meant a major variance in their contract, most of which they had to swallow. We eventually did deliver something to our customer that they wanted and needed but at a huge financial impact on us and our partner company.

This, unfortunately, is the path that predictive planning sets you on. You develop a fixed mindset around what is to be delivered because you know if you aren't dogmatic in your approach, you're likely to fail to meet the date, budget, or scope set in the contract.