Sunday, November 16, 2008

The Morning Shuttle, an exercise in Project Management

A few months ago I posted about the necessity of including uncertainty in estimates, for software building and todder shuffling in the morning (originally posted on the Flightpath blog and then reposted here). I've realized over the last few weeks that this morning routine is not just a matter of making sure there is enough padding in the schedule, but also includes exercises in risk management, scope and change control, and lots of other good fun project management stuff (in bold).

So, I just started working at a new place and even though they already told me that I can have the schedule flexibility I need in the morning, I figure I should try to make a good impression and get in as close to on-time as possible.

I took a close look at all of the steps involved in the morning routine and tried to figure out where I can trim the schedule. First, I should mention that three mornings a week I need to go three stops on the subway to shuttle the almost 2 year old to daycare (while dragging the 4 year old along) and then get back on the subway and go backwards 7 stops to get the 4 year old to preK. At that point, I walk back over to the subway and take the 35/40 min ride into Manhattan. I should emphasize here that this is ALL done on foot, no strollers and sometimes the occasional baby-carrier. And this is also working with the early (and not so early) drop-off times for daycare and school (my daughter's preK does not allow them into their classrooms until 8:55am). The other two 'easier' mornings are just making the trip to preK.

So, my first step was to identify my risks, figure out what events will have negative impact on my schedule and how I can mitigate those risks:


  1. Getting the girls dressed - can take anywhere from 5 to 15 mins, depending on how organized the dresser is, how picky the girls are, and how quickly I can find the matches to those "@#$%" socks. Response - pick out the clothes the night before, and try to get better at keeping their stuff organized.
  2. My own morning routine - can take up to 30/40 mins if I need to shower after exercising, or lose time hunting around for my own clothes. Response - give up on trying to exercise in the morning and do that and shower at night. Try to also pick out clothes the night before (including socks!).
  3. Lunches - not a huge impact, but can make the difference if I need to shave 5 mins off the schedule. Response - make my 4 year olds lunch the night before.

What risks do I have no control over?

  1. Trains - the time it takes for them to arrive and get us where we need to go.
  2. Bus - if it comes at all, and how long it takes us to get where we need to go.

What should my schedule goals be to keep me on track?

Major milestones:

  1. 6:30 am - need to be up by then to ensure we get moving early
  2. 7:15 am - if I want my younger one to walk to and from the train, then we need to leave enough extra padding time for her slower walking. Must be out the door by this time.

So, I've got my risks and milestones noted, now what happens in the morning when something unexpected slows us down? You can read the previous post I noted in the beginning to find out more about those, but then it comes time to figure out how to modify the activities in the morning routine to trim down the schedule.



  1. Walk or wear?
    Although my almost 2 year old would much prefer walking to and from the subway and I want her to have this opportunity to improve her walking and get good exercise, it can make the difference between a trip to daycare taking 25 mins and 45 mins. When I can I let her walk, but when we're short on time I'll strap her on my back and go (and haven't needed motrin yet, thank-you!).


  2. The Bus
    Although I have absolutely no control over the bus that can take us the 10 blocks from the subway to preK, if I see it coming and its not totally packed, I take it!


  3. Skip the trip into the school
    I started to realize, that (ironically enough) I am both the only working mom in my daughter's class and also the only mom to actually walk her to her classroom (and not drop her in front of the school and drive away). So, we compromised and I take her to the door of the school, say my goodbye's, then one of the teachers takes her to her classroom. This can save 5-10 mins on some mornings.


  4. Extreme skipping the trip into school
    The school has a very nice security guard, and any kids dropped off before 8:55 am are told to stay at the security desk until they are allowed to go to their rooms. I felt kindof guilty at first, but leaving her at the security desk seems to be the only way to win back some time before I get back on the train.

This has all shown me (again and again each morning) the importance of making estimates in ranges, keeping project risks on the agenda at all times, and finding ways to trim scope when possible or atleast not adding to it.

Have I made it in 'on time' yet? The first morning I was 5 minutes late, the second morning about 20 (the second morning was the double drop-off day). I'll keep working at it, again not because I am getting pressure, but it's actually a fun challenge at this point.

Now, if it was only this easy to keep large software projects within 5-20 minutes of their target completion time!

Sunday, November 2, 2008

The difference between saying you're sorry and meaning it: Formalizing the lessons learned process

I just read a great post on the pm411.org site, titled "Avoid the Same Old Mistakes by Focusing on Lessons Learned". The guest blogger is Duncan Haughly, and he writes about the importance of taking the time to review the good and bad of past projects and learn from them. He also discusses how organizations can create a culture "where people not only take the trouble to learn from past projects, but actually want to learn. A culture where we apply best practices and discard bad ones."

This is such an important idea, and he did a great job of outlining the key steps in making it happen successfully. Too many times you'll hear management say "Oh, that won't happen to us again, we'll do X or Y differently next time". Then the experience fades and months/years later the project team finds itself repeating the exact same mistakes. Steve McConnell in many of his books stresses the importance of reviewing lessons from past projects at the beginning of each new project. People might not always see the value in spending the time reviewing these important lessons, because as Derry Simmel says in the article that Duncan Haughly references, we're too much in a culture of 'let's go and get it done' and not 'let's make sure we plan properly and review lessons from the past before going forward with this new project'.


This reminded me of something I am going through now with my 4 year old. I should be grateful that atleast she is good at saying she is sorry for something, but what I am trying to get her to understand is that repeatedly saying sorry is ok, but making sure you think about what you did and the impact it had and try your best to not do it again is even better. It might be a lot for a 4 year old to fully understand, especially because many adults don't even get it.


So of course this whole idea is not just limited to software projects, it can apply to all areas of life. It's better to take the time to reflect on what was done right or wrong and learn from it than continue to repeat old mistakes.