The idea of good enough is certainly not new, and is simply the latest incarnation of the 80/20 rule.  Unfortunately, I think many of us who understand the 80/20 rule are still struggling to implement it in practice.  It turns out it is really hard to know when to stop.

In a world of dwindling development resources, knowing when to stop is crucial to providing maximum service for the minimum investment.  The moment a developer begins working on the eighty-first percentile of a project, they have gone too far.  They need to be pulled off and turned loose on the first percent of the next project.  This is true for everyone in the development stream: the business analysts, the designers, the infrastructure people, everyone.  At some point, they are spending too much time on a project, expending effort that will not result in proportionally additional value.  They need to let go and move on.

[Note that this is not true for testers.  There is no 80/20 rule for testers.  They need to test 100% of the 80% that has been built.  More on this in another post.]

The problem is that no one knows when they have reached the eighty percent point.  Very few projects have a bounded definition that makes it easy to see when enough is enough.  Even when you do have such a bounded definition, user-induced scope creep can easily push that definition further and further out, dragging the eighty-percent point along with it.

It is often the case that a team will unknowingly extend the scope of a project as they work through the details of the spec.  Seemingly appropriate questions lead people down paths that occupy way too much of their time.  Everyone in the room knows how they got there, and why they are discussing some arcane feature, but no one was able to throw the flag and stop the process along the way. It all seems to make sense at the time.

That’s when you need a “sudden interrupter:” someone who comes to the process late, has not been a part of the incremental walk, and can easily see that things are off-track. They provide a bit of cognitive dissonance that allows the team to reset, regroup, and reassess what they are doing. Even if the group decides that they do want to continue their discussion, the pause allows them to confirm that they are on the right track.

I doubt that many people carry the title of Sudden Interrupter, but I’m beginning to think we need a few of them wandering about.  Gentle challenges during any decision-making process are generally helpful, whether you are designing software or refining a budget.  If nothing else, having to explain “why” to an outside observer is a constructive, cathartic exercise. So, go help someone.  Interrupt them!

At my company, we have some sophisticated tools for tracking our project portfolio, managing schedules, resources, and priorities.  We use these tools to drive planning and prioritization meetings, as well as to help our customers understand our planning and resource processes.  They provide greater insight into the ebb and flow of the work we do.

There are tools at the other end of the spectrum, too.  In addition to our portfolio management system, I also keep a list of various projects on my white board.  These are the projects that matter to me, for one reason or another.  Some are big, some are small.  Some are strategic, some are tactical.  Some have great political implications, while others may be the linchpin of a critical operational process.  But all of them matter to me, somehow.

Next to each project, I place a 2×2-inch vinyl square, either red, yellow, or green.  This is the same kind of vinyl used in those Colorform sets from our childhood, where you would stick different vinyl shapes onto a slick black background to create pictures.  That same vinyl sticks nicely to a whiteboard, and allows me to express my gut feel about a project.  Red expresses grave concern, yellow shows some doubt, and green denotes that all is well.

I update the squares as the mood strikes and as updates flow in from my team.  When good news arrives, a project may “go green;” bad news pushes a project down to yellow or (yikes) red.

Each day, as I arrive in the office, I place a small purple dot next to each square.  If someone comes and updates me on a project, I erase all the dots next to it on my board.  If a project is neglected for a period of time, the dots accumulate.  If a lot of dots collect next to a project, I know to go hunt down someone and get an update.

This highly complicated scheme was originally created to help me keep track of lots of projects quickly.  It certainly works in that regard.  But the real value of this system is what it has done to my team.

As people come and go in my office, they always stop and check the board, looking for their projects.  They want to know that they are green or yellow, and do not like being red.  They want to make sure that dots are not piling up.  This generates lots of conversation, which is always a good thing.  The board also lets people know which projects are top-of-mind for me, although I sometimes need to remind them that projects missing from the board still matter.

Just as importantly, people must come into my office to see the board.  At some point, it was suggested that I aim a webcam at the board, so people could review it from afar.  I declined.  I like that people must go to the board to see what is going on, and I like the quality conversations that ensue.  I am also told that people stop by when they know I am not here, for a “safe” peek at the board.  That’s OK, too. As long as people are talking and interacting, good things will result.

