PHP Developers Network

I was speaking to a graphic designer this morning and mentioned that i want to start doing consulting for clients. I have a general idea on what consulting is but what are the finer points involved in doing consulting about web-development. Does anyone have any experience in this field that they can share? How should I expand my current skill-set (which is focused on development of web based systems) to fit into a consulting job?

_________________
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering

Probably others can give you more specific advice than I can, and I've been retired from active consulting for more than a decade, but I would offer for your consideration some broad concepts that I think are important.

Equally as important as your skill set is your ability to understand a client's business needs. That's the difference between a contract "hired gun" programmer or designer and a consultant. To earn a consultant's compensation, you will be expected to advise a client, whether that means agreeing or disagreeing with what he or she thinks they want. My guess is that about half the clients who seek a consultant's help are either confused or dead wrong about what they think is required, or even if they are attacking the right problem. You can't be expected to know in advance all the factors for every kind of business, but you have to have some business background and be good at asking questions that go beyond just "how do you want the report to look?" A successful consultant is one who is able to study a business operation and identify those factors that affect costs of operation or revenue flow. Only then can the consultant ask the right questions and either develop a suitable web project or challenge the client's ideas and propose a different solution that will result in more profits for the client. It is this potential that makes a professional consultant valuable and able to charge a whole lot more for their services.

To continue on califdon's points. It also helps if you can quickly conceptualize their business and ways to improve the efficiency of their day to day operations. Often I've gone into situations and saw a lot of redundant time wasting tasks between groups that could be integrated and automated freeing people up from paperwork or tedious activities while improving accuracy and quality. Many business people are too close to their operations to see many of things they are doing are unproductive. At times they can also be defensive about changing them. A good consultant should be able to offer a range of services (hardware, software, support, documentation, training, etc.) and work closely with them to make sure they feel you'll meet all their needs. And if you can bring new ideas to the table to make their business better then you're very likely to get their attention and the job. However you also don't want to come across as some know-it-all who thinks they know how to do their job, because you don't and can't, so listen very closely and broach new ideas slowly and carefully. It can help to present ideas in a question format so they feel involved in the development of the idea ("Is this something you would like to see automated/integrated/networked/tracked/etc...? " blah blah blah).

Even if it turns out they find reasons why your new ideas won't work, they'll secretly feel better about themselves and you'll learn a few more details that might help you come up with a better idea or at the very least learn more about their requirements. Of course suggesting really bad ideas won't go over well at all, so error on the side of caution.

All good points, Eric.

Thank you both for your feedback; the answers to me cover a wider area than i initially thought; The points about knowing the specific business and it's features / how it works and looking for areas where it can be improved are ones that i haven't thought about as thoroughly;

A point i just thought about - how do you present these ideas without giving away to much information? Last year i was pitching for a company and i described what i would use (software), some of my ideas about how to get their site more traffic. I later found out i didn't get the job only to discover that the company took my ideas (as i presented them) and used them. I guess you don't give away all the details but you can't give the client vague notions and expect to be hired, they'll probably consider something like that as you not knowing your job.

_________________
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering

I'd say it all depends on the nature of the project you are asked to bid on. If it's a question like "What software platform should I use for such-and-such", I think I would probably tell them that I wasn't interested in just making such a recommendation. But often you can help them see that they are asking the wrong question, and gently persuade them that by engaging you as a consultant to solve their problem rather than answer a this-or-that kind of question. This is where experience is so valuable; at first, you won't know how to frame your pre-contract discussions to avoid wasting your time and giving away what you feel you are offering them. Later, you will learn to recognize how your skills can best be presented without totally solving their problem before you reach an agreement or contract. Of course, if it is merely a matter of suggesting a few simple ideas that they could follow on their own, maybe your contribution really isn't worth very much (no offense intended). You have to honestly and objectively assess what it is that you can do for a client that makes it worth their paying you for. Then you are prepared to watch what you reveal prior to signing a contract. It is OK to say to a prospective client, "I would need to study your situation in greater detail in order to tell you what would be your best approach." The implication being that they need to agree to pay you for that. If you can't justify such a statement in a particular situation, maybe you need to re-assess what it is you think you're offering to the client. Another case for seeing the relationship from the client's perspective. On a larger project, it is sometimes in both party's interests to propose a 2-part contract: a fixed price study subproject with a deliverable of a formal recommendation report, followed optionally by the main project defined in the first part.

With this do you mean the client would pay for an evaulation of their requirements to determine a course of action (and the results of said study) and then pay if the work is done?

_________________
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering

