I spent a couple of days this week creating a deck that draws upon a lot of the knowledge I gained from working at Booz Allen Hamilton and Booz & Company from 2005 through 2008. During that time I was lucky enough to work with a few program management experts like Eric Kronenberg. I learned about creating a schedule by determining tasks and activities, assigning resources to them, and creating dependencies. I learned about cost accounting and budgeting, the critical path, crashing, forward and backward passes, and also risk assessment.

I worked with clients who were manufacturing large items for the military. When I say large, I mean really large, like, submarine-size, or airplane-size. Bigger than a breadbasket. These items were very complicated and required significant quantities of tiny and huge acts of labor and tiny and huge pieces of material to all come together to create something that flew, swam, drove, or otherwise propelled itself across distances. Small schedule slips could make or break the whole process. There were teams of people assigned by our clients to manage the schedules, and they coordinated frequently and significantly with each other.

One of the last clients I worked with was a company trying to take on a new project that was in their industry but outside of their expertise. They were very optimistic about the revenue potential of the new project until they got a month and a half behind-schedule, and that equated to going more than 30 million dollars over their budget. They were not practicing sound project management. Our team was there to train them about what that is.

I have been thinking about applying some of the things I learned back then to the way we do scheduling and budgeting here at Nuru since I have been here, but the work we do is very different from the work that my old clients do. Although it is complex work with many moving parts, the output of our work is incremental change across many factors in human beings’ lives rather than tangible large pieces of equipment for which the indicator of success is binary (they either work or do not work). Also, I should note that there already is a good deal of rigor in the way our work is currently managed. All team-members know how to develop schedules and budgets and manage to them.

That being said, there are a few concepts from my old field of work that Aerie and I feel are worth introducing to the field staff in the next Foundation Team training at the start of May. So, I got to build a deck this week that reminded me of my old work. During the training, we’ll talk about critical path, dependencies, resource loading and just one or two other small topics. Nothing too excessive or crazy, and nothing specific to the world of manufacturing.

I am interested to see how these topics are received by our staff. I anticipate that they will like it. Maybe I can eventually convince my old colleagues to use our success with program management as a good example for people who are trying to build airplanes. Who knows?

 

Posted from Cincinnati, Ohio, United States.