In spite of all of our fancy tools and systems, simple things often work best.  What’s the simplest tool you use to be an effective leader?  Have you considered Colorforms?

Nonetheless, various US cities fought fiercely to host the event.  After much politicking, Chicago won the rights to the fair in 1890, tasked to create an entire global event in less than two years.  Other cities, most notably New York, were sure that Chicago would fail miserably, embarrassing the US in the eyes of the world.

The citizens of Chicago proved them wrong.  Their herculean efforts to create the 1892 World’s Fair are chronicled in Devil in the White City, by Erik Larson. His scrupulously researched book provides a glorious view not only into the vast project of the fair, but of daily life in 1890s Chicago.  For those of us who manage large projects, there is definite sympathy for the team of architects and engineers who struggled against all odds to deliver, on time, the greatest fair in history, ultimately topping the French and cementing the US position in the eyes of the world.

Beyond the appeal to project managers, any fan of history will relish the endless number of things that originated with the 1892 fair.  Juicy Fruit gum, Shredded Wheat cereal, AC power, and the Ferris Wheel? All debuted at the fair.  A young draftsmen dismissed by the architects for refusing to adhere to their designs? That would be Frank Lloyd Wright.  A carpenter who helped create the fantasy structures of the fair who later regaled his children, Roy and Walt, with tales of the project?  That would be Roy and Walt Disney; each stroll down Main Street in DisneyWorld today is an echo of the same walk down the Midway of Chicago in 1892.

But what of the evil?  With the fair as a backdrop, the most prolific serial killer in US history preyed on visitors to Chicago.  H. H. Holmes came up with a clever idea: he built a hotel near the fair, offering rooms to the many young women who came to Chicago seeking a career amid the excitement of the fair.  Charming and charismatic, Holmes wooed these arrivals to the city, who seemed to disappear at an alarming rate.

The hotel occupied the top floor of his building, with his personal residence and shops on the floors below.  Few knew that the basement included a 3000° kiln and airtight rooms outfitted with gas jets. Holmes was a busy man; estimates of his handiwork range from 25 to 200 victims.

Erik Larson does a marvelous job of weaving these two stories together, contrasting the lofty aspirations of the White City of the fair with the dark evil lurking literally next door.  The technology and social structure of the Gilded Age that made the fair a success also allowed Holmes to operate with impunity.  Larson brings an immediacy to the book that makes it difficult to put down; his almost off-hand recounting of the present-day echoes of the fair is a delight.

This book is worth your time, if only to provide parallel views into worlds we will never inhabit: the fantasy of the fair, Chicago society in 1892, and the mind of a psychopathic killer.  Both are fascinating and in their own ways remind us that things, good or bad, are never really what they seem.

As you can imagine, the engineers were not overly enamored of this group.  Fortunately, the productivity team must have decided that our R&D group was beyond help, productivity-wise, since my group was rarely the target of their attention.  On the whole, our groups got along pretty well and often shared information.

At some point, a few folks from the productivity group got involved in a fairly elaborate project, working with another division in my company.  They were very excited about this project, which involved some fancy new computer system to collect and analyze a lot of data.  The more this woman talked, the more excited she got about the project, and the more doubtful I became of her chances of success.

After a bit, I asked her about system performance.  The data volume was large and the analysis was complex.  Even with the best current technology, a functional solution would be a challenge to build. Would the system be able to perform well?  Would the users be happy with response time?

She didn’t miss a beat.  “Of course, it will perform well!  We wrote that into the requirements!”

And off she went.  With the stroke of a pen, she had solved any and all performance issues this new system might have.  As you might imagine, the project never finished, for a variety of reasons.

It is easy to listen to this story and laugh at the naivete of non-IT people.  How could anyone design such a complicated system and them make it perform well with a simple written requirement?

