(Part 2 in the Consultant’s Pyramid series—a short blog series on keeping the project pipeline full).

So, this one should be a no-brainer: billable work is how most consultants¹ generate revenue. If you have billable work for one or more customers that is currently actionable, do it—but don’t overdo it. An all-too-common pitfall among consultants (myself included!) is to get wrapped up in a big project and sink all available time into it. However, even the best of relationships will end for no good reason.

Perhaps the worst time to go looking for more business is the week after your customer has been bought out by a larger company that has already unplugged your servers and routed all information through their corporate headquarters. Yes, it does happen.

No doubt, billable work is king, but even the king needs backup, and, more importantly, succession. When your favorite client falls over, what will you do next? Do only the amount of billable work that will still give you time to complete the rest of your daily routine, and have the emotional reserves to maintain a healthy life outside of work. For me, that translates to about 4 hours of billable work per day. Your sweet spot may be different.

Occasional dips and peaks in billable time are practically unavoidable for consultants, but chronically or significantly overshooting your daily quota can be just as disastrous as working too little. This business strategy is all about balance and sustainability; as an independent consultant, you must switch roles regularly, and that means stepping away from the technical work frequently enough to focus on the other aspects of your business.

Finally, billable work done to a high quality standard is easily your best advertising tool; it often leads to more billable work from the same customer, or at the very least, a glowing reference.

Success Measure for Billable Work: You have completed actionable, billable work today, with time to spare.

The next posts in the series will focus on the other tiers in the pyramid. You may subscribe to my RSS feed here.

---

¹ Of course, if you have product-based offerings, the main idea here will apply just as well.

As someone who has been doing consulting either full-time or part-time since about 1993, I have certainly tried a number of different methods to grow my business. More often than I’d like to admit, some of these methods have been unmitigated failures. It would be easy to excuse myself by saying I am a computer scientist first, and a marketer second. But of course, technical skills alone do not magically produce a successful consulting business.

Like the proverbial Phoenix, the best marketing truths I have ever come up with are usually the little ones—the tiny embers of truth—that rise from the ashes of the most spectacular failures. I certainly haven’t made millions, nor do I need huge success to fuel my passion for technology. (It has plenty of fuel by itself). My needs are far more modest: a steady stream of interesting projects to work on, and just enough money to pay the bills and have a little fun.

So, through the next several posts this week, let me introduce you to my current daily work routine. It consists of five tiers (activities) that I engage in every day. I think about these tiers in terms of their overall value; if one falters, the whole pyramid will (eventually) crumble. It won’t crumble overnight, so by the time I run low on billable work, it’s hard to identify which of the other four activities were neglected. Every step is vital to continued success and growth.

If you do choose to incorporate any of these habits into your own routine, keep in mind that rigid scheduling may do more harm than good. I suggest you complete these activities in a fluid order; if you always leave the same activity to the end of your day, there’s a good chance that some other activity will consistently pre-empt it.

The second you sense one of these key activities is falling behind, your mission is clear: forget about remorse, and instead make a concrete resolution to correct the imbalance within a day. Follow through. Ultimately, you want to develop and maintain these habits, not be a slave to your day planner.

The Consultant’s Pyramid

• Do Billable Work
• Serve an Existing Relationship
• Promote Yourself
• Begin a New Relationship
• Improve Yourself

The next posts in this series will explore each of these activities in detail. Subscribe to my RSS feed.

Happy New Year, everyone.

Michelle V. Rafter has written an interesting article about multiple monitors. She contacted me in December to obtain permission to publish some of my comments. Her article contains a healthy dose of anecdotal support for multiple displays, as well as some links to multiple display how-to information.

Rafter makes the claim that “Business people who’ve made the switch say using two monitors — or even more — make them more productive. And they swear they’d never go back.”

To me, Rafter’s article serves as a good reminder to really evaluate your computer display(s) in the new year, to determine whether you really have the optimal display configuration for the type of work you do. (Do you?)

CAPTCHA challenges are so ubiquitous these days that major web sites are frustrating users by the millions with distorted text, mathematical equations, puppies, and more. CAPTCHA stands for “Completely Automated Public Turing test to tell Computers and Humans Apart”. Typically, they are employed to allow web sites to reject, for example, blog spam entered by automatic spam programs.

Unfortunately, CAPTCHAs don’t work.

The problems with CAPTCHAs

It’s an arms race. As spammers and attackers get better at programmatically breaking CAPTCHAs, web sites use more ridiculous CAPTCHAs, and so on. We are already at the point where many CAPTCHAs are very difficult for most humans to read:

