Tuesday, November 29, 2011

Professional Pearl: Most difficult situations do not have simple, magic answers, no matter how much someone might want one.

I’ve spent much of the past fifteen years helping organizations improve the way they develop and manage the requirements for software projects. Most people realize that this is a challenging job without many shortcuts. Yet sometimes people ask me questions in a way that suggests they hope I will give them a magic, easy solution to a difficult problem.

For instance, someone once asked me during a training seminar, “What should you do if your requirements specifications come in Japanese?” This organization was collaborating with a Japanese company, who was supplying them with the initial requirements written in their native language. I could think of only three possible ways to deal with this situation: learn to read Japanese; have someone translate the specifications they receive from Japanese into English; or persuade the Japanese originators to write them in English in the first place. This seems obvious. But I could tell from the inquirer’s body language and expression that he was really hoping I would know of a magic and painless solution to this problem. I’m pretty sure he already knew that I didn’t have such a magic solution. Nevertheless, he asked. I hope he wasn’t too disappointed to learn that there was no easy way to deal with this situation.

I would like nothing better than to offer amazingly effective and cheap solutions to such challenging situations. Just think how much I could charge as a consultant if I knew such secrets! Alas, there are no such secrets. There are no magic wands, silver bullets, talking mirrors, genies in lamps, or all-knowing wizards. Sorry.

In another case, a business analyst told me that another analyst she works with sometimes proceeds with his part of the work without regard to the needs and limitations that her part of the work imposes. She wanted to know how to fix this problem. My suggestion was to build a more collaborative relationship with the other analyst, so they could work together on such problems and come up with more appropriate and feasible solutions. However, she was reluctant to talk to the other analyst. She didn’t seem to think was going to be feasible in her environment, so she dismissed my recommendation out of hand.

I wonder if she wanted me to provide her with a secret code phrase that she could use to get this other analyst to cooperate, or perhaps suggest some telepathic mechanism to help them to communicate. The best I could do was to suggest that she sit down with the other players on this kind of project and have them all say to their peers, “Here’s what I need from you for us jointly to be successful.” That’s a more collaborative approach. It’s not magic, it might be uncomfortable, and it might not succeed if the other participants refuse to work together. I wish I knew of some magical way to get all people to be reasonable and to work and play well with their team members, but I’m not aware of any such shortcuts.

This desire for wonderful solutions also shows up when planning a project. Project managers or team members often are asked to provide estimates for how much time or money it will take to accomplish a proposed (but often ill-defined) body of work. If you’re asked for such an estimate, you might come up with an answer that your senior manager or your customer doesn’t like. Perhaps it requires more resources than they have available, or it will take longer than desired. These disappointed people can exert considerable pressure on you to change your estimate, even if there’s no good reason to make such a change. Simply reducing the estimate doesn’t make the project smaller, shorter, or cheaper. It just moves you deeper into a fantasy world.

I saw a striking example of this phenomenon once. I knew a project manager I will call Rachelle. A senior manager asked Rachelle duringa meeting how long it would take to complete a particular project. Rachelle replied, “Two years.” This manager said, “That’s too long; I need it in six months.” So how did Rachelle respond? She said, “Okay.” In other words, she simply pretended that it was feasible to execute this project in six months, even though absolutely nothing had changed to call her original estimate into question. No additional people were assigned to the project; the extent of the required work did not shrink by a factor of four; Rachelle’s estimating method and assumptions were not examined for flaws; Rachelle’s productivity did not instantly quadruple. Rachelle simply said what she knew her manager wanted to hear. Not surprisingly, the project actually took longer than two years. Even thoughtful estimates often are optimistic and don’t account for risks, unexpected eventualities, and the inevitable growth in scope that takes place on software projects.

It does no one any favors to pretend that the world is different from how it really is. It is fruitless to seek magic solutions for difficult problems when there aren’t any. I’m not that crazy about reality, but it’s all I have, so I have to deal with it. Sometimes that means we encounter technical barriers or interpersonal challenges that just cannot easily be overcome, no matter how badly we would like to cure them. Instead of looking for secret solutions, we have to rely on skilled technical practitioners, adroit project planners, and leaders who can steer groups of people toward effective communication and collaboration. That takes talent and perseverance, but it ain’t magic.

Wednesday, November 9, 2011

Personal Pearl: If you tell other people how they ought to behave, follow your own advice.

