Hal Pomeranz, Deer Run Associates

Money matters seem to be uppermost in people’s minds when they ask me about consulting. Mostly they want to talk about how quickly and how high they can crank up their billing rate.  But before we even get to that information I need to teach you one very basic, yet very important thing you need to know about managing your cash-flow as a consultant.

Part of the contract you agree on with your client will spell out the terms under which you invoice and get paid.  For example, “bi-weekly, net 30” would mean that you invoice every two weeks (“bi-weekly”) and the client has 30 days from receipt of your invoice to cut the check (“net 30”).  Sounds fine to you, especially because you’re mentally calculating all of the cash that your amazing hourly rate will bring in, so you sign on the dotted line.

30 days later you’re behind on rent and starving.  And you won’t get paid for at least two more weeks. What just happened?  You made one of the classic consulting blunders that all newbies make.  You forgot to anticipate the lag-time between the start of the contract and your first income.

Let’s project our “bi-weekly, net 30” example to its inevitable conclusion. Say the start of your contract is “Day 1”.  You don’t even get to submit your first invoice until the end of Day 12– and it really hits the Accounts Payable department at your client on Day 15 at the earliest.  From there, they have 30 days before they actually have to cut you the check.  So you’re a minimum of 45 days out before you get your first payment.

And even if the client is on time cutting that first check, there are inevitable delays.  It will likely be mailed to you, so figure in 3-5 days for the USPS to jack around with it.  Then when you present it at your bank, they may put a hold on the funds for up to a week.  Now you’re looking at maybe 8 full weeks before you can actually start spending that money.

And let me tell you from personal experience, the first check is never on time.  What happens in the real world is that your invoice goes through the Accounts Payable system, and gets approvals from the people in the company who you’re doing the work for to authorize the funds.  But then when Accounts Payable gets around to actually triggering the payment they realize that (a) you’re a new vendor and you have to jump through a whole bunch of paperwork hoops for their system to pay you, or (b) they mistake you for another vendor and send your check to the other guy (true story, it actually happened to me), or (c) some other arcane craziness in their processing ensues.  Suddenly that 45 day goal for getting your first check cut seems like wishful thinking.

How are you going to live for the 45-60+ days it may take before you can spend that first check?  Remember what I said in Part 1 of this series about having six months worth of expenses in the bank?  Well this cash-flow issue when starting new contracts is one of the reasons why that six month “float” is so vital.  You may have to dip into those savings while you’re waiting for the money to start rolling in.  And by the way, when the money does start rolling in, you want to “pay back” those savings as quickly as possible so they’ll be intact for future emergencies.

Now the good news is that once the first check gets kicked out of the system, clients are usually good about paying other invoices on time.  And when the contract is over, you’re still going to have 30 days worth of outstanding invoices that will be catching up with you.  So if you can arrange for your next contract to start right after the one you just finished, then the outstanding invoices from your previous assignment will carry you over the inevitable payment start-up problems with your next client.  It’s gaps between contracts that are a problem.

So hint #1 for managing your cash-flow is to starting looking for your next contract before the current one ends.  This is a delicate balancing act.  First, it might not be clear exactly when your current contract is going to end.  Second, your next client isn’t going to wait forever, so you can’t start looking around too early.  I find that 30 days before the end of my current gig is the earliest reasonable date that I can start talking to people about my next engagement.

Hint #2 is to carefully manage your payment terms.  Even if the client wants you to bill bi-weekly, see if they’ll let you submit your first invoice after a week– “just to flush out any issues with Accounts Payable,” you say.  Also see if they’ll agree to shorter payment terms.  At this point, I’m insisting on “net 15” with most clients (they’ll still be late on the first check, but at least you find the problems quicker).  If it’s a fixed-price contract, I insist on a chunk of the money up front before I begin work.

Hint #3 is to be pro-active.  If possible, hand-deliver your first invoice to Accounts Payable.  Be friendly.  Introduce yourself as a new vendor and ask if there’s any special paperwork they need to enter you into their system.  A week before your first check is due to be cut, send them a note asking if there’s anything further they need in order to process the payment, referencing your company name, invoice number, and the responsible management in the company you’re working for.  And if they actually pay you on time, send them a nice thank you note (I’ve even sent flowers).

