Something deep down inside tells me that I'm heading for a controversial post so let me go into a CYA exercise first. Here we go:
| Desclaimer: I'm not an 'independent' consultant. My bread and butter does not depend on charging the client by the hour. I have an awesome software development job that pays me enough to keep me decently happy; I eat every day and have a blast building decently good systems for some of our clients at work who enjoy using these system. That makes me even happier. If this post seems to suggest that I lack experience in 'independent' consultancy it's purely because of the fact that I lack experience in 'independent' consultancy. :) |
Doesn't reading this post after reading the above CYA Declaimer seem meaningless? I've already told you that I am clueless about the topic I'm going to write on and that I take no ownership of the words I'm going to write. In other words, if the information presented here is outright wrong, it's your problem. My ass is covered.
Doesn't this attitude completely de-motivate you from reading this particular post any further dear reader? Humor me, read on. I have a point to make. I promise.
The folks who wrote screen-scraper have a manifesto which describes what they refer to as the 15% rule:
| “Before undertaking a development project we create a statement of work (which acts as a contract and a specification) that outlines what we'll do, how many hours it will require, and how much it will cost the client. As part of the contract we commit to invest up to the amount of time outlined in the document plus 15%. That is, if the statement of work says that the project will take us 100 hours to complete, we'll spend up to 115 hours (but no more).” |
Fair enough. If I put myself in a client's shoes, this seems to be virtually the only paragraph in the whole manifesto that I don't have a problem with.
I tell myself: I'm the client and these folks are a little worried about me blowing up the scope so they want to make sure they are covered. That's Fine. But then I read on. From this point on, the manifesto seems to get overly defensive and if I'm playing the client, I see myself knitting my brows at almost every other paragraph. For example:
| In the past we have shouldered virtually all of the risk in our projects. For example, if in our statement of work we didn't capture very well what the client had in mind, we've generally allowed for a significant number of tweaks and changes so as to deliver to the client what they truly wanted. For the most part, clients have been reasonable in this process and haven't demanded anything that was obviously outside of the scope of our statement of work. |
Followed by a contradicting statement:
| We've had unfortunate situations in the past where, because we've shouldered virtually all of the risk, we ended up losing money on a project with the seemingly infinite number of tweaks and changes a client insisted upon. As such, we now put mechanisms in place so as to avoid these situations. |
The Manifesto seems to miss out on one simple fact of life. Nobody cares about you! Your best friend betrayed you? Your girl-friend dumped you? One of your older clients cheated you? I know It's very important for you, but you know what, in the real world where we live, no-one cares! Specially your new clients. They don't care about any of this crap. Surprise!
I completely understand your need to share your past tragedies with your new clients but is it necessary? For a change, let's pretend they cared.
Let's pretend they wanted to know more. So, what was the name client of this client that insisted a lot of changes? What went wrong with this project? Can you also publish the contact information of these clients in the manifesto so that we can contact them to hear their side of the story?
See? You don't want them to care. Right? So why bring it up?
Besides, this is not your blog or your personal diary. It's an official project document. If you must commit to 15% more and no more, say it in a line or paragraph, highlight it, ask them to sign it, in a simple professional way and if they don't, explain why you added the line or paragraph to them. If they still don't get it, move on.
As you scroll through the document it gets worse:
| When we embark upon a project, it will be up to you how much analysis should be done up front. Given that the level of analysis will have a direct impact on the level of risk of the project, you should have a say in just how much risk we allow for. For example, it may be that you have a very tight budget for a project, and can't afford for it to go over a specific price point. Should you elect to have a significant amount of analysis done up front, you will need to pay for the time we invest in that analysis. In cases where budget and risk aren't big issues, we'll do a reasonable amount of analysis up front, for which we won't charge you. This obviously gets a bit tricky, since it's a gray area. At what time spent on analysis Level of precision in the statement of work point does a “reasonable” amount of analysis become a “significant” amount of analysis? The number we use to guide us is 3%. That is, of the total time required to develop your project, we will not charge you for about 3% of the time spent in analysis. Even with that hard number it's still gray, so see the “We're Going to Be Nice to You” section for more on this topic. |
The client telling me how much analysis to do or if analysis is needed up-front sounds scary. Go ahead, read the document in it's original form. Throughout this document, there are tons of CYA statements all over the place. Every time the author feels he is about to scare away the client, he is kind enough to point out that things are in the 'gray' area and that there is a We're-Going-To-Be-Nice-To-You section in the document.
Of the multiple places where I disagree with the document, one place where I completely beg to differ with this document is on it's stand on bugs:
| Right about now you might be thinking, “But what if they send me software that's riddled with bugs?” That's certainly a possibility, but our experience has shown that it's very unlikely. We've been doing this for many years, and the number of functional bugs we discover in our software is typically relatively small. At this point it becomes a matter of trust. You simply need to trust that we're going to deliver you quality software. By the same token, we're acknowledging that problems can occur by giving you a buffer through which we can account for them. |
Ok, so let's pretend I'm the client here; and what are you guys making me sign? A manifesto where you are not going to spend more than 15% of the project time on enhancements and bugs, not more than 3% on Analysis (unless I pay for more) and you're going to make me decide how much analysis I need. But when it comes to your figures on bugs, you expect me to 'trust' you. Convenient, eh?
Can we please also attach numbers to what happens if I find a Gazillion functional bugs in the project? Do I pay 'x' percent less? Can we also quantify 'x'? What if a thousand of those are critical which end up taking more time, which results in breaking the 15% rule this manifesto is setting? How much discount do I get?
What if some of these bugs are so critical that not being able to fix them makes it impossible for me to take the project to production? Do we just break the relationship on a it's-not-you-it's-me note and remain friends happily ever after or do we compensate each other monetarily?
Am I sounding mean here? As a client if you expect me to 'trust' you when you say you won't write bugged code, do you mind trusting me when I tell you that I won't blow up the requirements? You've been burnt by a bad client? I've been burnt by bad consultancy firms and programmers who can't program.
You've lost money? I've lost money too. You think there are bad people out there? Me too. It's your software industry that's famous for sucking clients like us into the infinite loop of failure. You guys as software developers are the most hated professionals in the world after lawyers and with a document of this sort in front of me, I find it very difficult to trust anything. I'm just way too nervous. Sorry.
Then there are references to the client deciding if he wants QA done on the project:
| This will generally be about 5% for project management and around 10% for quality assurance. If you'd like, you're free to request that we reduce the amount of time we spend on testing. If we do that, though, then it increases the likelihood that you'll burn through your 15% buffer as we fix bugs that we would have caught, had we been allowed to complete our testing. |
As a client, if I asked you to reduce testing time and deliver a bugged system in production, that's ok? You still want business from me? Seriously, why even talk about it? If it's important for you to ship quality just add a 10% QA code cost and a 5% project management cost and make a bold statement stating that you don't do work that's not quality. Why haggle? The We-Are-Going-To-Be-Nice-To-You section is the icing on the cake:
| At the same time, we need to do what we can to ensure that our business prospers. That may mean that we need to be a bit hard-nosed about things on occasion. When we do this, please know that it's only so that we can ensure that we're going to be around for a while. That way we can continue to serve you. On the flip-side, we hope that you'll be nice to us. If software bugs creep in, we hope you'll be patient while we work to make things better. If we get really busy, and need to push a deadline out a day or two, we hope that you'll afford us a bit of leeway as we will do with you. In the end we'll all be most successful if we treat each other fairly and kindly. |
We'll be hard-nosed, we hope that you'll be nice to us and in the end we'll all be most successful if we treat each other fairly and kindly... yeah. Here's what we just went though:
- A five page CYA document that makes me (the client) decide how much time you should spend on analysis, testing and project management.
- A five page CYA document that ensures that your business prospers even if my project gets completely screwed.
- A five page CYA document that ensures that you can get away with a Gazillion functional bugs by putting in just 15% more effort and time (everyone knows time spent on something is not always directly proportional to results achieved).
And why was this detailed five page manifesto necessary? Because you feel your older clients cheated you and that your future clients (me included, if I am pretending to be the client) might be similar. Awesome. After going through it, I feel really motivated to sign this document and treat you fairly and kindly.
Jokes and sarcastic humor aside:
Don't get me wrong. I know some of this documentation is necessary, particularly if you are an independent consultant working and getting paid by the hour. But then in almost all companies, NDA's are necessary and most employees don't mind signing them. However, when a company starts frisking their employees before they get in the office every day in the name of protecting intellectual property, it becomes a joke.
Similarly, CYA documents like this one might be necessary evil on both sides and a must have for some projects. The 15% rule might be acceptable to most clients if you put it in a line or two or maybe a small paragraph in the statement of work, highlight it sufficiently and get them to sign it. It's when you prepare elaborate documents giving out unnecessary and irrelevant details to the client that it becomes a joke.
If you genuinely intend to help the client, slide in one paragraph on the 15% rule in the scope of work document, get them to sign it and then forget about it. Help the client with walking the middle path on analysis and give them genuine value for money! Use constant feedback and quick iterations to guide them and keep your project on track. Use your art of prioritization to help yourself and your client both. Use it to control the scope and make the project successful.
The five page manifesto is just a Glamorized CYA document, nothing more, nothing less.
Yes, make them sign on a Statement of work that has that a paragraph on the 15% rule, but work your ass out so that you would never have to show them that paragraph and remind them they signed it particularly during the later stages of the project. If you have to, you have failed.
Maybe you failed at analysis, maybe at implementation, maybe at building a relationship, maybe at communication; but none the less, if you have to show that paragraph to your client, you have failed.
Remember your end goal is not to put in 15% extra effort and then run as fast as you can. If your client doesn't use your product, it's your failure. After all you and your client are allies in the same battle.
If you disagree with what I'm saying here and think that CYA manifestos and declaimers are effective and work, don't bother to leave a comment or email me. Read the declaimer on the top of my post? It says I have no clue of what I'm talking about, doesn't it? With that declaimer in place, I guess I can say anything-what-so-ever about this manifesto and get away with it. I'm covered! Right? :)
Seriously, I'm lucky to have a job with a firm that works with a completely different business model and I don't have to worry a whole lot about this crap. Personally I've had my share of demanding clients, but none of them have been evil.
If you disagree, that's fine. Let's discuss. I would also like to take responsibility for what I write and accept both comments and emails on this post. So go ahead, send me that hate mail if you must. Tell me that I don't belong to this world and I'm just looking for Utopia. Tell me what an impractical jerk I am! :)
Visited your blog after a long time ... Your articles seem to get better and better everyday .. It is really motivating reading through them ... U should consider releasing a book of short articles on software development ... It will do well .....
Aur bata bhai .. where are u these days .... cramped under loads of new technologies ...
Ping me if you are in Cal .. would like to meet up some day ..
Best Wishes,
Shahid
Comments are closed.