Thursday, April 26, 2012

So You Want to Publish Your Book (part 1/4)

Writing a book is one thing; making it available to the world is an entirely separate proposition. The world of book publishing has changed in recent years, as self-publishing and electronic books have skewed the economic value proposition for traditional publishers. While the new book author has other alternatives available, there are still numerous traditional publishers who look for good, marketable manuscripts. Once you've established a reputation as someone who can write books that sell, publishers are always happy to hear from you. Getting your foot in the door can be challenging, though. For this reason—and others—I'm eternally grateful to Wendy Eakin of Dorset House Publishing, who took a chance on a first-time author in 1995 and helped him craft a rather nice book, if I do say so myself.

In these four articles I will describe what I've learned about writing and publishing books. No doubt other authors have had different experiences. If you are such an author, please share your own experiences and suggestions through comments, or contact me about writing a guest post for this blog. I don't claim that this is the only way—or even the best way—to go about creating a book. It's just the approach I have taken for publishing six software development and management books, as well as a non-technical memoir of life lessons.

My friend Scott Meyers created an extensive web page that’s an excellent resource for the aspiring book author. Scott is a talented and prolific writer who is renowned for his expertise in the C++ programming language. He combined his own publishing experience with input from numerous other book authors into this page. If you're thinking of writing a technical book, read what Scott has to say carefully.

Even if you’re able to get a book written and published, you shouldn’t expect miracles. Don’t quit your job and buy that beach house, expecting book royalties to keep you in margaritas for the rest of your life. I don’t have any firm figures from the software industry, but here are my own heuristics. If your software book sells 5,000 copies, you should be pleased that you created something your colleagues find useful. If you sell 25,000 copies, you should be delighted. If you reach 100,000 copies with any book, you should be ecstatic. And if you sell more than that, you’re in a small but elite crowd of highly-respected authors. If any of you authors out there have different guidelines for judging “How’s my book doing?” please share your thoughts.

Targeting a Niche


I knew a consultant who envisioned publishing a comprehensive series of several books on a particular subdomain of software engineering. He had already drafted numerous volumes in the series, which he distributed during his training seminars. However, it's not easy to find a publisher who’s interested in releasing such an extensive series of books by one author in any specific niche. So far as I know, this consultant never did get any of these books published. It's rather a shame, because he had a lot of great material. I think he would have been better off to distill his vast quantity of material down into one or two focused, practical, and distinctive books in that area.

My writing approach has been to identify some area of software engineering that I felt was lacking an appropriate book and try to plug that gap. At the time I wrote the first edition of Software Requirements in 1999, just a few practical books on requirements engineering were available. None covered the breadth of requirements topics that I thought was essential, so I took a stab at it. A few years later, I realized that I had quite a bit of additional material, much of it developed in response to questions that people had asked me about requirements. That extra material eventually led to the second edition (what publishers call a “2E”) of Software Requirements in 2003. This edition was 60,000 words longer than the first; I guess I did have more to say on the topic.

As another example of plugging a hole in the literature, I've always been a strong proponent of software peer reviews and inspections. My own software work has been greatly improved by getting a little help from my friends through peer reviews. A decade ago there were several books in that niche already, but they were all hefty—350 to 450 pages—and they focused on the inspection technique, giving short shrift to other possible approaches for performing reviews. The topic just didn’t seem so complicated as to demand such long books. So, in 2001 I wrote Peer Reviews in Software: A Practical Guide. It was just 230 pages long, covered several review techniques besides inspection, and added some important content on review metrics and how to instill a review program into a software organization. I targeted this book at practitioners who were serious about software quality but might be daunted by a massive tome on inspection.

So, I suggest you aim your book at a niche that isn't already well covered in the existing literature for your domain. You can drill down into a specialized area, synthesize related topics into a comprehensive overview, improve on the existing books in a particular field, or invent something entirely new. A prospective publisher will assess how your proposal fits into a competitive marketplace. Something that's going head-to-head against numerous other similar titles (particularly from the same publisher) could be a tougher prospect than a book that stands alone. Publishers don't simply print interesting or well-written books; they need to publish books that sell or they go out of business.

The Elevator Pitch


You step into an elevator in a big hotel and press a button for the twenty-fourth floor. During the ride, you chat idly with the elevator's other occupant, who is heading for the nineteenth floor. Casually, you just happen to mention that you're writing a book. "Cool," says your fellow passenger. "What's it about?" You have perhaps thirty seconds to tell this prospective customer just enough about your book that he says as he exits, "That sounds interesting. I'll look for it when it comes out. Good luck."

