PeterSchuh.com

There are two factors that are almost prerequisite to project failure. These are:

1. The team does not communicate sufficient details on project status and issues.

2. Stakeholders do not pay sufficient attention to project status and issues (or the lack thereof).

This does not mean that a communicative team and responsive stakeholders guarantee success. There are too many other things that can go wrong. But it does buy you time to identify and correct for issues before they become catastrophic. In the worst case, stakeholders can determine that things are going from bad to worse and can chose to cut their loses by abending the project.

Ultimately, a combination of clear team communication and healthy attention from stakeholders is your best hedge against sudden and costly project failure.

One thing that makes me happy about my current gig is the managers whom I work alongside.

I’ve been in environments that were not nearly so healthy. One in specific where the egos of my fellow managers were matched only by the thinness of their skins. This made most every conversation painful. Sometimes even when the point of the conversation was to pile heaps of praise on an over-egoed, thin-skinned peer.

Comparing these two local environments (I’m not referring to the larger organizations in which they were embedded) I can clearly see how a bit of humility can completely alter relationships both within a management peer group and up and down its management chain.

When managers have some humility they speak frankly to one another and call each other out on half-baked ideas, even in front of others outside of the peer group. Because of humility, problems and issues are quickly identified, surrounded, and resolved. This is a collective and collaborate activity.

When managers are all ego they cannot deliver or accept feedback from one another. They do battle over whether an issue exists and how to go about solving it. They are focused on their own individual agendas and assume that their peers are similarly self-centered in their motives.

The teams that report to humble managers can go about their duties confident that their manager will hear and respect their ideas and opinions. These teams tend to behave with respect toward other teams.

Ego-driven managers let their teams get into messy battles with other teams then defend their teams in these disputes out of blind ego. Paradoxically, ego-driven managers will whip their own reports if an idea or opinion threatens the manager’s ego.

More humble managers seek to resolve issues within their peer group. They keep their managers informed and escalate as necessary but they try not to bother their managers with petty crap.

Ego-driven managers often cannot resolve issues within their peer group. They escalate to their managers as soon as a potential ego-bruising conversation is in sight. Once multiple levels of management get involved even the smallest of issues can result in the deployment of heavy artillery. Productivity and team morale often become hapless victims.

However, an ego-driven, trans-management cluster-fracas can only happen when the upper managers allow it to happen. In unfortunate fact, I’ve known upper managers who encourage egoistic behavior within their direct reports just so they can step into the firefight and “add value” by sorting out the mess. This is an extreme case. Nonetheless, you can behave like an over-egoed jerk at your workplace only if your manager lets you.

Returning to the larger point, it is a real pleasure to manage among managers with humility.

This was a recent statement of mine to my German (as in born and raised there) wife:

“You know, we’re going to have to teach our daughters that there are other forms of defense besides a swift punch in the nose.”

And the rebuttal:

“Punching the nose is a perfectly appropriate defense.”

Andrew Wicklander over at Ideal Project Group has a great post on the answer “not yes.”  I hear this answer an awful lot when taking teams agile (or more agile).

“Not yes” is the answer you hear when you request permission to do something that’s not well understood by the requestee (such as initiate a daily stand).

The “not yes” answer means the requestee has no interest in saying “no” but doesn’t want the accountability of saying “yes”.

The “not yes” answer gives the requester the opportunity to try, succeed and reap the rewards of that success. But failure, and the costs of it, fall directly on the requester.

Welcome to the world of agile adoption. We thrive and starve on “not yes” answers. More often than not we thrive, which is why agile has achieved its current level of popularity.

But failure can be a major setback, because agile takes all the blame.

This “not yes” answer may help to explain why agile development can be such a polarizing topic. Across a multitude of organizations, the “not yes” answer has heaped the responsibility both for great success and great failure on agile. Regardless of whether this is accurate or fair, it’s no wonder there’s so much passion and experience on both sides of the agile debate.

It’s 2010. I’m shocked that I still hear this excuse. Hardware is cheap. Continuous integration and deployment tools are commonplace. Virtual machines are everywhere.

If a team can’t get its migration strategy straight at the beginning of a project, and consistently deploy-then-test on something that resembles a production environment (or at least the user-acceptance testing environment) then they have no business building anything more complicated than a birdhouse.

Coincidently, there’s a project tracking tool for that.

For some this is a heinous anti-practice. For others it’s standard operating procedure. Either way it’s the fast track to project ruin.

Plan and Ignore is the practice of quickly drafting a project plan (typically to satisfy an external demand; typically in Microsoft Project) then tossing the plan and never looking back. This happens for any number of reasons. Some people don’t know how to plan. Some people don’t know how to track. Some simply don’t want to invest the time to do either activity correctly.

Plan and Ignore should never be confused with even the simplest forms of agile planning. Even the lightest-weight planning (such as a product backlog, t-shirt size estimation, and a burndown chart) can keep a team free of this anti-practice trick-bag.

The fundamental problem with Plan and Ignore is that no one actually knows the status of the project. Behind? Ahead? Safely on track? Likely no two people on the project team will give you the same answer.

And when your team has no consensus on its status all manner of bad mojo can result.

If you are actually behind, the people who don’t see this will likely be busy cathedral-building and apple-polishing instead of developing the much-needed ladder that the team will use to climb out of its current hole.

Furthermore, lack of agreement on a team typically raises the attention of management, especially when that lack of agreement is around status. But management often does not know how to be helpful in situations like this. They’ll demand to see status against the current plan, go hulk-mad when they discover that there is no current plan, demand a new plan be drafted, and waste yet more precious time prying tracking data from team members who are frantically trying to not fall further behind.

Finally, if management doesn’t cop on to the lack of consensus then the team will know they are behind only when they reach a consensus on the matter. Typically this happens one week before a major milestone, at which time the team recognizes the obvious – that it is no less than four weeks behind. And that’s when the fit will really hit the shan.