The deeper lesson (you knew there would be a deeper lesson, right?) is that someone failed to educate this person as to the real complexity of her project.  Non-IT people cannot understand what we do.  Unfortunately, when we do it well, we make it look very easy.  When it looks easy, people assume that it is easy and base their world on that assumption.  This results in projects that fail to meet user expectations.

Users do not want to know the details of our technology.  But they need to know when things are really hard or really expensive.  If they probe, you can explain why. We owe them enough information, matched to their curiosity, so that they can appropriately plan and manage their world.  If we fail to do that, we have failed them, no matter how well our technology works.

Pretty straightforward: everything can be placed in one of these four quadrants.  We are either doing the right things or the wrong things.  We are either doing them well or poorly.  In contrast to all the complicated governance models that are being bandied about these days, this is a simple way to run your IT shop, your business, and your life.

As an eye-opening exercise, take all the major business processes in your company and place them in this grid.  We all like to think that we live in the upper right, doing the right things the right way.  In reality, way too much of our world is in the lower left.  Every business has outdated business practices, ancient processes, and needless bureaucratic overhead, firmly entrenched in horrifically bad tools and mechanisms.

It is not hard to find these “red” processes and set out to fix them.  Ideally, we seek to push them to the up and to the right, into the land of “green” processes: the right things, done right.  More often than not, we wind up just moving to the right, or just moving up.  That’s certainly a better spot, but only as a resting point, not as a final destination.

Doing the wrong things right is often known as “paving cowpaths.”  Some awful business processes are so entrenched that they cannot be rooted out.  Discretion being the better part of valor, we choose to automate bad processes, throwing good technology at a bad system.  Life does get better, but you’re still left with a bad process.

Doing the right things wrong is a little better.  By eliminating the bad process, you’re much better positioned to ultimately do the right thing the right way.  If you wind up stalled on the way to the upper right, I’d rather be in the “right things wrong” world instead of the “wrong things right” world.

It’s easy to understand why.  Technology is easy; people are hard.  The worst part of our jobs is the social engineering: getting people to change their ways, adopt new practices, and learn new tools.  Actually installing a new system can be a pain, but it can be done.  People, with their delightful quirky personalities, pose real challenges to change and growth.  If you move a process to the right, you’re still stuck with the difficult people problem.  If you move a process up, you’ve solved the people problem and are left with the simpler technology concerns.

It is often said that managers get things done right, while leaders get the right things done.  On our chart, good managers push things to the right.  Good leaders push things up.  Are you a manager or a leader?  Which way are you pushing?

At the highest levels, CIOs must deal with the business as a strategic partner.  This means living in the world of finance, operations, and process.  In any general conversation between a CIO and a business peer, specific technology terms should be few and far between.  In the end, the business does not care about our geeky little world.  They only care about what we deliver and how it helps them.

But the advice to “talk their talk” extends across all levels of our organizations.  I was reminded of this recently when a published project status confused our business partners.  We were closing out a project that updated several thousand PCs on our network.  We had completed the updates but ran a special audit job to make sure nothing was missed.  The update was complete but the audit was only half-done.  The project status noted that 700 or so PCs remained to be processed in this last phase of the project.

The business perceived this to mean that all these machines were not even updated and got concerned about the project.  It took a day of poking around to figure out the real answer and reassure the business.  Had we expressed the status in language that made sense to the business, the distinction between the update and the audit would have been clear and the confusion avoided.

Those of us in IT often use the language of technology to either impress or confuse our customers.  This never helps in the long run, although it lets you get away with a lot in the short term.  In the end, another old adage holds true in our world: People don’t care what you know.  They want to know that you care. And that starts by speaking to people in a language that they understand.

It’s when times get tough that real leadership shows itself.  For lesser CIOs, the easy way out is to simply buckle down, cut back on everything, and ride out the storm.  You manage to a reduced budget, defer all your projects, and hope to regain ground when the business climate improves.  When the business complains, you can shrug and point to the economy, promising solutions when the managing gets easy again.

Alas, the easy way out is the wrong way.  When times get tough, a good CIO focuses on how to keep moving ahead in spite of limited resources.  In good times or bad, new challenges will constantly confront your company.  You must respond to them, deliver solutions, and find ways to help your company succeed.

