Project Management: Escaping the vortex
Posted by Arjun ThomasAs reported on Tech Republic.
I attended a conference several months ago where the CTO of a small development company was adamant about one thing: Making excellence a standard should be a focus on getting teams to work together. This is not a new concept, but one any successful organization embraces.
Around the same time, I ran across Robert Martin’s ‘Whiners that Fail’ post at objectmentor.com. In it, he basically addresses how there are those who will complain about having to pay for things like white papers and how those people expect employers to shell out cash to make their own personal lives better. His point? “YOU are responsible for YOUR career and no one else.”
I agree with that statement strongly, but not just because I realize my boss or company is not my mother. This mindset extends to how we deal with our work lives, especially when confronted with managing a problem project with difficult people, systems, and requirements. How we take responsibility for our own lives/work/projects makes all the difference.
Making excellence a standard should be a focus on getting teams to work together. And part of that excellence model? Establishing excellence is not whining.
A somewhat recent example jumps to mind. A project I’ll call Vortex does a bunch of stuff: It retrieves some records, manipulates them, massages them, then makes them reportable (allegedly). There are several environments at play, including flat files generated from a mainframe, a monolithic database, some half-working Java-based Windows apps, and some database engine processing. It’s slow, it has jobs to run jobs which may or may not run, has entirely too many moving pieces, and is a mess overall. The point is this: Even the very nature of its architecture is suspect, but it’s way too late to even entertain gutting the overall project and rewriting it. While it can be shown we spend thousands of dollars on it, the millions it would take to recreate it from scratch mean we’re pretty much stuck with it. Most large companies have at least one of these.
Of course, there are way too many voices in the conversation when it comes to making changes to it and in determining how those changes should be facilitated. The rules of overall agreed process are regularly overruled by political demands. Roles are unclear or dismissed altogether, process is conditional, and the support requirements are incredible. The ongoing support alone is a medieval gauntlet–those who survive may not have been eaten by lions, but would probably prefer it.
It becomes very easy to complain about a project like this. It almost encourages a chant of bonding where all involved fully agree with only one thing: It sucks. Have you been on a project like this, where everywhere you look a process or procedure or design is broken? A project like this truly has the potential to become the thing that ushers us all into Armageddon. Or at least wish for it.
If you are (un)fortunate enough to manage a “Vortex”- type project, you can bet everyone involved already knows how bad the project is. The very last thing you must allow is the introduction of complaining into the equation. As a manager, you must not tolerate it. All whining does is choke the team and encourages an attitude of negativity and blame all around. Encouraging a bad attitude happens to be the exact opposite way of pulling a problem project out of the miry clay it has lived in up until now.
Related posts: