Musings<Biefeld>
- curiosities of development, life, the universe and everything -
«
»

If and when is it ever good to say no to a customer?

I have been pondering this question a lot lately. My thoughts have been on this topic because of something we promised the customer of my current project.
After all of the requirements gathering, analysis and design our customer informed us that they need to be able to perform a certain process with the system, that was not currently planned for. We inquired further, and came to find out that the chances of them needing this additional functionality is 1 in 1,000,000. They only perform said task very rarely.

This was a new customer so we agreed to add the functionality even though there would have to be some massive changes in the design and in what we had already implemented. I am not sure that agreeing to this proverbial “scope creep” was the correct thing to do.

We are going back and refining some things as we are nearing the end of this project. Unsurprisingly because of that additional functionality some of the customer’s business processes are now broken. By broken, I mean there are some stringent rules about the flow of data and the accuracy of that data. The requested functionality blurs the lines of the data being entirely accurate.

There is now an issue near the end of the project that could have been avoided closer to the start of it. Had we not implemented that request it would have been in no way detrimental to the current system. It’s only on that rare occasion when pigs fly that our client needs to this. In order to prevent further hiccups with future customer my team needs a way to determine if and when to just say no. The point is that I am not entirely sure when to tell your customers no. I’m sure it varies on a case to case basis.

In this case I believe we would have been much better saying no. That would have prevented the hiccup in the end of our development, prolonging the customer’s wait. In turn, they might actually be happier if they received their product sooner rather than later. Maybe even requested the additional functionality as a future enhancement. I still can’t ignore the seeds of the customers first mentality implanted into my brain no doubt by my business professors in college. Damn them for clouding my mind. :-)


This entry was posted on Tuesday, March 11th, 2008 at 11:38 pm and is filed under Coders & Customers. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  • http://www.derickbailey.com Derick Bailey

    Welcome to the world of business-oriented software development. :)

    This really comes down to a number of things:
    1) was it “implied” in any of the requirements
    2) how will it affect the timelines and development efforts
    3) how do the project management and customers want to deal with change

    1) If it was implied in any of the requirements, but not explicitly spelled out, you might be out of luck and have to do it for no additional cost.

    2) when a feature request causes this much pain for the developers and causes potential problems in the existing functionality, it’s up to the developers to inform the project management of the issues so that the project management can report the issues to the customer. ultimately, it’s the customer’s software, but it doesn’t have to be on our dime. if there is a cost associated with the change, then the customer should be willing to pony up that dime. and the customer may decide that the cost is not worth the benefit, right now, and leave it out. on the flip side of that, the project management may decide that the cost is small enough for the development company to eat.

    3) change is inevitable. feature requests are inevitable. this is where Agile development efforts really come into play and help you out. i won’t go into detail in a comment to a blog post, though… there are entire libraries of books written about this subject.

    if the feature really does make other parts of the system fuzzy or not work entirely correctly, you may be in a situation where the object model needs to be fleshed out in a different manner. perhaps theres something in the language of the customer that has not been clearly defined in the code mode; perhaps this new feature will cause you re-clarify some existing portion of the model; the point is, you may need to look at what’s going on and why, and see if there is a way that the new feature can fit into the model by changing the model in some way. Chapters 8 through 10 of Domain Driven Design discuss this in detail… i highly recommend reading the entire book, too.

  • Sean Biefeld

    Thanks for the reply.

    1) The additional functionality was not implied in the requirements in any form or fashion.

    2) It caused a minor delay in development efforts.

    3) As far as the object model goes, it is flexible enough to be able to handle the change, the true issue is how additional functionality breaks the process that the customer wanted to lock users into. It is more of an issue of the customer’s request breaking their own business process that they wanted mirrored in the application.

Musings<Biefeld> is proudly powered by WordPress
Entries (RSS) and Comments (RSS).