If you live in or grew up in a northern climate, you know about cars getting stuck in icy ditches. If the weather is cold and icy enough, even a shallow divot in a driveway can turn a modern vehicle into a beached whale. Speaking as a person who has spent most of his life in places like Chicago and Cleveland, there are 2 ways to get your car out of an icy ditch. There is a wrong, absurd way and a right way. The wrong, absurd way goes like this: get out of the car, take precise measurements of the angles of the ditch, the temperature of the ice. Note the horsepower, tire tread depth, and weight of the of the car. Then use these statistics to calculate the perfect RPM and torque of the steering wheel, and voilà! Your car is free. The right way to free your car is to get in, put it in reverse, slam on the gas pedal, and then put it back in drive. Repeat this until the car is free.
My story about the car in an icy ditch reminds me of the “paralysis by analysis” we see so much of in modern corporate life. While this phenomenon can take hold in any business function, it seems especially common when it comes to implementing software. And flexible cloud platforms like Salesforce and Workday make the paralysis even more tragic. This is because with highly configurable apps, the cost of making a bad decision is quite a bit lower.
When it comes to implementing software, most problems organizations run into have little to do with the technology itself. Bad code can be fixed, but a team with unclear goals and paralyzed by indecision can drain a project’s ROI. The following are a few ways teams can create better decision-making mechanisms:
Talk about decision-making before starting a project
Before an implementation begins, it’s important that the team agrees to a structure for making decisions; just as important — the structure for making decisions should be written down. In an agile project, user stories need business owners. The technical people implementing the solution must have a decision-maker to go to when a decision must get made. Under agile, a less-than-perfect decision is better than no decision. Connecting a decision-maker to each piece of work builds accountability. At the same time, a team must also agree to value good, timely decisions over time-consuming, “perfect” decisions.
Know your objectives before you start
Investing time in understanding the values and goals of a project before you start can help prevent paralysis by analysis before it begins. As Becky Kane wrote on the Todoist blog: “When you encounter a tough decision, avoid analysis paralysis by asking yourself which option aligns best with your most important goal or value.” It’s important to build anactionable strategy to understand the business goals before doing anything with software. Every member of the team should be able to recite a short list of project goals in plain language and in order of importance.
Commit to configuration before customization
There are many good reasons to customize software. But understand, one of the key advantages of configuration over customization is that it is easier to undo bad decisions. Also, once a solution is configured, the team can better weigh the tradeoffs that come with a customized version of the solution.
Stair-step your decisions
Many times people get paralyzed by a decision (in life and in software) that seems monumental. Jeff Boss writing for Forbes suggests “Rather than looking at the decision to be made as a one-time, main event, consider smaller yet actionable decisions that can be made now or that lead up to the main one.” Breaking down decisions into smaller bits lowers the anxiety associated with making decisions, and helps clarify the decisions down the road.