When a project spans more than a few weeks, its planning tends to be no small feat. Moreover, once the project does kick off, workers tend to invest more time and perform more efficiently during the second half than during the first due to the feeling of "working against a deadline." This phenomenon raises the natural question, how can one encourage a team to work on a project with a more even level of effort throughout, so that it is always completed by the deadline or sooner?
To illustrate the problem, let's think about a fictional project with the following outline that may sound all too familiar:
- A meeting occurs near the beginning of the project to establish its scope and define its goals
- Time passes and work is accomplished at a fair rate, although never at the team's full potential
- The midpoint of the project nears and the team assesses whether it has truly completed 50 percent of the work
- It hasn't. Panic sets in! Amplification of effort occurs as the deadline looms, climbing exponentially as the deadline rears its ugly head
- Making matters worse, previously unknown obstacles invariably seem to appear and introduce delays
- Coupling these newfound stumbling blocks with the imbalance of work, features are rationalized away and the deadline is pushed back
Graph courtesy of Dr. David Schneider.
I certainly saw this phenomenon while developing a series of robots to showcase at the Cornell Cup USA presented by Intel; a national embedded systems competition held at Walt Disney World. For one of robots, shown in the picture below taken by teammate Benjamin Allardet-Servent, we developed a dune buggy-like rover capable of many feats such as identifying visual signposts and playing a game of laser tag. In January, our team defined over 20 deliverables to be accomplished by May, goals ranging from streaming video off of our robots with less than 0.2 seconds of latency to a wheel system with built-in suspension allowing the robot to traverse rough terrain.
In order to mitigate the dreaded last week/month crunch time, we broke our project and goals up into bite sized pieces with tangible deliverables. For instance, one of our May end goals was to have two cameras streaming with less than 0.2 seconds of latency. Therefore, we set a deadline of having one camera streaming with less than 1 second of latency by February. In fact, we broke up every single goal that we expected to take longer than a month into some form of a deliverable that could be tested and confirmed to work within the first few weeks.
Additionally, by having deliverables throughout, unanticipated hurdles can become unearthed sooner, and their potential delays can be obviated. As an example, we discovered from our February milestones that even one camera proved to create a heavier load on our network than expected. This was an issue that we were able to address via compression libraries and reducing the frame rate, but it was also an issue that we did not discover until we actually had a working prototype. Had we attempted to have both cameras working in the end, stumbling across this issue later in the game would have undoubtedly forced us to cut the feature or delay our deadline.
This example also demonstrates how having milestones gives you the opportunity to reevaluate your priorities, and redirect efforts to reduce risks and uncertainty while there is still time. Decisions can be made more carefully and calmly, while properly considering the overall performance of your system, instead of being made haphazardly as a knee-jerk reaction during crunch time.
If you're curious about how our dune buggy-like robots turned out in the end, an article by Engadget can be found here. In short, we attribute much of their success and the confidence in our work not only to the talents and skills of our team, but also to our approach of using multiple milestones with deliverables. Short-term milestones with deliverables improve overall throughput, but moreover the repeated cycle of developing, testing, and reevaluating helps to actively bring out and deal with the unforeseen and unpredictable obstacles early on.
Also if you're interested in getting an intro to some of our other Systems Engineering techniques, be sure to check out the Cornell Cup USA presented by Intel resource page here. And remember as the adage goes, "test early, test often."