How to recognize when we’re avoiding a problem instead of working to resolve it (Part 1 of 2).
I was having a conversation with someone who is in an organizational support role about failing IT projects. He told me that his team has been given a directive to escalate support for a high-profile but failing software development project – to prioritize their requests over any other. Because this project was running over on budget and time, they had suddenly become more important than any other individual or team in the company, the premise being, I suppose, that their failure was due to a lack of support.
Many times, extra support is just what a project team needs. If metrics show that not enough people were assigned to a job, or the right skills aren’t present to do the work, or the scope of work has simply increased to become more than a team can manage, then adding support is probably the right move.
The big risk, however, is that in reality the team is failing because they are doing it wrong. In this case, blindly adding support to a project in many ways is like pouring gasoline on a grease fire. Damage can spread, and quickly. In an intra-organizational situation where success is not being achieved as expected, the worst response is to engage others in the organization without evaluating and assessing the root issue.
Adding support to a lagging project without identifying the root cause of the problem is an example of “active avoidance”. This is common when projects are highly visible and the problems are obvious and concrete (budgets are overrun, timelines are slipping). Something visible is being done to remedy the situation, but without fully understanding the root causes, it’s not immediately obvious whether that is petrol or water that’s being thrown on the fire.
Another, perhaps less evident example of how we avoid dealing with problems starts to pop up much earlier in a project’s lifecycle, and is more of a slow burn if left unacknowledged. I am referring to resistance to a project’s agenda by the user (or “business” community), which can manifest itself in many ways. You might recognize it as people playing “office politics” – which is so common it’s become an accepted source of corporate problems, rather than an identified symptom of a bigger issue.
For examples on how to overcome office politics, check out Ron Ashkenas’ article, entitled “Use Office Politics to Your Advantage”.
People are creatures of habit. We generally resist change. A little resistance is normal. But when it starts to feel that stakeholders are taking sides more than collaborating, or withdrawing rather than contributing, what we have is a clear signal that something is amiss. The short term negative impact of this is on morale – technical stakeholders feel underappreciated and overworked, and business participants feel like they aren’t being listened to or involved in the process. Long term impact is a much bigger problem, however, and left unmeasured and unchecked can cause projects to fail closer to the end.
“Passive avoidance” comes about when subtle risk indicators (like an increase in stakeholder resistance) are ignored, written off as “human nature”, or when nobody involved takes responsibility for resolving them. Sometimes these are elephants in the room, other times they are just accepted as the “way it is”. Either way, they are hidden risks that can threaten a team’s success from the inside out.
There are ways, however, to avoid these types of avoidance strategies. Later this week, we will discuss how to keep from getting into fire-fighting in the first place. Plus, I will provide a few tips for preparing yourself and your project to weather the smallest brush fires, preventing them from turning into forest blazes.
What have you been avoiding on your project? In your relationship? In life? Time to get honest with yourself at www.MeetMaple.com.
R. Alliance, LLC 