Many people confuse “project management” with “schedule maintenance,” and treat project managers as if they were just bean counters. I suspect that one reason for this is the emphasis that many project managers on tracking projects. The project manager needs to control the project, but a big part of that is keeping track of every single aspect of the project… right?

Well, not exactly. The two most important reasons we track our projects are to see where we are with respect to the project plan and to have historical data so that we can estimate when building future project plans. The tracking itself has its uses — making each individual team member more aware of his or her contribution, for example — but these are subordinate to the impact of tracking on current and future project plans.

When looked at from that perspective, the question of how to track progress and exactly what to track becomes easier to answer: take whatever system we used to create the project plan and make that the baseline. Then have a periodic (weekly, biweekly, monthly, etc.) meeting to compare the progress done so far against the plan and update it to reflect the actual work done. By the end of the project, the PM should have a series of deltas: the baseline project plan, then how that plan changed over time.

At the end of each project phase, hold a phase-end review to look at how accurate the plan was. Which estimates were accurate? For ones that were not accurate, what happened? Write these reasons down. At the end of the project, hold a post-mortem meeting (or, ideally, have your QA manager hold it, since that really ought to be a QA function!) to analyze the data and come up with a final report that summarizes all of that. Then next time the team gets together to build a project plan, make sure everyone goes back and reads the post-mortem reports from previous projects.

When project managers think about tracking information as a way to gain insight into how well the project was carried out, they can turn tracking from a dull bean-counting Lose Weight Exercise into a useful and important project activity.

I’ve been doing a lot of work with Sarbanes Oxley governance compliance lately. It’s interesting how many similarities there are between what it takes to put good accounting and financial processes in place, and what it takes to do the same for software engineering. I’ve found that many of the core project management principles — transparency, honesty, “doing it right” all the time — which Jenny and I write about are very important in accounting and finance as well. So I guess I shouldn’t be surprised that we software project managers can learn something from our cousins in the accounting discipline. They’ve identified an important idea which I’ve encountered many times in software enigneering, but which I’ve never had a name for: “tone at the top”.

Essentially, if your senior managers don’t have the right attitude — if they don’t honestly support the idea of transparency and good practices — then that’s an reliable leading indicator that there are more serious problems down the line. You can fail an audit if the auditor finds that your company has poor tone at the top.

In an organization with poor tone at the top, the senior managers are simply unconvinced of the value of good practices. They will often reject the ideas of transparency, honesty and measurement. They run the organization based on gut instincts rather than sound planning, and they reject attempts at improvement. I suspect that the reason this is a more recognized and discussed problem in accounting than it is in software engineering is that there are codified ethics principles and more visible consequences. Poor tone at the top in a software project manifests itself in micromanagement or lack of leadership, which leads to project failure. That may sound serious, but in contrast, poor tone at the top in accounting manifests itself in ethical breaches and fraud, which can lead to shareholder revolt and even jail time for executives. If project managers could go to federal prison because they lied to their stakeholders about the project schedule, we would see much more transparency in software organizations.

The “tone at the top” problem may sound very familiar to anyone who has tried to put a good practice in place only to find resistance from the boss. A basic tenet of software project management is that a project manager has no hope of putting better practices in place if his company’s senior managers aren’t behind them. I’ve talked to many project managers who recognize that sinking feeling that they get when the boss — who previously said he was completely behind the PM’s effort — did an about-face as soon as he heard a complaint from a programmer or stakeholder about the new practice. It turns out that that’s a classic example of bad tone at the top. The next time I need to talk about that problem, I’ll have a name for it!

Jenny and I are working on an article about how open source projects have such great practices. We’ve been talking a lot about what corporate IT can learn from open source, and what kind of chronic problems routinely and repeatedly happen on corporate projects. Our idea is that open source projects adopt practices which corporate IT teams can adopt as well. But thinking about poor practices on project teams really got me thinking about another serious problem in IT projects: micromanagement.

I have a hunch that a lot of people on development teams who are micromanaged and don’t even realize it. Like a lot of terrible practices, they just think that it’s part of being a professional software developer. I’ll bet that an “Are you micromanaged?” checklist might help open a few eyes. Here are a few things I might put on such a list:

• Do you feel like you’re often blamed for not doing things you don’t have time to do?
• Are you routinely asked to stop what you’re doing in order to take care of something “urgent” or “an emergency”?
• Does your boss often fail to even follow up on your “urgent” or “emergency” work?
• Is there a rule that you’re not allowed to release anything without sending it to your boss first?
• Does your boss make a lot of changes to your work?
• Is your boss constantly tapping you on the shoulder, wanting to talk about the last two hours of work you have done?
• Have you ever been reprimanded for doing something differently than how your boss would do it, even though you got the job done in a reasonable amount of time?
• Do you feel like part of your job is reading your boss’s mind?
• Do you spend more time reporting your status than you spend doing your job?
• Do you feel like you’re not allowed to make mistakes?

I think a lot of people have trouble recognizing symptoms of being micromanaged because they’ve never worked any other way. In fact, I have a feeling that if someone was able to conduct an accurate survey, they would find that a surprisingly large number of managers are micromanagers.