This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: This Consulting Business
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Several times in the career of a "programmer" one considers opening up shop and becoming his own boss - becoming a Consultant ( the capital C stands for the extra money consultants demand ). Brady brings up some interesting issues budding consultants often encounter. Robert offers some really great advice from his own consulting process. I especially appreciate the value of using escrow services. (Update: Robert adds some more advice here ) I'd like to share what little experience I've gained over the years in the hope that some other consultant just starting out may save himself some grief.
From my experience, the main skills area that needs improvement in programmer-turned-consultants is project management. This area deals with everything around the actual product/system developed. Development really isn't the problem. Bottom line - first and foremost, READ ! Anything and everything about project management, contracts, RFPs, and all other things relevant in some way to the project. The hard part is always implementing all the great accumulated wisdom out there.
The most critical thing to remember is: It Takes Time.
Not pure programming, in the zone, 100% productivity time. Time to develop relationships with stakeholders. Time to go through the RFP/RFI process. Time to negotiate. Time to travel ( a lot of people when starting out forget to take this into account when budgeting - it IS time spent on the project, and should be measured - at the very least). Time to meet with users. Time to learn the terrain. Time to reconcile differing views. Time to play politics. ... Time.
Obviously there isn't enough room here to go over all the skills and techniques of project management and consulting, however, I would be remiss if I didn't come full circle from time to money.
First of all, unless you have a signed contract, signed detailed project description document, etc... no project will be done in 2 months. Once you have all those things, AND there are NO mid-project changes, then you have a case of "contract programming" mentioned in the comments of Brady's entry, which has a chance of being done in 2 months.
However, there are end-project activities which have to take place, installation, training, support ( yes, even if you didn't include it in your offer, if you don't give some support for the bugs that will doubtlessly come up, the project will be labeled a failure. ), meeting with the major stakeholders to see that they're happy, ... you might as well not have done the project.
So, in essence, once you're a consultant, work != programming. In the vast majority of cases non-programming.Time > programming.Time. Its this mindset that has to take hold. This particularly becomes difficult when a potential client comes to you with a project that sounds exactly like something you just did. It happened to me recently. A client asked for a system that I just finished rolling out at a different client, and I thought: Easy money. Well, the politics there were like nothing I'd ever seen. The project took even longer than at the first client, even though the code had already been written !
Bottom line: Everything is a project, and must be treated as such.
Now, getting to money. Money is important, and so is when you get it ( see Robert first post about milestones ) and making sure that you get it ( Escrow a la Robert ). And, don't forget taxes. For one-person shops that aren't overflowing with projects, deferring a payment to a new fiscal year can make a big difference to your net income, and may buy you a favor with the client if you play your cards right.
Of course, no discussion about money and consulting would be complete without raising the issue of hourly vs flat-fee pricing. Most clients prefer fixed price offers, since they fit with their yearly budget planning.
Many consultants I've met use hourly fees, but billable hours is a fickle measure that varies from project to project. Personally, I have certain issues with the hourly pricing model - note that I'm referring to the invoice the client receives. When charging hourly, the client will obviously want to know what you did on an hourly basis. Try explaining to the client to pay you $X/hour for having lunch with the head of computing services to make sure that he was pleased with the effect the project had on his department.
Fixed price offers allow a consultant to roll up many project expenses that are often difficult to collect from clients in an hourly model. For those who are skilled in project management, this model often works well. However, the risk involved in under-estimating scope, or time required, may adversely impact the bottom line.
Recently, after reading this great article on Value-Based fees, I've had great success in this model. In a nutshell, you, in cooperation with the client, assign value to each deliverable, and price it. This model handles scope creep very elegantly. For lack of space, I suggest you go read the entire article. Moreso, the "Million Dollar Consultant" has a whole page of tips for those going the consulting route. Highly recommended.
To sum up, to succeed in consulting one has to treat it as a whole different career path to be learned and lived. Think "Career Calculus" by Eric Sink. More importantly, consultants are PEOPLE people, not computer people. Soft skills rule.
Previous Topic
