Monthly Archives: August 2006

So You Want To Be A Software Consultant?

So you want to be a software consultant, eh? I hear “how do I get into the business” questions a lot. I suppose I could save this for my next Monday Consulting Questions article, but I think I’d like to finish the month with a bang. So, let’s talk about it today.

There are several things I think you need in order to launch and have some assurance of success. Note that this list is by no means conclusive, it only represents the things that occurred to me in the shower this morning.

Experience. Ideally, you’ve been developing software professionally for at least 5 years, with steadily increasing responsibilities. You want 5 actual years of experience and growth, not 1 year of experience repeated 5 times over. But wait, there’s more. Hopefully you’ve also been able to spend about a year as a Team Lead or in some other position that lets you work at a slightly higher level, learning to manage people and allocate workloads. It would be super super ideal if you managed to get some project management experience too. In fact, I’ll go so far as to say that when launching a software consulting business, being a good project manager will be at least as important as being a good coder. If you don’t have any project management skills, be prepared to learn some.

Humility. Just because you’ve been a dev for 5+ years does NOT mean that you know it all. Preferably you’ve made some serious blunders, learned from them, and done better the next time a similar situation presented itself. If you’ve never fallen on your face, odds are you haven’t attempted anything worth a damn.

Wisdom. Read these: Peopleware; The Mythical Man Month; Code Complete; Under Pressure and On Time Project Planning, Scheduling and Control; Slack; The Art of the Start; Book Yourself Solid; Million Dollar Consulting; Influence; The Time Trap; The E-Myth. Don’t argue, just read them. Read them all. Then read them all again. You don’t have to agree with them or even do what they tell you to do. But you do need to read them.

Contacts. When I say contacts, I’m talking not just about people you know, I’m talking about people you know who can be of help to you in launching your firm. People who can hire you for project work. People who can introduce you to other people who can hire you for project work. People who like you. People who want to see you succeed. People who will benefit if you succeed.

Clients. I can hear you already: “Well, DUH, Christopher.” But bear in mind that when I say you need clients, I’m saying that you need clients BEFORE you launch your firm. Don’t form a corporation, rent an office, buy computers with fancy 20" dual LCDs, hire a staff of 5, and then try to find clients. Oh no. Get yourself a few projects first, THEN launch. Deposits for several projects can make for decent start-up money. Work your network of contacts to find your first clients before launching your business.

Money. I’ve heard it said that professional services (like software consulting) are the easiest type of business to bootstrap. This may or may not be true. There’s another saying, though, one that I particularly like: always be prepared. Try to have as much of a financial cushion as possible before you launch.

A Team. Now, this is going to be controversial, since there are plenty of successful one-man operators. In fact, I used to be one, and even argued with Joel Spolsky about it. But the fact of the matter is, the sooner you are able to start delegating work, the sooner you can spend time working ON your business instead of working IN your business (kudos to The E-Myth for that saying). Working ON your business means you are building a system for doing business that will work even if you’re not actually billing. Basically, having a team means that you don’t have to do ALL the billable work. Starting out you will likely not be able to hire employees full time. Find some trustworthy subcontractors (former co-workers seem to work best) to begin with and make actual hires once you’ve fattened up.

Nerves of Steel. Launching a business of any kind is tough. When you’re just starting out, you can’t just code. You need to do your own books, you need to sell, you need to write the proposals, take out the garbage, negotiate the lease on your office, pay the bills, serve as technical support, beg your creditors for extra time to pay bills, and oh yeah, you might even write a little code from time to time. Clients will abuse you, they will slow-pay you, they will change their minds twice daily about what it is they really want you to be building. Cash flow will ebb and flow sharply sometimes. You may experience the rush of feeling like you hit the lottery one month, then the despair of feeling near bankruptcy the next. Of course, all of this can be managed, but you probably won’t know how at first. If uncertainty is emotionally difficult for you to deal with, re-think launching a firm.

I’m sure there is more to launching a software consulting firm than what I’ve laid out here. In fact, I know there is. However, I’m not going to be able to think of it all in one sitting; it’s a strange and varied universe we live in, and there are plenty of things that can make your consulting experience very unique.

If you would like to suggest additional requisites that belong on this list, go ahead and leave a comment.

Overtime Means Late Projects and High Blood Pressure

