1,825 Days

1,825 days ago, everything changed in America. The way we think about our place in the world, the way we look at other nations, even the way we look at ourselves – it’s all changed.

1,825 days seems like a long time, sure. But really, it’s just a cosmic eyeblink (if that).

1,825 days is far too soon to allow ourselves the luxury of forgetfulness.

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.

Do Your Clients Ever Make You Furious?

If so, I offer a free 10-day e-mail course that can help you resolve exactly the kind of conflict that’s outlined in the article above.  Paying late, not responding to emails, arguing about art direction…enough is enough.  Sign up for Conquering Client Conflict today and learn to make more money & get more respect by squashing these conflicts.

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

Today I’m just going to tackle one Consulting Question.

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 to get that scope creep paid for. 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 adults 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 with regard to scope creep once you let it happen. 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 you have 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 and scope creep is easy to illustrate. 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 I manage scope creep at Cogeian Systems:

  • 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 (obviously, in the case of scope creep, the estimate 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 — it can be a sign of opportunity for the client, and a chance to (ethically!) up-sell for you as a consultant. 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.

Do Your Clients Ever Make You Furious?

If so, I offer a free 10-day e-mail course that can help you resolve exactly the kind of conflict that’s outlined in the article above.  Paying late, not responding to emails, arguing about art direction…enough is enough.  Sign up for Conquering Client Conflict today and learn to make more money & get more respect by squashing these conflicts.

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.