Hint #4 is to not be afraid to be the bad cop.  In addition to payment terms, have your contract spell out penalties for late payment.  I normally charge credit card level interest on late payments– around 1.5% per month, compounded.  And if your client is more than a month delinquent on their first payment (remember this means you’ll have been working there for two months without getting paid), tell them you’re going to stop work until they pay you the outstanding invoices.  This will usually light a fire under the management of the team you’re working for and get any Accounts Payable logjams broken up.

Normally you have to live through some huge payment SNAFUs like I have in order to be hard-hearted about getting paid on time.  But you’re doing your best work for your client, and you deserve to be paid according to the agreed upon terms.  If you follow my advice here, hopefully any issues you have will be taken care of quickly.  And they won’t impact your quality of life, because you’ll have enough float to carry you over the rough spots.

Meditate on this advice.  In the next installment we’ll talk about how to figure out your billing rate.

Advertisements

Hal Pomeranz, Deer Run Associates

Introduction

January 2012 will mark the 15th anniversary of the founding of the consulting business I run with my wife.  Lately I’ve had a number of people asking me questions about consulting– how to get started, how it works, pitfalls, etc.  I’m more than happy to answer these sorts of questions because I’m still “paying it forward” for all of the great advice I received when I was just starting out.

However, in an effort to reach a larger audience and to not have to repeat myself as much, I’ve decided to devote some blog space to the basic advice that I cover in my usual consulting talks.  This is a huge topic area, and I’m expecting to write several posts to cover just the foundational stuff.  I’ll crank them out as time allows.  If there’s anything you’re particularly curious about, be sure to leave a comment and I’ll try to address questions as the series rolls along.

In this first installment, I wanted to talk about some of the basic pro/con arguments you hear about being a consultant, and give you the view from where I sit.  Let’s call this installment…

The Case for Consulting

Pro: Consultants Make a Lot of Money

This is definitely one of the first items that piques people’s interest in becoming a consultant.  You hear about consultants making hundreds of dollars per hour, divide your annual salary by 2000 hrs/yr, and start thinking the grass is greener on the consulting side of the fence.

Yes, top consultants bill at hundreds of dollars per hour.  But guess what?  We don’t get to bill 2000 hours per year.  There are all sorts of unbillable “overhead” tasks that take away from our billable time:

  • Marketing, finding new clients
  • Invoicing, collections, time and expense reporting
  • Taxes and other official paperwork
  • Arranging insurance and other benefits
  • Continuing education, training

The list goes on, but the point is that when you become a consultant you’re really working two jobs: the work you’re doing for your client that you get paid for, and the work you do to keep your own business running which you do as “overhead”.

Also, there are costs that you pay when you’re on your own that you never see as a full-time employee (FTE, for short).  Normally your employer covers a portion of your healthcare and other benefits and sometimes contributes to a retirement account on your behalf, as well as paying the employer’s share of taxes.  If you talk to your employer, you’ll find that they typically figure these costs as being 50-100% of the employees’ base salary (you’ll hear this referred to as an employee’s “loaded salary”).  So you have to factor in these costs when trying to figure the net take home pay as a consultant.

The compensation discussion is a huge topic in itself, and will be covered in detail in a later post in this series.  Yes, if you have financial discipline and a clear understanding of your costs, you can make a lot of money as a consultant.  But be wary of straight “apples to apples” comparisons between full-time employees and consultants, because things are never that simple.

Con: Consulting is “Risky”

People ask me all the time if I’m worried about where my next job is coming from.  In fifteen years, I’ve lived through two major downturns.  Yes, there have been times when consulting work has been scarce.  This is another reason that consultants bill at such high hourly rates– we’re factoring the inevitable cost of being out of work.  Sometimes this is just a brief period while were transitioning from one contract to the next, and sometimes there’s a protracted drought.

The difference between a successful consultant and somebody who’s going hungry is an understanding that downturns happen and preparing for them.  The best advice I ever got when I was first starting out what to make sure I had six months of expenses (rent/mortgage, utilities, car/insurance payments, food, medical, etc) in the bank before I started my consulting business.  I’m going to come back to this point over and over because it’s important in lots of ways, but at its most basic your “six months in the bank” is shelter against bad times.

