(A) 
(B)
This is a fun idea; it can be good and fast, but it’s won’t be cheap, or it can be good and cheap but it won’t be fast. Fortunately, this not always true. There is no universal standard for good, fast, or cheap. Each of these words is relative to the specifics of the project, and being expensive and slow doesn’t guarantee it will be good.
When developers adopt this mind set, and consistently apply it to all their projects, they become prisoners to the “or”. It has to be this OR this, because it cannot be this AND this. Who made up this rule and why do so many adopted it as truth? Yes, it can be used as a reality check on the constraints of a team, but it should not become the team’s motto. I’ve seen great results done quickly and on a low budget.
Here are two examples of good, fast, and cheap ads created for an internal campaign directed towards a technical support team. The goal was to get everyone to record the exact version of the customer’s software on every call. They were getting the major number, but too many were not recording the minor and release numbers.
We needed something in their face that would capture attention. The life cycle would be short and the problem needed to be corrected as soon as possible. What they didn’t need was to be lectured by their managers, pulled into a training room for an hour, or given a traditional job aid.
This ad (A) [click the image to enlarge] was printed in color at 4” x 6” and taped on the shelf in everyone’s cubical next to their monitor. The image was a free download of the week from iStockphoto and the text and formatting took ten minutes. I used SnagIt but could have easily created it with Microsoft Word or PowerPoint. This ad (B) was used in a follow up e-mail a week later.
The number of techincans recording the version number increased dramically. By the following week we were reached 100%.
Sometimes things can be good, fast, and cheap. Especially when the life cycle is short. Here’s one more example (C).
(C)
Matthew R. Lee 