Saturday, May 11, 2013

On Co-Authoring a Book (part 2/2)

In the first article of this series, I described how I came to be co-authoring the third edition of my book Software Requirements with Joy Beatty. I described how we set the requirements for the requirements book and established our collaboration process and tool environment. This concluding article in the series describes how we tracked progress on this complex writing project and my overall observations about the co-authoring experience.

Tracking Status

When writing a book, there is a vast amount of information to keep track of. At any given time one of our chapters can be in one of many possible states:
  • Not yet begun
  • Initial draft written
  • Initial draft being reviewed by the other author
  • Reviewed draft being revised by primary author
  • Out for peer review
  • Being revised following peer review
  • Being edited by our own internal editor
  • Submitted to publisher for copy editing
  • Being revised following copy editing
  • Final manuscript version submitted to publisher
  • Formatted PDF pages and artwork received from publisher
  • Formatted PDF pages and artwork being proofread and corrected
  • Final final final pages submitted to publisher
Our book contains a total of about 40 components—chapters, front matter, and back matter—plus more than 100 image files, and we are working on many of them simultaneously in these various states. Sometimes I feel as though I’m juggling 20 flaming chainsaws. We set up a spreadsheet to track the date each chapter transitioned from one of these statuses to another. Each of us had to maintain our own set of pending revisions to the shared tracking spreadsheet so we wouldn’t step on each other’s changes when we updated it periodically. We also had a tracking spreadsheet for review status. We recorded when each chapter went out for peer review, the target date for receiving review feedback, the actual date we received feedback from each reviewer, and a rating of how useful each reviewer’s input was.

Tracking status carefully like this was essential for us to make sure that we always knew what each of us should be working on. It helped ensure that could make our target dates for getting chapters where they needed to be at the right time. Speaking of which, we spent quite a bit of time scheduling those target dates for critical chapter milestones and rescheduling them as we saw how the work progressed. We had a lot of schedule flexibility until the publisher’s editorial team was put into place. At that point, they needed a firm schedule of when they could expect to see chapters, and they needed predictable turnaround on our review of copyedited chapters and final page proofs. When the editorial team was assembled, the project changed from being more or less open-ended to being timeboxed with firm constraints. I take pride in having never missed a deadline for any of the articles or books I’ve written, and I’m going to try hard to make sure I don’t break that record with this project.

The Result

Writing this book has been an interesting and fun experience, as well as a huge amount of work. Joy has been, well, a joy to work with. She closes important gaps in my own knowledge, and she brings a broad set of experiences and stories to share. Fortunately, our underlying philosophies and perspectives are very similar. Those minor disagreements that we have are easily worked out through the dozens of emails we exchange each day and the occasional phone discussion. It’s been great to have someone to bounce ideas off, to clarify my thinking, to help me choose between different possible approaches, and to straighten me out when I’m off in the weeds. Joy has also obtained some input from time to time from her colleagues at Seilevel, running small chunks of text past them to test their reaction. This quick, real-world input saved us from ourselves more than once.

You might think that working with a co-author who has responsibility for many of the chapters would save time. That has not been my experience. If anything, this book is taking more time than if I were doing it all myself. That’s mainly because each chapter goes through more iterations than if only one author was involved. However, there are some important advantages. First, I couldn’t do it all myself. Joy has expertise that allows her to write chapters and sections that I simply could not. She has taken some of the chapters that I had written years ago for the second edition and greatly enhanced and updated them.

In addition, working with a co-author has made the material I’m writing much better. On my previous books, I just did the best job I could on a draft chapter and sent it out to a dozen or so reviewers. This time, Joy and I are spending a lot of time going over each other’s work before the reviewers ever see it. We commit acts of unspeakable editorial brutality on each other’s writing (politely, of course), all for a good cause. We are each other’s toughest critic. As a consequence, our ultimate presentation of each topic is much clearer and more thorough than it would have been otherwise. It has also been great to have somebody to kick ideas around with, to help me determine the best way to approach a particular topic or whether to cover it at all. We’ve learned a lot from each other, and the quality of the work shows the benefit.

All that said, I’ll still be glad when it’s done!

(For your convenience, I have pulled together many of my blog articles about writing for publication into a small ebook titled "Writing Your Way to Success".)

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

Sunday, May 5, 2013

On Co-Authoring a Book (part 1/2)

I’m doing something right know that I’ve never done before: co-authoring a book. It’s a new experience for me but it’s going remarkably well. I’ve written several articles with co-authors over the years, which went fine, but nothing like the scale of the book. If you’ve ever thought about writing something with someone else, you might find the story of how we approached this to be interesting.