This condensed summary of your book is called the elevator pitch or elevator story. The first time someone asked what my book was about, I confess that it rather stumped me. How do I distill the essence of a 400-page book into thirty seconds? This puzzlement was beneficial, though. It forced me to sit down and think carefully through just what my book was about and how I could explain that to even a normal (i.e., non-software) person concisely. That's a valuable exercise that I’ve applied to all of my subsequent books. With practice, your elevator pitch will roll right off your tongue whenever you encounter a possible reader.

I highly recommend that you devise your elevator pitch early in the writing process. It will help you keep your overriding objective and book themes in the front of your mind as you develop the contents. And if you have an initial phone conversation or e-mail exchange with a prospective publisher or agent, the elevator pitch is your first shot at piquing his interest. In the next article in this series I will address choosing a publisher and developing a compelling book proposal. Part 3 will address the contract and tracking your progress to meet your publishing deadlines. The final article describes my experience with self-publishing a book.

I've collected all of the blog posts about writing -- getting ideas, choosing a style, editing, proofreading, publishing, etc. -- into an eBook now available for just $5.00 at http://www.processimpact.com/handbooks.shtml#writing.

(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!)

Thursday, April 19, 2012

5 Tips for the Traveling Trainer (contributed by Matthew Kabik)

Matthew Kabik has worked as a corporate trainer and copywriter for Computer Aid, Inc. since 2009. You can read more articles by Matthew at www.caiuniversity.com.

I’ve seen plenty of commercials by credit card companies, hotels, and the travel industry showing tired businessmen reaching their destinations after hours of driving or flying. They are worn out—disheveled even—and collapse into a bed without even kicking off their shoes.

Yeah—I can say that’s sometimes pretty accurate. After a six-hour drive from Pennsylvania to Rochester, New York, last year (through the snow and uphill both ways), I found myself very much in the mood to sleep until I needed to train the next day. Fortunately, I didn’t. And that brings me to the subject of this article.

Delivering training can bring along immense stress. That stress can fill your mind to the point where you forget about everything else, including how to make your journey a bit easier, your hotel stay a bit more pleasant, and your time away from home an adventure instead of a pain. Here I offer five tips to help keep the traveling trainer or consultant calm, collected, and well-rested.

Leave Home Early


This one is pretty self-explanatory. Leaving early gives you enough time to get a good night’s sleep at your destination and to deal with any unexpected delays. We all know that.

However, I’m talking about leaving a day early. This isn’t always practical, but if you can manage to arrive at your hotel a day early, you’ll have time to familiarize yourself with the area so you know where to eat, where to get gas, and where to buy any supplies you forgot. You’ll also be able to drive from your hotel to the training or consulting location as a dry run. This is a monumentally useful trick if you’ve never been to the place before. Not only does it help you figure out approximately how long it will take you to get there, but knowing where you’re going also calms your nerves the morning of your training or consulting event. At least it calms mine.

Even if you can’t arrive well before the event, try to avoid taking the last flight of the evening to your destination. Sure, that late flight will reduce your wasteful travel overhead time, but it also greatly increases the risk. Flight delays—and stranded passengers—accumulate during the day, especially during the winter. Any experienced business traveler knows the fun of being stranded overnight in an airport or reaching the hotel in the wee hours of the morning. The resulting combination of exhaustion and stress guarantees that you won’t be at peak performance with the client the next day. It’s also a good idea to have the cell and home phone numbers for your contact person at the client site in case you encounter unavoidable travel problems despite your precautions.

Check Your Materials


The very first time I taught a class at a client site, I forgot to bring pencils for everyone in the class. A small thing, to be sure, but it threw off my confidence and my timing, since we had to find fifteen pencils and pens, which took longer than anyone would think possible.

What I have learned since then, and what I recommend for anyone who is a travelling trainer or consultant, is to create a checklist to help you pack everything you need, and to run through it again the night before your engagement. If you find you’ve forgotten extra pens, a power cord, or batteries for the laser pointer, you’ll have plenty of time to run out and find replacements.

Be Nice to Everyone


When you’re at a client site, you’re a stranger in a strange land. That can be tiring for anyone. I have found that the people I interact with during my training trips (hotel staff, waiters, team leaders, and so on) are empathetic to your position and happy to help. Spending a little time saying “thank you” and “please” gets you far anywhere, but it really helps when you’re on the road.

