Project Management (Not Too Boring)

So I'm learning more about project management from my peers and from the expensive contract Senior Project Managers we meet with occasionally. What I'm learning is different than I expected--it's lessons about flexibility and analysis of the specific situation you're in, not just applying abstract formulas and rules from the Project Management Book of Knowledge (yes, that is the actual title). In the end, I think the organization you're in really makes this type of process possible, or not.

As I understand it, the official parts of managing a project are to figure out

- The requirements
- What work you need to do to meet the requirements
- How long the work will take
- Who can do the work and when are they available
- How you will test it
- How you roll out/deliver it

They're all equally important.

What's my experience with this method in different organizations? At Not Big Blue, my former mainframe company, there were requirements written for the projects and plans created for the work. Testing and delivery were well covered. There were two problems, though. First, everyone created plans that ended at the date suggested by upper management, not the date they might actually finish. Second, whenever things didn't go well for any reason, the plan was changed so it looked like there never was a problem.

During my first years at Whatever You Want Widgets, my group was run by a very disciplined Project Manager. Okay, she went too far sometimes and couldn't get the upstairs people to ever completely buy the idea of project management, but she set up a methodology for launching web sites that was the basis for launching almost seventy new sites on time and according to requirements. Back in those early days we presented our company as people who knew the internet and our partners respected that, negotiating the requirements and delivery schedules for their various sites. For the last few years the partners starting ignoring most suggestions and dictating schedules that allowed for some collection of requirements (depending on the project), a little bit of planning for resources (more like scrambling), no schedule for the work beyond the end date, no real testing and exhausting late-night rollouts.

Lawyers R Us has put a lot of money into project management. That doesn't mean things go perfectly because they don't. Some development groups create large products with no documentation so no one's sure what they have, business people don't like to write requirements, and there is no history in the company culture of groups talking to each other about the product they are getting integrated into. But we're working on all those issues and everyone involved knows it's necessary to do the planning so they're doing it with surprising enthusiasm.

I think an important factor in our sucess at Widgets was mutual respect among the team members. The project managers respected everyone's opinion as they assembled requirements and created schedules, and management respected those schedules and based their decisions/communications on that information. Everyone in the group respected each other's contributions and their difficulties. Everyone felt like they were in it together.

Those early days at Widgets were fun and I miss them but I think things will go well at Lawyers because the management support and mutual respect are there too. We'll see.

*******

Thanks to Soccer Girl, the famous Coed Rec player, for mentioning my awesome goal on Wednesday night. I don't score many goals and I think this one was the best. In return I'll feature her next goal. :)