2004.02/24 Consulting Crash Course
EXCERPTED FROM MESSAGE TO WILLIAM KISZKA
} I can't
} I'm gonna
} They want to
} They want *me* to
} I might...
}
}
}
} *pant*pant*
}
}
} Okay, so I'm in line for a contracting gig, where a company wants to redo
} their medical billing application. But they're cheap, and they're only
} hiring one person. Somebody I used to work with is married to the
} owner/operator of a consulting company, and if they get this contract,
} they're gonna give me the assignment.
Wheelah! This sounds like a fortuitous break into the contracting market.
} I HAVE NEVER DONE A FULL-FLEDGED APPLICATION FROM GROUND-UP BEFORE.
} Analyzing needs, taking inventory of existing hardware, projecting growth,
} creating specs, developing application (after deciding what
} languages/platforms are best fit), QA, implementation, post-install
} troubleshooting....
Well, you always remember your first. ;-)
} I feel like I'm over my head, but I keep remembering I never would have
} been able to beat Ray at ping pong unless I kept playing you over and over.
} You get better by breaking out of your comfort zone.
Indeedy. And the best way to learn something totally new is just to do it.
} But a lot is on the line here and I want to be prepared. Any tips?
} Recommended reading? Gotchas to avoid and things to do to impress?
} Applications that are especially useful?
Wowsers. That's a big set o' questions there. Lessee, perhaps the most
essential idea to have about contracting is the idea of a "deliverable".
It's very important to deliver features regularly to a client that clearly
improves their business, and to make sure that you underpromise and
overdeliver. Many times technologists (like programmers) try to solve
complex business problems with technology alone, say with a faster machine,
bigger database, more complex code, or slicker algorithms. However, what the
client wants is a solution (and now!), and usually doesn't care if only half
can be implemented readily in technology and the other half their staff would
have to manage. What they care is that something is delivered quickly that
makes their business easier. Always seek to find a way to give the client
what they need as simply and as quickly as possible, every day if you can.
Avoid long investment cycles where "we have to do X before we can do Y before
we can do Z which is what you want"; that's a warning sign that you are
implementing a poor solution.
Anyway, a good book that expounds upon this philosophy is Extreme Programming
(XP) Explained. For right now you can safely ignore most of the practices
they describe in the book (since they might be too distracting to implement
if you are battling your first experience with contracting at the same time).
However, two parts are immediately useful. First, they describe in depth the
importance of making small daily changes to give concrete deliverables.
Iterate workable solutions quickly; give the customer 10% of what they want
every day, instead of 100% in a week. You'll discover bugs quicker, get
better feedback, and be able to prune entire branches of the project that the
customer realizes they didn't even need because what you've given them is
good enough. Second, the XP book stresses the vital importance of daily
communication with your client. Listen to the client. Absolutely make sure
you understand what they need in addition to what they ask for. That way you
can suggest alternatives that might better fit what they want / be cheaper /
be easier for you to build and maintain. Ask lots of questions and try to
understand their business. Don't worry about seeming inexperienced: you can
always let the people know that they have their specialty and you have yours,
but you can't do yours unless they help you understand theirs. Most clients
are all too happy to talk about both their business and their needs. And
even brief daily communication gives the customer real time feedback on your
progress.
So, summing up the general approach, talk to the client, list all their
needs, come up with solutions for each, and then order them according to what
could be implemented fastest. Try to, every day, give them something they
need. Talk to them some more, and you will discover that they have uncovered
new needs. Find out where they fit on the features list; sometimes a small
feature will pre-empt the previous schedule because it gives immediate
utility to the customer. Do those, and keep doing those, and your customer
will love you. For the most part, work in that 80% zone all the time: make
features that are good enough to use, spend time making them bug free, and
then move on. Don't spend the extra time getting the 20% perfection until
such time as all other needed features are addressed first. Every so often
you'll get an experienced client that has been through the process before and
has already distilled their needs for you; most often it's an evolving
process as the project proceeds.
As for programs, the video game mentality is best. Ask the client if they
use any comparable programs, and then watch people use them. Once you've
understood what they want, see if you can find something close application-
wise and then fool around with it. Seeing what someone else has already done
(and already works) is much easier than coming up with something tabula
rasa. Even once one has a good feel for user interface, its always better to
look at something visually in front of you. Again, get client feedback.
Draw little pictures of what the thing might look like, or better yet, have
them doodle pictures with you. When people can see something, it sparks all
types of associations of how the thing will work, etc. There aren't any real
"consulting programs" that I'm aware of; I personally just issue invoices in
MS Word docs and keep track of my finances with Quicken.
Hmmm... on the topic of common pitfalls, the three biggies are scope creep,
cost overrun, and mismanaged expectations. Scope creep is when the client
really doesn't know what they want, they don't really define it properly, and
then they constantly change their requirements on you. Then they complain
that you never make any progress. The main ways to combat scope creep are:
coaching (help the client discover what they really need), limited definition
(focus on one feature at a time, make them small and definable, and then do
them before the customer changes their mind again), and one-text contracts
(an involved topic for another conversation). The second common pitfall is
cost overrun. That's when you say you can do something easily and
cheaply... and then it takes you twice as long and costs twice as much. The
main ways to combat cost overrun is: Scotty quoting (quote twice as much for
everything, and then deliver in half the time; it leaves you leeway when
things inevitably come up), not to exceed (quote features high, but promise
not to exceed them; suck up when you make a mistake and need to work extra on
something), and incentives (for time crucial things: have bonuses if you
complete by a certain time window). You will impress your client by
consistently underpromising and overdelivering (even if they don't initially
like the sound of it) than by even once overpromising and underdelivering.
The third big pitfall is mismanaged expectations. That's when, by
miscommunication or omission, one party thinks things will be done one way
and the other thinks it will be done a different way. Managing expectations
mainly revolves around coming to clear and explicit agreements about all
aspects of the project, and actively querying for concerns. You might to be
expect to be paid weekly but they might be expecting net 30. They might
expect a per hour work breakdown whereas you might be expecting to just bill
the total hours. You might be expecting to work on-site but they have no
computers available and expect you to bring a laptop. If you (or they) are
the formal type, then these sometimes get written into the contract; more
often they are simply verbal agreements that are made as you go along.
} This contract is by no means in the bag. First the dude has to decide if
} he's going forward with this or if he's just going to buy something
} pre-packaged; and then my friend's husband has to land the contract. But
} if the chips fall where I want them to, I'll be working in Boston by next
} month and I want to be ready.
Well, you might not be as wolf-thrown as you might feel right now. If your
friend's husband has been running the consulting company for awhile, then you
can follow his experienced lead / ask him in real time for specific advice.
Even if you are the only person working on the project, you can still draw
from your friends and peers for help.
} My non-specific style of work is kind of biting me in the butt. I'm no
} expert in any language, but I'm competent in at least a dozen. But for
} something like this, I feel it's better to know a language inside-out to
} properly take advantage of all tricks and efficiencies. Unless it turns
} out to be a web-application which is usually a mish-mash of several
} environments, which I might be better suited for.
Ahhh... perhaps you have more desirable qualities than you might think,
Bill. What if a good consultant was an advisor first, businessman second,
and technologist last? You get along with people, listen and understand
them, and are genuinely interested in helping. That makes for a mighty good
advisor: someone who will make recommendations on what's best for the
client. You've got enough work and programming experience to make you a fair
businessman and technologist. If you focus on what you have and how you can
use it effectively, you might feel more confident. Heck, you may even be
more effective. ;-)
Anyway, most of the time the client cares more about functionality first and
then speed second. Meaning, they care that what you implement is clearly
better than what they already have first, and then they want to make it as
efficient as possible second. So, that gives you enough time in the interim
to figure out ways to make things faster / get yourself up to speed on
performance improvements. I can absolutely guarantee you that the client
doesn't care jack about getting 3% more efficiency from the perl hashing
function on Solaris vs. Linux, so don't worry if you don't know about it
yourself. We are trained as technologists to think that these are crucial
for us to know, but in actual practice they rarely are even relevant. Most
often things like people skills (building relationships on trust and
understanding), professional attitude (responsiveness and work ethic), and
communication (being able to listen attentively, present comfortably, and
refine consistently) are the hallmarks of the successful consultant.
You are ready, my friend. Seize the day! ;-)
} I don't have many details, but I get the impression that aside from
} web-app/non-web-app, and general look-and-feel, I can make whatever
} decisions I deem necessary. As long as it looks and performs how they
} expect, they don't care what's inside.
Exactly! So use whatever looks like it would be the easiest / stablest /
cheapest to do. In that case, your jack-of-all-trades background might be an
asset in helping the customer find the best tool for the job.
You might be intrigued to know that scripting languages are becoming more
popular even as compilers are becoming more sophisticated. What? Aren't
scripting languages slower, less precise, and more prone to error? Indeedy.
But then they are also faster to get features up and running in, easier to
deploy, and good enough for most applications. Meet the need reliably, and
quite often no one will care about the technology.
} Your thoughts? Any mistakes or horror stories I can learn from?
Well, mainly I'm excited for you. This was something you mentioned that you
wanted to do after you got some more experience. Well, you got some more
experience since then, and this looks like a good opportunity. Woohoo! ;-)
Also, I think it's highly commendable that you want to make sure that you do
the best job that you can. You may want to let go of some of the anxiety,
though, since ultimately it is a draining distraction. In the worst case
scenario, you make some mistakes and learn from them for the next time. You
know, falling off a bike a few times doesn't prevent us from learning how to
ride well. Heh, heh, heh, in some ways making the mistakes is a more assured
path to proficiency. I rarely if ever write memory leaking code nowadays...
because I have already made the twelve most common errors... many times! :-)
Anyway, I have confidence that you'll do fine; you are already starting off
on the right foot by seeking advice.
Good luck! Let me know if there's anything else I can help with.
} Thanks dude. I gotta go throw up now.
De nada.
_____________________________________________________________________________
KIM E LUMBARD Web Page = http://KimLumbard.com/
21502 Camino Trebol E-Mail = [Deleted due to spambots]
Lake Forest, CA 92630 Mobile = +1 (626) 429-4492
or MANIC ZIGZAG
Teasle: What obsessed God in heaven to make a man like Rambo?
Trautman: God didn't make Rambo, I made him!
-- First Blood (1982)