Have you ever been asked to deliver a software solution only to discover that the requester doesn’t know what she wants? In addition, she gives you a deadline, yet when you question the relevance of the target date, it becomes apparent that the deadline was picked at random.
It’s happened to me more times than I can remember and I have no respect for people that do it. They believe they’re assigning work and managing deliveries, when they are giving birth to a disaster.
It’s a blamestorm waiting to happen.
Fortunately, this is the ideal situation to use an agile software development approach like Scrum, Kanban, Lean or XP. There’s no better way to nail down what someone really wants (and needs) than to start building it. Throw together a quick mockup or wireframe. Try out a few ideas. Explore the solution space.
Tradeoffs have to be made
If there’s a good working relationship among the responsible parties, everyone will realize how big and complex the request really is. They’ll be able to rough out a solution and even estimate a target delivery time frame. Neither the solution definition nor the time frame will be precise because many details will remain to be worked out.
If the software is needed in a hurry, the requester will need to control the scope tightly. If feature set and quality are more important than timing, the initial deadline likely won’t be met. (You can’t have it all. Deal with it!)
Building trust makes it easier
The way to make this work is to build trust among the key players. You build trust by seeking areas of agreement. I’m often asked questions like “Is this possible?” or “Can that be done?“. The flip answer is “Of course, anything is possible.” The real and practical answer is more like “It depends.” — it depends on time, money, people, priority, etc.
I always try to offer a specific approach. For example, if I’m asked if the software can send an email message, I might offer that while it can, a simpler approach would be to log the item in an already existing log file. If the requester likes my suggestion, we’re good to go. If not, we can have a conversation around what’s needed and why.
This approach is far better than saying “No, it’s not possible” (none of us likes to hear ‘no‘). Also be careful with a simple “Yes, it can” response. It will likely leave the impression that the request is simple when in fact, it may be difficult and outside of time and cost constraints. Be clear. Be honest. Be agile.