The batch-scheduling tool procurement was weeks late, and a lack of a decision was slowing the efforts of a very expensive integration consultant. The tool was a minor part of the solution, but waiting to know which one to use was a huge roadblock.
During a status meeting, everyone turned to the representative from the operations group for an update on the tool purchase.
"We are still coordinating with one of the candidate vendors to get a demo scheduled for a time when all of our staff can be there," said the representative. "It's hard because Sue is on vacation next week, and John is going to a conference at the end of the month."
The development team members present rolled their eyes and sighed in frustration. Another delay in the tool selection! People understood that the support team wanted to assure the tool chosen was best for the job, but this was ridiculous and expensive!
Hearing this status report and knowing the impact of yet another delay reminded me of a proverb: "The best is the enemy of good enough."
This project was paying a hefty price during this misguided, though well-intentioned, quest for the best. But I have to mention that I'm agnostic about batch-scheduling tools. Moreover, I'm agnostic about many tool choices. Some tools are undoubtedly better for some situations than others, but I imagine that most that survive in the marketplace can provide basic functionality. There may be legitimate, differentiating questions about ease of use, interoperability with other parts of the environment, specialized functionality, quality of support, and cost, but I worry when an organization spends hundreds of person-hours of key technical resources (equating to tens of thousands of dollars of people time) to make a relatively minor $5,000 decision.
If you are choosing a spouse, a parachute, a major chunk of your architecture, or spending a significant amount of money, then do your homework and choose carefully. The wrong choice can be really expensive, and you may be stuck with the consequences for a long time. If you are making a minor decision involving a small investment that could be revisited if it didn't work out, the research investment should be bounded by the cost of correcting the wrong decision.
When someone is assigned to make a decision that involves research, it is helpful to think of the decision-making process like a project and ask the following project definition questions:
What do you want?
- What would a good decision look like?
- What should be considered?
- What should be excluded from consideration?
- How thorough should the research be?
- Who must approve the final decision?
When do you want the final decision?
- Why then?
- What is the business consequence of delaying the decision?
- Are there any benefits to a faster decision?
What resources are we willing to invest in researching and making a decision?
- How much human resources should we use (person hours or person days)?
- What's the budget?
- What will it cost the team/company if the decision doesn't work?
- What will it cost the team/company if the decision is late?
The batch-scheduling-tool-selection project would have benefited from better framing so that the team knew where the project was on the continuum between the following points:
A. Read a few trade magazines, make a few phone calls to people you trust, back it up with a Google search, then pick a tool.
B. Examine and prototype all commercially available options in detail.
The batch-scheduling-tool-selection project needed decision process A but was getting decision process B—not because the people doing the research were foolish, but because the scope of the decision was unclear. All projects—including tool-selection projects—benefit from thoughtful scoping and a good understanding of the business case that drives the decision. Consider these factors the next time you need to make a choice. The grief you save may be your own.
