In December, our consulting contributors discussed what makes a good client and what type of client sends them screaming into the night!
One of the biggest factors was communications. A client who understands what the consultant is asking for and is able to explain what they need, is a client you want to keep. Some of the consultants talked about how planning is the key. It's so true. But as was mentioned, planning is not just related to the client, but also to the consultant's business and their own schedule. Some clients think that if you say a project will take 10 hours that you will be working away for 10 hrs straight on only that one project, so you'll, obviously, have the project to them tomorrow, right?
Think about your own office environment. When was the last time you had 10 hrs of uninterrupted time that you could devote to just one project? Granted, if you're a successful consultant, you must be much better at time management than the average employee. As you're flipping those many hats on and off...you're working through dozens of different types of work in one week. Accounting, marketing, tech support, sales, project planning, project development, coding, client management and tons and tons of email.
A big reason why a company will hire a consultant is not just because they can do a project faster than most people they have already employed...or because all those who can do the same job are already busy with other projects...but because they are an expert at what they do.
But any project means that all the players must do their part in order to be successful. If a consultant has planned out their week and know they will be handling a few clients within that week, they know that they will work on Project A and pass it to the client for review. In that time, they will either handle their own business work or work on Project B. By the time Project A's client returns with feedback, the other work should be done or on its way to Project B's client for review. But when clients don't keep their end of the bargain by compiling the proper information and returning it to the consultant in time, that can cause ripples all the way through the week.
Also, since consultants live from project to project, if Project A is nearly done and Project B's client is delaying the work, the consultant must get busy finding Client C. Even with the best project planning, when all parties aren't keeping to proposed schedules, it can become a matter of first-come, first-serve.
And don't forget those unexpected events that can mess up the best planning. As I write this, I've spent about four unplanned hours digging our house out of the mountain of snow that suddenly dropped on us. Sure, the weather guy told me to prepare for it yesterday. But where was he Saturday when I was planning my week?
So if you plan to hire a consultant, try to have a good idea of what you want to do. Granted, you don't have to have all the answers, since that is part of what you are hiring a consultant for...to consult and give you their experienced advice. But when it's time to discuss specific plans or provide valuable feedback, don't brush it off as not being important, because this type of information is vital to the person building your solution and when they ask you to review the work so far...they're expecting you to do just that.
This month we asked these consultants to look back and tell us about things that they wished they'd done better, as well as what things they've done that caused them to jump up and give themselves a high-five. Anyone who is starting out doing something new will learn as they go forward. Mistakes will be made and processes improved upon. Some are minor...some are major. Anyone in business will have lots of "I remember the time..." stories of wins and...well, of those moments that they'd rather forget.
Q: Tell us something you've done that you wished you did better. Describe a mistake you've made.
Throwing a design "over the wall". That is, after gathering
requirements and designing a solution, due to time constraints, I have
sent the design documentation to the customer for review, without
scheduling time in person to walk through it. This is a very bad
idea! It is really important to remember that most customers don't
possess a innate understanding of design documentation--I have to
remind myself how long it took me to develop this understanding
myself! It is imperative to walk people through it so they
understand: the purpose of the document, the layout of the document,
and then the specific techniques (site maps, diagrams, user scenarios)
that are employed in the document, and what they are striving to
communicate. Otherwise, there will inevitably be a misunderstanding
or lack of understanding of what you're trying to build, which causes
confusion and mistrust.
One of the biggest mistakes I ever made as a consultant was to skip the step of creating a contract for a new client because 1) I thought the client was trustworthy, and 2) the job seemed too small to bother creating a contract for it. Boy was I wrong! The client turned out to be a demanding, confused, bossy, and unpleasant person AND the job kept changing and growing every step of the way. When I kindly explained to the client that the scope of work had changed and as such I should receive more money for the project, the client flipped out and called ME unprofessional. A contract would have saved me from this situation. Contracts not only clearly define the work to be done, but they protect both parties and help keep projects on track while promoting feelings of competence and respect. At that point I realized that there would be no pleasing this person no matter what I did, so I quit that project and in good faith gave the client 8 hours of my work at no charge. Since then, so that both myself and the client are clear about what will be done for the fee being charged—no matter how small the project is—before any work is done, I write a contract clearly outlining the scope of work.
Every once in a (long) while, I'll take on a project that requires a technology in which I don't have strong experience. This can be difficult mostly for me because it creates too much stress for me. It usually doesn't affect the client because I'll do my best to insulate them from my learning curve. There was one time however when there was a tight deadline and even though I told the client that I thought we didn't have enough time to complete the project, he wanted to push ahead on schedule anyway, and I went along with it against my better judgment, and it did end up being a bit of a fiasco.
Not Eating my own dog food. (See successes below for details.)
For me I would have to say the biggest "mistake" I made in my consulting business is actually a business mistake. With clients and projects you usually know what you are dealing with or at least how to deal with them. When it comes to the business side of things many of us are way out of our element. Simple mistakes early on, like setting hourly rates, not specifying deposits, agreeing to work on flat fees, not advertising properly and well, you get the idea. Most of these are things that a business major could tell you but most of the independent consultants in the tech world seem to lack this, myself included. If I could go back, that's where I would start. I'd get the business knowledge before I ever took on a first customer.
I don't know if this fits in this series, but this is the only really bad failure I have. A few years ago I was asked to get involved in a partnership with another consultant who I worked with while at a big company. The idea looked very promising, particularly because I'd been involved in project work with this person and knew him for a few years. After two years of success and making good money, my partner suddenly started to cheat me and take over the company. This was very disheartening and frustrating. Be aware that, although a partnership can be a good business decision, it can also bring on a lot of trouble.
This isn't so much a failure as it was a huge mistake that I had made in the starting of the company. When I started the company I put a lot of focus on building the company's image, documentation, marketing material, website, and plan of action. I did this for a few months building a great website with a full private section for clients to check on the status of projects, a messaging system, and online quote management system. I created all the legal documents for the company: terms of service, non-disclosure, non-compete form, and anything else I thought I may need. What I failed to focus on was the most important thing about a startup business - capital. I should have focused on building my client list and started generating capital for the company. So take it from me and get clients. A company isn't a company without clients.
As consultants, even during a recession, we all still have to figure out how to pay the bills. Some businesses weathered the bad economy of the last couple of years better than others. Like most businesses in the computer industry, the recent recession is something I'd rather forget. But I think I've learned from the mistakes I made. First, even though you may love working for just a few particularly great clients, you absolutely must diversify. Putting "all your eggs in one basket" makes it almost impossible to recover, if one of those major clients goes away. Secondly, watch your cash flow and save money aside for a rainy day. Nothing substitutes for having a cash "buffer" when things go poorly.
My biggest screw up came early in my consulting career. My first full-time consulting job had evaporated after less than a year due to the disintegration of the company. I flew to San Francisco for an interview with the owner of another consulting shop. He hired me on the spot and said, "Oh by the way; we're heading for a meeting with your first client right now."
We ended up in the conference room of a big financial services company where he gave a quote on their project and they accepted. I wasn't provided with any documentation of specifications, but I assumed there must have been something in order for this guy to pop off a quote, so I didn't ask about it. Big mistake. As we were driving back to the airport I learned there was no formal documentation at all and the quote was a seat-of-the-pants estimate based on that meeting and a couple of phone calls.
I had virtually no idea what the client wanted exactly, so I started creating user interface mock-ups that could be navigated well enough to discuss the application but had absolutely nothing behind them. After working through three iterations of these it became obvious that the job had been drastically under-bid.
I worked as fast as I could, cut as many corners as I could and even did a lot of work off the clock. Still, by the time I'd billed the full amount of the original estimate the project was maybe half complete. The client decided to cut their losses and pull the plug.
The moral of this story is to never quote a job, never mind start working on it, until you have a detailed description of what you are supposed to deliver.
Q: Tell us something you've done quite well. Describe something you did that made you excited because you knew you did a good job...as a consultant, you were right on track.
For the first few years of my career I avoided database work like the plague. I was a committed Excel geek and relational databases just didn't make sense to me. Then one day the hammer fell. The lead consultant at the company I was working for left to take another job, so the projects he was working on got parceled out among the rest of us. All of his projects had a significant database component, and the one that landed on me was a big SQL Server application that he'd just gotten started.
I knew absolutely nothing about SQL Servers. I had trouble just getting it installed correctly on my computer. I got two weeks of heavy tutorial before the guy left and then I was on my own. Luckily the database design, which was the part of the project that absolutely couldn't be faked by a beginner, had already been completed. But I still needed to figure out how to write the SQL and code to make an application out of it. For the next six months I spent five or six hours a day working on the project and another five or six hours a day studying SQL Server and ADO books. By the end of the project, not only was I actually enjoying working with SQL Server, but I'd learned enough to pass both SQL Server MCP exams on the first try.
This turned out to have been one of the best things that ever happened to me. If I hadn't been forced into it I have no idea how long I would have remained willfully ignorant of database programming. This would have been a very bad thing, because most of the best projects I've had since then have required a significant amount of database work. And in general, the experience taught me that I couldn't remain stuck in my little Excel silo if I wanted to be a top-notch programmer. Since then I've tried to set aside an hour or two every day that I devote to learning some new technology.
I have learned over time that there is no absolutely correct way to
document requirements and design. I have learned a variety of
techniques and try to tailor the communication to match the needs of
the project and the customer. Different customers have different
thresholds of understanding, different levels of interest, and
different amounts of time to apply to reviewing specifications, so it
is key to marry that with the deliverable you give the client. Don't
give the customer a 100-page design specification if they will never
read it. If you want their buy-in, give them an executive summary
with supporting documentation. Don't write wordy use cases if your
developer would be more responsive to a flow diagram. Be flexible in
how you are willing to convey the information.
I sat and thought about this one for a while when I realized that this moment, for me at least, never really happened. I mean I'm confident in my abilities and always have been so that's not the issue but when it comes to the success of the business itself, I'm not sure any of us ever really "know" that we've made it. We have our moments of glory when we succeed in releasing a tough project or when we get inquiries that say "I really loved your work and would like you to do (x) for us." but these are moments of success. The consulting world is a fickle one and like show business you are only as good as your last job. Oh sure, the royalties from a good success can keep ya rolling along for a while but if you don't keep climbing the pile will pass ya by and you'll find you're no longer king of the mountain.
One of my biggest successes was to start my own greeting card line. As a child, all I ever wanted to do was to be an artist and be paid for it, and I even day dreamed of having my own greeting card company. Along the way of growing up, however, I got brainwashed into thinking that artists were crazy and poor; and that, if security was more important to me, then I should do something else to pay the bills. That worked for about 7 years after college until finally I realized I was dying on the inside and had to say “f-it!” and give art a chance.
I really enjoy completing a product that performs a useful function. I like seeing the end result in action and knowing how many peoples' lives it's affecting. I love making my client happy. I love that moment when the product comes alive, like Frankenstein's Monster, that moment when the computer program starts functioning and is no longer just an idea but is now a reality. I enjoy teaching my clients new things about their computers.
I have created some extremely complex systems that manage massive machinery. That was very rewarding. I have also created systems that have either saved my clients a lot of money or helped them collect a lot of money. It's great to know that systems I've created caused these effects.
Realizing that when I set my mind to it, I can figure out how to do most things. For example, even though I worked in publishing for years, when I started my magazine, I didn't know much about the advertising side of things. But I learned to sell advertising and even make cold calls. It was hard for me to "get out of the bubble" and contact all those people, but I did. Along the same lines, more recently, I've also learned that I can do public speaking if I have to. For me, speaking in front of a crowd is the stuff nightmares are made of. But I've now taught classes and done presentations in front of large groups of business people. Who would have thought it?!
I can't remember some of the biggest success. But what I mostly like is to solve tricky things in programming. So when somebody, who knows this, comes to me as his last hope to see if his problem can be solved, and we find a good solution - this makes me feel great.
One of my big high-five moments was when I realized I should be eating my own dog food. No, I'm not making this up because I'm a dog person. I actually first learned this term from Microsoft many years ago. Microsoft "eats their own dog food," i.e., uses their own software. Here I was, a consultant telling business owners that they can save money and time by developing their documentation with automation to make those big tasks much easier...and I'm over here cutting and pasting all night long to recreate custom project proposals! Can you say "Duh!"?
Sure, I knew that it would save me time and effort (time/effort = money), but I didn't want to take the time to do this for myself. I had to realize I was a client, too...a client to myself. So it was time to spend some time designing automation to tackle my own paperwork and documentation. After I did...I felt great. Not only did I feel like I was getting it together, but this took a lot of stress off me to get it all done because I could now much more easily create custom, professional documents in a very short time.
The success that I feel comes every time a customer accepts a proposal and the project is completed within the time frame. Although this sounds pretty basic it trickier than one would think. I work within the time frame that my client wants no matter how short. As a consultant you don't want to turn down any job and even if the time frame is ridiculously short and there is nothing you can do to extend it, you just work with it. This is when you know you can handle being a consultant when you are up at 3:00am working on a project that your client needs (not just wants) right away. This is one thing that gives me the best feeling to deliver a website to a client in 3 days because they are having a big launch and ran into issues with their other developer and I worked through the night to get it done.