Rick commented on my last post that some engineers think that status checking slows them down. Mark said that engineers push back on demos and pointless measurements and then said in another comment, “progress metrics can always be free.” Here's how and what I look for, to determine status.
If I'm managing a traditionally-planned project, I have weekly status meetings with everyone on the project. (For large projects, each project lead has these meetings and I meet with the leads individually.)
I ask people to explain the status of their work and what they'll do next week, and how they'll track status. I request that people think of their tasks as to-do lists with inch-pebble level work.
I won't put their inch-pebbles into the project schedule; that's just too complex and I'm not about to track each person's work. I ask people to monitor when they are stuck and to tell me if they need help in some way.
Asking for help is fine. Floundering is not.
I request that people peer review each other's work product (unless we have more formal reviews in practice), so that they get peer feedback about the quality of their work.
If someone's working on a big work product, I ask them to consider what they want to show me: interim designs with chicken scratches, performance measurements of algorithms, number of scripts they threw away, something that shows me progress.
Since the engineers determine their tasks, deliverables, and when they need help, I don't usually come across as micromanaging them. I hear them describe their work products, when they've had problems or needed help, and I have a fairly good handle on the project state.
Every so often, I run across an engineer who thinks his work requires privacy to complete. When that happens, I explain that I don't know how to manage the project adequately with his need for privacy, and what is he willing to show me or give me so I can see his progress.
That doesn't always work, so I ask him when his deliverables will be complete. If he gives me a date of more than two weeks, I explain that's too long. In many projects, we can afford for one person to be off by two weeks, but I've never worked on a project where any single person could slip a deliverable by more than two weeks without affecting the entire project.
I'm willing to give the engineer the benefit of the doubt, if he can come up with deliverables that are fewer than two weeks in duration, and maybe I can wait to see the status at the end of those two weeks.
If an engineer can successfully deliver work every two weeks, I'm still nervous, but I can manage my nervousness. Once an engineer misses a deadline, we negotiate a different way to track tasks and status.
So far, this has worked well. I've run into people who hated this, but we figured out a way to deal with my need for information. (I meet with the engineer whenever the engineer wants it, as long as it's sometime within the normal work day.)
On traditionally planned projects, I send out an email every week explaining the state of the project. Project team meetings are optional. Problem-solving meetings for the project are not optional. (They are two different meetings.) I keep people focused on the end goal and aware of interim milestones.
On agile projects, status is much more obvious to everyone on the project. Since there's a standup meeting every day, everyone explains what they've completed, obstacles they've run into, and what they're going to do. Since I still have to prepare a report to management on project state, I send that by email to the project team also.
When I look for tangible work products, I look for: checkins, designs, how many designs were rejected and why, data about performance or reliability (depending on the product), algorithm development and debugging, people working together on pieces of the product, people working alone, how many people are actually working on this project, number of pizza cartons or other food containers, how long people seem to be at work.
If I think there's too much overtime, I ask people what's happening and what we should do about it. I really want to prevent people from making stupid mistakes.
When I explain why I need information and the level at which I need the information, most engineers are willing to work with me and I obtain visible progress about the project state.