I don’t think it’s any secret that working a lot of overtime means you probably have a lot of late projects bearing down on you. Who needs that? Well, it turns out that working overtime has another downside, one that’s a hell of a lot worse than slipping your release date; working overtime leads to high blood pressure.

It seems that the study determined that working more than 51 hours per week means you are 29 percent more likely to have high blood pressure, compared to someone who works 39 hours or less. Here’s an interesting snippet:

Interest in the topic began in Japan, they add, where a notoriously high-pressure work culture has given rise to a phenomenon known as Karoshi, or "sudden death from overwork." Today, Americans work longer hours than do Japanese, the researchers add.

Sudden. Death. From. Overwork. Holy cow.

There’s no way anyone is seriously going to be surprised by this, but at the very least we now have a study to point to that proves what we all know intuitively. I wonder if insurance companies are going to raise the medical premiums on companies that routinely send their employees on death marches? If the desire to keep insurance costs down won’t encourage companies to adopt more sensible project management practices, nothing will.

Of course, there’s a sick glimmer of hope for bad managers to use to justify continuing the death march methodology:

The researchers also found that hypertension was more common among clerical and unskilled workers than among professionals. This "suggests that occupations requiring more challenging and mentally active work may have a protective effect against hypertension," Yang and his colleagues write.

I can just hear the idiot boss now: “You’re a skilled worker, a professional! You do knowledge work! 100 hours a week won’t hurt ya!”

Don’t let your company work you to death.

Monday Consulting Questions: Scope Creep and Getting Paid

After a 2-week break, here we are again with Monday Consulting Questions. Today I’m just going to tackle one.

Q. I need to negotiate payment on a project that went out of scope. How do I do this?
A. Trying to get paid for out-of-scope work after it’s been done can often be like trying to un-ring a bell. Depending upon the circumstances, it may not even be possible. So, let’s look at the circumstances.

The first thing to think about is, how do we know this project went out of scope? Do we have a measurable way to determine what features comprise the project’s scope, like a functional spec? If not, you have a real problem, because without some record of what the project’s expectations were at the start, anyone can interpret anything however they want. To be honest with you, if you don’t have anything to prove that the project is out of scope, you’re sunk. Start negotiating and be happy to get whatever you can get.

Now, if you do have a scope document, you’re on more solid ground. However, you’re not out of the woods just yet. Did you set the client’s expectations correctly? That is, did you either a) notify the client at the outset that additional features would increase the cost or b) notify the client at the time of the change request that the change would increase the cost? Yes, I know your client is staffed by adult and that adults have no excuse for thinking that more work costs nothing extra, but to be perfectly honest, nobody cares about you or whether or not you are treated fairly. It’s sad but true. You get what you negotiate. Nobody will be fair with you; you have to defend yourself at all times. So, if your client can throw up the "but you didn’t TELL me this would cost extra" defense, you’re in a tough position. At best, you can point to the scope doc and offer to remove the additional features if they don’t want to pay for more then the original scope. But in all honesty, the moment a client plays the "but you didn’t tell me" card, you’re sunk.

The third scenario – the one that puts you in the best position – is that you have both a scope document and that you communicated effectively with the client. The scope documentation proves what you were setting out to build, which means that anything not in that document doesn’t exist. So, changes are easy to identify. The communication ensures that at the very start of the project OR at the moment a change request came in, the client was informed that yes, when you request more work, you have to actually PAY for it. This is a one-two combo that even the most dishonest of clients will have a hard time applying twisted "you should work for free" logic to.

Here’s how we manage scope around here:

  • Every project has a scoping phase, even if it is lightweight. We believe that figuring out what you are building is a normal part of any project. Any client that refuses this and tries to order you to "just get started" is a client we don’t want. Experience has taught me that ambiguity is frequently an ingredient in abusive client behavior.
  • Clients are informed before the project even begins that changes to the project plan WILL result in a revised estimate. Sometimes, the revision means that the estimate goes down. Sometimes, the revision means it goes up. The determining factor is whether we are adding features (which is usually the case) or consolidating/eliminating features.
  • Clients are also informed that some degree of scope creep is normal, because nobody can know in perfect detail what a project will consist of. There are unknowns in everything, and software development is no exception.

