A lack of solid specifications can seriously derail your development efforts much more often than bad programming. Decisions affecting a project can come from all over the place during the design and development cycle. As a project manager, one of your primary functions is to facilitate decision-making. More often than not, you must make decisions yourself.

Read on to learn more about decision-making disorder (DMD) and how you can prevent it from infecting your project.

Diagnosing decision-making disorder
Making sure the right people make the right decisions in a timely and consistent manner will help keep your projects on track. Watch out for the early indications of DMD listed below to facilitate early detection and prevent the need for drastic measures:

  • There is a shortage of feedback, or a lot of redundant or contradictory feedback. You can’t get a clear concept of what needs to be delivered.
  • Specifications are lagging behind. If planning isn’t complete within the allotted time, either a decision hasn’t been made, or too many early questions were left unanswered.
  • Requirements trickle in or change rapidly. Making decisions and frequently rescinding them is another indication of DMD.

Left unchecked, a mild case of DMD can become a full-blown problem. Some of the symptoms of serious DMD are:

  • Your list of unknowns never gets shorter. You’ve moved past a critical juncture but don’t have all the pieces in place.
  • Initial development phases are lagging. Architecture and design diagrams might be overly ambiguous, or specifications were left incomplete. Decisions are forced forward onto the next person in the chain, putting that much more work on the developer.
  • Critical details slip through the cracks. You might be missing database schemas, workflow diagrams, or other planning pieces that represent a clear model of the solution to be delivered.
  • Change orders are rampant. Not enough details were finalized, or a fear of commitment is becoming an issue.
  • Unit tests work, but system tests don’t. Something was missed, and your people are working without sufficient direction.
  • Your timeline is slipping. DMD is a frequent cause of this problem. Questions left unanswered can eat into your precious development time.
  • Requirements are missed or don’t match expectations. Either decisions were ambiguous or weren’t made, and the problem seeps into the specification.
  • These symptoms can have other causes, but if you’re experiencing one or more of these, it’s time to do something about it.

Project first aid
If you’re halfway into development and you’ve discovered some of these symptoms, it’s not too late to perform emergency surgery. You must seek out indecision and eradicate it before irrevocable problems occur. It takes steady effort, but with proper treatment, your project will recover.

The first thing to do is assess the situation. Before taking drastic steps, find out why a deadline was missed or the system doesn’t meet expectations.

Don’t be surprised if your development team made assumptions when the relevant information wasn’t present—this is a given when it comes to writing code. Asking about decisions takes a lot of time that could otherwise be spent programming. Document critical assumptions and see how they fit into the scheme of things.

Make sure your team isn’t working with ambiguous specifications. Each developer has his or her own comfort level, and exceeding it can seriously affect your timeline. Meet with your lead developer and architect to refine the specs, if needed. Avoid making changes that require reworking. If it makes sense, go with the path that’s already been taken.

If you haven’t already, identify unknowns and assumptions, and seek clarification where necessary. If you can’t get answers from project drivers and clients, get recommendations from your team. Then make a decision and inform everyone involved in the project. If there’s an opinion either way, you’ll be sure to get it.

Examine your change orders. If they’re verbal, shame on you! Put a process in place immediately, and enforce it. Disallow add-ons—those requests for additional functionality that weren’t in the original plan. If your project is hurting, you must maintain the distinction between expectation and delivery. There are diplomatic ways to handle this. For instance, schedule new functionality for the end of the project. You’re not saying “no,” you’re saying “yes—but later.”

If change orders are “changed-my-mind” orders, push back. Make sure those who request changes understand that processing every whim delays the project. Explain that the code in question has already been completed, and make a case for why it’s sufficient. If you’re changing things back and forth, try to get a higher-level decision from the requester by stepping back and reviewing that part of the project. If changes must be made at that point, at least you’ll be able to get them all at once.

These tips will help hold DMD at bay, but not by themselves. You must apply preventative measures to help keep problems to a minimum.

Regular checkups
There are practices you can adopt to keep waffling at a minimum and shield your project from the effects of DMD:

  • Always look two steps ahead. Stay in touch with clients and project drivers about what comes next. Provide ample opportunity for feedback and foresight. Decisions become weaker as time moves on, so verify goals shortly before they’re put into practice to eliminate ambiguity and doubt. Share this information with your team.
  • Create a decision-making chain of command, even if it’s an informal one. Let people know who’s working on what, so the experts are apparent. Publicly announce who should be contacted for what types of questions, and hold weekly reviews with those people to make sure nothing major is swept under the rug.
  • Use the power of suggestion to your advantage. If you can’t get the decision you need, suggest a solution or a course of action. If that doesn’t work, make an assumption and have it reviewed. If you still get nothing definitive, act on your assumption. Be prepared to ask for forgiveness.
  • Have a process for clearly identifying unknowns. Preventing DMD boils down to knowing what questions to ask and when to ask them. Accept the fact that it’s your responsibility to facilitate concept solidification. Ask your team to help you locate points that haven’t been finalized, and actively pursue resolution.
  • Make it easy for decisions to be made. Offer ample feedback, and share your opinion. Identify questions early to keep decision makers from feeling rushed, and keep everyone up to date on progress.

Prognosis for project success
Once DMD is diagnosed, take action. Don’t let someone’s inability to make a decision create a crisis for your project or your team. Plan ahead and facilitate commitment to provide general protection, and keep your eyes open for early warning signs that ambiguity is causing problems. If prevention doesn’t do the trick, home in on the culprits to minimize the effects of decision-making disorder.

Horror stories

Everyone has worked on at least one project affected by decision-making disorder. Share your experiences in the discussion forum below.