“Snapping the Chalk Line:” Organizational Problem-Solving

Problem

There I was, new to the company in my first senior engineering leadership position, leading an organization that has been troubled by not being able to deliver new releases. This inability to deliver had caused a huge problem in sales, ultimately causing the company to recap from scratch with new investors. I was brought in to "fix things; fast." My first blush investigation showed problems with estimation. But, that was not truly the root of the problem.

Actions taken

"This memo about estimation is brilliant! In fact, it may be one of the best papers on software estimation that I have ever read," said Tom, my new boss, Chairman and interim CEO. My chest swelled with pride... until his next statements. He continued, "But, it's all bullshit. Engineers are always going to make huge miscalculations with estimates: always have and always will. Issues arise during development that the engineer never knew about at the time of the estimate. You need to create a process that is insensitive to this estimation error. One bad estimate alone cannot take down the whole project." Tom made a good point, but a solution was not clear at that time. Thinking on it some, I came up with the concept of "snapping the chalk line." Most of the features that we were working on within a release are quite separable. So, we changed to separate the configuration management streams for each feature. That way, if one particular feature slid out beyond the rest, we could "snap the chalk line" and effectively deliver only those features that were ready on a particular date.

Lessons learned

The use of the "snap the chalk line" effort was made often and has been an element of the process we have used for many years with great success. But, the most important thing here was to use an organic (systems) thinking process. Instead of jumping to a corrective action based purely on what looked like the solution to a single root cause, think through how all the pieces of the process fit together. Understand that any process that relies on humans will have vast variations of results. Don't get locked into a single (linear) logic path when solving problems with your organization.