By way of example, I made it a point to chat with the front-desk person while I was checking into a hotel in Allentown, Pennsylvania. Our conversation was nothing amazing; I just asked about good places to eat, talked about why I was there, and so forth. The next morning, the front desk called me at seven in the morning as a courtesy, without my asking, because of a note the night person I spoke to had left. It turns out that I hadn’t set my phone alarm correctly, and I surely would have slept well past the meeting’s starting time! That thoughtful hotel staffer really saved my day.

Being nice to the people who can make or break your training success is very important. A bit of kindness can mean the difference between a mutually rewarding experience and a frustrating failed attempt.

Arrive Early on the First Day and Test Everything


Students don’t want to watch you struggle with login credentials to get your laptop working, a laser pointer that doesn’t shine, or a silent microphone. It is, in fact, annoying to watch someone click every button on an LCD projector in an attempt to get it to work. You can avoid most technical problems experienced on-site by testing the equipment beforehand.

Bring your laptop and make sure you can get online if you need to. Test the projector with your laptop and learn how it works. Check where the electrical outlets are and where you’ll be able to stand or sit. You might need a power strip or extension cord to get all the equipment powered up. All of this can be accomplished by simply arriving early the first day. It may seem like a nuisance, but showing up early saves considerable time and stress.

Use Your Clients as Resources


The people with whom you’re working at an engagement are usually happy to help you out. They know you aren’t near “home base” and don’t have your own team members readily available. Being away from your home office (and your coworkers) can make you feel like you’re completely isolated. It’s helpful to remember that you have a whole room full of professionals who are as interested in the training running as smoothly as you are. Make it a point to ask them how they believe the training is going during breaks to adjust your speed or message. Make them part of the training or consulting instead of just talking at them. Create an environment that is cooperative and collaborative.

The best training I’ve ever delivered involved the group having breakout discussions about how they’d use what I was saying to help them in their daily work, applying it to their own language and processes. It takes some of the burden off you, and, more importantly, customizes the training for the group. Busy people are interested in practical guidance they can begin to apply immediately, so structure the class to help them get the maximum benefits when they return to the office.

By applying these tips to your own work, I think you’ll find that travelling to conduct training or provide consulting can be a pleasant break from your regular nine-to-five routine instead of a stressful, demanding event. You’ll be better rested and better prepared, and you’re sure to create a better experience for yourself and your clients.

(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!)

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!)

Thursday, April 5, 2012

How to Get Repeat Business from Your Clients (contributed by Adriana Beal)

Adriana Beal (www.adrianabeal.com) spent 5 years as the principal consultant at a small IT consulting firm in Brazil, followed by 5 years as a consultant with a NY-based human capital boutique serving Fortune 500 companies. She now works for a large technology company as an internal IT Business Consultant. Adriana has two technical books published in Brazil, and work internationally published by IEEE and IGI Global.

Any consultant, working independently or as part of a consultancy firm, knows that getting repeat business from existing clients is at least as important as finding new clients. When I started providing consulting services to a variety of clients in different industries, I realized that I could classify my clients into two groups:
  • Organizations that needed my help for a specific reason that is unlikely to repeat for a long time (for example, a pension fund that no longer needed my services after implementing my recommendations from a fraud risk assessment).
  • Organizations that could benefit from my services from time to time, if they liked the results of the work performed (the majority of my clients).
Obviously, nothing changed in the effort I put into a consulting assignment because of this classification. I provided the same level of dedication to clients that were unlikely to need my services again as to firms that I knew could offer me repeat business. However, based on this classification, I was able to adopt metrics to monitor my performance as a consultant. I estimated that two years was enough time for another complex software project—the type of work I specialize in—to surface in a typical organization. Therefore, one indicator of my performance was the percentage of companies from the second group that offered me repeat business within a two-year period.

Recently, I realized that of more than ten consulting clients I have had since moving to the United States in 2004, only one had not yet asked me for repeat business. Even this exception didn’t reflect dissatisfaction with my services: a couple of executives kept in touch with me after the work ended, and one of them hired me to consult for his new employer when he changed jobs., Therefore, I thought I’d be a good candidate to answer a question Karl Wiegers posed: if you get repeat business over the years from the same clients, why do they keep calling you?

Combining my own observations with testimonials from former clients, here are the top three reasons why I believe the same companies kept calling me back during the past decade. I suspect these practices would also help you retain your clients.

