This is the Kind of E-Mail I Fear

It goes something like this:

"Hi Glenn!

Hope you are having a good day. We have a need for some modifications to our content management system. How much would it cost to change it so that when I upload a new product line doc, it sends out an email to a list of clients? Do we need a separate database for that? We use Provider X for email marketing and would like to pull the client list from there.

Thanks!"

Technologically, this is a pretty simple request. Build some logic into the upload process. Fire off some emails. Any good developer could have this done, tested and deployed inside a day or so. But it’s that sort of thinking that can lead to a troubled project if I’m not paying close attention from the very start. Fortunately, I recognized three things that prepared me to deal with this engagement in a way that encourages success:

The client told me very specifically what they wanted.

You’d think this would be a good thing, right? Not always. If I take their request purely at face value, chances are high that I’ll deliver something that does what I thought it should do, and not what they thought it should do. This is because they haven’t told me what they are actually trying to achieve. We call it, "The Why." WHY do they want to do this? What business problem or improvement opportunity is driving the request? It sounds like a great idea for automating a task, but is there a better way? You see, the client has come to me – the one with the expertise in doing this sort of thing – and told me precisely how they want something to work without drawing from my expertise or allowing me to get inside their head and see things the way they do. Sending some emails when a file is uploaded isn’t their goal here. Solving some problem they are having is. If I have an understanding of their vision, I know what success looks like at the end of the project. Without that, success is practically a shot in the dark. If I make the shot, great! If I don’t, then we have a service delivery issue on our hands. And that is certainly not where any of us want to be.

I don’t know what I don’t know.

The client’s main question is the cost of the solution. Granted, this is pretty much the first thing we hear in any engagement (one of the roughly 417 reasons why custom application development is difficult), but it’s a yellow flag I need to deal with, especially in this context. There are a whole host of questions that I need answers to. How does the system know you’re uploading a product line document? Should it always send the email? What’s the content of the email? Does the user need the ability to change that content? Who does the email come from? What should happen if a recipient replies to that email? What should happen if the email can’t be sent for some reason? How do I get the distribution list? Is it always the same list? The entire list? Will that list always be available? Will it ever change? How many emails will be sent?

I could go on, but I think you get the idea. The answers to all of these questions determines how much time it takes us to code and test their solution. If I fail to ask the right questions, then I can’t accurately scope the project, nor can I deliver a robust solution for their needs. If I don’t understand the entire landscape of what could go wrong and how things should be handled when they do, then we have a service delivery issue on our hands again. And it becomes an issue because the user’s perception is that the application is buggy. It might be written extremely well. It might be secure, performant, elegant code that does precisely what it was designed to do, but if it doesn't do what the business wants it do to, then their perception is basically right. In short, I have no real requirements here, and I’m being asked for the final bill before I’ve even begun the work. There is a lot of opportunity for failure there. I call it Swiss Cheese Requirements: If I’m not asking the questions, then I’m making assumptions, and I have too many holes.

There’s a third-party integration at play.

This type of project is often more fun for developers because they have the opportunity to learn and do something new. We want to say yes to this kind of thing. But such integration can also introduce significantly complexity into the solution, including another point of failure which we do not really control. This dramatically impacts the cost of the solution, as well as how it is architected. In the end, my project estimate to do the job using the third-party service was four times as much as if I had a simple list of email recipients stored within the application. The difference in cost and complexity is probably enough to ensure that I don’t get the work. But if I take the opportunity to suggest different ways of accomplishing the task, explain the tradeoffs, and get feedback on what the client finds suitable, I can still land the work and give the client what they want – even if it’s not precisely what they originally asked for.

The way we partner with our clients is one of the things that makes Definity Partners "Not Your Average Consulting Firm". We’ve learned all of these things from experience, and developed our approach to engaging with the client so that we can head off problems before they occur and deliver excellence in both large and small requests. The people designing and managing your project not only understand the technical implementation, but we strive to see the business context as well. We ask lots of questions because we want the big picture!