One criticism of my book was the omission of a chapter on multi-project or program management. At the time, I didn't think I knew how to write that chapter. Later I made amends with a paper on use of critical chain multi-project management based on my experience at 4thpass/Motorola using the user experience group as the synchronizing drum or constraint.

However, on reflection, I did know how to write a chapter on agile program management because Sprintpcs.com's PMO (program management office) had largely solved the problem but I didn't recognize it.

Back in the day, I wasn't a regular attendee at the PMO meetings. I typically delegated it to one of my staff. That's my excuse for failing to recognize how well the PMO team had done to create a truly agile opportunity for multi-project coordination and resource contention. They booked a large meeting room for 2 hours on a Wednesday evening. I can't recall the precise time but 4pm to 6pm jumps to mind and occasionally the meeting would run until 7pm. Each team in the business unit and the business owners - senior managers in the marketing department - would show up. The development groups would have the dev manager or team leads and from the project management side either the GPM or some of the PM's. Other functional groups such as user experience or testing would send a representative who had resource management as part of their role.

The PMO would bring a very large wall chart size plot of the master schedule for the business unit. They would lay it out on the meeting table. This was a very large plot - perhaps 12' long by 5' wide. The attendees would then simply swarm over it and mark it up with new projects, changes to existing plans and so forth. As they were doing so, others would see the changes which related to them and start to debate them. Small groups would form to resolve or discuss conflicts. This was a self-organizing meeting. There was no formality to it. Multiple groups would form simultaneously. Individuals would move around from one group to another. It looked and felt like a free-for-all. It was noisy. It was uncontrolled. It was highly productive. People would come and go - if they had no further issues they might leave early. Others would turn up late, delayed by other commitments. Towards the end of the time period, the manager of the PMO (there were actually two of them sharing the responsibility - Connie and Keith) would call the meeting to order and summarize the changes made to the master schedule and ask for a consensus from those still in attendance. The marked up schedule would be taken away and within a day or two the PMO would publish a new electronic copy along with the minutes of the meeting. This process would be repeated every week.

Issues raised from the meeting - such as insufficient resources, or resource conflicts which could not be locally resolved, would be taken by the PMO. The manager would then raise them with colleagues at the managers staff meeting with their director or VP. Some might be serious enough to be escalated to the monthly operations review with executive leadership. And provides me with a nice segue into my next posting about aspects of Sprintpcs.com that were done right - the operations review. Until then...