+972 52-548-6969
The Consulting Game
Casey had this to say:
I have actually seen organisations where (in one case actually explicitly expressed, and in many where it wasn't spoken out loud) software delivered roughly meeting the requirements on how the UI worked was considered delivered. The work to make it work (usually way more work than the initial delivery) was considered 'bug fixing' and therefore was billable additinally by the IT department or outsourcer.
Which reminded me of a joke about consultants, no relation to anyone I know, etc...
One day the manager calls the consultant to talk about the time sheet report...
Manager: You charged us on Wednesday for 19 hours, but you were here for only about 9 hours on Wednesday.
Consultant: Well, of course. Look, it is very detailed. I was here from 9:00 to 18:00, right?
Manager: Right.
Consultant: And because we left without a good solution, I kept thinking about it in the car, and when I walked the dog. You see, it is the entries for 18:00 - 19:30 and 20:00 - 20:45. From 19:30 - 20:00 I had dinner, I didn't charge you for that.
Manager: Nice of you. And the other 8 hours? 22:00 - 06:00 ?
Consultant: Well,when I walked the dog, I finally had a vision, everything came together in a moment of brilliance, and I could see the solution in my head. All I had to do is connect some little pieces and it would work.
Manager: Oh, so you did an all nighter?
Consultant: Ha? Of course not. I went home thinking about the idea, and then I went to bed and slept on it for 8 hours.
The above is not my modus operandi, nor am I willing to work with those who does. This is relevant because I am not going to consider practices built in those kind of shops as important to most of the discussion about software development.
All that aside, how the hell do you get the client to agree to pay for bug fixes? All my contracts include a 6 months guarantee for bug fixing, and most of the time they also include SLAs that says "drop whatever and get there", which is annoying as hell when this happened*. This means that I can't bill someone for bug fixes (change request are another matter, but those are for another time**), which is a great incentive to not have bugs.
* At one time I was called, after being on the phone for about an hour, came to the client, sat for 5 minute, sent a death treat to the DBA, and left. No space on the DB hard disk, argh! They backed it to the same HD and never cleaned it up.
** "Oh, you wanted it to also work? That wasn't in the original spec..." doesn't really fly in the real world
Comments
<<<
Mine do too for personal clients - but most in-house IT departments get paid on a daily rate basis for bug fixing. They don;t call it bug fixing usually of course, they call it new feature development.
There is a really easy way to do it too ... English, like UML, is a leaky abstraction. Any requirements specification, even the best of them, is leaky beyond words. How many requirements specs have you ever seen that include detailed security specifications for example?
So that thing that doesn't work right? Well it works how the consultancy interpreted the specification. If you didn't express it better in your specification, it is your fault, that will be more money please.
An example here would be most UK goverment contracts. They usualyl work this way ... the project had a budget of £500 million ... it is delievered 6-12 months late by the consultancy that outsourced it (EDS, Capita, Accenture, etc). It also doesn;t meet the most basic of the requirements. The goverment cannot piss off the consultancy (as they have a dozen other projects running with them), so they pay them £400 million for the work already done, and fine them for £100 million for the problems. They then hire another of the consultancies to fix the system, for a cost of £250 million. The process repeats ... and no consultancy loses out because they get to fix the work from one of the other ones each time.
If you don't think this is bad enough ... let me tell you a tale of the UK NHS IT systems .. so far a cost of £12.7 billion over the past 3-4 years. Recently part of the system was revealed on the nightly news to have a small flaw, you could view the personal details of any user of the system (doctors in this case) ... by changing the ID on the query string. No developer worth their salt would have made that mistake in the last 10 years ... but on a multi-billion pound project they had. If they had done something that stupid, how many other far more serious problems do you think there are with security and resilience?
From your other thread ... you said you had worked with internal teams, but I said tell me when you have worked as part of the internal team. As a consultancy, you are protected from almost all of the politics, trust me, anything you have seen is purely surface noise.
Define "work" ... a leaky abstraction ... so the fact that you don't think it works, doesn't mean that I dont think it does.
Now, would you like to pay us a reasonable sum to make it work the way you intended but didn't express clearly enough in your requirements, or would you like to employ another consultancy to do it, or would you like to take us to court to try and prove we didn't do it right (in the UK courts, you would spend many years and many hundreds of thousands of pounds pursuing this case with a 50/50 chance of winning)
Yes, Agile should prevent the above happening, but Agile is in the interests of the client, not the consultancy, so in the UK only one consultancy I know of successfully uses Agile (Thoughtworks) most of the others claim to, but having done work for and with a number of them I can assure you that they only use the bits that are in their interest.
In fact, under English law, a director has a primary fiduciary responsibility to maximise profits for their shareholders - which means for a software consultancy, they have to cut all the corners they can to make more money for their shareholders, or risk going to prison if it can be proved they did more work for their clients than absolutely needed.
In might sound silly, and in practice it isn't likely to happen, but it is the culture that exists.
After 24 years in this business I simply refuse to get mired in this debate between myself and my clients about what is and is not a bug. In my experience they have a strong tendency to classify every annoyance as a bug. What I tell them in my contracts is that I will perform work to accepted standards. What I tell them in person is that I decide what is a bug and what is an enhancement request and if we don't have enough trust established between us to go forward on that basis, they need to find someone they are more comfortable with. I explain that I hook up a hypothetical Stoopid Meter to any actual bug I encounter and it it reads high enough, I'll eat it.
I haven't been able to figure out any other way to get paid for my time consistently. And it seems to work fine this way. I can't remember the last time someone complained about or dissected one of my invoices.
I think a lot of it is in learning not to apologize for your existence and projecting that confidence into your business negotiations.
There was a similar discussion along these lines at the ALT.NET conference in the session on building user stories. Someone was insisting that you have to give the customer an estimate early in the process if they ask you for it, even though you haven't collected enough data to have much of an idea. The presenter suggested that you give them whatever number they feel comfortable with, and later you just extend the contract. No one wants to admit it, but this is just how business is done. Everyone, customers included, expects it.
I couldn't agree more. As (I think) Scott Bellware pointed out in that discussion, the lawyers get involved only when the customer no longer trusts you. If "things take longer than they take", and more time and resources are needed, AND you have been doing credible work up to that point, there will be no problem.
Having been doing this myself for the past 15 some odd years, I'll present a slightly different angle on it.
The fact is, unless the organization you're consulting to provides a full compliment of QA facilities, or is willing to pay for them, every dollar saved by not doing so should be considered as "bug fixing dollars". For instance, on average, only 1 in 5 clients of mine have ever put up the money to buy and build out adequate DEV, TEST, STAGING, and PROD environments. FYI and IMHO, STAGING should exactly match PROD, minus a time variance in the data (how stale is it). That is where we perform final tests against PROD level data (both from an unexpected volume and content perspective). The vast majority of actual bugs in what I've worked on over the years that make it to PROD have to do with this. And the money "saved" on not having an adequate STAGING environment is typically paid 5 times over in bug fixes. And no, a VM on the DEV workstation doesn't work when you're dealing with hundreds of GBs of data.
In addition to the environments, simply not having the hours to perform testing or having QA persons dedicated, etc. all impact the "bug freeness" of the code-base. Give me the time, and I will without a doubt provide you with bug-free code (understanding that bug-free means that it works the way you told me it should work and the way that I designed it to work).
In short, it is a cost/benefit/risk analysis for the client as to whether they pony up the cash in the beginning to ensure an adequate QA process is enabled (which roughly 5% of them even get what you're talking about), or just wing it, and find and address bugs as they appear, and then bitch endlessly about them.
FYI, the last large app I consulted on received quite a bit of scrutiny from the client as to the "bug count". After we produced the SCR (system change request) list that tracked every last thing we worked on (my CYA policy) and showed them clear as day that over an 18 month period, 2500+ SCR's were created, of which 12 were bugs (of which 5 hit PROD), 400+ were enhancements, and the rest were what we termed "refinements", meaning it wasn't a bug, nor was it a completely new bit of functionality, but simply the client working iteratively with us to figure out what they really wanted.
Comment preview