Take a More Agile Approach to Problem Solving
I was talking with a possible client the other day. He wanted a firm price for some of my services. I balked.
“But what possible objection could you have? I want to budget for you now, for next year,” he said.
“That’s the problem,” I replied. “I don’t quite understand your problems now. How can I know what you really need? I might want to propose something that would cost less. You might need something much more extensive. I don’t know. We’ve had a total of ten minutes of conversation. From what you’ve told me, your problems have existed for more than fifteen years. I don’t think a two-day workshop is going to solve those problems. I can give you a price for that workshop, but that’s going to raise your expectations and not fix your problems.”
Do you ever have conversations like this with people at work? I bet you do when it comes to estimates. Your managers want you to estimate features or projects months or even years in advance. But the work changes—or the code changes, or the people on the project change. What you thought might be a reasonable estimate four weeks ago looks wacko when you revisit it in six months.
But your managers want to make that estimate not a prediction or a guess, but a target.
What can you do?
Here are several ideas:
- Provide your estimate with an expiration date. That’s right. Say, “This estimate is like milk. It expires on October 15, 2014,” or whatever date you select. Choose a date that is reasonable—say, forty-five or sixty days out—so your management knows you’ve thought about the estimate.
- Provide your estimate with either a confidence range or a date range.
- Say what else you can do. When my clients ask me for a too-early estimate of one option, I often supply them with several options. “I know you asked me for a workshop, but maybe an assessment or coaching would work. Here are ballpark figures for those options. Here’s how they would work.” Too often, the people who ask you for an estimate have decided on one option already. You want to return them to problem-solving thinking, rather than problem-solution mode.
If you didn’t try these options, don’t worry. You can try them next time.
When someone asks you for an estimate just before you both commit to the project, you know you are in for significant change. You need to problem-solve together. On software projects, what your managers or product owners want might cost a lot less six months or a year from now.
The question is this: Can you take a more agile approach and solve problems together?
