|
In the soap opera of office politics, leading roles are often played by project managers. Unlike starring heartthrobs, being a project manager in software development is, without question, a thankless job. They catch all of the heat for whatever incompetence surrounds the project from the customer (they are, in the end, responsible for their team) and lose many in-house friends because their job is to push and prod everyone into doing the work and making the deadlines.
Good project managers must combine the ability to understand all elements of the project, from the big picture down to the nitty-gritty, and be able to convey that information to developers and customers. PMs spend time negotiating compromise, the reality being that, almost always, someone is unhappy, the jilted lover. A good PM must also be able to break bad news to clients ("we're behind schedule") in a way that keeps the client from having fits ("we found the perfect way to store your data, and it will save you time down the road, but will take you more time right now" aka "it's not you, it's me."). PMs should be able to tell the customer what is impossible, and tell the developers to make the impossible happen, all under budget and on schedule.
That is the ideal. The reality of project management is a wee bit different.
You would think that, given the nature of the job, PMs would simply have to be insanely organized and great communicators. Not so. The following are some of the more "real world" types of Project Management, the less-than-ideal PMs that make cubicle dwelling and software development just that much more unpleasant.
Mr. Vague
Mr. Vague has no idea what the project is actually about. He can parrot back what the customer says to him, but his technical knowledge and general lack of curiosity means that mostly, he pushes things off on the nearest available underling and goes off to play golf instead. By putting said underling in charge, the underling catches grief while he can say he's trying to push the project along and delegating appropriately. Mr. Vague tends to be easy to spot when the technical people come in and start asking specific questions, at which point, he somehow has important business elsewhere and must leave the meeting. If it's getting too rough, he'll leave the office.
Mr. Vague does set up an initial schedule, but has no understanding of how long any one section will take. He will reappear from the golf course the day before any milestone deadline and prod the now harried and irritated underling (who has been trying to warn him all along of impending doom) that they are not going to be able to do what he has asked. Mr. Vague nods, tells the customers what he wants to hear, and tells the underling to "make it happen" before swiftly exiting the building.
Mr. It's All in My Head
Unlike Mr. Vague, Mr IAIMH knows an enormous amount about the project. He's asked the customer real, pertinent questions, and has a thorough grasp of what the developers are telling him in return. The problem is that no one else knows. There is no documentation, no requirements document, no meeting minutes, no plans, no memos, no written material of any kind. Information is only conveyed verbally…and always, because so much is in Mr IAIMH's head, he leaves out what he knows as a given, but the developers don't. What follows is an endless round of tweaking back and forth between developers, customer and Mr.IAIMH.
Because Mr. IAIMH doesn't do any kind of planning or documentation, the only schedule is usually an amorphous delivery date that gets pushed farther and farther out. Usually, Mr. IAIMH can deflect the growing problems by suggesting unclear instruction from the customer (a fact that doesn't acknowledge that it is his job, in managing the requirements gathering – the requirement gathering that likely didn't happen in any organized fashion and certainly wasn't documented – to clarify and refine customer needs). Testing tends not to happen at all with Mr. IAIMH, as he (correctly) doesn't believe anyone else understands the application well enough to test it, and with slipping deadlines, any allotted time is quickly consumed in any case. Instead, the fires erupt and are doused until eventually the customer wanders off with its buggy software, disconsolate.
Mr. I'm Great!
Mr. IG combines the customer chat expertise of Mr. Vague with an interest in minute, but essentially minor and useless parts of the application. He micromanages to death one module, but then fails to notice if, for instance, large sections of the application don't function or communicate with each other. In general, Mr. I'm Great! likes to talk about how the project is going So Well and the customer is So Pleased! But when it comes to delivery date, one of his wearied staff members may finally point out that, gosh, the database can't actually load data onto the screen. Mr. IG tends to obsess on the graphic interface – it will be a pretty application! Inconsistent, but pretty, in his eyes, anyway! – but, like Mr. Vague, Mr. IG doesn't really understand what the application is supposed to actually do. When someone tries to tell him, pondering issues such as legal compliance and such, he just tends to wave his hands a bit and get a faraway look in his eyes until he can start talking about the GUI again.
These are, of course, only a few of a multitude of possible PM problems. Software development can breakdown in a myriad of ways, but the most common occurrences are failures in terms of planning and communicating. Planning and communication are essentially soft skills…and they are easy to fake. Anyone listening to politicians will realize that it's surprisingly easy to go on for quite some time without saying much of anything; PMs can and do use this to their advantage.
It's also easy to fake planning; a spreadsheet can imply organization, but often, on closer inspection, is so woefully broad and incomplete as to be virtually useless. So PMs keep on with their jobs, and odd products are delivered to customers that are, at least temporarily, convinced that they should be happy enough.
Imagine if it was actually done right. If there was a process in place that supported planning and meaningful communication. Now that would be some kind of story, not just the same old soap opera over and over and over again.
|
