The Consulting Conundrum, Part 2

In my previous post, I discussed project management. Julie brought up an interesting point (and several agreed):

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?

As is par for the course, I did not clearly express myself, so I will elaborate.

Large-scale changes are made more difficult because changes are typically the main way that most companies use to get out of a project. Because this system is designed around simplifying a given process and not “dealing with data“, it's very rare that large-scale processes will change during a project. Making the change process difficult forces people to think about ramifications of all aspects of the project up front. It forces the planning process to be much more lengthy and much more complete.

These concepts fit very well with the POC-DC method of project management. If this is familiar to anyone, it's because it's the method that the United States Air Force teaches to its senior enlisted personnel and officers. I was fortunate en ought to have had three years of management instruction in high school by the one of the former heads of that school. POC-DC stands for “Planning | Organizing | Coordinating | Directing | Controlling“. The hyphen in the middle stands to separate the phases, which are as follows:

Pre-execution   |   Execution
P    O    C        -  D    C

As you can see, 3/5ths of the work is done in the pre-execution phase. Therefore it's a good bet to say that 60% of your time will be spent creating the plan, and only 40% will be spent executing it. If you did your due diligence with the planning, you should not have to deviate too much from the plan. The way you execute the operation of the process may change, but that does not take away from the solution to the problem.

Part of the problem with software consulting today, and why we consultants get a bad name, is because we dive into projects without a plan. We take input from clients, such as what Brady came across, and just leap forward without any clear indication of what's ahead.

Any trip worth taking needs a good roadmap. If you've taken the time to plan a good roadmap, chances are you won't need to take many detours. You may have a few unplanned stops along the way, like stopping for some pictures at that rest stop with the dinosaurs (where they filmed “Pee-Wee's Big Adventure) along 1-10 at the Arizona/California border, or to relieve yourself of that Ultra Big Gulp that you just HAD to buy yourself before you left. That's where the Montgomery Scott Principle of Starship Repair comes into play. (For those of you non-techies, it's “Scotty“ from Star Trek, and he always  made his estimations 3x longer then what they would actually take, so he always looked like a miracle worker.)

I'm not saying that the solution will be rigid, I'm saying that the process has to be. You're going to have to quantify the intangible: what makes a small change and what makes a large one. This needs to be clearly defined in the contract, and you cannot waver from it. Consider this scenario:

Typically, hourly consultants will start to fall behind in the work. Then the client wants to start making changes to the project. The consultant compromises with his typical MO because the project is behind, and he wants to keep the customer happy. So he starts compromising, which sets a dangerous expectation with the client. Suddenly, a big change comes along. Now the consultant is stuck, because if s/he doesn't make the change, they'll say “Well, you did those 14 other changes, why not this one??!?” Sound familiar?

The techniques I posed may be heavy handed. They have to be, otherwise your project is doomed to fail. Having failed at enough consulting projects in the past, I can say that 90% of the blame on those failures falls on my own shoulders. Not because of a lack of execution, but because of a failure to assert control over my own circumstances.