Tactics for Controlling Project Scope
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.
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!
Click on the picture for a
The folks at Big Contacts
liked the idea so much, they tout
it as a feature ...
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,
Ok, maybe it's not "practical", but it's a Worthy Goal that could
help keep scope down to a dull roar ...
when demoing / training / pitching complex systems (May 23, 2005)
IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
a huge project list to simplify the prioritization process (October 27,
the Pareto principle (January 7, 2006)
requirements for technical documentation are lower than user
documentation (April 3, 2006)
on Why Tech Folks Hate Documentation (July 8, 2006)
Iron Triangle - Quality is a Feature that We Choose to Omit from
Projects (October 28, 2006)
caveat for the erstwhile agile developer (January 15, 2007)
Education Pareto Principle (50/30/20) (February 13, 2007)
the Business Value of a Project (October 25, 2007)
Anti-Patterns That Increase IT Project Cycle Time (December 7, 2007)
Prioritization - Project Descriptions should be Effective, Relevant ...
and Short! (December 9, 2007)
to Cheat at the PMO Prioritization Game (December 14, 2007)
to Win at the PMO Prioritization Game (December 18, 2007)
Technorati Tags: business
Management, tech management, training