Lighthouse Project Management
Blind spots are the cause of every project train wreck.
The project was careening towards a cliff. The technical debt was accumulating, the money was running out and the client was making larger and more distracting changes. At the same time the research and background was inscrutable. The specifications were detailed and vouched for. Expectations were set and reenforced with everyone agreeing enthusiastically with the project vision. Apparently none of that mattered.
I doubled down, vowing to figure out what was really going on no matter what. Eventually I uncovered a force more insidious than the common threats so often championed as the big bad wolves of project management: I was up against psychological bias.
By definition those under the influence of a psychological bias have no idea it’s even there. Unlike more the obvious threats it’s unlikely that anyone will bring it to anyone else’s attention. Even though the project had everything going for it, ultimately it was being undermined by a threat in a blind spot. Worse still, because team member’s can’t see them my related questions seemed like a distraction.
Here’s what I was noticing: Stakeholders would pledge allegiance to the project’s described outcome but their actual behavior would sometimes threaten the project’s success. Stakeholders would say one thing (in support of the project) and then do something contradictory (endangering the project). Smart people would make bad choices. Here are some examples:
- An engineer would agree to a timeline and tech and then go off and incorporate a coding language or methodology that was completely new to the team which (of course) adds a precarious tower of unknowns.
- A client would sign off on a specification and a deadline and then insist on needless time-wasting changes during every review.
- A salesperson would promise the new client a smooth build and then make side deals that wreck any chance of quality on-time delivery.
If you haven’t experienced any of these as a project manager you’re lucky; all are rooted in Incentive-Caused Bias. Here’s how it works:
- The engineer has career ambitions that overshadow your project or is just plain bored, both of which strongly incentivize learning new technologies.
- The client rep craves recognition among peers and management resulting in a strong incentive to influence product visuals and generate clear evidence of managerial involvement.
- The salesperson has a compensation plan that rewards sales more than quality on time delivery.
For the record, there are many different psychological biases and it’s rare that there is only one at work at a time. I’m choosing Incentive-Caused Bias† for simplicity and because I can’t think of a project that hasn’t been impacted by it.
After understanding that there were incentives I couldn’t control I began watching for the clues and practicing methods that might allow me to at least detect bias. This eventually led a sort of internal mantra I eventually named “Lighthouse Project Management.” It has become the way I remind myself to always bring conversations back to the unknown; back to questions that might seem tangential. It’s also a commitment to correcting or compensating for any dangers threatening the project — as early as possible.
I’ve found that the most direct route for finding stakeholder bias is to look for risk or, more accurately, the absence of risk. Two situations which I’ve become sensitive to as early indicators are:
Whenever I hear things such as, “It’ll just…” or “All we have to do is…” or perhaps the worst, “It’s easy…” I know I need to do more digging. If experience in tech has taught me anything it’s that it’s never as easy as you think. Supporting an approach with generalizations means that someone is missing how things might go wrong which is a strong indicator of a blind spot.
I love it when people are enthusiastic about an approach; it’s contagious and excites everyone. At the same time whenever I hear enthusiasm I immediately begin listening for acknowledgment of related risks. When a stakeholder includes risks as part of a plan I get a sense of whether or not the enthusiasm is thoughtful and takes the project’s larger goals into account. The fact is, a plan without risk isn’t a plan, it’s a dream. No plan goes perfectly and while enthusiasm is terrific, until someone talks about the risks there is a blind spot.
Neutralizing Incentive Bias starts with detecting it in team members but then it requires looking closer with humility. Perhaps in the search you’ll find bias but it’s important to keep an open mind. I’ve learned that asking honest (not ego-centric) questions helps maintain camaraderie while providing the opportunity to better understand. Simple “Why?” questions can be powerful lights for illuminating misaligned incentives. Your goal is to hear a clear explanation why they’re plan or idea is best for the entire project and team. If a plan is better for a single stakeholder than it is for the project the defense of it will quickly wither.
Bias doesn’t change until the incentive changes.
Uncovering an Incentive-Caused Bias doesn’t change the incentive, it merely allows you to defend the project plan. The final aspect of Lighthouse Project Management is to remember to check your blind spot again and again. If an engineer’s bias means a proclivity towards risky technologies it’ll be necessary to constantly check to ensure that this isn’t the source of technical complications. This is a powerful tool because when issues arise you’ll know where to look first. I’ve found that once I understand team members’ bias I also have a short list of possible problem sources; I can often get directly to the cause of an issue and have a prepared a way around it.
In many ways running a successful project is about playing defense; keeping bad ideas and competing interests from derailing your plan. A well-run project is a significant amount of work and the basic idea of Lighthouse Project Management is that protecting it from danger is actually the best offense.
The train wreck project eventually did deliver. By understanding the distracting psychological forces at play I was able to counter them and deliver on my promises. Still, I wanted to know more so I purposed to discuss my experience with colleagues who reassured me I wasn’t alone. That certainly made the story less embarrassing but no less critical to avoid.
Since then I no longer hesitate to ask questions and am comfortable asking more and more questions with as little ego as possible until I get at the root of a topic. I commit to checking and understanding and rechecking because when the project is over all the conversations, negotiations and deliverables will be forgotten and only the success or failure of the product will matter.
Mark Ovaska is a Product Manager with 20 years of business and software development experience who enjoys sappy metaphors.
All Images © Copyright 2018, Mark Ovaska