I wrote about ways to “cheat” at project prioritization [aka trying to figure out what to work on next, when there is more demand (projects) than supply (people to work on them)]. One significant tool you have at your disposal is controlling scope – can you do 20% of the work to get 80% of the benefits?
Easier said than done, sometimes you need tactics, that help identify an opportune place to stop, a run-on project, or a design that is”simple enough”.
- Apply the Law of Diminishing Returns “in reverse”, and front load the benefits. Let’s say we’re implementing a series of components (people, process, and technology) to analyze and improve promotion response. If I really understand the ROI, can I break it up into chunks? In this case, you might see a basic software package that defines master data, collects transactions, and provides basic metrics for promotion response. Let’s say this visibility allows you to realize 70-80% of the benefits, but we want to follow with “phase 2” where we add training, tuning, and optimization to get another 20 to 30% of your ROI. Well, time and resources are short – why not stop at phase 1, let the new processes soak in, and “optimize” later?
- Eliminate the 90-percent Done game – Projects that run-on forever sap the energy out of your teams, and destroy credibility with the business units whose projects are getting delayed. Via Vinson, here’s an excellent post from Blain that reference’s Zeno’s Paradox (I’ll never get there if I keep traveling half of the remaining distance …). The primary tactic is to define discrete deliverables (tasks?) and only accept a binary status – it’s either done or it ain’t!
- Keep It Simple, Sir! Feature creep is the greatest enemy of the short-term project. Some features (like quality / testing) are not what you’d want to negotiate out of the project. Thinking about cutting short on documentation? You naughty, normal person … However, take a look at this post from Sierra, with a great illustration of the idea that usability is optimized right before the user has to reach for the manual!
With Big Contacts there is no user manual. Because once you create a user manual, you are admitting your application is too difficult and that people need a book to use it.
Let’s steal that idea for our projects. No documentation required, because the deliverables (process, technology) are simple and common sense enough that people don’t need a manual, a training class, etc.
Ok, maybe it’s not “practical”, but it’s a Worthy Goal that could help keep scope down to a dull roar …