In case you missed it yesterday, I discussed the first half of this sometimes contentious topic: Is Project Management an Art or a Science? Yesterday I covered most of what I consider to be the scientific – and by that I meant consistent and repeatable – aspects. Today I'll cover the art.
Today on a Java mailing list, I came across the little gem: I think coding conventions are
useful, except when they aren't, and he thinks they aren't useful, except when they are said by the esteemed David Bock. Instead of chuckling in the seemingly inconsistency of this statement, I found myself nodding my head and thinking of how it applied to Project Management.
It boils down to a simple idea: Nothing works all of the time. Currently, I'm managing a team of a variety of skill sets and a variety of experience levels and it's amazing to see how the tasking works out.
First, I tried a little experiment. For the top two developers on the team, I needed a series of unrelated milestones met. For one, I gave him the list of milestones with short descriptions, made myself available for questions, and let him go at it. For the other, I parceled them out a couple at a time clearly delineating the expected inputs, outputs, and a very rough testing scenario. Both developers met the first couple of milestones quite well and quite quickly. A bit farther along, the one with the long list started to falter. Eventually – due in some part to a life-altering move – the remaining milestones got away from him. Alternatively, the second developer with the clearly defined tasks managed to reach most of the milestones after a revision or two. His problems consisted of incomplete testing and not always generating a complete release for distribution.
Neither of the developers' problems was a reflection of his talent. It was purposely set up to determine which style would work best for each of them. Some people need a very hands on approach to get started and to know their tasking. Others simply need to be checked on every so often. Which types are your developers? Don't bother asking them in an interview, watch them work.
Yesterday, I discussed estimates and project plans as a science, but they are also an art. You can use a variety of methods to make estimates and most attempt to reduce the process to filling in entries in a spreadsheet. In reality, it doesn't work that way. The project manager must delve into their own experience, the experience of the team, and their experience with the team to create an estimate. Quite a while ago, I was working on a team at the Library of Congress. During one quarter, the PM laid out all of the estimates based on what he thought. We worked diligently on them and I don't think we made a single one. Being a bit frustrated, but having an open mind, he let us make our own estimates for the next quarter. Not only did we meet all of them, but we managed to get slightly ahead of schedule and complete a few off-schedule things. Were our estimates just high/padded? Maybe. Were they met? Yes. Now, which is more important?
Team dynamics are the final point that I'll address here. Peopleware addresses this better than any source I've found so far. Do you have toxic people in your organization? Do you have people who simply can't work with others? Can't meet deadlines? Can't interact with customers? You either have to address those issues or get rid of the person. When I covered Hostile Work Environments quite a while back, I discussed it mostly from the point of view of a manager's hostility to an employee, but it can go the other way around and especially across.
At a position quite a while ago, I walked near the room where most of the developers sat. To my surprise, I heard shouting and found two of the senior developers yelling at each other. I was stunned and – probably somewhat foolishly since it was a new job – put myself in the middle to interrupt the situation. I told each of the developers to talk through me to each other and we started talking about what was going on. I was able to determine that the bulk of the problem came from the fact that they were almost identical in seniority except by a span of 2 weeks. Therefore, when rewards were given like new monitors, new computers, etc, the *slightly* more senior one had first pick. I won't go into the absurdity of treating basic tools as rewards, but that's beside the point. I was able to restore relative peace and from then on, both were aware of the issue that had previously only bothered one of them.