CRM design trap - revisited...
The following paragraph in Joel Spolsky’s recent post caught my eye:
‘Custom development is that murky world where a customer tells you what to build, and you say, "are you sure?" and they say yes, and you make an absolutely beautiful spec, and say, "is this what you want?" and they say yes, and you make them sign the spec in indelible ink, nay, blood, and they do, and then you build that thing they signed off on, promptly, precisely and exactly, and they see it and they are horrified and shocked, and you spend the rest of the week reading up on whether your E&O insurance is going to cover the legal fees for the lawsuit you've gotten yourself into or merely the settlement cost. Or, if you're really lucky, the customer will smile wanly and put your code in a drawer and never use it again and never call you back.’
While the article is about the challenges of prioritizing development work in respect of shrink-wrap software, his observations on the challenges of custom development resonated with my comments from earlier in the week regarding the design process, and it prompted a couple of additional thoughts. It strikes me there are three main reasons that organizations sign off design specifications then recoil in horror when the customizations are finally unveiled:
One. A point I made on Monday – the quality of design documentation is often poor. Either because it is plain badly written, or because it is written for the needs of the development team rather than the customer. Either way, it’s nigh on impossible for the customer to comprehend what customizations the implementer is intending.
Two. They get signed off without being read. Reading design documents, particularly badly written ones is painful. It demands high levels of concentration. It’s time consuming. There’s a compelling urge just to skim through it. Where there is group sign off a dynamic kicks in that leads people to believe someone else is sweating through the detail, so a light skim is all that’s required. And….
…..three, we have complete faith in our implementer. They do this for a living right? OK, they haven’t had to do too much on this project so far, but they seem to know what they are doing - let’s leave it to the experts.
And of course sometimes that faith pays off and the implementer delivers a perfectly designed system. But when they don’t, it can be a very painful place to be. For fear of sounding like a stuck record, and with the promise I won’t return to the theme of design for a post or two, take your time here, and don’t sign off until you are 100% satisfied that you both understand what is being developed, and that you are convinced it’s going to work for you.
‘Custom development is that murky world where a customer tells you what to build, and you say, "are you sure?" and they say yes, and you make an absolutely beautiful spec, and say, "is this what you want?" and they say yes, and you make them sign the spec in indelible ink, nay, blood, and they do, and then you build that thing they signed off on, promptly, precisely and exactly, and they see it and they are horrified and shocked, and you spend the rest of the week reading up on whether your E&O insurance is going to cover the legal fees for the lawsuit you've gotten yourself into or merely the settlement cost. Or, if you're really lucky, the customer will smile wanly and put your code in a drawer and never use it again and never call you back.’
While the article is about the challenges of prioritizing development work in respect of shrink-wrap software, his observations on the challenges of custom development resonated with my comments from earlier in the week regarding the design process, and it prompted a couple of additional thoughts. It strikes me there are three main reasons that organizations sign off design specifications then recoil in horror when the customizations are finally unveiled:
One. A point I made on Monday – the quality of design documentation is often poor. Either because it is plain badly written, or because it is written for the needs of the development team rather than the customer. Either way, it’s nigh on impossible for the customer to comprehend what customizations the implementer is intending.
Two. They get signed off without being read. Reading design documents, particularly badly written ones is painful. It demands high levels of concentration. It’s time consuming. There’s a compelling urge just to skim through it. Where there is group sign off a dynamic kicks in that leads people to believe someone else is sweating through the detail, so a light skim is all that’s required. And….
…..three, we have complete faith in our implementer. They do this for a living right? OK, they haven’t had to do too much on this project so far, but they seem to know what they are doing - let’s leave it to the experts.
And of course sometimes that faith pays off and the implementer delivers a perfectly designed system. But when they don’t, it can be a very painful place to be. For fear of sounding like a stuck record, and with the promise I won’t return to the theme of design for a post or two, take your time here, and don’t sign off until you are 100% satisfied that you both understand what is being developed, and that you are convinced it’s going to work for you.
posted by Richard Boardman at 2:32 pm
<< Home