I don’t necessarily think that scope creep must be avoided. It CAN be avoided, but I don’t think it MUST be in every case; sometimes scope creep is a good thing for a project. However, there is no question that scope creep must be managed. The client must have an opportunity to think about the consequences of change in terms of additional cost, longer delivery time, additional complexity, etc. And the developer must be paid for the work provided.

So, the short answer is, you get paid for out-of-scope projects by defining a change process before the work ever begins. Barring that, it’s up to you and your negotiation skills. Try to do better next time.

Monday Consulting Questions: Nuts and Bolts

Q. How did you launch your business?
A. Out of necessity! The company I was working for blindsided about half of the workforce with layoffs. This was in early 2003. I had just closed on my first home 2 weeks before the layoff. Nobody but nobody was hiring devs or PMs at that time. Since I had been straddling the fence between dev and PM work for years, I thought that the dual skillset would help me find work, but no.

Everyone was telling me to sell the house right away (it had appreciated about $50,000 before I even moved in! Only in California), take the profit, live on it, and accept the very first job offer I got, no matter how bad it was, because then at least I’d have a job and an income.

This seemed like very bad advice. I decided that I would do the exact opposite of what everyone was telling me to do – I proceeded to stubbornly hold on to my house and turn down job offers right and left.

$42,000 for a Project Manager job where I’d be responsible for a staff of 5, but spending 6 to 8 months of the year on the road? No way. $44,000 for a “Development Manager” position where in actuality I was the only dev and a 48-hour workweek was a requirement? No thanks. There was a glut of technical talent on the market and nobody seemed to have any interest in doing anything but taking advantage of us in any way they could, demanding tremendous workloads and offering peanuts for pay.

I stayed calm, never lost belief in my own worth, and slowly started making contacts around the area. Eventually, I got a tiny bit of contract work here and there. Some of it was dev work and some of it was PM work, but that was it – I decided to drop the job search and focus on custom dev. As more projects came in, I began to bring on other devs so I could focus on being the PM and on keeping the business coming in.

There were a few times during 2003 and 2004 where I considered giving up, but for some reason I just kept plugging away. Now things are peachy.

Bear in mind that I had always planned on going into business for myself eventually. However, I had expected that I’d be able to plan it out once I was ready to make the leap. Having to go into business as a defense against the consequences of a layoff was not what I had in mind, but I’ve managed to make it work.

Q. What would you do if a customer stole a site or an application?
A. You know, this actually happened to a colleague of mine. His client simply copied all the HTML and saved all the images off of the test server and put it all up on their hosting account. Then they proceeded to act as though they’d never even heard of my colleague, let alone hired him to design a site for them. Free website, right? Wrong. To be perfectly blunt, signed contracts talk and bullshit walks. He ended up having his attorney send a nastygram to the client, and another to the web host, who took the site down as soon as they were notified that they were hosting stolen IP.

The client eventually paid for the site, cursing my colleague all the way. Score one for the good guys.

To avoid this sort of thing, I structure my projects so that a customer rarely has a final release before they have paid for it. The exceptions are situations where the work is ongoing and the project is never truly finished, or when we take on a remediation job. But even then we tie payments to milestones, whether time-based or feature-based.

On web projects, I do not allow ftp access to the project directory and I do not install to the client’s environment. Not until it’s all done, of course.

So to answer the question of what I would do, I say this: I’d have done the same thing as my colleague did, but I’m not sure I could have resisted publicly shaming the thief.

Q. The sales guy keeps committing to totally unrealistic time frames without consulting anyone from dev first, and the top boss backs him up every time because “he pays all of our salaries by making these deals”. This place is out of control. What can I do?
A. This isn’t really a consulting question, but it is a question that I hear a lot. I, too, remember working as a software dev in an organization that would allow salesmen to give estimates and promise completion dates, and allowed PMs to shave developer’s estimates in order to make them more politically palatable. So here’s what you can do about it if you are a developer in this kind of organization:

Nothing. Absolutely nothing. Unless you are in this salesman’s chain of command (and it sounds like you are not), there is literally nothing you can do to change the culture. Culture changes have to be reinforced from the top and this one clearly isn’t going to change. If top management doesn’t see anything wrong with letting a salesman quote delivery dates or dollar estimates BEFORE finding out what the feature set is and what the development estimates are, then that’s the way it’s going to stay. I agree that the sales force keeps the dollars flowing and that as such, they do need certain kinds of leeway, committing to x feature set for y dollars without consulting anyone from the technical side of the business is just stupid and is not the kind of leeway they need to have. Don’t work stupid places. Find a new job.