In August 2012 Joy Beatty, vice-president of research and development at Seilevel, asked me if I had thought about writing a third edition of my popular book Software Requirements. The first edition was published in 1999 and the second in 2003, both by Microsoft Press. I had indeed thought about writing a third edition from time to time. While virtually everything I described in the second edition is still valid and useful 10 years later, the book would benefit from an update in many respects. Some important changes have taken place in the software business and the world of business analysis in the intervening years. Frankly, though, the prospect of revising a 500-page book was daunting. I knew it would be a massive amount of work. I hadn’t been following the software requirements literature closely since I largely retired from consulting and training a few years ago. The hammock, my guitars, and my volunteer work were more appealing than spending hundreds of hours at a keyboard.

Nevertheless, Joy’s question got me to thinking. What if she and I were to co-author the third edition of the book? Joy is well respected in the business analysis field, very much up on current happenings in the domain, and the co-author herself of a nice book called Visual Models for Software Requirements that was published by Microsoft Press in 2012. So we began kicking this possibility around. Before long it became clear that there might be value in this collaboration. We agreed to give it a try.

Requirements for Requirements

Our first task was to create an outline. We began with the outline for the second edition (what the publishers call a 2E). We identified chapters that would benefit from major enhancements, chapters that just needed a tune-up and refresh, and new topics that we could add. We each went through a copy of the 2E and made notes about specific changes to make. I came up with more than 150 sticky notes with ideas, strategically placed at the relevant sections in the 2E. My email archives contained more than 60 email exchanges I had had with readers over the years (including several with Joy from 2004 and 2008!) addressing questions they had raised. Those were a useful source of other improvement ideas and stories to share.

Joy and I settled fairly quickly on the overall chapter structure and our preliminary first- and second-level headings. Then we enhanced this outline, each of us adding bullets under each chapter with our thoughts about possible changes to make. This annotated outline—which we call the AO—has been our primary working medium for exchanging thoughts and ideas. In essence, that outline and all the associated notes established the requirements for our book on requirements.

The high-level outline also was incorporated into the proposal that we submitted to Microsoft Press. Joy and I were very pleased when Microsoft accepted our proposal, as they’ve done a very nice job for us on our previous books.

Across the Miles

I live in Portland, Oregon. Joy lives in Austin, Texas. We have only met once in person, a couple of years ago at a conference, although we have had other professional interactions over the years. We needed to figure out the most efficient and reliable way to exchange materials throughout the duration of this many-month project.

Joy established a Microsoft SharePoint repository for us to use as a configuration management tool. We also set up an issues list to keep track of some of the myriad questions that arise. We created the following folders in the repository for managing our files:
  • The final chapter files from the 2E, which served as a great starting point for much of the new book.
  • The drafted chapters that we would be iterating on during creation, when making our own revisions, and during peer review.
  • An infrastructure folder to store various working documents: status tracking spreadsheet, chapter checklist, collaboration process, reviewer’s guide for our peer reviewers, and so forth.
  • A folder for the many figures and other images to appear in the book, organized by chapter.
  • A folder for the submitted chapters that went off to the publisher for copy editing and the revised versions the publisher sent back to us.
  • A folder for PDFs of the final chapters that we receive from the publisher for proofreading.
As each of us uploads modified versions of a chapter or other document to one of these folders, it gets added to the collection so we retain the history of previous versions. We use check-out and check-in procedures to make sure that only one of us at a time can make changes in a particular file. This basic configuration management discipline has worked very well to keep us from overwriting each other’s work or losing changes one of us has made.

Planning the Collaboration

I have long suspected that many teams of people who work together on a project don’t spend much time thinking about how they’re going to work together. They can do fine for a while, but when deadlines loom, there is too much going on, and the stress level ramps up, the lack of a process begins to show. So Joy and I spent quite a bit of time working through the process we would follow for collaboration on the different aspects of this book.

Each us took responsibility for being the primary author on certain chapters; we’ve adjusted that allocation as we went along to share the workload equitably. We crafted a detailed process to describe how we would hand materials off from one to the other, process feedback received from our reviewers, and handle the interactions with the publisher’s editorial team. We also agreed on some writing style and format issues. One goal was to give the book a consistent feel and style such that it would not be apparent to a reader which of us had written each chapter. This was perhaps easier on those chapters for which we began with the version published in the second edition of the book. But even on new chapters, the numerous passes we made back and forth smoothed out the final presentation. It was well worth the time we spent working out this collaboration process.

