The Consulting Conundrum

Brady commented earlier about the A-number-1 problem with being a contract software developer. I've been burned by this more often than not. So I've stopped allowing those kind of events to take place. Instead of playing Swammi The Magical Mind-Reading Bridgebuilder, I start out by charging a flat rate for what I call "Project Discovery". At this point, we build the bridge's blueprint. We interview everyone currently involved in the existing processes, and map them out. Then we separate manual from automated processes, and kill any steps that can be eliminated.

When this phase is finished, we have a complete recommendation for moving forward, including the dedication of resources, estimated timelines (with healthy buffer zones, AKA The Montgomery Scott Principle of Starship Repair) and project milestones. We then bid a flat rate for the project, with equally disbursed payments at each milestone. If the project is accepted, each section of the contract is initialed, and the document is signed by all parties involved. It then becomes etched in stone and unchangeable.

If the project is accepted, the entire project amount is deposited into an escrow account, and funds for each milestone's payment are released upon satisfaction of service for that milestone.

Changes to the plans are strongly discouraged, and therefore I make the change process as difficult as obtaining a Constitutional Amendment. Any deviations from the plan are agreed to in writing, signed by both parties, and are then billed on an hourly basis. If you went through the planning correctly (preferably using the MSF process, as Jesse corroborates), there shouldn't be too much need for deviation in about 60% of all cases.

This is an extremely simplified version of my consulting process, but it's a good overview. If you're going to start consulting, and just jump right in, you're doomed to fail. That's what I did, and I'm about $12,000 poorer because of it. YOU'RE the expert, so it's up to YOU to make sure that the framework for success is in place, because your contractor isn't going to have a frickin clue what they're doing. It's up to you to make sure that the job functions are delineated, and keep the project on course. Don't let businessmen start telling you how the database should be structured, that's not their area of responsibility. If the project gets out of hand, as the technical expert, it's your fault for not standing your ground and keeping it in check.

6 Comments

  • Robert-

    I wonder about your statement that changes to the plan are strongly discouraged. I must be misreading this. I've been a consultant for almost 20 years. Plans change and clients pay for those changes. Otherwise you end up having software that was originally described but may just plain old fail to meet the clients true needs. I'm not even talking about XP but just common sense. What am I missing in your statement?

  • I like the idea of charging for project discovery. I think something that can be challenging is figuring out when a project starts. (Not always, but sometimes.) I'm getting ready to start on a new project with a firm I've never worked with before, so I may try this out. Thanks!



    I have to agree with Julie, though, regarding change. Changing the spec/scope isn't necessarily a bad thing. So long as the customer understands the impact, I don't have a problem with change. In fact, I will often change small things for free. (Depends on the project, the customer, the specs, the expectations, etc.) However, I have found that when I am willing to throw in some small changes for free, my customers are a lot more agreeable when it comes time to negotiate the charges for larger changes. I think this is because they can see how I am willing to be flexible for them.

  • I agree with Julie, I think you need to adjust to change. Our customers' environment changes rapidly, and our job is to enable them to capture value in the marketplace. Maybe I am also misunderstanding how you are doing that.



    Second, project discovery should almost always be billed as time and materials. Then the output of that "phase" could (should?) be used as input to a proposal on actually implementing the solution within the given business constraints.



    But that's just my two-cents. In the end, if it works, it works! :)

  • I agree with Robert. If you agree to change the plan for free afterwards, it's the beginning of troubles. As Robert says, everything should be written down and signed and charged. This is what makes the client responsible and think twice about what he asks and what he really wants and when. Thinking twice is always good, and you should not undervalue yourself by giving your clients the impression you can work for free.

  • "If you went through the planning correctly..."



    after working in consulting exclusively for the past 7 years, for consulting firms large and small...i can personally attest that "planning correctly" never happens. and that's ok. technology consulting, and development in particular, is an iterative process...*most* large, well educated organizations understand this...and if they don't it is the obligation as a consultant to also play a business consultant role and help this process...



    change is something you cannot (and should not prevent). yes, scope creep sucks, but it is a reality. the customer is the business and they drive the business rules...when technology consultants get in the way of the business defining the way they want their solution to work (from a business perspective) because it may impact the technical implementation of that...it is wrong...i'm not saying it sucks, but just that it is wrong. the business should drive the business solution...and the tech people implement as best they can that solution using technology...if the requirements change, so be it...then the implementaion may have to also...



    but in the end...you can plan as much as you want and it is never enough. i just finished a project with one of (if not the largest) chip manufacturer...which has a rigid requirements process...and guess what...what was "approved" is not what was implemented in the end...why? because the business changed...and we adapted. and most clients would understand this requires changing the scope, which may impact cost, timeline, resources...and if they don't, then shame on the consultant for at least not explaining this.

  • Don't misunderstand me. Just because I make change difficult does nto mean I make it impossible. I make it difficult enough to make them consider the ramifications of "on a whim" changes.



    Someday, I'll have to blog abotu the single consulting job that made me adopt this MO. But not today.

Comments have been disabled for this content.