Quantifying software in the Consulting World.

I may have an opportunity to take a more "consulting" oriented contract in the future, but i'm a little hesitant to do so.  The job would be advising on good software practices, helping them implement a lifecycle, reviewing their architectural process, (and actual architecture itself), setting up test cases, etc.  The problem is, how do you *prove* that any of this improves their productivity (especially since some of it can "feel" like a waste of time to developers new to it). 
    For example, I think everyone here agrees that Source Control is a good thing.  But how can you show that by implementing source control, productivity is quantifiably increasing?  And source control is something everyone agrees on!  I imagine it would be much more difficult for things such as unit testing and stress testing, etc. 

  As always, thoughts and comments are appreciated.

vince
Tuesday, April 20, 2004

Vince,
  quantifying things is hard, and knowing that your metrics are the right ones is harder still.

My experience in consulting is that you go through flip-flops of wishing you were more hands-on, and wishing you were more abstract/consultative.

The gold standard for me is always

i) If a parallel me was running the show, would I employ me to do that job/ for that price/ at that amount of effort
ii) Are you happy being a consultant - where true success is walking away from an engagement where everyone thinks the new idea was theirs originally - which is why they have embraced it
(see Gerald Weinberg - secrets of consulting)
iii) If you are nervous, or if the economy changes, do you still have the technical skills to go back to a non-consulting job ?


It kind of boils down to whether you get pleasure from  teaching, learning and other people's success (consult) , or whether you need to control, or prove your own ideas (do it).

Hope this helps

Jim

jim dallas
Tuesday, April 20, 2004

Just do what Gartner does, bullsh*t your way to a five figure cheque.

Seriously though, there are really only two ways to quantify stuff in the consulting world.

1. It used to cost you £x to do ABC. Now it only costs you £z, where (£z + your cost + cost of software) < £x

2. Now that you have this software, you can do XYZ which adds £m to your bottom line. where £m>(cost of software + your cost)

The metrics you use, and how much the bill payer buys into them will define you as a consultant.

Everything else will be a variation of this same theme.

This is what keeps mgmt consultants in biz.

The one undocumented feature is the fact the sometimes mgmt will bring in an outsider to validate decisions that build their turf at the expense of others, irrespective of the true business value. Conversely, sometimes the consultant is brought in as the fall guy.  I know a couple of guys who make a healthy living as mercenary fall guys. They don't mind taking the flack as long as they get paid. Not sure its for me but .... .... 

Tapiwa
Tuesday, April 20, 2004

Thanks for the advice guys.  I guess what concerns me most, is the fact that a lot of "good" development practices appear to take away from productivity, in the sense that less LOC will be written over a certain period of time.  Its hard to show that spending time stress testing in advance prevented $30k in potential bug fixes/catastrophes.    I guess i'm not even sure how to quantify productivity/success in the software world at all, other then maybe # of bugs. 

vince
Tuesday, April 20, 2004

If you don't what to do, you shouldn't be doing this job. This seems to crop up time and again here.

Tuesday, April 20, 2004

"sometimes mgmt will bring in an outsider to validate decisions"

I was used that way many times as an Engineering cosultant working for telephone companies. This was Telecom engineering, not software engineering, but I suspect all CEOs work the same way :-)

Mr. Analogy
Tuesday, April 20, 2004

  Recent Topics

  Fog Creek Home