In part 2 of this article I'll describe how we carefully tracked the status of the many elements that make up the full book (it wasn't simple!) and summarize my observations about this collaboration experience.

(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, July 19, 2012

It’s a Matter of Policy (part 2/2)

In the first article in this series I described some of the business rules or policies I’ve adopted for my consulting and training company, Process Impact, over the years. That article presented several policies I have regarding traveling. In this concluding article I share some additional policies regarding finances and client relations. I’ve mentioned some of these in earlier posts so I won’t elaborate on them in detail here.

On Finances


One of the first things I learned about consulting was to Set my price so I’m happy whether the client says yes or no. I’ll ask a higher fee if I’m not that interested in doing the job (like teaching the same two-day class for the 182nd time—literally!) or if the travel required is excessive or inconvenient. I’ll ask less if the destination is someplace I want to go anyway, if the opportunity sounds like a novel consulting engagement, or if it's a class I don't get to teach very often. Most of the time that high price scares the client away, If not, then I’ll grin and bear it and cash the check. One consultant I know was invited to travel from the east coast of the United States to Japan to deliver a half-day presentation. Not wanting to spend that much time traveling for such a short gig, he requested an outrageous fee and first-class airfare. The client agreed; off he went.

I also Quote an all-up fee that includes my expenses. This way I don’t have to provide receipts (potentially subject to client frowning and debate) for travel and lodging expenses, books, printing handouts, and the like. This policy has greatly simplified my invoicing. It also permits me to Request payment at the time of the event with a new client because I can submit the invoice in advance. I adopted that practice after having countless invoices get lost in clients’ accounting systems. This reduces my aggravation level and saves me the time of chasing down late payments. I also do not let clients get away with their occasional attempts to give themselves a discount for payment within 10 days. My terms are net 30 days (45 days for some clients), with no discount for early payment.

Another consulting colleague insists that New overseas clients must pay half the fee in advance. This is a good idea in case you have any concerns at all about whether you’re going to get paid, in what currency, in what form, and when. A Canadian friend recently told me that he suffered a significant loss because of changing currency exchange rates thanks to an American client company that waited months to pay him.

I’ve had a few problems with overseas customers who ordered products from my website but never paid the invoice. This small percentage of rip-off artists forced me to adopt the policy that Customers outside the United States must pay for products in advance. When the money comes in, the product goes out.

Just this past week I had an experience that caused me to contemplate a new business policy. I recently delivered a webinar at the invitation of a small company that sells certain software development tools. My invoice wasn’t paid on time. That’s not terribly unusual, but when I followed up I learned that the company had just closed and gone into receivership. I am never going to get paid. So now I need to consider whether to ask small companies with potentially shaky finances to pay me in advance for any work I perform for them.

Early in my consulting career I was invited to speak at a meeting of a local professional society. The contact person asked me what my fee would be. Not having encountered this situation before I wasn’t sure what to request. After I thought about it, though, I concluded that I Do not charge a speaking fee to give a presentation at a local professional organization. Delivering such presentations is a way for me to contribute to my profession as well as being a marketing and networking opportunity. Conversely, I Do not provide services to a company for free. If I’m delivering value to a company’s employees through a presentation or consulting, I’m entitled to be compensated for that value.

On Client Relations


Professional and personal integrity being important to me, I will Never misrepresent the work I’m performing for a client. A prospective client once asked me to state in my consulting agreement that I would be providing certain services. In actuality, though, he wanted me to do something different. He asked me to lie because he didn’t think his management would approve funding for the service he really wanted me to perform. I said thanks but no thanks. I don’t want to work for a company under false pretenses.

A client who hires a consultant for the first time is taking a risk. What if the consultant doesn't have as much experience as he claims and doesn't provide good advice? What if he's not a good presenter and the students don't find the class interesting or useful? I once brought a well-known consultant and speaker in to a company where I worked to teach a one-day class. She was very entertaining but provided little useful content, stimulated no class discussion, incorporated not a single exercise or practice activity in the class, and provided us with no reference materials to take away. The class evaluations were mediocre; we never brought her back in. To help my clients reach a comfort level with hiring me, I always Provide a money-back guarantee. My goal is for every client to feel that they would happily work with me again. Fortunately, no client has ever asked for a refund, but I'm fully prepared to reduce the fee if they don't feel they got their money's worth.

Periodically I receive e-mails or phone calls from people who have read one of my books or heard a presentation and want some advice about their situation. I’m always happy to Answer the first question for free. Sometimes this reply leads to an ongoing dialogue, but of course it’s not feasible to provide unlimited free consulting to everyone who writes to me. Therefore, if the person who contacted me has more questions, I will offer an off-site consulting agreement so that we can continue the discussion at my usual hourly consulting rate. Most of the time that terminates the discussion. Occasionally, though, it has led to an interesting short-term consulting engagement. (As an aside, I do always try to provide a substantive response to the initial question, so I’m frankly surprised at how seldom the questioners even say thank you. That seems rather rude.)

Once in a while a fellow software consultant will point a prospective client in my direction. I’m always grateful for these opportunities, but years ago I decided that I Neither pay or accept referral or finder’s fees for these kinds of connections. I figure that it averages out over time, because I am also happy to pass along such referrals myself. This is because of my policy that I Don’t take on engagements for which I am not a good fit. If someone can do a better job for the client than I can for a particular service, that’s who the client should hire. This policy notwithstanding, I do engage in business relationships with various companies to resell my products, teach my courses under license, or sell their products through an affiliate program. That’s a different kind of deal for which revenue-sharing is appropriate.

So there you have some of the policies that I’ve adopted during my fifteen years as a consultant and trainer. What are your own business rules? Please share any policies that you have found to work for you by posting comments on this article.

(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, July 12, 2012

It’s a Matter of Policy (part 1/2)

Every organization operates according to a set of business rules, whether explicitly documented or merely integrated into the culture’s oral tradition. You should adopt a set of business rules, or policies, for your consulting practice, too. In this two-part series I will share some of the operating policies and principles I’ve accumulated for my one-person consulting and training company, Process Impact. These might or might not apply to your business, but I encourage you to consciously formulate your own analogous policies.

On Traveling


One characteristic of consulting and training is that you usually have to go where the work is. This isn’t always true, thanks to virtual consulting and webinar technology. Most of the time, though, you can expect to have to travel to client sites. Early in my consulting career I had no idea how much work I was going to get, so I happily accepted every opportunity that came along. I was fortunate to get traction with the business quickly. The result was that I was doing a LOT of traveling. Before long, I adopted the policy that I Don’t travel during more than three weeks out of each month. This doesn’t mean that I was gone three-quarters of the time, just that I might travel one or more days during three out of every four weeks. It’s important to set time aside at home to get caught up, maintain relationships with friends and family, develop new training material, write articles and books, and even relax and enjoy yourself. This policy also has helped keep me healthy. I know two consultants who became ill and couldn’t fully recover for several months because their travel commitments were so exhausting. The only thing worse than traveling a lot is traveling while you’re sick. So leave time for yourself.

Along that same line, I find it very tiring to teach more than two days in a row. It’s hard to be witty and charming, both on your feet and on your toes for seven or eight hours day after day. Therefore, if a client asks me to teach two sessions of a two-day class, I Take Wednesday off between a pair of two-day training sessions. I might do some sightseeing, visit friends in the area, or take in a movie. My voice, my feet, and my disposition all benefit from the refreshing break. Of course, I don’t charge the client for my expenses or time on the day off.

Anyone who travels a lot has had the joy of being stranded overnight (or longer) in an airport or a nearby hotel. It happens, whether due to bad weather, mechanical problems, missed connections, or terrorist acts. I was stuck at a client site far from home for several days after 9/11. Another consultant friend was trapped in Rochester, New York, for more than two days because of just one canceled flight, because there was simply no space on numerous later flights to accommodate the affected passengers. I don't worry much about such delays on my way home, but it can be disastrous on your journey to a gig. Therefore, I Never take the last flight of the day to a client site. I'd rather arrive several hours early than to miss the engagement because I'm in an airport hotel a thousand miles away.

I’ve done some international travel, going to Europe a couple of times and taking several trips to Australia and New Zealand. This led me to my next traveling policy: Only fly across an ocean in business class or better. Yes, it’s expensive, and no, you don’t get there any faster. But it certainly is a lot more comfortable. I arrive at my distant destination better rested and ready to work. I build the fees for the business class airfare into the price quotes that I provide to my overseas clients. If they are unwilling to pay the cost, that’s no problem—I just thank them for their inquiry and stay home.

I have a consultant friend who thrives on international travel. He and his wife are real outdoorsy people who love to rough it and explore exotic locations. They really suck the marrow out of life. (I tried to suck the marrow out of life once, but I chipped a tooth on the bone.) Ken has decided to Spend one extra day sightseeing for each time zone change. So if Ken goes to China or India, he takes along his wife and they spend several extra days touring, hiking, camping, or whatever. This is not a bad way to see the world if you can afford the time and cost.

You know all those little bars of soaps that hotels give you? I don’t let them go to waste. Instead I Collect hotel soaps and shampoos and donate them to a homeless shelter. I know some people think it’s unethical to “steal” soap you didn’t use. I view the soap as part of what I’m paying for the hotel room, so it bothers me not one whit to take it with me. Over the years I’ve given hundreds of little bars of soap and bottles of shampoo to people who need them more than I do.

Some years ago I figured out an interesting traveling trick: I learned how to Leverage frequent flier programs against each other. At the time I had second-tier premium frequent flyer status on just one airline. I wrote to a second airline that flew on some of the same routes and invited them to match my premium status on the first airline. They didn’t bump me up two frequent-flier levels, but they did bump me up one. “Hmmm,” I said to myself, “that was easy.” The next year I tried it again—it worked again. Then I mailed a copy of my new premium card on Airline #2 to Airline #3 and made them the same offer. Again, they took my bait.

I was able to pull this scheme off for several years, parlaying premium status on one airline into others and enjoying the ensuing benefits. It cost me nothing more than a few letters and stamps. There was nothing underhanded about this—I was simply presenting each airline with a business offer. One year, I actually held premium frequent flyer status on four airlines without having earned any of them. The scheme didn’t always work, and lately I don’t have premium status on any airline because I don’t fly very much anymore. It certainly was nice while it lasted, though. Let me know if this works for you.

What are your own policies regarding business travel? Please share them with comments on this post. In part two of this series I’ll share some additional Process Impact policies regarding finances and client relations.

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

Friday, July 6, 2012

Selling Your Proposal When You’re Not in the Room (contributed by Michael Boyette)

Michael Boyette is the executive editor of the Rapid Learning Institute’s Selling Essentials elearning site and editor of the Top Sales Dog Blog. He’s also managed marketing and PR programs for DuPont, Tyco Electronics, and US Healthcare. Contact Michael via email at topsalesdog@rapidlearninginstitute.com.

Just about anyone who has worked as an independent consultant knows how it feels when your contact says, “We’ll discuss your proposal and let you know what we decide.” After all your hard work and preparation, you’re locked out of the meeting that matters most. What if people have questions that only you can answer? What if your contact misunderstands what you proposed? What if he or she wilts at the first objection, more worried about staying on the boss’s good side than getting business for you?

For example, let’s suppose you’ve been working with Jennifer, the VP of marketing, on a proposal to enhance the company’s website. Jennifer has assured you repeatedly that she’s the sole decision maker. But now she lets you know—for the first time—that she has to take your proposal before her management team for review and approval.

Of course, you’ll want to see if you can attend (perhaps by phone or Skype) to answer any questions the management team may have. But don’t be surprised if Jennifer says it wouldn’t be appropriate for you to attend. At that point, your best strategy is to make sure that Jennifer has (1) the desire and (2) the ability to be a strong advocate for you and your proposal. If either element is missing, you’re not likely to win. So begin by finding out what Jennifer really thinks of your proposal. Don’t succumb to wishful thinking. If Jennifer is anything less than 100% committed, you need to know why and address her doubts before she walks into that meeting.

Once you’re sure Jennifer’s on board, ask her to walk you through the decision-making process so that you and she together can identify and address any potential obstacles or objections. You might say, “Jennifer, I completely understand why the team will want to have this discussion without me there. So I’d like your help to be sure everyone has the information they’ll need to make a good decision.”

Ask whether any members of the management team usually look for specific information before they reach a decision. Go through each member of the team one by one. For example, Jennifer may tell you that decisions are often delayed because the Chief Financial Officer (CFO) needs time to review the numbers. If so, offer to provide your budgets, projections, and other financial information in advance of the meeting so that the CFO can prepare. Or let’s say Jennifer tells you that the Chief Operating Officer (COO) is likely to have concerns about the amount of time your proposal would take to implement and how it will affect ongoing operations. If that’s the case, you may want to suggest that you, Jennifer, and the COO have a call before the meeting to discuss those specific concerns.

Next, analyze the decision-making process point by point. What are the hot buttons? Where are the land mines? What are potential showstoppers? Here are some questions you can ask during your analysis of the buying decision:
  • Which team members have the most influence over the outcome?
  • What is each step in the decision-making process?
  • What are some likely reasons the decision might be delayed?
  • What questions or objections often come up in these discussions?
  • When the team has said no to a proposal like this in the past, what derailed it?
  • When the team has said yes, what made it happen?
  • Who tends to dominate discussions?
  • How will the decision be arrived at: majority vote, consensus, or some other mechanism? Does any individual have veto authority?
  • What happens next? Will the CEO want to review the decision, or is it final?
  • Is price likely to come up at the beginning or end of the discussion? How big a factor will it be?
Your goal is to do everything you can to help Jennifer act as your advocate in her meeting. Granted, that’s a nontraditional role for your buyer. But if she seems uncomfortable doing it for you, it probably means you have to back up and make sure she really is as committed to your proposal as she said.

Working through this process with your prospect won’t always guarantee a sale, of course. The meeting may still go the wrong way, often for reasons that have little to do with you or your proposal. But by following these suggestions, you’ll have done everything you can to anticipate objections and influence the outcome—even though you’re not in the meeting 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!)

Monday, June 25, 2012

Modes of Consulting: What’s Your Preference? (part 2/2)

Peter Block’s Flawless Consulting defined three types of roles a consultant could play when working with clients: expert, pair-of-hands, and collaborative. In the first article of this series I addressed some aspects of working in the expert role. This article explores the other two classes of consultant roles.

When working in the pair-of-hands mode, the consultant is providing a service that the client might be able to perform himself but for which doesn’t have sufficient staff or time available. The client defines the need and sets the project boundaries and expectations. The consultant then goes off and performs the work largely on his own, with the client contact assessing the deliverables to ensure they are complete and satisfactory. Some companies, for instance, hire an experienced business analyst on a contract basis for a specific software development project. The consultant comes into the organization and performs the traditional BA role of identifying users, eliciting requirements, writing specifications, and so forth. This is a kind of short-term staff augmentation engagement for a specific objective.

In the collaborative mode, the outside consultant joins forces with members of the client organization to work on the project or solve the problem together. In contrast to the more independent work that characterizes the pair-of-hands mode, the collaborative mode involves frequent interactions between consultant and client to identify solutions, set priorities, make decisions, and create deliverables jointly. As an analogy, you could think of co-authoring a book as being a collaborative engagement, whereas hiring a ghostwriter to craft your memoirs would be a pair-of-hands type of engagement.

I have done a great deal of work for one client I’ll call Jack over more than ten years. Jack leads the software center of excellence in a large product-development company. Much of my work for Jack has been off-site consulting work in either the collaborative or pair-of-hands mode. A lot of the pair-of-hands work involves developing process descriptions, templates, and other work aids. Jack is sufficiently knowledgeable and experienced to do this kind of work himself. but he simply doesn’t have the time or staff to do it in a timely fashion. Therefore, he outsources the activity to me. Jack carefully reviews whatever I create and we iterate on it until he finds the final product acceptable. For the most part, though, Jack simply delegates the work to me, relying on my domain knowledge and our previous agreement of format and structure for such documents to feel confident that he’ll get a product that made him happy.

Frankly, I haven’t always been totally comfortable producing process-related deliverables in this pair-of-hands mode. I trust my experience and ability to create sensible process documents, so that’s not the issue. Instead, I am sometimes concerned about how readily the people in the client organization will accept process materials—or any other artifacts—created by an outside third party. I saw evidence of this problem when I was employed at Kodak years ago. Certain departments would hire consulting companies to create templates or other process documents for them, but sometimes practitioners would resist using those items. The artifacts were created by people who didn’t know the organization well. Sometimes they weren’t a great fit for what the client teams needed or expected. I’ve always worried about this reaction when doing similar work for Jack, but it hasn’t turned out to be much of a problem in practice. Nonetheless, my philosophy is that process-related deliverables are best created in a collaborative mode between a highly experienced consultant and members of the client organization. This helps the client staff buy into the new artifacts.

My consulting agreements with Jack always include a general description of the type of services I will be performing and a list of deliverables. Most of the time this works fine. In fact, we generally have a good mind meld and need very little planning documentation. I understand what he’s asking for and can accomplish the objective independently without demanding a lot of his time. Sometimes, though, Jack asks me to do something novel. Neither of us has a clear idea at the outset of exactly what the desired outcome is. In those cases, I ask him to write a short vision statement using a keyword template described in Chapter 5 of my book Software Requirements. Jack usually grumbles a bit about the vision statement because I'm asking him to think carefully about just what he wants out of this project. That’s hard! But then he works through the keyword template and always comes up with a clear one-paragraph statement that works wonders in keeping us focused on our mutual objective. I highly recommend asking your client to write such a vision statement anytime the nature or goals of the consulting engagement are too fuzzy at the beginning.

In some cases, it makes sense to combine the expert and collaborator consulting modes. A client recently hired me for an extended off-site engagement that was just such a hybrid. This large financial services company wished to implement peer reviews as part of its architectural governance process. A manager at the company was familiar with my book Peer Reviews in Software so he engaged me to help. The clients relied on my twenty-plus years of reviewing experience to advise them on how to adapt and incorporate peer reviews to be effective in their environment for a specific set of work products and issues.

One member of the client’s staff and I worked closely together on this project to define the process and develop several hours of eLearning presentations to train their staff in the new approach. The client drafted the slides and key talking points for the presentations, then I fleshed out the script with a more detailed narrative. I have a lot of experience giving presentations and developing eLearning training so I could contribute to improving the slides for a more effective presentation. I also recorded the scripts and generated the eLearning presentations, since I was already set up to do that. This was a fine example of collaboration, with a consultant and a client employee working side-by-side (albeit remotely in this instance) to generate effective work products that were better than either participant could have created alone. It was also educational and enjoyable for both of us.

I can only look back to my own experiences to reflect on the times when I have worked in an expert, collaborative, or pair-of-hands mode with a client. I don’t have any idea what the distribution of these kinds of engagements is among the software consulting domain in general. What has your experience been? Do you mostly come in as an outside expert to fix a problem? Or do you get involved with more participative activities, working jointly with a client to get something done? If you’ve worked in several of these engagement modes, which of the roles do you find most rewarding? And if you are a client who has worked with a consultant in one or more of these modes, which types of interactions did you find to be the most effective?

I enjoy the collaborative type of activities the most. It’s fun to work with smart people who know what they’re doing. One thing I’ve felt lacking in my career as an independent consultant is the opportunity to kick ideas around with other people, scribble on a whiteboard together, get review feedback on deliverables I’ve created, and put our heads together to come up with better ideas and solutions. That’s probably why I enjoy the collaborative engagements; they help fill that gap in my professional activities. These kinds of engagements are good learning opportunities as well. They always leave me better prepared for the next engagement, with a broader base of knowledge and experience to synthesize when I confront the next thorny challenge.

I recommend that you keep these different consulting modes in mind when future client engagement opportunities arise. Understanding your own preferences will help you select those gigs that are likely to be most enjoyable and fulfilling. It’s also a good idea to match the consulting mode with the needs of a specific project. Your client might ask to hire you to perform some work in a pair-of-hands mode, but your assessment of the project might lead you to conclude that a collaborative engagement would be more effective. Shaping the engagement’s parameters to yield the most satisfactory outcome is part of your responsibility as an independent consultant.

(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, June 21, 2012

Modes of Consulting: What’s Your Preference? (part 1/2)

In his classic book Flawless Consulting, Peter Block described three types of roles that consultants might take on: expert, pair-of-hands, and collaborator. Each of these represents a different type of interaction when working with clients and a different type of reward or satisfaction for the consultant. In these two articles I will describe some of my experiences with these different types of consulting engagements. Please share your own experiences by submitting comments to these blog posts.

Outside Looking In


As an expert, you’re working with a client who has a problem and wants you to fix it. I’m working in the expert role when a client brings me into do some training, perform a process assessment, or review some project deliverables or process materials. More than one client has told me, “You’re here because the pain has become too great.” The organization typically is suffering from problems resulting from ineffective practices and processes in some domain, and they hired me to help them rectify those problems. I cannot actually fix the problems in their organization. I can assess the current reality, identify areas ripe for improvement, help identify root causes that lead to the pain, provide the clients with knowledge that can help, and propose a roadmap for implementing that knowledge. But it’s up to the managers and practitioners in the organization itself to implement those actions.

I’ve found that when I perform a process assessment, whether formal and structured with a written report or simply by providing feedback based on informal discussions, I rarely tell clients things they don’t already know. For the most part, my clients are aware of their pain points. However, they might not be able to get senior management to take the matter seriously or to provide the necessary resources to address the issues. It’s not unusual for a manager who brings me in to say, “Please tell these other guys what I’ve been trying unsuccessfully to tell them for six months. They’ll listen to you.” For reasons I’ve never understood, it seems to be more acceptable to have an outside expert come in and make the same observations and proposals that some in-house people already have made. It helps that a consultant is independent of the local organizational politics and isn’t caught up in the history of “the way we’ve always done things before.” The outside expert has the perspective of having worked with numerous other organizations and observing patterns of both ineffective and effective practices in the industry.

Some of the most fun I’ve had in the expert consulting mode involved sitting in a room at a client site for a day while a procession of people came in to talk about various random problems they were facing. I never knew what kind of question was going to come up next. It might be about getting customers engaged in requirements discussions, dealing with configuration management issues, or generating better estimates for project planning. I found these all-too-infrequent types of engagements stimulating and challenging. I really had to think on my feet to quickly understand the situation and try to come up with suggestions that were likely to be effective.

I've done a great deal of consulting that involved reviewing process or project deliverables (most commonly requirements documents) for clients to point out errors and provide recommendations for improvement. I'm functioning as an outside expert in this sort of engagement. After having reviewed dozens of requirements specifications over the years, I have a good idea of what constitutes a good one and what sort of problems to look for. This body of experience allows me to efficiently examine a client’s requirements spec and spot many improvement opportunities. Of course, I can't confirm that the document contains the correct requirements for the project because I wasn't involved with defining the need, interviewing customers, or otherwise eliciting requirements. But I'm very good at spotting other kinds of problems that someone with less experience in writing requirements might not detect.

One more way in which you might work in the expert consulting mode is as an expert witness in a lawsuit. I had this experience just once. The project involved a vendor of a package software solution and a customer organization that had purchased the package and hired the vendor to perform some customizations and data migrations. One of the parties in the lawsuit hired me to try to determine the factors that contributed to the project failing abysmally. After studying numerous project documents, I concluded that the party whose attorney had hired me was responsible for a lot of the problems. The attorney read my report, said thank you, paid me, and that was the end of that. I heard later that the parties had reached a settlement, so I never had to testify. This consulting engagement led to an article titled “See You In Court,” in which I shared some advice about making such outsourcing projects more successful. I know numerous consultants who make a very good living working as expert witnesses. The expertise these consultants gained from years of industry observation and participation serves them well.

The Idea Man


I view my responsibility as an expert consultant as providing ideas, ideas that will help a client solve a problem or build software faster and better. Some solution ideas are better than others, so I try to generate a lot of them. For every ten ideas I come up with, I figure that about two will be ridiculous, two might not be very effective or won’t suit the culture, three will be obvious, two will be clever and novel to the client, and one will be brilliant. So I need to produce enough ideas to get a nice handful of solid hits in those last two categories.

I use a mental test to provide a reality check on any advice I propose in consulting discussions or when I write a formal process recommendation report. First, I consider whether the actions I'm suggesting have a high probability of actually solving the client’s problem. That is, my proposal must be effective. And second, I ask myself if the client could actually implement my suggestions if he chooses to do so. That is, what I'm proposing must be both pragmatic and appropriate for the client's culture and situation. Each practice that I have in mind must pass both of these reality checks before I pass it along to the client. The last thing I want to do is give my clients advice that wouldn’t help them, isn’t realistically feasible, or might do more harm than good.

Roadblocks


Perhaps the biggest source of resistance to input from an outside expert are NIH and NAH syndromes. NIH means “not invented here.” The solution proposed by an outside expert can be rejected because the affected practitioners didn’t create the solution themselves, so they don’t necessarily buy into it or trust it. NAH means “not applicable here.” I’ve often heard the claim “we’re different” from clients who weren’t interested in trying my recommendations. They thought that whatever I was suggesting might work in other places but certainly not in their environment. While organizations and cultures do come in a variety of flavors, there are also a lot of similarities between them. For example, I think nearly all software-developing organizations can follow basically the same change control process. Citing NIH or NAH as a reason not to accept the consultant’s recommendations is often just a sign of resistance against change in general.

And Then What Happened?


One of the frustrating things about working with a client as an outside expert consultant or trainer is that I rarely learn what happens after I leave. Unless the client has engaged me for some ongoing consulting, it’s totally up to the organization to decide how best to apply the training or recommendations I presented. Of course, I hope they will maximize their return on investment in the engagement, but if they just keep on doing whatever it was they did before I did my bit they’ll get an ROI of zero. There’s no way to find out what happened unless the client is willing to share that information with me.

Occasionally, I have received some feedback about the outcome after I taught a class. One time I had a student in a public seminar who had taken a requirements class from me about a year earlier. He said that now they have product champions serving as key user representatives for all of their projects, something I strongly recommend. This approach was really helping their projects be more successful. Such anecdotes help validate that I am presenting ideas and practices that in fact are pragmatic and can lead to better results in the hands of organizations that implement them and learn how to make them work.

Have you ever worked in the expert mode as a consultant? What sort of activities did you perform in this mode? How did you like it, compared to other types of consulting interactions you have had? Please share your experiences by commenting on this blog post. In the next article, I will take a look at the two other modes of consulting: pair-of-hands and collaborator.

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