“You’re all doomed.”

When my wife introduced me to the world of opera a few years ago, I assumed it’d be a peek into high culture, not a lesson in keeping technology projects on track. But as we sat through Les Troyens — The Trojans — I watched a familiar story unfold.

Cassandra is a familiar presence in Greek mythology. She can see the future, but spurning Apollo’s amorous advances earns her a curse: no matter how accurate her prophecies are, no one ever listens to her. Les Troyens finds her in the city of Troy in the final days of its brutal war with Greece. When the Greek soldiers surrounding the city mysteriously disappear, leaving a gigantic wooden horse behind, all of Troy celebrates.

Obviously, the end of a decade-long siege means that it’s time to break out the champagne! Cassandra warns them that it’s a deadly trap, announcing that they’ll all be killed... but of course, no one listens. They’re too busy feasting and admiring their new monument. Their Trojan Horse.

Spoiler warning, folks: the horse is full of Greek soldiers.

Stop me if you’ve heard this before

If you’ve ever been the skeptical person in the room during a new project’s first, joyous planning session, you probably know how Cassandra felt. You’re seeing bad omens, and your spidey-senses are tingling — but everyone else is smiling and saying, “Let’s crush this!”

The horse is full of crazy deadlines, and no one will listen.

Getting stuck in the role of the naysayer is never fun, especially in the very early stages of a project. Often, the warning signs you’re picking up are vague, and easy to dismiss.  At those moments, it’s easy to lean back and turn the concerns into Cover-Your-Ass disclaimers. “Perhaps,” I sometimes think, “tacking an ‘assumptions’ section onto the project plan will shield me from the consequences of a disaster I fear is inevitable...”

As tempting as that can be, I try to remember Cassandra’s fate. She was right when she warned Troy that it was doomed, but she lived there, too. When disaster struck, she perished along with the rest of the city. If we really care about the projects we work on and the people we work with, there’s no joy in saying “I told you so.” The entire team suffers, and we’re right there with them.

Dodging Cassandra’s curse

In a mature team under ideal circumstances, gut checks can be enough to get a decision-maker’s attention, but there are always times when something more concrete is necessary. How can we overcome Cassandra’s curse, and turn our vague portents of doom into clear, unambiguous advice? There’s no magic bullet, but a handful of basic techniques can improve our chances.

1. Catalog the uncertainty. Is there a hard deadline, but a fuzzy and ill-defined list of required features? Is unfamiliar or immature technology required to make it happen? Does the team lack an unambiguous set of success criteria? Make a list, and map out those scary shadows. Sometimes, there are answers and they’ll assuage your fears. When there aren’t, though, it can help decision-makers realize they need to head back to the drawing board.

2. Compare the work to similar tasks and projects. If the early estimates for a large project feel too optimistic, it can be difficult to explain why. Whenever possible, find examples of similar projects or tasks from the past. Show how long they took, and if the estimates for those projects shared the same early optimism, point it out. As unpleasant as it is to keep time sheets and logs, they can be critical ammunition in the fight for sanity.

3. Identify deep dependencies, in technology and teams. Are you building a mobile app that relies on a third-party library... which relies on a fourth-party service... which relies on a fifth-party startup? Does one department control the infrastructure your project will need to launch, while a second is responsible for content and a third handles the development? The more external dependencies a project has, and the deeper those chains go, the more risk there is. There’s no way to avoid reliance on outside teams or tech, but mapping them out makes the risks clear.

4. Identify fuzzy authority roles. Few things are as depressing as ironing out a project’s requirements, building it to spec, and preparing for launch  only to discover that your client wasn’t really in charge. The last-minute emergence of a VP with different aesthetic tastes, or ongoing conflict between two or three equal stakeholders, can sabotage an otherwise well-run project. If you hear talk of “running the plan past a few other people” before it can be approved, or it’s unclear who’s in charge of key decisions, don’t be shy. Get a list of people with veto power and ensure there’s a single buck-stops-here person for key decisions, or wave a red flag. 

5. Time-box and prototype. Especially when new or unfamiliar technology is involved, accurately judging risks and sketching out timelines can be impossible. Carving out a small chunk of time for a prototype is critical. If the exercise reveals unanticipated challenges or problems, you have concrete evidence to offer rather than vague concerns.

Towards a happy ending

The goal of these techniques is twofold. First, the work that goes into them can reveal solutions to the problems and clear answers to the troubling questions. Obviously, that’s the best outcome: successfully routing around danger rather than grumbling about it. If that isn’t possible, though, carefully articulating the concerns can make the pitfalls clear and unambiguous.

It’s an approach that goes beyond avoiding blame and puts important information in the hands of people who need it. It doesn’t always work, and we can’t always avoid the dangers, but it’s far better than the cynical alternative. 

Now, if you’ll excuse me, I have to look into the next trip to the opera. This time? I think we’ll try a comedy...