Knowing When To Stop October 30, 2009
Posted by Chuck Musciano in Leadership.Tags: Leadership, Management Skills, Project Management, Software, Teams, Users
6 comments
A recent issue of Wired had a great article on the concept of good enough: when products meet enough needs that consumers are happy. The author gave several examples of good enough: MP3s instead of CDs, Flip cameras instead of high-end video cameras, and even Predator drones instead of manned fighter jets. In each case, the product is woefully short of perfection, but is still so useful that the perfect alternative is being sidelined in the market space. (As an aside, you may not need to read the entire Wired article; for many of you, my summary will be good enough).
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!
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio124″ only_single=false]
Management By Colorforms August 31, 2009
Posted by Chuck Musciano in Leadership.Tags: Project Management, Teams, Tools
6 comments
As big a fan as I am of technology and tools, sometimes the simplest things really are the best.
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?
[tweetmeme source=”EffectiveCIO” alias=”http://bit.ly/cio098″ only_single=false]
Good And Evil May 15, 2009
Posted by Chuck Musciano in Book Reviews.Tags: History, Leadership, Project Management
1 comment so far
The stakes were high for the 1892 World’s Fair. Dubbed the Colombian Exposition, the fair was intended to celebrate the 400th anniversary of Columbus’ discovery of the new world. Coming on the heels of the spectacular World Exposition in Paris in 1889, symbolized by the new Eiffel Tower, chances were not good that the Colombian Exposition could never, ever top what the French had pulled off.
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.
Get It In Writing April 13, 2009
Posted by Chuck Musciano in Random Musings.Tags: Management Skills, Project Management, Technology, Users
1 comment so far
When I worked in R&D, we shared our building with another group whose job was to improve engineering productivity. They took their job quite seriously and had a mandate to investigate any aspect of the engineering groups that appeared to be in need of improved productivity. They weren’t engineers, but they did claim to understand process and project management, and they often used a new acronym, TQM, as a sign that they were on the cutting edge of this kind of stuff.
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.
Right Or Wrong? Well or Poorly? March 2, 2009
Posted by Chuck Musciano in Leadership.Tags: Best Of 2009, Governance, Leadership, Management Skills, Project Management
5 comments
In a previous life, my boss had this chart hanging on his wall:
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?