Shortly after Ogg, the Cro-Magnon design engineer, joined the Bison Valley Ax Works, he was told to plan his first project. So he made a list of the project tasks, and he realized that there were many possible sequences that he could use. Because he was in awe of the more-experienced senior engineers who appeared both intelligent and wise, he decided to seek their advice. "Should I do the hard tasks first or the easy ones?" asked Ogg.
Opinions were divided. Some of the experienced engineers argued that it was better to begin with the easy tasks. They explained that this would generate quick pro-gress, which had both political and psychological advantages. They stated that early progress would impress management and inspire their support. Access to resources would be easier, and annoying micromanagement would decrease. In addition, they claimed that the project would develop a "winning" image and people everywhere would fight to be associated with its impending success.
Supporters of this side further explained that team members are energized by a sense of progress. Merry from accomplishing easy tasks, they would work harder, leading to even faster progress. They would secretly begin shifting increased attention to the "winning" project.
Engineers on the other side argued that it's important to tackle the hardest tasks first. They explained that if you save the difficult stuff for last, then you have a good chance of throwing out the easy stuff. For example, the particularly tricky input stage that you saved for last might not work with the rest of the system. Then you experience a dreaded "design reset" in which the dramatic progress made early in the project on all of the easy subsystems instantaneously vanishes.
Where does the truth lie? As a general rule, the smartest sequence for tackling a development project is to resolve the greatest risks first. Product development at its heart is a process of risk reduction. It's usually a bad idea to save the large risks for last. Nevertheless, there are some circumstances in which large risks may be deferred, although this has nothing to do with psychological or political motivations. (There are better ways to motivate both team members and management members than resorting to inappropriate task sequences.)
When should you defer resolving large risks? The cost of resolving a particular risk is key. Our objective in design is to resolve risk efficiently and/or quickly. Therefore, a particular task should be performed early in proportion to the amount that it reduces risk per dollar spent (or in the case of cycle-time driven projects, per day of the critical-path time that's consumed). It can be better to resolve a small amount of risk with a cheap, fast test than a larger amount of risk with a very lengthy, expensive activity. For instance, animal lab testing in pharmaceutical development doesn't reduce risk as much as human testing, but it's much faster and cheaper.
In rare cases a large risk may resolve itself. Very often this occurs with regard to market risks. While it might be difficult to forecast the demand for a new feature at a long time horizon, it could be easier to make predictions later on in the program. In such cases, deferring commitment can make a lot of sense.
In summary, it's usually sensible to resolve the greatest risks first. But always think carefully about how you will resolve risk on your project.
Reprints
