Drinking the Kool-Aid, part 2

A couple weeks back I wrote about our “new mech” project, a wholesale redesign and reimplementation of our knowledge aggregation mechanism. In this post I will talk about why traditional project management techniques failed us and how Crowdcast helped us to recover.

As I mentioned last time, our initial attempt at running the project revolved around a project plan and regularly scheduled meetings. The project plan was standard — milestones, subordinate tasks, dependencies. Task owners came up with costing estimates. Since we were an experienced team, we added fudge factors liberally. Once the plan was in place, the team leads — engineering, product management,qa — agreed to meet weekly to track progress.

The alpha release milestone was critical, but comfortably far away, so the first few meetings were genial. But a week before ship it became ugly. Turned out that the port from our development environment to test (which simulates production) was in trouble. This was one of those on-going tasks. Deal was that as new APIs came on-line, they’d be ported for testing. Somewhere along the way, this stopped.

How could this have happened? How could it have taken us until the last minute to find out?

After the dust settled, we saw that the task reached 85% completion weeks ago and stalled (the problem was a serious bug in some 3rd party code, which was waiting for a patch). The engineer who owned the task, and indeed others, knew that the alpha milestone was at risk, but lacked a good way to give their knowledge voice. Since everything else was tracking well, intentionally or not, the problem that derailed the project was swept under the rug.

On reflection, it wasn’t a problem of scoping, project sponsor buy-in, staffing, or implementation. Rather, it was a problem of communication. That was when we decided to drink the Kool-Aid.

In the first post in this series, I described our experience with using Crowdcast to gain insight into risks around the next important milestone — the beta release — in the new mech project. Recall that the system rewards people for revealing rare and relevant information early. Moreover, since bets are placed anonymously, participants’ incentives are uniform and aligned. As bets come in, the system aggregates them in real-time and generates alerts when new information reduces the likelihood of success.

The first screenshot is of a piece of the console, which shows crowdcast summaries. The second is a part of the detailed view, which shows the distribution of beliefs as well as how they are tracking relative to target.

My bet on the beta crowdcast caused an alert to fire. It was an early warning for Huned, which gave him time to understand the root cause of the problem and make adjustments to keep the project on track. Next time I’ll put all the pieces together and present a complete overview of the platform that the new mech of ours enables.