By Jack Ganssle

Thoughts on Consulting

Summary: Some insightful comments about consulting from a reader.

Daniel Drubin is a consultant. He sent me a long and interesting email about his experiences in consulting, which I am reprinting here with a few edits.

I am an embedded software developer and consultant from Israel. I have worked in embedded s/w for twelve years, for the last 4.5 years as a consulting "sole proprietorship". I decided to write to you after reading your articles "I, consultant" and "Consulting As a Career". It's amazing how some things are the same across the globe. The "sell, sell, sell" mantra is very important here, too. Even handling governmental military projects via dedicated partners is a very similar pattern in my experience. I would like to assert something about fixed-priced projects. I completely agree with you that they are more nerve-wracking and require a lot more attentive approach; however, I managed to make them much less of a nightmare with an approach that's not very hard to take, but which requires a bit of self-discipline to follow. It produces very effective (if not amazing) results for the customer and brings credibility to outsourcing. If the thing gets known, just there may be more embedded programming work getting outsourced. The idea is simple and well-known but as well widely ignored. It is defining a plan with a schedule together with the customer and then following it. In order for that to work, you've got to develop a Functional Specification for the project together with the customer, conduct several meetings with them closing all TBDs and having them sign it. Then it should be mentioned somewhere in the contract something like "...the contractor is obliged to hand in deliverables according to the Functional Specification (appended to the contract)". Then there are several things to remember having in the spec, otherwise the project may get out of control. 1) It's a must to have an "Assumptions and Dependencies" part of the spec, which has everything that comes to mind that may kill the project. Even seemingly stupidities like "customer's supplied libraries work according to their specifications" (in fact it's quite an important thing to include). 2) Breaking the project's payments to milestones and having the contract say that met milestones are never reversed. 3) It's a must to take something in advance. People are reluctant to knowingly wasting money for nothing, and this is a good thing to have in case that the customer "regrets" even about the whole project (advance payment is milestone 0). 4) Include an Acceptance Test Procedure as the last milestone. One milestone before the last should be "beta delivery" with all functionality principally working, and ATP should bear something like 10% of the project. This guarantees the customer's satisfaction and a good impression on overall project performance. Also, most managers have experience with making internal projects from definitions (in many cases vague) to delivery with testing (in many cases poor). They will have very good impression with the less buggy project done in less time and will even instinctively consider the bearer of such a great methodology when they are starting a new project. 5) Never agree to add things to Functional Spec during implementation under the current breakdown. If the client really must have it, offer them the requested features set under a different milestone. Always make it clear that all future milestones move on (and don't forget that more development work may mean more testing too!) 6) Always add at least 20% overhead to time estimations. Even if the contractor excels at estimations, communications problems may occur. Some common things that may go wrong and their treatment. 1) If the client delays payment, just stop working on the project until they pay a milestone and let them know that. Many contractors are afraid of saying "no" in order not to lose future projects. However, not insisting on the client committing their part of contract will make their treatment during future projects even worse. 2) If the client delays provision of necessary prerequisites, stop working on the project also. Don't go on with future milestones. 3) If the client regrets about the whole project - the case should be defined in the contract (e.g. passed milestone never return and next milestone is estimated on days percentage) 4) What if the client delays the last payment by trying to get additional features by claiming they are bugs? This is a tricky thing, but I found a kind of solution which seems to work. Decline their claims and claim your copyright on the whole project instead. Resist handling them the copyright until the whole payment is completed (I know it's work for hire or equivalent, but only after the compensation is paid!) It's wise to have a legal statement in the contract, something like "by completing the full payment, the client will assume copyright". For fixed-price projects you'll need self-discipline, being assertive, your leadership and cooperation. The contractor will actually assume technical management and responsibility over the project, it simply won't work otherwise (he doesn't get paid if he fails). If the contractor is not experienced in fixed-priced projects, the best way to try is start with relatively small projects with well-known existing clients.

Daniel's model is akin to the traditional waterfall approach. Some consultants use a more agile method, which may demand other ways to manage the project. and manage the customer.

Published January 6, 2011