Cockroaches just love projects. Several projects have loads of them, but most projects have at least a few of them. Software projects are notorious for breeding cockroaches that are not only hard to spot, they are harder to exterminate. They are a project manager’s worst nightmare, and despite our collective advances in project management theory and experience, we still are answerless in face of collective might of those otherwise innocuous-looking pesky little creatures that simple turn the best laid out plans and intentions into history.
What are these cockroaches ? I am not referring to the ugly kitchen pest that refuses to die (it is rumored to be the only living form with capability to survive a nuclear fallout), but the Cockroach Theory, defined as:
A market theory that suggests that when aÂ company revealsÂ bad news to the public, there may be many more related negative events that have yet to be revealed. The term comes from the common belief that seeing one cockroach is usually evidence that there are many more that remain hidden.
For example, in February 2007, subprime lender New Century Financial Corporation facedÂ liquidity concernsÂ as losses arising from bad loans to defaulting subprime borrowers started to emerge. ThisÂ company was the first of many other subprime lenders that faced financialÂ problems, contributing to the subprime mortgage meltdown.Â
In other words, the fact that one subprime lender (one cockroach)Â faced financial problemsÂ indicatedÂ that many other similar businesses were likely to face the same issues.
In my experience and learning, the real problem is not so much about having a cockroach (or a few of them) in a project. The real issue is about an initial trivialization of the sightings of the first few of those cockroaches, until the time they have had enough time to breed and become a problem so large that no easy way to walk away from it.
When the project architect leaves half-through the project, it simply might not be a human resources’ backfill problem. So, if all you do is find the replacement without really finding other cockroaches (the architect is not a cockroachÂ his departure mid-way through the project is). They could include things like impossible deadlines that are simply not going to be met despiteÂ all hard work; or unreasonable resource constraints placed on team or project resources; or slow and indecisive leadership by the product owner leading wasted cycles and subsequent rework; or a bug list that grows even when there is no testing being done (ok, that’s a poetic exaggeration, but you get the point). Similarly, if the project misses its alpha date, it might not always be because of some showstoppers. There might be other cockroaches lurking in the dark, waiting to pounce off the pizza bones left by team working late nights, as soon as the lights are dimmed.
The most common response to a project cockroach is denial. Check the data again. That new timesheet tool is still unreliable. Run the tests again….and so on. We almost always try every possible excuse invented by mankind to avoid confronting the cockroach (the “problem”). We fail to recognize the iceberg model – what meets the eye is only 10% of what is waiting to drown us down. So, we gloss it over. Let’s give a workaround to the customers. Let’s backfill the architect from outside. Make timesheet reporting mandatory for any task over 15 minutes. Get a new tool to do automated pass/fail test status reporting….and so on. Nowhere we try to find the source of this solitary cockroach (to be honest, he is your project’s best friend becuase he is telling you there are more of him somewhere deep inside the project).
Sometimes we kill him by brute force blissfully thinking that’s the last of him. But alas ! If only this were even half-true. Those who do any amount of kitchen cleaning do know it better 🙂
Any of these methods only leads to the cockroach factory getting more time to become bigger, stronger and eventually, unignorable. Unfortunately, by this time, the rot had spread to the entire empire, and there is only this much a project manager can do. The army of cockroaches has spread its wings to multiple failure-points in a project, and no matter how much you do to manage one or two of those failure-points, you can never handle all of them. If you ever get to the last of these cockroaches, several new ones crop by then.
Does it sound like a typical day at work ? If not, you are doing a few right things that we all could learn from. But, if this is anything like your typical workday, you might want to stop firefighting (rather cexterminating cockroaches) and think a while what’s happening around you. Instead of denying the existance of a cockroach, or triviliazing its potential or brushing it away as an one-off event, you might want to start peeling the layers to find why and where this cockroach came from. Try an approach known as Five WhysÂ developed by Toyota that is all about commonsense wisdom. Don’t stop until you have found the root cause of the problem – and it is at this point that you can decide what to do next – if the trail of questioning leads to a dark alley that is infested with many other cockroaches, you probably know what’s the right thing to do. However, by stopping at any of the prior levels, youÂ might never get to the real issue.
What else canÂ you do ? Think of rewarding your folks who don’t always just complain, but come out with real issues and concrete suggestions on how to fix them.Â Â Relook at your status reporting if that is just about reporting yesterday’s weather, or more like a weather guide for the coming week ? Are your team members more likely to raise their hands and report an issue and happily volunteer to fix it, or are they more likely to ignore the issue with a quick-fix and let someone else worry about it ? Do you reward early failures in your projects that help , or do you use early successes to build political support for your project even if they lead to faulty assumptions downstream the project ? Do you manage your customer, or the other way round ? Do you see your upper management as a project resource that you can enlist as required, or do you see them more like the stakeholders to be satisfied at any cost ? Are you, or our team members,more likely to compromise on the ethics for short-term gains on the project, or you prefer the old-school way of doing business with conscience ?
Will doing all this guarantee there are no cockroachs, like for the next 6 months ? No way. In life and in projects, there can’t be any guarantees. But doing some of these right things will create a climate where problems (cockroaches) are not ignored, there is a systmatic way to deal with first-sightings and the messengers understand how the information they bring is of potential use to the project.
So, does your project love cockroaches ?