Showing posts with label consulting. Show all posts
Showing posts with label consulting. Show all posts

Friday, November 30, 2007

Hazardous Attitudes: Disregarding VC Due Diligence

The FAA identifies five "hazardous attitudes" that have proven so dangerous to pilot decision making over the years that they are explained in the FAA "Pilot's Handbook of Aeronautical Knowledge" and included by reference in exams and regulations. These attitudes are Anti-authority ("Don't tell me."), Impulsivity ("Do it quickly."), Invulnerability ("It won't happen to me."), Macho ("I can do it."), and Resignation ("What's the use?").

Working with startups, I've seen entrepreneurs exhibit all of those attitudes when trying to convince others (and themselves!) that they needn't worry about VC due diligence.

I would advise those entrepreneurs -- and any wannabe entrepreneurs -- to read Rick Segal's fabulous post on due diligence. In addition to giving advice, Rick explodes a commonly held notion that VC due diligence is just a formality and that, if you get to the d.d. stage with a VC, you're all set, you can just wait for the wire transfer to hit your bank account.

Due diligence is real -- Rick suggests that one or more of three deals he's currently looking at will not close because of problems at the due diligence stage. Read that sentence until you believe it. Then, before you tell yourself that it doesn't matter because you're going to bootstrap, you'll never need a VC or a corporate investor, go back and read the five hazardous attitudes again. If you think success means believing in Plan A so much that you don't bother preparing a Plan B, the odds are you'll be laughing about this failure some time down the line over a beer.

Now that we've got that out of the way...

A couple of Rick's points that deserve emphasis:

  • Financial Forecasts. Of course they'll be rosy. What's important are the assumptions. Where did you get your data? How hard did you try to get good data? Is the logic that ties the data together sound?
  • Business Thesis and Assumptions. "... [W]hat do I have to believe?  What do you believe?  And, of course, what are the assumptions behind those beliefs. ... You have to have the same story, metrics, thesis, etc, from day one." If you change your execution plan a few times, that's to be expected. If your fundamental beliefs about the space are changing faster than you can execute, you have little chance.

At some point between the kitchen table stage of your startup, and the time when you walk into a VC meeting, the following things will become relevant. Plan accordingly:

  • "Understandings" or "Gentlemens' Agreements" with investors or employees. Unusual terms can be changed or dealt with at VC time, but I wish I had a buck for every time a CEO told me these issues would just melt away because everyone would be so pleased at the prospect of making a big deal or closing a round.
  • Questionable expenditures. This can either be a few big items or systematic spending that adds up. Don't do it, and if you do, don't try to hide it or hand-wave. I've seen a VC identify a six-figure sum missing from the books, and still make the investment. The firm identified the issue and decided they would arrange the deal so as to handle it and get it under control. It wasn't a showstopper for the company, but it was the end of the line for the guy who tried to cover it up.
  • Team issues. Although Rick says that not every VC would talk to all the employees in a small company (he would), it's a good bet that your core exec team -- and probably everyone in your first 8 people -- will get a good grilling regardless of the VC. The team has to be a team, and you won't be able to fake it. This doesn't mean everyone needs to agree or be buddies, but they need to function properly as a group. If you don't have a team, the VC will figure this out, and your funding is unlikely.
  • Product. Ok, this should be obvious. You can spin the marketing claims ("a better way to manage your contacts" could be anything) but you can't fake the technical claims ("syncs up to 5,000 contacts to any device" is either true or it's not).
  • Customers. Although some VCs seem to be trying to get all the risk out of their portfolios by investing only in companies with a solid customer base, that is their problem, not your excuse to pretend you have customers that are fictional, occasional, or just plain unlikely.

If you still think this is all hypothetical, or won't affect you, then take another look at the five hazardous attitudes and ask yourself: are you really planning for success? just closing your eyes and hoping? or fooling around and enjoying the ride?

Sunday, November 11, 2007

Agile Clients Present Challenges for Fixed-Price Consulting Firms

As more companies adopt agile development techniques, their increased desire for flexibility is causing pain for fixed-time, fixed-price consulting partners who have not yet figured out how to make the new dynamic work.

Traditionally, there are two models for technology consulting: "Time and Materials" (T&M), where the consultant bills per unit time and is only minimally responsible for the overall timeline, and "Fixed-time, Fixed-price," where the consultant is responsible for proposing a combination of scope, budget, and timeline and then delivering it.

The problem is that the initial time and price estimation models are based on a particular deliverable target. And while it's traditionally been a consulting challenge to keep change under control during an engagement, now clients are being completely upfront and saying, "We are developing alongside you and we intend to make substantial changes to the target every month, as the project develops."

With agile methods, this is not a shocker. And the client is justified in believing that if their organization can deliver new features and make spec adjustments every few weeks, surely high-priced consultants should be able to keep up.

The good consultants can keep up. The problem is figuring out a way for them to get paid for it; otherwise they won't be able to do these kinds of projects for long. Without a model that specifically addresses the possibility that expensive goal changes may arise, the consultants are forced into (a) being less agile than the client, (b) eating the cost of the changes, or (c) asking for more money or time. None of these options are good ones for the consulting relationship.

A first step toward a solution is to change agile co-development from an externality to a core part of the service delivery model. An iteration length should be defined as part of the project work statement. So far so good. The tricky part is allowing the consultants to make time or price changes at the checkpoints between iterations. After all, wasn't this whole project sold as fixed-time, fixed-cost? Sounds like having one's cake and eating it too. The reality is that both parties need to allow these changes (the client needs to change the specs; the consultant needs to change the cost) in order for the process to work.

The problem on the client's end is that development methods like agile, even if they tie in to product development processes, are often more "micro" in the budgeting scheme than the department budget or consulting budget. That is, the client's finances are not as agile as their development.

On the consultant's end, if the engagement is renegotiated -- even at a micro level -- between iterations, the overhead of managing and selling the project goes through the roof. And of course it's always possible that agreement can't be easily reached to match a spec change with a cost change. In that case, the whole engagement can fall though adding massive risk to delivery and reputation all the way around.

While not a complete solution, a number of elements would be helpful

  • Guidelines that throttle the rate of change between iterations via specified metrics, so that both sides have some ability to predict cost
  • Escalation chains for approval based on the amount of money or time involved, so that small and large changes alike don't necessarily need to go to a VP Finance or the legal department every time
  • Emphasizing these agile mechanisms in the sales process, so that an agile consulting firm (which might potentially cost a little more) remains competitive with others (who might offer a lower price but not be able to speak to how they will deal with these issues).

At this time, technology consulting opportunities abound and make good sense for clients and service providers alike. But to succeed in the long term, fixed-cost consultants need to evolve their models a few steps to keep up.