Suspicious of the “One-Stop” Tech Shop

I don’t know if this is just a small-town phenomenon, but I notice a fair number of “one-stop” tech businesses popping up in Central Cali. You might know the kind of place I’m talking about. They do custom computers. AND they sell games. AND they do tech support. AND they do PC repair. AND they do network admin. AND they do web design. AND they do web hosting. AND they do custom software. AND they’re an ISP. Etcetera.

The question I have is, is it even possible for this kind of place to do all of those things well?

See, I have this gut feeling that in order for a company to do something really well, the whole company needs to be optimized for it. I am inclined to trust companies with a clear focus on one discipline. Certainly, some disciplines have enough overlap that it makes sense to offer both services (network support and web hosting, perhaps), but in general a lot of this stuff isn’t even in the same field.

If you do networking, great, do networking. But don’t try to say you’re in the web design business just because you hired one web guy and gave him a desk in the back room next to the big basket of server parts. If you do custom software, great. But don’t try to suddenly say you’re in the custom hardware business just because you hired one PC tech and gave him a little workbench in the storage room. I mean, you can, but people like me will really wonder about you.

Once you have a working business that deals in one discipline, you can’t simply add a completely different discipline to your menu of services and expect to provide a high level of expertise. Being successful in a given discipline requires that you have the infrastructure and culture appropriate to do so.

And don’t tell me you are a “full service computer business”. Computer business? It’s 2006. Saying you’re in the “computer” business is like saying you’re in “industry” in the 1800s – it’s so broad as to be meaningless.

Is it just me? Is my inherent distrust of one-stops irrational? I mean, they must be getting customers or they’d not be in business for very long. Is this just another case of “the client can’t tell good from bad unless it breaks in spectacular fashion”? Or is my own view that no one small company can possibly do 5 different computer-related disciplines well just a misinformed prejudice on my part?

Monday Consulting Questions: Getting Personal

I got a decent response to the first Consulting Q & A last Monday, so here we go with round 2.

Q. You are an overly-opinionated blowhard who writes things that are obvious.
A. That’s not a question, but OK. I AM highly opinionated. Whether or not I am a blowhard depends upon whether or not you agree with the aforementioned opinions. I’ve said on multiple occasions that I don’t write about anything we don’t – as a profession – know; I write about things we don’t – as a profession - do. It pains me to see the profession suffer because people can’t muster the discipline to do the things we know will make the profession better, and most of my writing is driven by that pain.

Q. Why haven’t you launched a product yet?
A. Well, it’s not for lack of desire. In truth, my original plan was to do consulting in order to get a revenue to pay for steering Cogeian Systems toward product development. But the reality is that the custom side of the business has grown so much, it’s all I can do to just manage the projects and keep everyone busy performing the work. I’m still learning to manage multiple projects at one time and I write code sometimes, although I’m trying to get away from that. It’s all been terribly disruptive to my original plan and although the revenue is excellent, at a certain point I’m simply going to have to put my foot down and accept less consulting revenue in order to free up the time and manpower to do a product. I guess the basic problem is that I just can’t turn down money.

Q. How do you handle maintenance contracts for custom work?
A. We don’t. In a software or web shop, projects tend to fall into two categories:

  1. Build something new.
  2. Fix something that is broken.

For projects of type 1, a lot of my colleagues suggest that I should set up a maintenance contract to ensure x amount of recurring revenue per month. The price of the contract varies; usually it amounts to 20% of the project cost, per year. But I don’t do this. I may be leaving money on the table, but it occurs to me that I only want to bill for work that my company does. So the official line is, Cogeian Systems performs maintenance on an hourly basis. That’s it; boring old time-and-materials billing.

For projects of type 2 – which we get a lot of because we specialize to some degree in fixing broken apps – the fundamental issues are more complicated because the code base ends up being a mishmash of old, under-performing code and newer, better-performing code. But ultimately, I decided to again stick with T&M billing. If it’s broken, we will fix it. If it is working, good for you, Mr. Client – I hope you keep it running long enough to earn a return on your investment. But I’m not going to charge you a monthly fee on the off chance that it’s going to break and you might need me. Just call when it breaks and we’ll fix it. Simple.