Of course, on the other end of the spectrum, CAPTCHAs like the following are really just an inconvenience to both users and computers alike (this one is very easy for a computer to see, so it defeats the purpose of CAPTCHA altogether):

The majority of ordinary users are penalized for the actions of the minority of spammers. This is like forcing all drivers of a certain highway to take a breathalyzer test without probable cause in case they might be drunk.

Users with impaired vision (in some cases, colorblindness might be enough!) might find it impossible to read CAPTCHAs. On sites that do not have an audio CAPTCHA option, vision-impaired users are often out of luck. Heck, my vision is fine, and even I have to take several attempts at some CAPTCHAs.

Real humans are for hire. A truly determined spammer with a few dollars to spare can easily hire extremely cheap labor to sit at a computer and type in CAPTCHA responses all day long. Sadly, this is surprisingly cost effective for many spammers.

Humans will tend to give up after a few attempts, but computers are very patient by nature, and robots have numbers on their side. If a site doesn’t have any sort of rate limiting, a spam bot can and will easily hammer a form hundreds of times to slip one submission through.

For these reasons, current CAPTCHAs are far from a panacea.

In a nutshell

The pure idea is sound—to tell humans and computers apart—but, in my opinion, the execution is fatally flawed. All current CAPTCHAs, being “Completely Automated”, rely on computers to tell humans and computers apart. Essentially, this boils down to computers trying to fool other computers. See the problem, here?

Sure, if we had computers that could replicate human AI, they would probably do pretty well at telling humans and today’s computers apart. But, by then, the spammers’ bots will have full human AI, too. That’s an even bigger problem. See http://en.wikipedia.org/wiki/Turing_test

I am definitely not saying that web sites should immediately abandon all use of CAPTCHAs. I still use CAPTCHAs on this blog to slow down the spammers. I would get a few more comments from real users if not for that, but I understand the drawbacks, and I’m willing to take the hit.

It is beyond the scope of this article to go into a full discussion of all alternatives to CAPTCHA, so I will say only this:

Choose the right tool for the actual problem you need to solve.

CAPTCHA on, say, a sign-up page, can easily do more harm than good; you’ll be losing some percentage of legitimate users while you unwittingly support some 3rd-world economy. Basic rate limiting, exponential backoff, and reporting on new account creation, are probably enough for all but the most high-profile sites. But, again, this depends on a thorough understanding of your problem domain, coupled by a careful analysis of the available options.

One of the tenets of software process improvement (or, really, any process improvement) is conducting a thorough, honest “post-mortem” on a completed project. The concept is simple: you take a recently completed project (or well-defined milestone), and look at the good, the bad, and the ugly, and turn your observations into actionable steps you will take on the next project.

Actually executing a post-mortem can be a challenge to companies of any size. In my experience, there are a number of roadblocks to actually completing a post-mortem. This article discusses them, and is targeted towards the typical middle management software professional heading up a project. However, stakeholders of all levels will hopefully appreciate the points herein.

“We don’t have time to sacrifice billable/profitable hours to do a post-mortem.”

This is a difficult point to argue, especially when it comes as a directive from the executive. Even if you successfully browbeat the boss into letting your team do a post-mortem, you are then faced with the even more daunting task of later convincing him/her that the outcome is going to be a net benefit to the company’s bottom line, when you may not actually have the authority or the buy-in to implement all of the recommendations from the post-mortem.

All hope is not lost. For the purposes of a successful post-mortem, you really need buy-in from all parties, and I suggest you start from the bottom. I have consistently found that motivated developers (and even some unmotivated ones) are very, very eager to share their experiences and opinions, so get them on-board, along with vendors, customers, and anyone else with a stake in the project who is available for a few questions. Essentially, I am suggesting you go ahead and do the post mortem anyway—informally is just fine. Getting fired is unlikely. At the very least, you and your team will learn some valuable lessons, and it’s possible the chief may soften up, too.

“The project went well. We don’t need to do a post-mortem”.

This is a common pitfall. Whether the project really went well—or you think it went well—is debatable. Unless your company directly profits from the warm, fuzzy feelings of your project management team, you really need to analyze and measure your success criteria.

Let’s be generous, for a moment, and assume that the project was successful. The more successful the project, the more you have to gain by doing a post-mortem. Imagine the army of doctors that would line up to do an autopsy of a real-life Superman. The idea here is, find out what worked, why it worked, and then reproduce it.

