Alice had a great idea for a product. She had designs, validation, and a small budget. All she needed was a dependable, affordable development shop to make her dream into a reality. She reached out to two such companies: Bumbling, LLC and Helpful Hands, Inc.

Bumbling reviewed her RFP, assured her that everything in it was easily done, and proposed that they could build her app in 8 weeks for an estimated price in the low 5-figures. She was happy.

Helpful Hands responded with a 12-week timeline, and a price in the mid 5-figures. "Why the huge discrepancy?", Alice wondered. Helpful Hands' proposal enumerated a few high risk items that needed to be cleared up in the first days of work.

Both companies' proposals were estimates, not fixed bids. What should Alice do?

Being Predictable

What Alice didn't know is that if she could have looked at each companies' past projects, her choice would have been much clearer. Bumbling had a history of overpromising and underdelivering. Helpful Hands often turned out a similar quality product, but had great awareness of their staff, and nailed their estimates with accuracy.

If Alice could have graphed the distribution of Bumbling's project completion times relative to their estimated completion times, she would have seen that Bumbling finished most of their projects a little late. They finished some of their projects really late, doubling their original estimate. In fact, the curve was so wide, that you could hardly rely on Bumbling's estimates at all!

The same graph for Helpful Hands revealed longer project lengths, but a much smaller variance. Helpful Hands's projects often came in right on time, with a few a little earlier, and a few a little later.

In the graph above, the blue line represents Bumbling, and the orange line represents Helpful Hands.

Alice only knew subconsciously that for project stakeholders (i.e. those with the most to lose), software projects are entirely about predictability.

With complete information, she would have gladly paid more to know that a project would get delivered on time as expected, than run the risk of it spinning out of control.

Shortening the Feedback Loop

Alice chose Bumbling based on their cheaper price, and her project commenced. Everything was going well until about halfway through the project. Alice noticed that although they had been meeting weekly—Bumbling practiced Agile, after all—she hadn't seen any part of her app running. They explained that there was nothing to show because it was still early, and that they were still building a lot of infrastructure. It made sense to Alice, but she still felt uneasy.

75% of the way through the project, Alice started panicking. Bumbling had only completed half of what was planned. Worse, when Alice looked at what they had completed, though technically it adhered to what she designed, she knew it was too many steps for her users.

With 25% of her budget remaining, Alice raised her two concerns. Bumbling explained that the primary reason for the delay was that they spent a lot more time than anticipated on integrating a 3rd-party library. Alice told them that the library enabled a feature that was "nice to have", but not critical, and that they could have ignored it. But it was already done.

She also asked about modifying some of the UX. The Bumbling project manager drew this graph for her:

"The later a change is made in a project, the more it costs," he said. He told her that they could make the changes, but that it would add heavily to the timeline. Alice was sad.

In an alternate universe, Alice went with Helpful Hands. They met weekly, but it wasn't a "status" meeting. They came with an agenda of concerns, risks, and alternatives. They identified the risk with the 3rd party library, and together they decided to nix the feature. Because Helpful Hands committed to delivering deployable, working code two weeks into her project and every week thereafter, Alice saw a rough UX of her app 25% of the way through her budget, instead of 75%. She asked for her UX changes and Helpful Hands easily took care of them.

50% of the way through her project, Alice suddenly realized that the product that was being built barely resembled her initial designs at all! And she was glad! Though her app was incomplete, she showed it off to her close friends and family, and started getting real, user feedback. In fact, she had enough budget left to incorporate some of the feedback into the remaining work immediately.

With 25% of her budget left, Alice met with Helpful Hands's project manager. He drew this graph for her:

"People often misinterpret this graph it as saying that the cost of a bug goes up if it occurs later in the project. But the x-axis here isn't the project duration. The x-axis represents the time from when the bug is made to when the bug is discovered. So a bug that is introduced late and fixed immediately doesn't really cost more than a bug that is introduced early and fixed immediately. By the way, a bug could be made anywhere, like in system design, UX, or coding.

"What this means is that best way to control a software project is short feedback loops, and the shorter the better. Feedback comes in many forms, from automated tests, to having the client onsite and communicating daily."

Building Vision

Then, the project manager let her in on a little secret.

The reason that Helpful Hands was so good with their estimates was that they were selling a vision, not hours, not features.

Their clients were buying a vision, not a block of hours, and not a set of features. Features were simply a means to an end. Selling hours is easy, but you may not get what you want. Selling features is hard because there are always surprises and unseen obstacles. But vision is a world state, and there are many ways to get to that state. With good personnel, building a piece of that vision in a fixed amount of time was a matter of choosing the right thing to work on.

There are many clients like Alice. As a development shop, we strive to be more like Helpful Hands, Inc. and less like Bumbling, LLC. Planning poker, story points, Kanban, Scrum… there are many books and articles about software processes, project management techniques, and estimation. But over the years, I have found the three principles in this article—be predictable, shorten the feedback loop, and build vision—can guide all actions in a successful project.