What fascinates me, however, is the belief that a lot of people seem to have that as a FTE they somehow have more job security than your average consultant.  In practice, I believe these people couldn’t be more wrong.  At least here in the United States, most people are “at will” employees and they can be let go at any time at the complete discretion of their employers and with little or no notice.  So really we’re all what the HR types like to refer to as “contingent employees”.  Why shouldn’t you be compensated like one?

I know that many people can understand this argument intellectually and still have a hard time with the notion of going out their own.  Sometimes our gut overrules our brain and makes the consulting lifestyle untenable.  But even if you don’t end up as a consultant, I recommend you think about putting some money away for the rainy day when you might be out of work.

Pro: Consultants Have “Freedom”

I usually hear this one from folks who are unhappy with their current job duties and are envious of my ability to “pick and choose” the work that I take on.  During good economic times, I do have a certain amount of leeway on the jobs I decide to take on and can optimize for more interesting assignments.  But during the bad times, you take whatever you can get.

Also, having taken on an assignment, you have to see it through to the end.  As an independent consultant, I have a limited of “bandwidth” and can typically only support one or two major clients at a time.  If a really interesting project comes along when I’m busy with other work, I have to let it go by or risk alienating my current clients.  In this business your reputation is the key to your success.  Doing a bad or incomplete job because you let yourself be distracted by the new, shiny contract is a sure path to the end of your consulting career.

Another consulting freedom that I hear FTEs envy is the ability for consultants to take time off “whenever they feel like it”.  Sure, if a client is not expecting me on-site and I don’t have any pressing deadlines, I can take time off whenever I feel like it.  It’s definitely a benefit of my lifestyle.

But you have to understand that I don’t get paid during this time.  Vacation, medical leave, and all other periods of “downtime” that are necessary to ensure your health/sanity and prevent burn-out are all part of that unbillable “overhead” I talked about earlier.  So a better way to talk about this freedom is to say consultants can take time off whenever they can afford to.

One more consulting freedom I wanted to mention is the freedom from a certain amount of organizational politics.  Normally, by the time an organization has made the choice to hire a high-priced expert, they’ve already realized that they have a significant problem and have “cleared the decks” of the typical political impediments to making the problem go away.  This is a wonderful thing.

In Summation

I love the consulting lifestyle, but recognize that it’s not for everybody.  There is substantial risk and you spend a lot of time working on mundane aspects of running your business.  But you can earn good money and enjoy substantial freedoms unavailable to FTEs.  I hope you’ll join me for future articles in this series when I drill down on specific details like figuring your billing rate and managing your cash flow, finding and managing clients, and classic blunders that all new consultants commit.

Hal Pomeranz, Deer Run Associates

Tell me what this is:

TCP Header in Lego(TM)

TCP Header in Lego(TM)

If you said, “Hey! That’s a TCP header diagram in Lego(TM)”, or perhaps, “Holy &^%@! That idiot made a TCP header diagram in Lego(TM)!”, then you’re exactly right!  This is another one of those wild, wacky ideas that we dreamed up in the middle of one of my SANS classes (note to the SANS staff: shorter breaks might be a good idea).  I bet my students never thought I’d actually do it.

Of course, you know I couldn’t stop with just doing the TCP header:

IP Header in Lego(TM)

IP Header in Lego(TM)

Now why am I wasting all that space on the building plate in each case?  Why so you can put them together of course:

TCP/IP in Lego(TM)

TCP/IP in Lego(TM)

The use of color here really highlights certain portions of the packet header.  For example, the source and destination addresses and ports really jump out.  But there are some other, more subtle color patterns that I worked in here.  For example, if you look closely you’ll see that I matched the color of the ACK bit with the blue in the ACK number field.  Similarly the colors of the SYN bit and the sequence number match, as do the URG bit and urgent pointer field.

Actually I wish I had a couple of more colors available.  Yes, Lego(TM) comes in dozens of colors these days, but they only make 2×8 blocks (aka one “Lego(TM) Byte”) in six colors: White, Black, Red, Yellow, Blue, and Beige.

