When the Customer Insists on the “Wrong” Design

GarageI was recently confronted with a familiar situation: a customer telling my team how to design the system during a requirements session. For those of you unfamiliar with application development projects, let me explain the scenario this way; you’re building a new house and you tell your architect that you will need a place to store all of your gardening tools and lawn equipment. You instruct her to design a second-story storage area into your garage. “Wait,” says the architect, “I think I can get you all the storage that you need if we just add a built-in shed on the back of the garage.”

“No,” you insist, “the second-floor storage area is just the ticket.” What should the architect do? What should my development team do? The way I see it, we have a handful of choices:

  1. Beg for forgiveness (not permission) and do it the right way our way.
  2. Debate with the customer until we’re blue in the face about the right way to do it.
  3. Sell the customer on the right approach our approach.
  4. Throw our hands up and walk away form the project.
  5. Just Do It (the customer way).

Here’s what happens in the first four scenarios above:

  1. We tick off the customer, probably miss their vision and end up owning (responsible for) the feature/process/system in the end.
  2. We tick off the customer, waste a ton of time debating over pointless details and end up right back where we started.
  3. We convince the customer our approach is best, probably miss their vision and end up owning the feature/process/system in the end.
  4. Tick off the customer, get reprimanded for not making it work and hopefully don’t get fired or sued.

More often than not, the best approach is to swallow our pride and “Just Do It.” I know what you’re thinking. I’m taking the easy way out. “Just Do It” the customer way and then blame them when the project goes down in an inferno of failure. Except, that is not what I’m recommending. No, what I’m suggesting is that there is a strong possibility that neither of you is right and that by insisting that you are (or even quietly believing you are), you are setting the project up for failure.

How can this be, though? Developers know how to write software. We’ve studied database normalization,  object relational mapping, decoupling and user experience design. We’re the experts…in software design. But are we experts in the customer’s business? While we may have years of subject matter experience, how well do we understand our customer’s specific business processes?  Even if we have spent many years inside the customer’s team, working with them and their current systems, we may not understand their vision for the project. Heck, even the customer may not truly understand their vision for the project.

As an Agile practitioner, I believe that respecting the customer’s requirements is important. It’s important not just because the agile manifesto says so, but because (along with the rest of the principles covered in the manifesto) it’s the most effective way to uncover the real requirements. I’m not suggesting that we should blindly follow the customer’s lead into a situation that my team or I believe to be ill-conceived. I’m saying that we should respectfully explore the customer’s ideas. Doing so in small, well-planned chunks will usually bring more clarity to the goal that the customer is trying to achieve. So maybe I should rephrase my approach as “Just Go With It.” By exploring the customer’s vision/concept/requirement, we allow ourselves to understand more about them, while also showing the customer that we are listening to them. Not only does this improve our understanding of the customer’s vision, but it also develops credibility with the customer, which hopefully makes it more likely for them to respect you and your vision down the road.

Advertisements

First Post

Wayne and Garth standing togetherI’m launching the blog with all of the fanfare and pomp reserved for new public-access cable TV shows. If this goes as planned, my first post will pass quietly like the sound of a tree falling in an empty forest. Instead of searching for something profound and meaningful to use as the cornerstone for this little encyclopedia of Keil, I decided to just blurt out something and avoid all of the procrastination normally associated with trying to write the perfect post.

Fortunately, today revealed a pretty good topic for discussion when we extended an offer for a new staff member who is a former co-worker that I’m really excited to work with again. We won’t have his response for a couple of days still, but the incident brings to light something that I think is very important for project managers and those in leadership positions in general: The power of a positive (or hopeful) viewpoint. Three weeks ago, I learned that one of my developers had taken a position with another organization. She was a fantastic contributor on our team and we all knew that she would be tough to replace. It would have been easy at that point to focus on the problem (“great, we’ll never find another Lisa”) and skulk about, projecting that negative attitude on my team.

In my opinion, good leaders regularly find opportunity in the challenges they face. Now I’m aware that some situations have no silver lining and simply require the team to grind out the problem. In most cases, however, opportunities can be found by looking at the issues through the right lens. In our recent situation, the challenge of losing a good team member brought the opportunity to bring on someone who will be even better. Even in those cases where little or no chance for benefit can be seen, remember that a positive outlook that is focused on the end goal will help your team drudge through to a resolution.