“The project was on time, on spec, and on budget. We don’t need to improve.”

This seems to be a Holy Grail of sorts for some companies. It isn’t. Even though a project may indeed be on time, on spec, and on budget, who defined the timeline, specification, and budget? The problem is, some mature software and business teams get very good at working together and setting goals they know they can meet. To the extent attainable goals are a good thing, the danger lies in becoming complacent with sub-optimal developments.

The company that can develop a certain widget in 6 months for $500K is in for a shock (not to mention the possibility of significant lost revenue) when their competitor develops a better widget in 4 months. Wouldn’t it be nice to be ahead of the curve?

“The project was a flop for obvious reasons. Let’s not waste more time by over-analyzing it!”

To some, doing a post-mortem on a failed project can feel something like eating a box of thumbtacks; more so, if the outcome seems inevitable. Suppose you chose a vendor to develop a seemingly innocent bit of middleware for your project, and they significantly overran their deadline, creating a cascade effect on your entire timeline. It is easy to blame the vendor for your failure, and vow never to use them again. It is harder, and so much more valuable, to step up a level, swallow your corporate pride, and ask the more difficult questions, like:

• Was outsourcing this component really the best strategic move?
• Did we make any serious attempt to mitigate this risk in our project plan?
• Did we fail to recognize a dependency upon this vendor’s deliverable that caused the critical path slip?
• Were there any early warning signs that we failed to act on?
• Could a different approach to managing this subcontractor have helped us identify the problem earlier, or keep the project on track?

Of course these are just a few of the questions you might want to ask in a case like this. Always remember to keep a mixture of “standard” post-mortem questions, and to really ask the hard questions that are specific to the project’s circumstances, as well. Resist the urge to take a “clean room” approach and let just one person come up with all of the questions. Encourage all stakeholders to participate; good answers are more likely to follow good questions.

“We don’t want to say anything negative, because it will make us look bad/get fired/lose our bonus/etc.”

For whatever reason, some companies manage to create an unfortunate culture where employee performance appraisals trump honesty, and developers become loathe to admitting mistakes—or even suggesting improvements. To be fair, I doubt that companies’ top execs intend for this to happen. However, some of these same companies are also pretty bad at recognizing and fixing a gun-shy culture. Doing a post-mortem in this sort of environment may not net the most useful results, and shifting a defensive culture in short order may be next to impossible, in your position.

The best advice I can give you in this case, is to create a small bubble of trust within your project. Go one-on-one if necessary. If you think your stakeholders won’t be honest with you, that’s another problem entirely. Clearly this is not the best time to flex authority and demand honest answers. I have seen entire teams literally go stiff when someone takes this tack, with some mixture of fear, hostility, and apathy, in proportion to the relative burn-out of the team. Instead, I suggest finding someone on the team (probably below you) that is well-connected to most people, and have them take a soft approach. Put them in charge of gathering the inputs (preferably around the lunch table, not the boardroom table), and back them up with tools, information and mentoring, not muscle. Putting the best people on a task is of course one of your best strengths, right? Don’t forget to look at the project’s culture as part of the post-mortem, as it almost certainly had an effect on the project itself.

“We have done post-mortems before. Nothing ever changes.”

You are more likely to hear this sort of comment from the trenches. The perception (probably based in reality) is that the company’s efforts to analyze projects have historically not brought any real change. Developers don’t see the value, and believe the post-mortems are little more than a chance to vent, or pat themselves on the back, or otherwise waste time they could be devoting to the next project you are keeping them from.

There is no easy response to this assertion. If your people feel nothing has changed, they are probably right. Surely, not every recommendation will be implemented, but, by choosing a set of suggestions from a key project, and then reviewing the effects of those suggestions, in a visible and inclusive way, is the key to demonstrating a company’s resolve to benefit from the collective genius of its employees (not to mention vendors and clients). This need not be an onerous undertaking. Having a quick meeting—or at least some sort of announcement—a month or so after the post-mortem to review the implementation status of the suggestions will go a long way, providing some actual progress has been made. Having measurable criteria for improvement is also important, but the time quantum there is typically longer. Keep the door open for additional suggestions at any time, and, if one of the recommendations isn’t working, get rid of it. Obviously, before making a serious investment into any recommendation (including job creation), the company should absolutely undertake due diligence—just don’t over-analyze.

- – -

These are just some of the more common sticking points I have encountered. I am sure that the seasoned readers of this article will have had varying experiences when attempting to run software project post-mortems. Please do share your comments here!