Lego(TM) Byte, Nibble, and Bit

Lego(TM) Byte, Nibble, and Bit

So while I tried to use Beige exclusively for size fields, Red for reserved bits, Yellow for checksums, and so on, I ultimately ended up having to use these colors for other fields as well– for example, the yellow sequence number fields in the TCP header.  Maybe I should have just bought a bunch of “nibbles” (2×4 blocks) in other colors and not been so choosy about using full “Lego(TM) Bytes”.

Serious Fun

Cute idea, but is there any practical value?  After a lengthy conversation with my inner child (who is generally more mature than my outer persona), I realized that there was a fun learning game we could make out of all this.  So I labelled all the blocks.  Yes, that’s right. I. Labelled. Every. Single. Block. I even did the individual bits:

TCP Header "Bits" in Lego(TM). Labelled.

TCP Header "Bits" in Lego(TM). Labelled.

So the game becomes learning where all the fields are in the various packet headers so that you can re-create the packet diagrams from piles that look like this:

Lego(TM) blocks waiting to become TCP header diagram

Lego(TM) blocks waiting to become TCP header diagram

Now we can teach students how to decode packet headers by letting them play with Legos(TM).  And that means we can all write off our Lego(TM) collections as a business expense!  How cool is that?

Admit It.  You Can’t Wait To Do It Too!

Project Tools

Project Tools

If you’ve got a hankering to try this out for yourself, it doesn’t take a whole lot.  I way overbought on the Lego front: six green base-plates, and 20 2×8 “Lego(TM) Bytes”, 8 “Nibbles” (2×4 blocks), and 16 “Bits” in each color.  Total cost for the Lego(TM) was around US$100 delivered.

Labelling was accomplished with my P-Touch(TM) labeller.  3/8″ ribbon is precisely the right height to be placed on the side of a Lego(TM) block.  It also helps to have a razor blade type tool to help separate the P-Touch(TM) labels from their backing and apply them to the blocks.

And of course I have to give a shout-out to the late, great Richard Stevens and his biblical tome TCP/IP Illustrated: Vol 1.  If you don’t already own this book, buy it. Seriously.

Final Thoughts

Finally, to all of you who think I need a life, all I have to say is:

Labelled TTL "Lego(TM) Byte"

Labelled TTL "Lego(TM) Byte"

Baby, I’m living the dream!

Hal Pomeranz, Deer Run Associates

Not too long ago, I was bemoaning the fact that my mother still uses floppy disks and that it’s becoming harder and harder to get her set up with a computer that actually has a floppy drive.  Then one of my friends suggested a brilliant idea, which I’ve only just gotten around to implementing:

Floppy Disk w/ Low-Tech USB Adaptor

“Just tell her it’s an adaptor!”, my friend suggested.  Heck man, not only is it an adaptor, it also spectacularly increases the amount of stuff you can store on that floppy!  I wonder if my Mom will go for it?

Not News is Bad News

May 17, 2010

Hal Pomeranz, Deer Run Associates

I read an article this morning about on-line banking fraud that was so awful it prompted me to dust off the Righteous IT blog and write about it.  Sure, it’s a sponsored article from a financial industry site and not really journalism, so maybe I shouldn’t expect too much.  But the problem is that the misinformation in this article– which is so typical of other articles related to on-line banking fraud– is actually hampering our ability to make the situation better.

Let’s start with the “money quote” in the article from F-Secure’s Sean Sullivan: “Last year there were more online bank robberies than there were actual on-site bank robberies.”  You can be sure that this quote is going to get a lot of airplay on Twitter and in the popular press.  I even understand what Sean is saying here– there were numerically more cases of on-line banking fraud than there were physical hold-ups at banking institutions.  I might even believe this.

The problem with the quote is that it ignores one important point.  When a real-world bank is held up, the bank’s insurance covers the cost of any losses.  When a small business is the victim of on-line banking fraud, the bank is not legally obligated to make good the loss– a fact that is even noted later in the original article.  The reality is that in on-line banking fraud, the bank is not the victim, their customers are.  So while the quote is surely an attention-grabber, it ignores the critical fact that in the on-line world, the financial institutions have managed to transfer a whole lot of risk squarely into the laps of their customers.