Instead of pulling back on everything, review each and every project in your portfolio.  There will be a small group of projects that are mandatory, without which your company will fail or suffer dramatic setbacks.  You must fight for these projects and ensure you have the resources to deliver them.  In most cases, it is easy to make your case: corporate failure usually gets the attention of senior management.  Some level of funding or support should follow; you’ll need to make do with what you are allotted.

Beyond the mandatory parts of your portfolio, there is a second set of projects that are not mandatory but that will deliver significant immediate value.  These are the projects that you must embrace and fight for.  Often, they fall by the wayside as budgets are reduced, lost in the clutter of projects that really can be delayed or canceled.  In fact, these high-value initiatives are the ones that will help your company succeed in difficult times.

A good CIO will find a way to sell these projects on their merits, justify the investment, and deliver on the results.  Especially in tough times, those new tools and processes that reduce headcount, improve efficiency, and drive value to the bottom line are critical to your, and your company’s, success.

Proactive portfolio management is the key to delivering this kind of value.  Even when times get better, be aware of those projects that are the real winners.  You’ll be able to respond to business needs faster and react to changing conditions more effectively.  And that makes you and your organization more valuable in good times and bad.

A lot of software is written in the same way.  There is a common belief that you can completely control the development of software, planning each step of the process, deciding when the builds will be ready and the final product will roll off the line.  We all work to such tight project deadlines that there is little choice but to manage the development process this way.

Unfortunately, writing software is not a process.  Writing software is an art.  Just like singing, dancing, painting, or sculpting, certain people are born to write beautiful pieces of code that other, lesser mortals simply cannot produce.  For those who can dig in and appreciate a piece of code, there is true beauty inside the very best software.

Like any other art, beautiful software does not happen in predictable, scheduled ways.  It happens in fits and starts, when the muse strikes.  I can remember many times when the solution to some problem, the perfect algorithm or data structure, would suddenly pop into my head in the middle of the night.  You can beat your head against a problem all day, but the elegant solution only arrives when it is ready to be revealed.  Regrettably, it’s tough to put milestones like “Muse Strikes” into your project plans.

Now that I am on the management side of this process, I have true sympathy for the developers that struggle to deliver results when they know that the muse has not yet struck.  Lesser programmers are content to produce a Velvet Elvis, a pedestrian piece of code that gets the job done in a brute force way.  Programming artists seek to deliver art, something they and their peers will consider and appreciate.

As managers, we have to decide when we need art and when we need Elvis.  All great artists can produce a Velvet Elvis with little effort, but their spirit will be sapped if they are not allowed to create true art every so often.  Keep that in mind as you plan your projects and determine your schedules.  Know who your true artists are, and make sure they get to produce that occasional masterpiece.  And when you do, they will certainly come to you and say, “Thank you.  Thank you very much!”

Time, Quality, or Money: Choose Two

I am always surprised when I meet IT folks who don’t know this old canard.  Simply put, in any project something will be sacrificed.  If you want a high-quality result on time, you’ll spend a lot of money to get it.  Want to hit your budget and deliver high quality?  You’ll take longer with fewer people to get things finished. And if you want to hit your date and hit your budget, you’ll never meet your quality goal.

Apparently, this is the choice that Apple made for MobileMe, the new shared email service launched along with the iPhone 3G earlier this month.  After making the bad decision to release four big things all at once, Apple seems to have stuck with that decision without regard to the quality of the MobileMe product.  The fallout has been terrible and Apple has lost face with a huge swath of its customer base.  The problems still aren’t fixed, and users are still (rightfully) upset, as witnessed by the FailMe parody web site.

The key to successful project management is to realize that this rule is inviolate.  When a project goes awry (and they all do, to some extent), you will be choosing two of these three goals.  How to decide?

If possible, choose Time. Money may be limited, and quality is crucial, so delaying a project and slipping a date is your least distasteful choice.  If you are managing a project whose date cannot slip (end of year reporting or tax filing, for example), recognize that constraint right away and budget lots of money to ensure that you will wind up with good quality.  A good product delivered late is still a good product; a bad product delivered on time will never be forgotten.  Apple will be hearing about MobileMe for a long time; slipping it would have been no big deal.

