A PM with a Different Approach [Philippe Habib]

In the 20 plus years of writing software, I have acted as a project manager (PM), as well as having worked for a good number of PMs. A recent experience really made me re-evaluate what makes for a good project manager.

Most of the project managers I have worked with acted as the tie-breaker, or opinion of last resort when it came time to decide on features or schedule. They’d come up with a schedule, often guided by when the client wanted it done, and a list of features that the client desired, and keep tabs of progress during weekly meetings as time went on. Everyone on the development team always had a great relationship with them. Note: I mean client in the largest sense; either Marketing or an actual customer.

This all changed when I worked with a PM who had a very different approach. He started off with a list of features that the client requested, and asked each engineer to commit to the time required for every feature. Then, he turned that into a schedule and got the client’s approval.

Starting at that point, engineers were held to the schedules to which they had committed. A schedule slip was not treated as an inevitable part of the development process, but as a real problem that needed to be addressed and remedied. Engineers were asked to find ways to recover lost time without abandoning other commitments made to the client. This PM wasn’t a good buddy who drank coffee and ate doughnuts with us for an hour a week at project meetings. He was a tough taskmaster who pressed us to deliver what we had committed to.

During these same meetings, we’d often hear the client give feedback on the progress as they saw it, and maybe ask for feature changes or additions. This PM defended the original schedule just as doggedly in those instances. New features or changes would mean, at the very least, some time spent evaluating the impact on schedules and deliverables. Maybe it would mean more time, or dropping other features, or maybe even less time, but nothing got committed to without a thorough evaluation.

At the cost of losing a good buddy during project meetings, we gained a clear view of expectations and some strong protection from the feature creep that kills schedules, and make projects drag on, and rob everyone of the feeling of completion and a job well done. Besides, we could always be friends outside of the project meetings.

______________________
Philippe Habib consults on embedded device design and firmware. Prior to consulting he has worked for Oracle, IBM (lotus/cc:Mail), Apple, and several startups. More information can be found at www.phenomasoft.com.