The article goes on to extol the virtues of multi-factor authentication systems, including passwords, keys, security questions, personalized pictures, and so on.  We even get another quote from Sean Sullivan: “The more layers you have before you get to your account, the safer you are.”  Really? Then why does Sullivan also state in the same article, “Some more advanced types of Trojans can make fraudulent transfers and drain your account while you are logged on to the account online.”

The reality that banks may not want to admit right now is that readily available malware kits like Zeus are completely bypassing the bank’s on-line security protocols.  This happens because the attacker has simply taken over the victim’s machine and is using the victim’s own credentials to conduct the fraudulent transactions. It doesn’t matter how many “layers” you have when the attackers own the victim’s system.  To borrow Bruce Schneier’s phrase, all of those hoops that your on-line bank makes you jump through are not much more than “security theatre” at this point.

Finally there’s the standard wrap-up for an article of this type: the dreaded “How to Help Protect Your Account” list of bullet items.  These lists always include advice on keeping your anti-virus/anti-spyware up-to-date and turning on auto-updates (it’s #2 in the list in this article).  Well guess what?  Perhaps more than half of the PCs infected with the Zeus banking malware had up-to-date virus signatures and patches.

And of course there’s the exhortation to “Use a strong password with letters and numbers combined.”  How exactly is a strong password going to help you when the attackers learn what the password is as soon as you enter it into your web browser?  Can we please stop suggesting that passwords– strong or otherwise– are going to help here?

At this point, I’m not sure there’s a way for normal users to achieve a reasonable level of security for on-line banking.  The “attack surface” of a typical home computer is so vast that attackers will find a way to compromise the system.  The best suggestion I’ve heard floated to date– using a dedicated computer for on-line banking— seems too expensive to be reasonable for home users, or even a typical small business (to say nothing of the inconvenience factor).

The bottom line is that current on-line security measures are not stopping thieves. We need to stop publishing articles that suggest that there is some magic litany of security steps an average user can take to make their on-line banking secure.  If users were to abandon on-line banking– which is a huge money-saver for financial institutions compared to bricks and mortar branches with live tellers– you can bet that the banks might actually start working on some more effective security measures.

Similarly, as long as the banks can keep pushing their liability onto their customers, they have no incentive to fix the problem.  We need more customers who are willing to go after their banks to recover their lost funds.  Small business groups should agitate for the same sorts of protections that are afforded to individual accounts.  By pushing the liability back onto the financial institutions, we make it more likely that the banks will actually spend their own money beefing up their on-line security measures and back-end fraud detection.

Policy Matters

August 12, 2009

Hal Pomeranz, Deer Run Associates

Hey, I read a great policy today! I bet you can count on the fingers of one kneecap the number of times you’ve said that in your life.  Yet in this case it’s quite literally true: I did read a great policy today.  Surf on over to Will Weider’s blog and check out his organization’s draft Social Media Policy.

Let me try and articulate some of the reasons why I like this policy document so much:

  • It takes something that many organizations are viewing as a threat– the use of social media by their employees– and instead dares to envision an opportunity instead.
  • It’s inclusive, recognizing and supporting the role that all employees have in promoting the business.
  • It’s respectful to employees, treating them as adults with decision making capabilities rather than naughty children who need specific rules in order to be kept in line.
  • It discusses the problems that can occur with social media outside of the contexts that directly affect the reputation and bottom-line of the organization (in particular see “Don’t jeopardize your reputation and/or future employment opportunities” and “Don’t alienate your co-workers”).
  • It’s educational.  It’s readable.  It’s short.  And it clearly indicates who has authority and who to contact in case of questions about the policy.

I tell you, if more policies were written this way maybe “policy” wouldn’t be such a dirty word to people.

The other thing I love about Will’s posting is that he’s clearly demonstrating the opportunity of Social Media by posting a draft of the policy on the web for comments.  I challenge you to read the draft policy and not think, “Hey, this company seems to have their head screwed on straight.  This might be a good place to work.”  Oh yeah, and he might get some comments directly about the policy that might help improve the document.  “Open Source” policy, anyone?

So kudos to Will and the team at Ministry Health for an excellent piece of work.  By the way, all of you IT folks reading this blog should consider following Will (@CandidCIO) on Twitter.

Hal Pomeranz, Deer Run Associates

Today I received a rather alarmed email from one of my customers who’s on the faculty at a large research university here in the US.  Apparently, email originating from the server I’m maintaining for this customer is being bounced by the mail servers at the educational institutions that are users of our software.

Examining the bounce messages, I find that they’re originating from anti-spam appliances sold by Barracuda Networks, Inc.  Each bounce message contains a URL pointing you to an explanatory web page, which indicates that the messages are being bounced because the outgoing email servers for the Engineering department at this large university have been listed in Barracuda’s “bad reputation” blacklist.  There is a laundry list of reasons cited as to why these mail servers may have been listed, but no clear indication of the actual offense that caused these specific servers to be listed.

However, there is this little highlighted tidbit on the web page:

One way to get your email through spam filters even if you are listed on the BRBL is to register your domain and IPs at EmailReg.org. Email administrators can configure their systems to use EmailReg.org to apply policy to inbound email. Emails from domain names and IP addresses that are properly registered on EmailReg.org can be automatically exempted from spam filtering defense layers on Barracuda Spam Firewalls, preventing your email from being accidentally blocked.

Surfing on over to EmailReg.org I discover that getting your server address “properly registered” requires a $20 “administrative charge”– apparently per server.  Furthermore, it seems that EmailReg.org is at least receiving hosting equipment from Barracuda Networks.  There is little other information to be found regarding who exactly is behind EmailReg.org.

But let me tell you what it smells like to me– it smells like a “protection racket” being run by Barracuda Networks.  They can add arbitrary senders to their “bad reputation” blacklist and then prominently advertise the services of EmailReg.org as a mechanism for being removed from the blacklist.  Judging by the number of bounce messages my client is receiving, being blacklisted by Barracuda devices cuts you off from sending email to a significant number of organizations.  Many companies, even legitimate senders, will likely pay the $20 just to avoid the hassle.  If, as I suspect, Barracuda Networks is receiving some commercial gain from EmailReg.org, then this is conduct of the lowest order.

I have filed a complaint with the US Federal Trade Commission, asking them to investigate this matter.  I urge everybody who has had similar experiences to file similar complaints with the appropriate organization for your jurisdiction.

Skunkworks in the Clouds

April 23, 2009

Hal Pomeranz, Deer Run Associates

Skunks... clouds... get it?

I was recently asked to make a guest appearance on a podcast related to information security in “the cloud”.  One of the participants brought up an interesting anecdote from one of his clients.  Apparently the IT group at this company had been approached by a member of their marketing team who was looking for some compute resources to tackle a big data crunching exercise.  The IT group responded that they were already overloaded and it would be months before they could get around to providing the necessary infrastructure.  Rebuffed but undeterred, the marketing person used their credit card to purchase sufficient resources from Amazon’s EC2 to process the data set and got the work done literally overnight for a capital cost of approximately $1800.

There ensued the predictable horrified gasping from us InfoSec types on the podcast.  Nothing is more terrifying than skunkworks IT, especially on infrastructure not under our direct control.  “Didn’t they realize how insecure it was to do that?” “What will happen when all of our users realize how easily and conveniently they can do this?” “How can an organization control this type of risky behavior?” We went to bed immersed in our own paranoid but comfortable world-view.

Since then, however, I’ve had the chance to talk with other people about this situation.  In particular, my friend John Sechrest delivered an intellectual “boot to the head” that’s caused me to consider the situation in a new light.  Apparently getting the data processed in a timely fashion was so critical to the marketing department that they figured out their own self-service plan for obtaining the IT resources they needed. If the project was that critical, John asked, was it reasonable from a business perspective for the IT group to effectively refuse to help their marketing department crunch this data?

Maybe the IT group really was overloaded– most of them are these days.  However, the business of the company still needs to move forward, and the clever problem-solving monkeys in various parts of the organization will figure out ways to get their jobs done even without IT support. “Didn’t they realize how insecure it was to do that?”  No, and they didn’t care.  They needed to accomplish a goal, and they did.

“What will happen when all of our users realize how easily and conveniently they can do this?” My guess is they’re going to start doing it a lot more.  Maybe that’s a good thing.  If the IT group is really overloaded, then perhaps it should think about actually empowering their users to do these kind of “one off” or prototype projects on their own without draining the resources of the core IT group.  Remember that if you let a thousand IT projects bloom, 999 of them are going to wither and die shortly thereafter.  Perhaps IT doesn’t need to waste time managing the death of the 999.

“How can an organization control this type of risky behavior?” You probably can’t.  So perhaps your IT group should provide a secure offering that’s so compelling that your users will want to use your version rather than the commodity offerings that are so readily available.  This solution will have to be tailored to each company, but I think it starts with things like:

  • Pre-configured images with known baseline configurations and relevant tools so that groups can get up an running quickly without having to build and upload their own images.
  • Easy toolkits for migrating data and out of these images in a secure fashion, with some sort of DLP solution baked in.
  • Secure back-end storage to protect the data at rest in these images with no extra work on the part of the users.
  • Integration with the organization’s existing identity management and/or AAA framework so that users don’t have to re-implement their own solutions.
  • Integration with the organization’s auditing and logging infrastructures so you know what’s going on.

Putting together the kind of framework described above is a major IT project, and will require input and participation from your user community.  But once accomplished, it could provide massive leverage to overtaxed IT organizations.  Rather than IT having to engineer everything themselves, they provide secure self-service building blocks to their customers and let them have at it.

Providing architecture support and guidance in the early stages of each project is probably prudent.  After all, the one hardy little flower that blooms and refuses to die may become a critical resource to the organization that may eventually need to be moved back “in house”.  While the fact that the building blocks that were used to create the service are already well-integrated with the organization’s centralized IT infrastructure will help, having a reasonable architectural design from the start will also be a huge help when it comes time to migrate and continue scaling the service.

Am I advocating skunkworks IT?  No, I like to think I’m advocating self-service IT on a grand scale.  You’ll see what skunkworks IT looks like if you ignore this issue and just let your users develop their own solutions because you’re too busy to help them.

Hal Pomeranz, Deer Run Associates

awful-wiring-2-smallerOne of my personal and professional mantras is, “It doesn’t take that much longer to do it right.”  Sure, you can always do a half-assed job on some project just to shove it out the door, but there are inevitably down-stream costs.  Whether it’s time lost having to go back and fix your broken junk or customer frustration and negative perception, your short-cut decision usually ends up costing you more in the long run.

Of course you know I have a story to illustrate this principle.  During the peak of the dot-com boom I was helping a small start-up company move out of their sub-lease arrangement into their new permanent home.  The weekend of the move, we had contracted with a moving company to do the physical move of all the equipment and personal items and I was helping the IT team for the company do the setup, server room build out, telephony configuration, etc.  The building we were moving into was a two-story affair, and the plan for the equipment that was moving onto the second floor was to arrange it on pallets, wrap the pallet securely, and forklift the pallets through a second-story window.  Pretty standard practice, actually.

The moving company, however, had negotiated a fixed-price bid.  So it was in their best interests to get the work done as quickly as possible.  Without our knowledge, they decided to throw caution to the wind and not wrap the palleted equipment.  Sure enough, the first pallet went up on the forklift and as the pallet was moving forward through the window, one of the computers toppled off the edge and fell a full story onto concrete.  The punchline is that the computer belonged to the office manager for the company and was the computer that was going to cut the check to the moving company.  We were actually able to recover the hard drive from the twisted chassis and boot it in another PC, but the moving company had to pay a significant penalty that more than erased any savings that they might have achieved from not wrapping the pallets.  Also, after that incident, we made them stop and wrap all the pallets anyway, which cost them even more time.

Once the equipment was loaded in, the IT team and I could get started with our part of the project.  And it was a big project:  from our Friday evening start to late Sunday night, I think we got maybe 12 hours of downtime to sleep.  But there we were Sunday night and everything appeared to be ready for business to resume Monday morning.

Exhausted, but feeling pretty good about ourselves, we were standing admiring the new server room and somebody pointed out that we forgot to put the covers back on the cable raceways.  There was a collective groan.  We were “done”– surely replacing the covers could wait until the following week when we were all less tired?  But when we all looked each other in the eye, we knew that the upcoming week was going to be so chaotic that if we put off doing it now we’d never get around to it in a timely fashion.  So, without a word being spoken, we all grabbed some covers and spent another half hour or so fitting them into place.

When the execs toured the facility the following morning, we actually did get some compliments about how “neat” and “professional” the server room looked, but I don’t think that’s really why a crew of exhausted geeks spent an extra half hour re-assembling cable raceways.  Nor was it because we’re anal retentive or budding masochists.  I think it was because (a) we wanted to establish a culture of “doing things right” in the new server room so that entropy wouldn’t set in so quickly, and (b) we knew that going back and fixing the problem later would take longer than doing it right then.

So when you find yourself looking for excuses not to “finish” a project and just “get ‘er done”, take a moment and think about whether expediency is really the best policy.  Remember that bugs are always cheaper to fix in development than after the product ships.  It doesn’t take that much longer to do it right.

Avoiding Avoidance

April 6, 2009

Hal Pomeranz, Deer Run Associates

At a recent tech event, I ended up having a conversation with Wendy Kincade and Colleen Dick about how we sometimes let critical projects slide. Wendy said a very wise thing, which is that when people are avoiding a project, it’s most often because they don’t think they’ll reach a successful outcome.  In some sense it becomes a vicious cycle: we know we really should be making progress on that big project, but yet we somehow always find other things to be working on that allow us to avoid it.  Of course, the longer we avoid it, the less time we have to complete the project and it only becomes bigger and scarier as a result of the shrinking time window.

Full speed into the unknown

I’ve certainly come to recognize this behavior in myself.  It’s much more comfortable to spend your days doing small, tactical tasks that have short completion times and satisfying outcomes.  It’s a huge leap of faith to set out to tackle and enormous project when you’re not sure if you have all the skills necessary to accomplish the task, where the end of the project is not clearly in sight, and where the cost of failure may be high.  It gives me an uncomfortable feeling in the pit of my stomach, not unlike the feeling you get when contemplating stepping off from a great height.

When I recognize this feeling in myself, I immediately take steps to start tackling the project, because I know from previous experience that if I let it linger the situation is only going to get worse.  Here are some tactics that I’ve developed for getting over the hump:

1. Break it up: Vast monolithic projects are daunting, so break the project up into a set of deliverables, milestones, and dependencies.  Then outline the steps necessary to reach each component of the project.  You don’t have to create a formal project plan– in fact, I’ve seen people spend all their time grooming a plan in MS Project, just to avoid getting started on the actual work.  A simple outline format is fine.

2. Pick an easy one: Once you’ve got a notion of the individual tasks you need to accomplish to finish your project, pick one of the tasks that you think you can complete quickly and get it done.  During our conversation, Colleen commented, “I know that if I can just knock one thing down, that gives me energy to push further into the project.”

3. Make it fun: What motivates you?  I really enjoy figuring out and mastering new technology.  So if there’s a component of the project that requires me to do a bunch of research to figure something out, I’ll tend to do that first plus give myself leeway to spend extra time really getting mastery of that subject.  While I need to be careful to prevent turning the research into an avoidance exercise in and of itself, I also know that any mastery I acquire will be useful at some point in the future, even if it’s not directly relevant to the project at hand.  Some people reward themselves after completing a particular part of the project– take a break to play your favorite video game, hang out with friends, go for a hike, whatever.

4. Consider past success: Reflect on the fact that you’ve accomplished difficult tasks in the past.  Remember the satisfaction you felt when you finally shipped those projects.  Use these feelings to reinforce your belief that you’ll be successful at the project you’re currently embarking on.

While I’ve come to know my own avoidance behaviors and learned to take steps to work around them, I don’t think I’ll ever be entirely free of them.  I think it’s just a natural human risk aversion response.  However, I also recognize that one has to take risks to accomplish great things.  I have a quote from the explorer Magellan on the wall in my office and I look at it often:

Unlike the mediocre, the intrepid spirits seek victory over those things that seem impossible… They embark on the most daring of all endeavors… to meet the shadowy future without fear and conquer the unknown.