If you can’t choose Time, choose Money. Money buys labor in the form of developers, testers, tools, and anything else you might need to hit that date.  The goal is to ensure that you avoid having to choose quality.  Be careful, though: money only goes so far.  At some point, you cannot buy your way to hit a date.  (There is a closely correlated rule for this: Nine Women Cannot Have A Baby In One Month).

Never choose Quality. If you really have to choose Quality, argue strenuously to cancel, defer, or redefine the project.  Like eating bad food, memories of bad quality linger for a long, long time.  Slipped dates are soon forgotten as people move on to other things, and even blown budgets fade after time.  Bad quality never diminishes and can come back to haunt you over and over again.

In short, make rational decisions on Money and Time, but never give in on Quality.  If you cave in on Quality, you’ll soon find yourself living through Musciano’s Extension to this rule:

Time, Quality, Money, or Your Job: Choose Three

In these cases, you usually aren’t the one making the final choice.

Turn One Knob At A Time

Divide and conquer.  Divide and conquer.  Divide and conquer.  This mantra, more than any other, must be burned into the brain of anyone hoping to make a career of IT.  Break big jobs into small jobs, deliver on the small jobs, and the big jobs will solve themselves.  Very few projects cannot be divided into sequences of interdependent smaller projects that, in turn, are easier to understand and complete.

Although Apple committed many errors in the iPhone deployment, they can all be traced to breaking this fundamental rule.  In one day, Apple launched the new iPhone 3G, a new matching version of iTunes with the new Apps store, a corresponding firmware update for the iPod Touch, and a replacement for the .Mac service called MobileMe.  Any one of these launches is a big event, bringing significant value to new and existing customers.  Each is fraught with peril if things don’t go well.  Tackling one or two would be a big deal; tackling all four was a mistake.  Apple’s hubris, I suspect, made them think they could pull this off.  They were wrong.

From the comfort of my Monday Morning Quarterback Chair, here’s how I would have scheduled this rollout:

• Launch with the iPhone 3G, along with the new version of iTunes, but without the App store going live.  Instead, put a teaser link in iTunes to get people salivating over all the wonderful new apps that are just a few days away.  People will be so excited over the new iPhone that they won’t care that the apps aren’t yet available.  Apple servers cannot keep up with all that phone provisioning anyway; why burden them with additional traffic as people look for new apps for their phone?

• Allow the phone rollout to stabilize over a period of two weeks.  Apologize for the provisioning problems with some comment that emphasizes how hard it is to predict demand with such an insanely popular phone.  Let the press write glowing reviews on the virtues of 3G speed and the business connectivity in the phone.

• After two weeks, announce the fabulous new App Store.  People that have just gotten a bit bored with their fast 3G access on their phone will now go crazy all over again, downloading and trying out apps.  This is the lowest-risk step of the bunch, since most of the app problems are related back to the authors, not Apple.

• If the iPhone is stable at this point, release the firmware upgrade for the iPod Touch.  If not, wait for the bugs to get fixed and slip the release for a future date.  If things are going smoothly, you’ll be quieting the revolt among Touch owners who desperately want those new apps and features.  If the firmware is buggy, you’ve saved yourself calls from another class of irate users.

• Finally, hold off on MobileMe for however long it takes to fix it.  This product, among all these releases, is clearly not ready for primetime and is a real black eye for Apple.

In the end, you must understand and slightly exceed your users’ expectations.  No one in the user community was demanding a new phone, and new firmware, and new apps, and new iTunes, and MobileMe all on the same day.  Why try?  Any experienced IT professional could tell you this plan was bound to fail. In every rollout, something goes wrong.  And when one thing falls over, it’s bound to tip over lots of other dominoes behind it, resulting in an avalanche of problems.  If you set up fewer dominoes to begin with, you increase your odds of success.  If you have to turn a bunch of knobs on something, turn just one knob at a time!