1. Applying systems thinking skills


Systems thinking is a way of understanding reality that emphasizes the relationships among a system's parts, rather than the parts themselves. This is one of the most valuable skills for a consultant. Systems thinking doesn’t apply just to information systems, but rather to any system (people, organizations, etc.) whose components are interconnected in such a way that they produce their own pattern of behavior over time.

It’s difficult to provide an example of how systems thinking can improve project results without talking extensively about the characteristics of a particular system, so to illustrate my point, I’ll use a simple case. One of my e-commerce projects received a change request to add a screening process during checkout to prevent certain products from being sold in regions where their sale is restricted by law. The business stakeholders approved the requirements, and the development team was ready to start coding the solution. However, I realized that what seemed to be a simple change affecting only one step during the checkout process also affected other business areas, including the call center operation. Without other changes, such as a new feature in the call center application to allow agents to filter out restricted items when recommending products to a customer, the sales process would suffer. Call center representatives would run the risk of wasting time convincing a customer to buy a product, only to learn at checkout time that the product could not be ordered from that location. This would increase the risks of customer frustration, lead to a higher abandon rate, and increase the handle time of inbound calls.

Systems thinkers aim to enhance total system properties, rather than trying to optimize certain parts of the system. A good resource is Thinking in Systems by the late scientist Donella Meadows. Meadows explains such phenomena as why everyone in a system can act dutifully and rationally and yet have those well-meaning actions add up to a terrible result, and why a system might suddenly and without warning jump into a completely unexpected type of behavior.

By using systems thinking, you will be able to forge more creative and satisfactory solutions for your clients, ensuring that separate groups keep the whole in mind while working on their individual parts. When a new challenge arises, the client will remember the benefit of bringing in an external consultant who is mindful of such causal relationships.

2. Being truthful and straightforward


I’ve always been very candid with my clients, telling them when I thought an idea didn’t sound feasible or a solution didn’t seem effective. Often, a team member would disagree with my approach, but throughout the years I kept my belief that speaking up early and honestly about problems improves your results and increases client satisfaction.

Here’s an example, based on a common business problem. In one of my client companies, the IT group had not met a software release date in years and budgets were out of control. As part of the process improvement initiative I was leading, the head of development wanted his project teams to stop lying and hiding problems that threatened the completion date, something they did mostly to look good in meetings. This manager’s proposed approach was to confront his subordinates and demand a change in behavior.

The problem, however, was that “lying to look good” was a practice that permeated even the top management layer. The only way to solve the problem was to acknowledge the role executives and managers played in it. It wasn’t easy to discuss this sensitive issue with my client, but being honest about the need for change to come from the top allowed us to modify the signals the development teams received from senior management. Before this problem was addressed, team members would hide issues they were experiencing, opting instead to wait until another person reported a delay. Their hope was to get the extra time they needed without having to be identified as the "source" of the project slippage. With the change in behavior starting from the top, the teams became more comfortable speaking up and dealing with any problem threatening project success as soon as possible. Such change caused a significant decrease in delivery delays, defects, and runaway costs.

During project retrospectives, a positive feedback I frequently received from clients who later went on to hire me again was related to my ability to speak up early and honestly about project issues. This "culture of candor" was seen by these clients as essential to having an early-warning system put in place to eliminate or minimize project risks in a timely manner.

3. Putting your client’s interests above yours


As a consultant, sometimes I saw that I was not the right person to take on an assignment or that the project I was being hired to assist did not have a solid business case. Even though taking the assignment would be financially desirable for me in the short term, my client always appreciated me confronting such problems directly with them. In several cases, the client and I were able to rethink the project’s mission and purpose, if necessary canceling either the initiative or my involvement in it. Whenever this type of situation arose over the last ten years, it led to repeat business with that client or referrals to other companies that could use my services.

By being candid with your clients, even when the truth is not in your best short-term interest, you help paint the picture of the real problems and you reassure the clients that you will stay with your mission and purpose and not compromise your principles. Most clients will appreciate your transparency, opening an opportunity for you to build solid relationships with those with whom you’re doing business.
---

Getting repeat business from your clients, as well as referrals from them, is one of the most effective ways of growing a consulting business. My approach is not the only successful strategy to achieve this goal, but the practices described here have helped me develop lasting and profitable relationships with my consulting clients. However, as with everything else in life, there is no one-size-fits-all solution, and each consultant needs to find a system that works well for her.

(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!)