Walk the talk. Practice what you preach. These phrases speak to the importance of having congruence between the advice people give to others about how to behave and the behaviors they exhibit themselves. If you’re in a leadership position, it’s important to set an example through your own actions. You want to avoid the embarrassment of having to tell someone, “Do as I say, not as I do” if he sees you acting differently from how you tell others to act. Like the time when I saw my high school band director smoking at a marching band performance after he told us students not to smoke or drink while in uniform. To be fair, he wasn’t wearing a band uniform, but still.

I learned the importance of this lesson when I was a Visiting Assistant Professor of organic chemistry at the University of Illinois. Fresh out of graduate school and just twenty-three years old, I taught the introductory organic chemistry laboratory course to hundreds of premed students and others who were not majoring in chemistry. My students attended one hour of lecture per week, which I presented, as well as a four-hour laboratory session, which was supervised by a graduate teaching assistant. It was an ironclad rule that all students must wear safety goggles at all times in the laboratory. Students hated the goggles because they fogged up on humid days (that is, every day in Illinois), and the elastic straps were uncomfortable.

My custom was to pop into each laboratory session and walk around for a few minutes to see how things were going. A student once asked me why I was not wearing safety goggles as they had to. It was an excellent question. I always wore my regular eyeglasses, but of course that’s not the same as wearing safety goggles. Slightly embarrassed, I made sure to put on goggles every time I set foot in the lab thereafter. It was important for me to model the proper behavior and set an example for my students to follow. I’m glad that one student called me on my laxness.

You see disconnects between stated and observed behaviors or values all the time. Consider medical professionals who advise you not to smoke but then take their own cigarette breaks. The news periodically reports on a public figure, such as a minister or a politician, who definitely is not following his own advice. A well-known televangelist rails against homosexuality, only to be caught in the company of a gay prostitute. Ministers preach against the evils of extramarital sex even as they conduct affairs themselves. Moralizing politicians who advocate virtue and “family values” are revealed to have gambling addictions or other vices. Famous people are still people, subject to all of the weaknesses and temptations everyone else confronts. That’s no surprise, and it doesn’t bother me. What bothers me is the hypocrisy of people who castigate others for activities that they themselves are practicing.

You see the same kind of thing in the professional world. As an example, one large software company developed a framework—a set of processes, principles, and practices—for developing software applications. They recommended this framework to their customers and sold consulting services for it. As I understand it, though, they did not follow the framework themselves. You’d think that if it was such a great system, the developers would use it themselves. There’s even a term for this in the software world: it’s called “eating your own dog food” or dogfooding.

I’ve encountered this issue in my own work in the field of defining requirements for software products. Numerous companies have created commercial products called requirements management tools that project teams can use to store and manage the requirements for their product. Whenever I talk to a vendor of such a product, I always ask if their teams store their own requirements in that product. If the answer is no, I don’t get very excited about that tool. Why is it good enough to sell to other companies, but not good enough for the developers of the tool itself to use? Eating your own dog food certainly shows a commitment to your product, process, or principles.

If you ever find yourself showing a disconnect between behaviors you advocate for others and those you demonstrate yourself, take a look in the mirror. Either start practicing what you’re preaching, or change your sermon.

Wednesday, November 2, 2011

Cautionary Pearl: Be sure you don’t take away an invalid life lesson from an experience.

When I began riding a motorcycle many years ago, I shared an office with a man who had grown up on the island of Cyprus. Mike told me about the time he rode a small motorcycle when he was a teenager. At one point he had to hit the brakes hard, and he pitched over the handlebars and landed on his face. As he was not wearing a helmet, Mike got a little banged up. Fortunately, he did not suffer any serious injuries. I asked Mike what lesson he took away from this accident, thinking he might have learned that it’s always a good idea to wear a helmet when on two wheels. To my surprise, he responded, “Don’t use the front brake!” He interpreted the cause of the accident as being excessive braking on the front wheel, which caused the nose of the motorcycle to pitch downward and toss him overboard.

This isn’t the right lesson to take away from that experience. In reality, the front brake provides about twice as much braking capability as does the rear brake. If you decide to never use the front brake, you're going to greatly increase your stopping distance. This could be fatal in an emergency stop. The best bet is to apply both the front and rear brakes simultaneously.

The story illustrated for me the importance of taking away the correct life lesson from an eye-opening experience. If you draw the wrong conclusion you might learn a “negative” lesson, which could come back to bite you. As you ponder the insights you gain from your daily encounters and observations, make sure the lesson you draw are valid and will serve you well in the future.