February 2009 - I'm of the belief there are three phases of a new project - Vanity, Humbleness, and Crisis. Let me explain.
A project starts in the Vanity phase. During Vanity, everyone is overly confident. It's believed the project will be a massive success and will solve all problems that have caused suffering and harm in the past. A common management saying is to "Break down the barriers - we're going to do things different." "Different" is what the project team infers as "better."
Verbose project team members dominate during the Vanity phase. Everyone has a voice and those that enjoy hearing themselves, take control and provide, what they call, "leadership." Myriad documents are produced laying out how the project will work and the problems it will solve. A common output is a Return on Investment (ROI). The ROI is what management will use to secure funding from upper management.
Often during the Vanity phase, new amenities like "free food" or "free pop" are offered as tokens. Off-sites are common. They make the layperson feel important. Moreover, closeness is important during this phase. It's thought that cramming more people into meetings is a benefit. Making people sit closer is seen as a way of promoting knowledge sharing.
The Vanity phase ends when the project requirements start to be realized. You know you're into the Humbleness phase when hard questions start being asked. For example, let's say you're developing a new pop can which provides a tighter seal than the current flip tops. The idea is to have end users open the can with their Boy Scout pocket knife. Sounds great until a layperson asks management how many people carry around pocket knives? At this point, everyone knows they are in the Humbleness phase. Off-sites will diminish and the thought of doing everything different (remember "different" means "better" for new projects) becomes less vogue. In fact, it's during this phase that the term "leverage" comes into play. Management might say "we need to leverage our existing resources."
Humbleness exists until upper management asks for a finite time-line of when the project will be finished. Crisis is next. It's at Crisis, people are finally held responsible. During Vanity there is absolutely no accountability. If a verbose idiot said something erroneous, they were simply brain storming. Back to the new pop can design; "I didn't really mean that a user needed a pocket knife to open the can. I was just tossing out ideas."
Another indicator that the Crisis phase is beginning is, consultants, and/or overly verbose individuals, start leaving the project or being asked to shut up. Crisis is the fun part. You get to see the big important people squirm in their seats. The verbose people are the best. If they are still on the project, their jubilant behavior is whittled to slivers. They sit in their cube, knowing they are overwhelmed with work, and stare into their computer hoping that someone would put an end to the misery.
The Crisis phase ends in one of two ways. The project is cancel by upper management or the project completes and a mediocre product is released to customers. If the product is a modest success, upper management funds phase two, but requests a new set of management. The new management is typically aware of the near failure and avoids and changes that might further damage the product and or their career. They move the project into maintenance mode and hire below average personal to fix bugs and make minor adjustments.
Subscribe to:
Post Comments (Atom)
2 comments:
I had this post locked so I could come back to it. Were you feeling in a very pessimistic mood?
As the manager of some projects that aren't doing so well, I can feel your pain. I spend a bit of my time deflecting anything from other groups, and sometimes even my own, that targets individuals for late releases. Sure, there's bad code. But that bad code would have been caught if we had stuck to original timelines, if we had flushed out all the requirements instead of just the most obvious ones, if we'd been more agile and rolled with the changes instead of demanding we still meet dates set when those requirements weren't known, if we had checked code into dev instead of trying to upstream it w/o knowing the impact, if we had been cheerful in meetings and talked like we had a good project and good people that had met some obvious hiccups instead of gloom and doom about why it wasn't going to meet target, why we introduced risk at half a dozen stages, why we changed our attitude, why we didn't just move requirements to a new stream, why we're worried about FTE overage for developers when we're still holding core team meetings of over a dozen individuals, why we didn't escalate our environment issues so that testing could be done earlier and we could check into lower environments, on and on. In the end, my primary avenue of change is to meet with my group and talk about what we can do differently and then try to influence other groups to see the light of what needs to change, but it definitely takes a village to screw up a project in any appreciable way in my experience (yes, one person can really drop the ball, but usually there are enough eyes and scrums and reviews to see that happening before it's a project killer) and it always feels like that should be common knowledge and embraced as part of the adaptive software development process. Of course, when a project is make or break for your company, the level of concern rises, but if you iteratively tackle the thing in chunks that don't have that deadline feel, everyone seems happier.
We have some initiatives we run at that aren't projects per se. I enjoy these immensely because they're like any other product in the vanity phase, but the outcome isn't tied to a product release. Everyone can brainstorm, learn, and if there's a raised feeling of engagement or lessons learned at the end, then there's benefit. Of course, it doesn't pay anyone's salary ;)
good comments. Yes, I was a bit pessimistic that day. Reason being, I'm a realist who looks for simplicity. That is, I look for easy to understand and realistic solutions. And when people spend a year pontificating complicated and un-realistic solutions, I get frustrated when everyone figures out those once great ideas are full of sh*t.
Moreover, I'm a believer of flushing out all the sh*t early on so there are no surprises. I hate surprises. I loath surprises. Yet, it seems like dysfunctional projects always have surprises. We've got a few good ones coming. Surprise!
Post a Comment