excerpts.

Some things are just too surreal to not talk about - my 10 hour day yesterday broke down as follows:

• 2 hours - 2 interviews with extremely poor candidates
• 6 hours - 3 meetings (2, 1, and 3 hours, respectively) with almost the same people, about the same topic: how disfunctional the organization is and how we can attempt to align our actions
• 2 hours - This was at the beginning of the day where I actually got in a revision to a specification and deployed a latest code build, that might I add, no one looked at

Sure, Stephen Cohen's #1 thing for avoiding project failure is talking to each other and #2 thing is to have some sort of leadership, but we don't have any leadership, or that which we do have is inconsistent and more often than not, not empowered to Lead (with a capital "L").  If I were following his #3 thing, "Be honest with yourself and everyone else," I would quit.

There's a behavior pattern that's infectious in our organization - we've a core group of people that pay lip service to trusting other people, but continually undermine trust by blaming and and demanding that their irrelevant personal whims be met before they participate, simply to fall back into blaming mode.

Fiona Charles has an article about how to rescue "troubled projects," Pack Up Your Troubles , where she mentions some characteristics of a troubled project, such as

• Team abuse, working mindless overtime
• Lack of support of least empowered team members
• Dropping bombs on colleagues during meetings

I ended the day thinking I was watching a looping video reel of the "best of" trainwrecks.  I didn't have lunch, so I was probably a bit on edge.  In every one of the 3 meetings about how to get everyone on the same page to make the project proceed in a positive direction, the same few people lashed out and threw random people on our team under the bus for their personal disengagement problems.  In one of the meetings, we had our off-site consultants on the phone and they were briefly exposed to some of this, but they didn't see that progress wasn't being made.  In fact, we appeared to agree with the consultant's facilitator that talking was helping the process.  It appeared that, although disgruntled, our team was grudgingly willing to attempt to align forces and make a positive impact.

The instant the conference call was over, the same few people proceded to throw them under the bus, on their hours, on their progress, and their individuals.  With that feeding frenzy over, they went back to our own team.  In one horribly childish (but consistantly typical) moment, there was screeching about the lack of a "system architecture" from a person who doesn't understand either word let alone those two together. 

We've already had two of our most senior people leave and I think we're beyond talking about how this project is a death march.  The project is a death march.  Even if we manage to turn the heel-draggers and nay-sayers around, their attitudes have permeated and poisoned our team dynamic.

In November, when I went through a horrible process almost all by myself (one never goes through any painful process alone, there's always a bunch of people holding you down), I wrote a "post mortem" and lessons learned document and passed that around to the people whom I saw as stakeholders in the project.  I've been working my way through the pages on retrospectives.com, in particular trying to internalize the retrospective prime directive.

Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

It's a bit morbid of me to be reminiscing about a project before the time of death has been called, but watching this group flog, viciously, a gasping dying project-horse is close to the best I can do at the moment.  It's the fantasy that the constant surrealism of my day forced me into.  My initial reaction was that certain people, including myself, haven't done the best job they could've on this project, but then I realized that's not wholly true - while my heart may not have been completely in it all the time, it's more than clear that the best job that some people in particular could do was what they did, actually do - they sat back and sniped, bitched and looked smug continued to be resentful.  For some people, that's their forte - those are their skills and abilities.

The Prime Directive and it's correllary the Second Directive seem like self-help for the software management set and, to some degree, it is.  Circling back to the interviews during the day, the people we met with have a glaring lack of social skills which is par for the course in engineering-oriented people.  It's worth repeating some basic interaction skillsets within the context of software management.  I find the reading and the discussion around retrospectives with it's mediation-like angles to be a refreshing distraction from technical issues allowing people to focus on people-issues.  (ie it is "pretend" to some degree, but it has purpose - to attempt to ignore the base hateful and spiteful nature of some people)

What's sad, though, is that most of the people in our "information technology" division are not software people, they're just people with poor social skills and the inability to cope with change except by considering it a threat.  The common wisdom and foresight of the Prime Directive and Second Directive (and, for that matter, Dr. Phil and Oprah) are probably lost on these people made comfortable by years of patronage.  Peter Principling someone is not the answer, either forced retirement or firing someone is.  "Reupping" someone's "trust level" just to watch it be frittered away in a next meeting gets emotionally draining.  At some point, someone has to realize the individuals that aren't engaged aren't because they're useless.