I agree with califdon and just want to add my 2 cents. If a client wants to know all the details, it's fair to ask for compensation to provide an evaluation (under an NDA) and then pay for the work if they choose to proceed. Odds are good if they go that far with you, they'll sign up for the project. However, paid evaluations have only happened for me when I'm going through a consulting house on a big project with a big company (i.e. 6+ figure budgets). So I try to limit meetings to 1 hour max to avoid wasting too much of my time for free. If they are aware ahead of time you only have an hour, they tend not to pick your brain too much and want to talk about their problems. During "first contact" with a client it is important to gauge their areas of expertise. If your skills are redundant to what they can do in-house, then the strategy would be to impress them with new ideas that once developed (by you) they can easily manage in-house. If they are a smallish company with some capital, you have to be careful about details. I tend to be vague until I know they are serious. Try to avoid nuts-and-bolts discussions unless they have a specific concern about your skill set and their own preferred technologies. Early on, never say no, just say we could use whatever XXX you prefer or I can make some recommendations based on your staff's experience and budget. You should be prepared though, in your budget, that you might need to hire some specific talent to round off your proposal in case they require some skill set that you are lacking. (And it would be a good idea for you to have a group of contract buddies with a variety of skills who have time to jump in and out of pieces of projects when you need them.)

When they get to the serious stage, I often have the "let's talk about a contract" discussion with them before giving away details. It is a fine line. You want to impress them, but you don't want to tell them everything either. If I'm doing work for a big company, I don't hold anything back or limit meeting times. Big reputable companies have big budgets and staff. If they want your help then they are going to be working with you for a long haul. In those cases it pays to be upfront because the long-term benefits are usually larger, but the chances of getting the contract are also slimmer.

There has been times where large companies (I'm looking at you Microsoft) has taken all the ideas and ran. So there's no guarantees either.

The bottom line, when they hire a consultant for a job, they want to accomplish "Goal A" and anything else you bring to the table is a bonus as long as it doesn't impact "Goal A" or the budget. They also don't want to hire you full time, so part of the deal needs to include how you are going to make yourself obsolete (meaning in-house people take over or support is not required). Companies are always pleased when you explain them in detail how you won't be needed when the project is done. The guys making the decisions often don't have a detailed grasp of the technical issues, but they are fearful of going down a path that will cost them much more in the long run with support costs (to you or others).

If possible for your geographic area (meaning if there are a lot of high tech jobs around) I suggest you start by doing short term contract work though a good design house. Watch how their project managers handle the clients, proposals, budgets and problems. You'll make good contacts there for when you go independent and need project help, because as you'll find most design houses are full of guys "going independent".

(sorry for the overly wordy responses, but I'm procrastinating from working and the PHP questions on the forum have been pretty thin lately).

Again, Eric makes excellent points. His suggestion about gaining some experience with a design house or consultancy is good, if that is possible in your situation. In any case, I agree with his comments about relationships with clients.

Actually I have never personally tackled a big enough assignment where I could propose a 2-part contract, but I know how it generally works. The way you pitch it is something like this: "In order to make a responsible recommendation to you, I need to spend some time studying details of your operation and requirements. As you will understand, I'm sure, I can't afford to do this just for speculation, so what I'd like to propose is that I will spend [X amount of time] with you [or your staff, where that is appropriate] and deliver to you a thorough written analysis of your problem and my plan of implementation, as Part I of our agreement. I will charge you for that amount of time. The plan of implementation will include a proposal for the timing and your cost for me to complete the work described in that plan." In other words, they pay you for Part I, so you're not wasting your time, and they get a look at how you see the project, as well as a cost estimate. Naturally, you won't reveal enough details so they could pick up the plan and execute it themselves. If you succeed in impressing them, it should be a good basis for them to approve Part II, as described in your Part I document. Now this isn't appropriate for a simple web design project, it would only be used for a fairly major project, probably one where you would need to call in some others for certain parts, as Eric described. The concepts are: splitting off the study (R&D, if you will) part and defining a "deliverable"--what you promise to deliver for a price; and, once again, looking at it from the client's perspective: for a rather small known cost, they can get a formal analysis and a well thought through cost estimate for the entire project. One of things every business hates is uncertainty. This approach helps the client by limiting his investment until he has something more than just an interview to go on. He has the option to reject your plan and only pay the amount agreed on for the report. You might charge a client just a few hundred dollars for such a report, which isn't a big amount for most businesses you're likely to deal with. For this, they get a document that demonstrates that you understand their problem and have a professional plan for how to solve it (but not with such innovative, detailed descriptions that they can easily have someone else execute it). It should give them more confidence in your ability to execute your plan. And they will have a cost estimate based on reasonable knowledge of the scope of the work; again, eliminating uncertainty.

Nearly every opportunity is unique, so "one size" definitely doesn't fit all! But that's one potential approach for a large and poorly defined project.