Thursday, April 12, 2012

No Easy Answers

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 have asked 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 expression and tone of voice that he was really hoping I knew of a 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 BA she works with sometimes proceeds with his part of the work without respecting the needs and limitations that her part of the work imposes on his. She wanted to know how to fix this problem. My suggestion was to build a more collaborative relationship with the other BA, 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 BA. 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 thought I could provide her with a secret code phrase she could use to get this other analyst to cooperate with her. Or perhaps she expected me to suggest some telepathic mechanism to help them to communicate. The best I could do was to propose 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 lovely way to get all people to be reasonable and to work and play well with their team members, but I don’t. If you’re aware of any such shortcuts, please let me know.

This desire for painless solutions also shows up when planning a project. Project managers or team members often are asked to estimate 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 offer an answer that your senior manager or customer doesn’t like. Perhaps it requires more resources than management has available, or it will take longer than customers desire. 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 or reduce how long it will take to do the work. It just moves you deeper into a fantasy world.

I saw a striking example of this phenomenon once with a project manager I’ll call Rick. A senior manager asked Rick in a public company meeting how long it would take to complete a particular project. Rick replied, “Two years.” This manager said, “That’s too long; I need it in six months.” So how did Rick respond? He simply said, “Okay.” In other words, he just pretended that it was feasible to execute this project in six months, even though absolutely nothing had changed to call his original estimate into question. No additional people were assigned to the project; the required work did not shrink by a factor of four; the productivity of Rick’s team did not instantly quadruple. Nor were Rick’s estimating method and assumptions examined for possible errors. Rick simply said what he knew his manager wanted to hear. Not surprisingly, the project took more than two years to complete. Even thoughtful estimates often are optimistic and don’t account for risks, unexpected events, and the inevitable scope growth 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’s fruitless to seek magic solutions for difficult problems when there aren’t any. Sometimes I’m not that crazy about reality, but it’s all I have, so I have to deal with it. So do my clients, whether they like it or not. 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’s a special kind of magic in itself.

(If you found this article helpful, please consider making a donation to the Norm Kerth Benefit Fund to help a consultant who has been disabled since 1999 with a traumatic brain injury from a car accident. You can read Norm's story or donate here. Thanks!)

No comments:

Post a Comment