Zentrope

notes on project management

The following are notes I wrote up on Project Management some time ago. Obviously not those of an expert, but having been subject to the project management of others, I’m certainly an expert on what I want.

• The most important thing is to mediate between the waterfall needs of business planning and the iterative needs of software developers. What to communicate, and even more importantly, what not to communicate.

• Separate issue trackers. Product tracker for business and customer requests and problems. A separate system organized around code components. If a business request requires changes to three components in a distributed system, that means three separate tickets in that system. A project manager deals in terms of the first, a tech lead mediates between the two, and devs use the second system only.

• Keeps a regular schedule of status meetings with biz types and code types, but not at the same time. A project manager (developer focussed) needs to bridge the gap between the business/product world and the developer world. Both are customer focussed, concerned about over all strategy and the moment to moment tactics of execution: it’s just that the language and materials are so different, and, well, the strategy and tactics are also different. Recognize this. Embrace this.

• Always reminds developers of the overall strategic goal. Ad nauseum. They must needs be face down a lot of the time, and their strategic goals are often about how to make the software maintainable and extendable over time. These are not the same goals as the business as a whole, so they need to be reminded because knowing the business goals has a direct impact on their own software goals. Or, sometimes, it doesn’t.

• Never ever think that adding more people will solve anything unless there are new concerns. If the project discovers it needs an extensive, distributed relational database solution, then you can add a DBA. Not only does adding people disrupt a team due to the fact that the new person isn’t familiar with the problem, it disrupts the delicate emotional and political balance a given team has evolved in order to work together. Beware. In fact, don’t do it unless the team asks for it.

And that’s about all I had written in my notes. I think each one of those is quite arguable, but I’ll have to save the extended explication of each of them for some other day.