The Last Line of Defense, in Soccer and Bug Catching...

I was a goalkeeper on my soccer team from about 8 years old through college. I didn't always like being the goalkeeper, but my coaches and teammates always liked putting me in goal anyway. It was stressful, nerve-wracking, and either very boring or way too exciting. Sure, sometimes I had my hero moments when I made a really great save, but other times I messed up and let a goal through that should have never gone through. Whenever I had a bad game my parents would remind me that "the ball has to pass through 10 other players before it gets to the goalkeeper." So, 10 other people messed up before the ball got to me, unfortunately my mess up as the goalkeeper was the most memorable and dramatic one.

So, how does this relate to a software project?

Well, the ball is a bug and the soccer team is each member and phase of the project. In many cases the bugs that are found post-launch are blamed on programmers or testing team, when in fact they could have been caught much earlier on.

What is the first line of defense? The offense.

From the very beginning, be sure to clarify requirements with the project stakeholders, the client or the end users. When possible, use prototyping to demonstrate how the application will work. Using a prototype will hopefully dig up more questions that will lead to defining the product more carefully.

Next, as you move back to the mid-fielders, make sure the technical, functional and design specifications are closely married to the requirements. Review specs with the client/users to ensure that everyone is on the same page with what the end product will be. A bug can just as easily be created in this phase of the project, by missing a critical requirement or misinterpreting the user's needs.

The defense is the programming team. Make sure the level of quality is consistent in this phase by holding peer code reviews, functionality checks and regularly merging all of the elements back in to be tested together. Programmers who develop independently might build perfect pieces of an application, but if not brought together often enough those incongruous pieces are useless.

The last line of defense, the goalkeeper, is the tester teamed with the programmer assigned to fixing those bugs. Of course this stage is critical, and to ensure the highest level of quality you want to make sure there is proper testing documents, adequate time to properly test and fix and then test again. Ideally there will be a full system test each time a new set of bug fixes is rolled out.

All of these players in the project are human, and they can all make mistakes. I haven't yet found a software solution to ensure that requirements are completely met 100% from start to finish, without some level of human intervention.

So, next time one of your end users finds a bug or the opposing team scores a goal...don't just blame it on the goalkeeper, take a look at a whole picture and figure out where else the mistakes could have been made and how to avoid them next time.

(as the referee whistle blows, the next play begins....)

good luck!

"Sending Confirmation", the slow and painful way

I continue to be amazed by the processes used at my older daughter's school. I have no doubt that they are doing an exceptional job teaching her and providing her with all of the tools she will need (and in the end that's what's most important anyway), but sortof just like one of the administrators put it to me a couple weeks back, when referring to technology "it's like the new immigrants are teaching the natives".

Natives = my daughter's Pre-K class

New Immigrants = their teachers

So, a week or so ago I get a call to schedule an appointment for my younger daughter to have an 'interview' for preschool. Won't use this space to get into the 'hows' and 'whys' of a preschool interview, but I'm sure they will see she is not a violent threat to her future classmates and will be happy to accept her. So, I gave the registrar my preferred date and timeslot and she said to me "Ok, you've got it, I'll send you a confirmation."

At that point we hung up and I thought for a second, "wait, does she have my email address to send the confirmation?"

And then for a quick happy second I thought "well, they must have a database of all the students and families and I'm sure my email address is in there."

That was just a quick second because the email never came and after checking my junk folder a few times I gave up on it ever coming at all. The confirmation was actually coming (gasp!) via postal mail. I won't go into the thought of how many trees their are wasting handing their communications via paper rather than electronically, but it's also just so inefficient when it comes to sharing information quickly!

This first call took place on a Friday. The following Monday morning I called back because I realized that I wanted to change the appointment and push it back two days. So, we found a new date and she penciled me in (literally!)

She then said "you can ignore the confirmation that you were sent now that we have changed the date." Oh, thanks for letting me know, that confirmation hasn't even arrived yet.

What I would suggest to them to save them time, money, paper, trees, etc... (any one of these will do):

• Send me an email! Save the paper and postage.


• Setup an electronic calendar that can be shared when appointments are made. Use Google calendar and shared events, or an Outlook calendar with meeting invites.


• If sharing the electronic calendar is too complicated, than trust that I will write down my appointment (or enter it into my electronic calendar) and you will also write down yours. We are all adults here (and this can be the first 'test' to see if my younger daughter comes from a family organized enough to be a part of their school).

I should remind myself that I spend most of my day in a happy technology bubble, and I shouldn't have such high expectations of the teachers at the school. I don't expect them to walk around with blackberries, communicate with other teachers via Yammer, and share their class information via Ning sites. But, maybe little baby steps....try to incorporate email a little more into your regular communication.

What if they find out that I'm criticizing them, and decide to keep my younger daughter from attending their preschool??

Something tells me they probably don't surf the blogosphere much, so my thoughts are safe...

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!

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.

Guest blogger as "Working Mom of the Week!"

Check it out here...
"Being a Working Mom can (sometimes) have its perks"

The best project specs I've seen so far -- by Dunkin Hines

I'm lousy when it comes to cooking & baking. I won't go into the stories of muffins gone wrong, chicken not cooked right, even hard boiled eggs not really hard. Thankfully my husband does the cooking and he's great at it. I'm the one who builds the furniture, deals with home repairs/renovations (not always so well), and smashes front 'yard' concrete with a sledgehammer so that we can make way for a little garden (should have seen the neighbors galk when I was pregnant and working the hammer!).

But anyway, I'm not much of a cook. But, when it came to making cupcakes for my daughters little party, I felt like it was my duty as a mom to make them for her. We bought the Dunkin Hines Devil's Food mix and with the instructions from the back of the box right in front of me, I nervously get started. I always get tripped up with the variations between baking temperatures for glass & metal vs dark or coated pans. But, since this time I was making cupcakes my situation was a little different.

Since these days I often find myself relating something I'm doing to something about managing software projects, I suddenly was thinking of project specifications. I was the lone programmer working on part of an application, and there was no project manager or information architect to answer my questions that came up...

- How do I treat the pan if its a cupcake pan and not a cake pan? Do I grease it, just put the little paper cups in, or put grease in the paper cups?

- How much batter do I put in each little cup? How many cupcakes should this make?

- What if I don't have vegetable oil, will another type of oil do?

Those of you bakers out there are probably laughing at my silly questions, but because of my bad history I really am a very timid baker. Fortunately, I had wonderful specs to work with. The back of the cake mix box had very clear instructions and color pictures showing exactly what I needed to do. There were accurate illustrations of each of the ingredients needed in addition to the mix, and each of the three main steps were broken into smaller steps with clear bold red headings. There was a little table at the bottom that showed what baking time is needed for different size pan and even my own (yes!) 24 cupcakes. If I had a question about something that seemed to be outside the realm of the normal baking process, in most cases the answer was there on the box.

I'm reading "Rapid Development: Taming Wild Software Schedules" by Steve McConnell right now, and am always impressed when I see the charts plotting out recommended times to be spent on each area of the project. In this and all other books I've been reading lately, there is always more time devoted to design and specification for the project than on coding. This seems consistent regardless of the Lifecycle model used (unless its the "Code and Fix" lifecycle). The general theme is that when enough time is put 'upstream' into planning through how things should work, both with interface, technical functionality, etc...then less time will be spent later 'downstream' with rework, bug fixing, or worse...cancelling the project all-together.

Did I have to cancel my cupcake project? Definitely not, they came out fine...a little lumpy but definitely edible.

Did I have to do any rework later on? A bit, I was a little too conservative with my batter amounts in the beginning so I had to go back and add more to the small cups at the end.

Was there any bug-fixing? Nope, I had all the right ingredients in there and the correct amounts of them.

All thanks to an excellent specifications document.. thank you Dunkan Hines!

Life in the slow lane... (for toddlers and team members)

Last week I was taking my younger daughter to daycare and decided that since I had extra time that I would let my younger daughter walk on her own rather than strap her into my back carrier. She'll be 2 in December and seems like all she wants to do these days is walk (she was a late walker so she must be making up for lost time). She was thrilled that I let her walk and loved the morning stroll. I got a kick out of watching her walk to the subway, she stopped at all of the flowers and touched them, picked up leaves and dropped them to find new ones, tried opening gates and going up steps. It was a true pleasure to take a slower walk with her, and not only was it great for her to get more practice walking (she's a cross between a zombie and a drunken sailer when she walks and even more when she tries to run) but also for her to get a chance to take in her surroundings and not be rushed off to daycare.



This reminded me of something that seems so crucially important with software developers, designers, QA, anyone involved with the project...which is getting the opportunity to 'slow down' and learn something new. Seems like everyone in this industry is getting pushed along and constantly pressured to get as much work done in as little time as possible, since that is what appears to be the most 'productive' way. After reading Peopleware: Productive Projects and Teams and Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency I completely see and understand how pushing people to their limits can have the reverse effect on productivity and actually cause more harm then good. Not to say that it didn't seem obvious before, but those books helped put some numbers behond the theories.

I've heard that Google programmers are all encouraged to pick up a side code project, try something new, research something, or build something that's never been built before. Sometimes the end result becomes part of one of their applications, sometimes it doesn't. But, even if it doesn't directly contribute to one of their applications, it can have an incredibly positive effect on programmers morale, creativity, loyalty to the company and productivity while they are doing their other work.

If we get past the idea that we need to make sure people are working 100% of the time and give them some time slow down and learn something new, I'm sure the payback will be totally worth it!

The last step in dropping the "a"...

So, without going into too much of the details, my husband and I knew that we liked the name "Lila Ruth" for our daughter who was born in December 2006. So, when it came time to fill out the paperwork in the hospital, I realized we never discussed how we wanted to spell her name. I liked "Lilah", but I figured since my husband wasn't in the room at the time I should give him a call and see if he had any opinions. He said he really liked "Laila" because he had seen it in a book somewhere and thought it was a pretty spelling. I figured I'd go with his suggestion, he is the english teacher after all and I'm just a software project manager...what do I know of names?!

When we announced the name to our friends most people said "Layla! What a beautiful name!" (think the Eric Clapton song). So, immediately we realized we had a problem. We didn't want our daughter going through life having people mispronounce her name all of the time. My husband was especially sensitive to this, since he was one of very few Garfinkels in Indiana and people always got his name wrong!

As time went by, I decided I didn't think it was such a big deal, but my husband still insisted on getting the name spelling changed. I told him that if he wanted to do it then he needs to do it soon, the older she gets the more documents are in her name (she already has a facebook account, a gmail address, etc.). Seriously though, I wanted to make sure the change was done before it came time to fill out preschool applications, which would be this year.

So, my husband committed to getting the process done this past summer. He downloaded the application, filled it out and got it notorized, then went to the civil court and waited in line to get it accepted. He then was given a date to go back and appear before a judge.

The last part of the process is to 'publicize' the name change, and this is where it gets funny. We must pay for an ad in the "Irish Echo" newspaper (apparently is has a circulation of 26,000 which qualifies it as a large enough audience) and announce that our almost 2-year old daughter is now "Lila Ruth" and not "Laila Ruth". I know that all of her friends who read the Irish Echo will appreciate that we reached out to them. Nothing against the Irish readers of the paper, but I don't understand how this will help us get the word out to the people it matters to.

In these days of super high technology and super fast communications, it seems so silly to put an add in a newspaper about a toddler's name change. There's so many other much more interesting and effective ways to spread the word. I see people announce their pregnancy on facebook, or watch their status changed from 'dating' to 'single' (hopefully not the same person who announced their pregnancy). I learned of someone's divorce through my newsfeed....that was wierd. I can easily post a question to tens of thousands of project managers on any number of social networking websites. I'm on a Brooklyn parents listserv of several thousand that's so active that I don't have the time to sift through even the daily digest version of the notices. Lately I've been pretty hooked on Twittermoms, what a wonderful way to connect with people!

So, how else could I tell the world that Laila is now Lila? Well, I could post on my facebook status ( I don't have 26,000 friends, but if I made my profile public for the day then more people might see the news). I could send an email with the news to everyone I know and ask them to forward the email to 20 of their friends. I could post the note to the neighborhood listserv, and easily get 7000 and probably some people who might actually know Lila! I could tell all the project managers in my networking group or all the mommies on Twittermoms, and add a note to twitter just to top it off. All of these things would not only get the word out faster, but to more people who might have an interest in our news.

Oh yes, and of course...my blog!

Getting my priorities straight (both with project team members and potty-coaching)

Yesterday I was working at the computer and keeping an eye on my almost 4 year old as she was playing nearby in the same room. She needed to take a potty break and is at the *fun* stage where even though she can do the whole business independantly, if I'm around she wants me to stay in the bathroom with her and help out, etc. I know, I know...I should cherish these moments, and I'll regret not enjoying this time more when she hits the stage where I am just not cool enough for her and she doesn't want to hang out with me anymore. But, I'll be honest, I was focused on what I was doing, frustrated that I had to stop, and impatient with her when she was in the bathroom.

She was finishing up, and I found myself nagging her with different tasks:

"Pull up your panties"

"Put the seat cover down"

"Wash your hands!"

"Flush the toilet!"

All those things she knows to do, but since I was in there I felt like I had to coach. I was so busy giving her more stuff to do, I didn't stop to think that I might have been confusing her with all these different tasks, that were actually not in logical order. She stopped for a moment and looked up at me with this look of such total confusion, so I slowed down and started over, this time being careful to be more patient and take it one step at a time.

I find myself in the same position both at home and at work, when I am given several tasks and told that they are all equally important. I don't know what to do first, what needs to be done when, and how to properly manage my time to make sure the important stuff gets completed at the right time. When I saw the way my daughter looked at me, I knew exactly what she was thinking and I've been through it enough times myself.

Fortunately I am not involved in potty training any of my project team members, I trust that they are all fully competant in that area. But, I do occasionally find myself sending over one email after another with this task or that, sometimes related sometimes not at all. I have to remember to stop and think that this puts my team members into that same position of frustration that both my daughter and I were in. I've been good lately, I sift through that list of tasks and send out another note (or even walk over to the person and discuss with them face-to-face...imagine, so low tech!) that will list all of the tasks in order of priority, with any other relevant notes that will help him/her figure out how best to get it all done, without going crazy.

Having just finished and thoroughly enjoyed reading "Peopleware: Productive Projects and Teams", I know the importance of happy, comfortable and focused team members. Since I didn't have a camera handy with my at the time, I'll have to make sure to keep the mental picture of my daughter looking up at me so confused and pin it up at my desk at work, to make sure I don't put any of my team members into that same frustrating position.

Maybe I'm just spoiled - my new calling in PTSTC

Maybe I'm just spoiled by all of the technology that I see and use around me, I work in the technology field after all. Words like RSS, social networking, blogs, email, text messaging, and others are a part of the daily vocabulary where I am each day. And when I get home at night, I get the time to catch up on all of the blogs, feeds, social network site activity, etc. (after the kids are asleep of course).

So, now that my older daughter is beginning pre-k and we have gotten a taste of how her new school works and especially the private minibus system chosen to bring her to and from school each day, I am painfully aware of how spoiled I am with the technology I have at my fingertips.

What DO they have? Two phone lines ( I give them credit for having more than one). No voicemail, no message system to let you know if your child's bus is delayed or has forgotten you entirely (like what happened to us a few times this week). They put you on hold forever and you're stuck there waiting to see when your kid will get picked up, held completely hostage to the phone attendant lady.

What DON'T they have? No website, no email, no efficient communication system. It's hard to even find them on Yellowpages.com or Google Local, sometimes I wonder if they even exist.

What's my perfect dream scenario? The bus company sends me an email the night before reminding me that my daughter's bus pickup will be the following morning at 8:45 am. This is good to do, especially in the first week when things are hectic and the route is getting figured out. This probably won't be necessary every day of the schoolyear, maybe just reminders when the bus service isn't running, etc. Then, the morning of the pickup, I would like a text message sent to my phone to alert me if the bus is behind schedule. I would like to know approximate location, which kid is getting picked up, and how many more need to get picked up before they come for mine. I would like to be able to go to a website and see a live map with the bus on it, and each pickup pinned and the order that the bus will go to them (and it would be extra nice to have the pin label show the name of the family, so that I can call that home to introduce myself and my daughter and help start a bus-riders playgroup).

This is really not so much to ask, right? If I wasn't rushing off to get my younger daughter to daycare and then myself to work, I probably wouldn't mind sitting around dealing with all of the uncertainty of it. But, since I am... then I do. Maybe this is a new career calling - Private Transportation Service Technology Consulting (PTSTC).

Ultimately I will probably cancel the bus service and use the good 'ol MTA and the Coney Island bound F train to get my daughter to school, atleast then I will have more control over when we come and go and it will be nice to see her classmates and teachers each morning. Then I won't have to feel so much in the dark ages when working with these bus people, and guilty about demanding so much more of them.

Reflections on "The Sprint"

I am really enjoying reading the 'Slack' book by Tom Demarco (Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency). It's setting in enough that I am pressuring myself to not do real work right now and write something for the blog instead. He makes many great points, and ones that I've already been trying to push on my colleagues (for example, by ordering one of the support staff to not stay a minute past quitting time and "Go home!").

One section I found interesting was his description of the "Sprint" at the end of a project. He describes one way of handling the sprint, where team members pull marathon weekend work shifts, taking naps on the office couch or overdose on caffeine to keep going. The team will stick it out together until Monday morning, and (hopefully) will finish victorious. Another way is to have people work regular overtime in the last weeks/days before the launch to finish everything up, rather than crashing all of the resources at the very last few days. He explains that each one of these methods has a different effect on the team morale. To do the sprint over a couple days rather than the last few weeks, although exhausting, can create a real bond and almost a 'high' for the team as they pull together their last bit of energy to bring themselves to the finish. The extended overtime will more likely lower the morale, cause stress and problems with personal life, etc.

The description of the weekend marathon sprint brought back memories of college, of the last days before my senior engineering project was due. Three other Mechanical Engineering pals and I had spent the year together designing, building and testing a small low-cost and feul efficient turbojet engine. In the last days before our project was due the engine was built to the best of our ability and we were gathering our reports, writing up our research and putting it into as presentable a thesis as possible (engineers trying to write a paper...funny). We were in and out of the engineering building at all hours of the night, taking turns sleeping and writing, and thankful for the one or two 24 hr takeout places nearby. It was an amazing bonding experience, and we did finish in the end and get our report written, nicely bound and in our advisors office by that Monday at 5pm.

I was 22 back then, and had alot more energy and the drive to do those marathon work sprints. The best I can compare it to now is the first few months after each of my daughters were born, staying up at all hours of the night to handle feeding & changing and whatever other needs they had, trying to get daddy to help with whatever he was biologically able to do, although even that was a project sometimes.

But, enough reminiscing about those wonderful sleepless nights, I started to think about the sprints I've been involved with for my software projects. Not too many I'm happy to say, and I even wonder if the ones I was involved in were very effective, especially when it comes to quality of product.

Writing, fixing, and migrating code is not exactly something you want to do when you're tired, there's way too high of a risk of error and more problems as a result. We like to joke "Hey, don't drop the database by accident" when our programmers write scripts on the database, because someone did once, by accident of course and thankfully not on the live database. Making critical decisions about a project is not something you want to do when you're tired, it's too easy to get caught up in the moment and not be able to think clearly. System test and bug checking is not something you should do when you're tired, you don't have the focus you should have and will be too quick to rush through testing because you feel so close to the finish.

The times when my project team has had to do these types of sprints to get a project done have not ended in disaster, for the most part things were ok (except for that one time years ago when we realized at 2am Monday morning that we had to roll back an entire project and months of programming work, by the time people got into the office at 9). And even though it might have been a nice bonding experience, I can't say I love doing it this way. I would like to think that in an ideal world we won't be in the situation where we have to pull marathon work shifts to get the project out in time, and I'd like to say that in the interest of quality we should avoid this all-together.

Is it possible to always avoid? Probably not. I am fortunate to have a client who allows me flexibility most of the time with my launch dates, and I guess I should just be grateful for that!

"To Catch a Bug" - New Quality Assurance related post on Flightpath blog

This latest is nothing about adventures with contracters, but stuff about bugs that's been floating around my head for a while and wanted to get it all written down...

To Catch a Bug: Quality Assurance at all Stages of the Project

My Failed Project, and Lessons Learned

I'll probably come up with a couple more posts about my contracter before this is all over, he's finally back in touch and doing some work for us. It's always interesting having him around, especially when I can reflect on how work we do with him can relate to good or really bad project management.

This time I might as well take the blame.

We asked Fernando to install two wall unit air conditioners in each of our daughters small and stuffy rooms. For reasons I wont go into, window unit A/C's were not an option and fans weren't cooling down the rooms enough (nothing like getting woken up at 2am by a very sweaty baby, I felt terrible about it and we had to fix it as soon as possible).

So, what went wrong? Well, the air conditioners were cemented into the walls and put through to the back, but without a sleeve to hold them. So, two big problems here - the mechanics in the back of the A/C are exposed and not protected by the elements, and there is no easy way to remove the A/C if and when it breaks down. How did this big (expensive) mistake happen? A serious of bad decisions...

Let's start with the purchase of the appliances. My husband (who is a wonderful father and very intelligent and talented in his field of English Literature, but not exactly a handy fixit kindof guy) went to buy the wall units. Ideally we would have went online beforehand and picked out exactly what we wanted and done the research to help us figure out what accessories we needed, but we didn't.

Mistake #1: Lack of research & planning.

We rushed to get the A/Cs so that Fernando's guy could install them ASAP, and before the next brutal heatwave. Apparently wall units are sold without the sleeves, because they assume you might already have one in the wall. So, the sales guy was happy to sell us the A/C, but when my husband asked if he needed anything else, the guy said absolutely not.

Mistake #2: Bad communication and transfer of knowledge (assuming that the sales guy knew exactly what our situation was and would know enough to make the right recommendations).

So, we purchased two nice new wall unit A/Cs and brought them home (without the sleeve, of course). Fernando came by to look it over and raised the red flag. He said we bought the wrong thing, these were without a sleeve and we could not put them into the wall without one. I think it was morning when we came to this realization, and I was juggling getting the girls dressed and fed and getting my own stuff together so that I could get everyone where they needed to be and myself to work on time, and had not planned for this little hitch in my schedule. So, I wasn't focusing enough on the problem and trusted that Fernando would be able make everything ok. We looked through the box and took out all the pieces. I asked Fernando if there was any way to make it work, or what we should do. He said he'd figure something out. Sounded good to me... I dashed downstairs, fed the girls and got us all out the door.

Mistake #3: Rushing the schedule and not taking the time to properly reflect on the issue at hand and manage the new risks of the project.

So, Fernando's guy (who is an electrician by trade and not an A/C installation expert) started working on putting the holes in the wall. Within a couple of days the units were in the wall. The units were cemented back in, so no chance of anything sliding out. When I went to look at the work that was done, it was only then that I realized how important that sleeve was, because I saw the 3-4 inches of mechanics exposed in the back of the A/C. I asked Fernando if this was going to be a problem and he said only in the winter. So, he promised to get it covered by winter.

The next day my neighbors (one of whom is an expert in heating & air conditioning I have recently learned) raised about 10 red flags and told me that we needed to cover that A/C as soon as possible, before the first rain. So, now I have my contractor (who I've trusted for many years) telling me one thing and our neighbors (who we also trust) telling me another. I'm just using common sense here and figuring my neighbor is probably right. Another issue that my neighbor mentioned and I'm kicking myself for not realizing sooner is that if we ever needed to remove the unit, we'd have to break through all that concrete. Without a sleeve, there's no easy way to get the units out of the wall.

So, what was the end result? We cut our losses and decided that rather than remove both units from the wall now to put in a sleeve (and risk breaking the new units while separating from the concrete), we'd cover the exposed parts of the units and 5-10 years from now (hopefully not sooner) when they break down for good, we'll break the concrete and put the sleeves in.

I regret not spending more time to properly think the whole process through and expecting that each player would know exactly what to do. At this point I'm just keeping my fingers crossed that the units aren't damaged by the rain we've had in the last couple of weeks and we can atleast salvage our investment.

The bright side is that I learned some great lessons. I try to be super careful with planning, risk management and communication with the software projects I manage from 9 to 5 (I only wish it was from 9 to 5!) but maybe it's time to be more careful with the stuff that happens after 5.

If only I could work with my outside contracts the same way the NY DOT does

Anyone who's run a project with an outside vendor or freelance, contract worker, or third party application knows that it's best to plan alot of buffer into the schedule because anything that could go wrong, probably will. I've learned this the hard way a couple times, from communication breakdown, to technical difficulties, to technical difficulties caused by communication breakdown. It would be so much easier if everyone working on your project was working under the same roof, on the same schedules, with the same work style, etc.

But, if this were the case than project management wouldn't be so much fun!

We worked with an outside vendor on the west coast last year and the only way I was able to get them to respond to my email was to mark them high priorty with the red exclamations, and make sure all relavant parties were copied. Kindof annoying, I know...but it worked.

If only I could work with my outside contracts the same way that the street crew works with theirs...

So, its finally time for my street to get repaved. They've been putting up signs for the last week, letting us know when we can and can not park on the street. Yesterday they did the block west of me and this morning was time for my block. Now, the residents of my neighborhood who own cars and park them on my street are like outside 'contracters' who can have a direct impact the schedule & progress of the street paving project. At 7am this morning there were still a few cars parked on my block, so immediately the street paving project was delayed. Within a few minutes, we hear out the window, very loud announcements from a truck with a megaphone attached "Good Morning. Please remove your car from Chester Avenue. If you do not remove your car we will have your car towed and issue you a ticket."

What I love most is not the threat, but the way it was delivered. I happened to have been awake already because I have young kids who got me up at 5am, then again at 6:20am, but for those who have a bit more time to sleep in the morning, to be woken up by loud annoucements from the street is just beautiful. This reminds me of my camping days, when the evil counselors would yell at the kids or find some way to be really obnoxious to get them out of bed (of course I never did that as a counselor, I was very nice).

I looked out the window while the truck was going by, and saw a nice big smile on the driver's face. You know he was just loving this job, I bet he was once one of those evil camp counselors. If only I could use these same tactics to keep my outside vendors on schedule and communicating regularly. But, they probably wont ever want to work with me again...

(ps - this is not to say all outside contracts are bad, I happen to be working with one now who is totally on schedule and even more ahead of the game than the rest of us are...maybe he'd like to use the megaphone on us!)

Everything I learned about (what not to do in) Project Management, I Learned From My Contractor

Well, let me preface all this by saying that my contractor Fernando is the most wonderful person in the world, and we have worked with him for years now and (almost) never regretted it. He's bent over backwards for us when we really needed him, rushing to finish up our bathroom renovations in our old apartment so that when I was coming home from the hospitol with my first child I could have a finished bathroom to use. Then he came back late at night to fix the bathroom floor when I (in my drunken, sleepless new mother state) stepped on the still drying tiles and messed them up.

That said, if he was to be my mentor when I started out as a PM, I probably wouldn't be a PM anymore. Let's start from the beginning...

The Estimate
I called Fernando because I wanted to have him walk around the house with me and show him 4 things I wanted an estimate for. He stopped by and I showed him the 4 things needing work:
- installing a storm door
- fixing a leak & ceiling damage in a side room
- installing a cabinet & counter around a dishwasher (we couldnt afford the cabinets last year, just the dishwasher and wood box around it)
- making holes in the wall in my daughter's rooms and installing wall unit A/C's

He didn't write anything down, but I did (it was the PM in me nudging). I called him up 2 weeks later and he gave me my price. He gave me one number, no ranges, no conditions, no specifics about the deliverables, just the flat price. When I asked about specifics of the 4 deliverables, he broke down the work estimates for me. He didn't specify whether the price covered labor and materials (which burned me in the past because I assumed that the price covered materials and I was wrong). He didn't mention how the cost might change if the wall was harder to bust through then he expected (its a 100+ year old rowhouse, needing repairs), just gave me the flat fee.


I remember from my PMP class that this is one type of contract, which can be very beneficial to the buyer but can be dangerous to the seller.

The Schedule
Ok, so anyone who has a contracter knows that they are completely unreliable and if they show up 2 of the 5 days of the week then we should be grateful. Fernando and his team are the same way at times. So, I've stopped asking how long something will take, because I think it will just get done when it's done and I have no idea when that will be. He does good work, so in the end that's most important to me. Fernando doesn't exactly know about the triple constraint, but as long as he does good work I don't bug him about it (so much).



Change Control

..or lack thereof really. Fernando is so nice, he will let us take advantage of him sometimes. When he's in the house doing work, I'll say "Fernando, can you take a look at ___ or ___ ". And he will, and he'll help us out with other stuff, but what he really should be saying is "I can help with this, but it will have this impact on the schedule of the current work I am doing for you and will affect the cost of the labor by this." Not that I'm complaining really, but I know not to adopt this process when I manage my projects!



Revising Estimates in Project Execution

Last year we needed Fernando to redo all of our electrical wiring because it was more than 50 years old and in dire need of replacement. We got our price quote (7K) and his electrician started his work. This guy was just as unreliable as Fernando, and came maybe 2-3 days a week. When he was there, he worked pretty slow (not that I'm complaining so much, electrical stuff should be done carefully!). The entire work effort took about 5 months, and throughout the project the electrician asked for installments of the 7K because he was running low on supplies. It seemed to me that all of the money was going to supplies, what was going to labor? They never asked me for more than 7K, but it started to seem like they severaly underestimated the work and were totally losing money on the job. Maybe this is why they only came half-time, they were putting their time into more profitable jobs. In hindsight, I kindof wish that Fernando would have come back to me and said its going to take 12K and this will ensure the project will complete more quickly and efficiently, and my employees will get the compensation they deserve. Not that I love throwing money into projects, but that's what home equity loans are for!



Fernando's business is thriving, he does great work and he's always got projects lined up. So, obviously he must be doing something right. We probably shouldn't expect our contracters

to follow PMBok, but maybe some happy place in between might be ok.



Maybe it's just my contractor, who knows!

Quick Decisions, in a Software Release and on the Staten Island Expressway

Caution: If you have a weak stomach and don’t like reading about baby puke and quick project decisions, you might not want to continue reading.

So, I guess my 18 month old daughter doesn’t like my driving. Since we don’t own a car and just rent a few times a year, her body probably isn’t prepared for the shock of it all. Regardless of how and why it happened, she had an unfortunate up-chuck while we were just slowing down in a huge mass of weekend traffic on our way back through Staten Island this past Sunday night. It was quite the event too… anyone who’s seen Monty Python’s “Life of Brian” can picture a similar scene. So, we’re stuck in the car with a wailing puke-stained baby and a 3 year old who keeps yelling, “stop crying, you make me sad!”

What to do? Do we try to pull over on the lack of a shoulder lane and try to change her into clean clothes? Do we pull off at an exit and see if we can find somewhere to stop and clean her up? Do we just try to keep driving and see how quickly we can get back to Brooklyn (granted, this is New York traffic on a Sunday night in June, seems like everyone left the city for the weekend and they’re all coming back now).

As I was weighing my options, I was reminded of similar situations that I’m in when I am managing software releases for my company. (Ok, so maybe I really didn’t drift off to such thoughts while in such a stressful predicament in the car, but it sounds funny so I’ll tell the story this way).

Our last large new feature launch was in the beginning of May, and we do regular bug releases and small feature launches. Inevitably things will go wrong, regardless of the amount of testing we do while on our QA and staging sites, there’s always something we find when we put the new work live. This can cause varying levels of panic, especially when it’s late at night and our project team wants to go home, or its early morning and we’re trying to finish up before our clients come into the office and want to start using their websites. When these things happen, we have a few different options –

1. Put a programmer on it ASAP and see if this new issue can be resolved and tested quickly and hope that no new related problems are created by the changes.

2. Roll-back the entire release and try again the next day, after spending time working on the new issue and resolving on the test sites.

3. Leave the issue on the live site, make the client aware of the issue and work on getting the fix thoroughly tested and live within the next couple of days.

It all depends on the severity of the issue, but what I can always count on is a project team looking to me to make the decision. I don’t always like making quick decisions, but I know it’s my job in these situations and I know my team is looking to me to make the call. It’s almost funny how much they count on me, on different occasions the programmers or the QA team and even the more senior members of the staff have shied away from making crucial decisions when it comes to software releases and potential impact on our clients. It’s as if nobody wants to be responsible if the decision made sends us into the deep dark sea, they’d prefer I be responsible and as the manager go down with my sinking ship. So far so good…we haven’t sunk yet. I wouldn’t call myself caption of the year, but we’ve been floating along somehow. This part of the job can keep things exciting, and terrifying at the same time.

So, what did we do with the sad sick baby in the car? We kept on driving, opened the windows up all the way to keep the smell from making me sick myself, and gave her a bottle of water. The bottle actually made her very happy, and within maybe 20 minutes she was calm and maybe even forgot that she was covered with slop. We figured since it was already late and she was tired, better to try to just get her home than risk getting stuck in an even worse crowd of traffic. We eventually got out of Staten Island and were able to get home to Brooklyn to get everyone hosed down. I was glad my husband and I (yes, he helped in the decision making, too) had decided not to stop because once I had started to clean the crime scene I found that it was a lot worse than her clothes, even in clean clothes she would have been sitting in a stink and gotten dirty all over again. Today she’s clean and happy and hopefully has forgotten the whole thing.

And can I even try to remember the show-stopping bug that plagued my project team the last time we did a release? Barely…

The limits of quality, in a crane

I walked past a crane yesterday. I have to say, being New Yorker and hearing a little too regularly about the construction accidents that have been happening, makes me not want to walk so close to those cranes.

There were a few construction accidents earlier this spring, one of them involved a crane that was improperly secured to a building, falling onto a neighboring building. Very recently, a crane on 1st Ave and 91st Street collapsed onto a 23 story building and killed the crane operator.

Many critics will say that the problem is that there is too much construction going on and too much rushing to get the projects done. Seems to make sense to me, especially after reading about the repeated complaints and stop-work orders on that crane that collapsed most recently. If there was not such an urgency to get these new high rises up, then maybe the project could have stopped and the crane properly evaluated and replaced.

I've been especially sensitive to these types of issues lately because I've been reading the very interesting book titled "The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA", by Diane Vaughan. It's a slow but very interesting read, and from what I've got so far it's about the 'production' pressures faced in the organization and the 'amoral' judgement and behavior used by the managers there. In both of these cases, the team just wasn't cautious enough, or chose to ignore the warning signs.

What stunned me was the statement New York Mayer Bloomberg made after the accident, something like (not exact quote) "there are only so many inspections that can be made and so many inspectors, sometimes problems aren't caught." When it comes to ensuring the quality of your system when the failure of that system can mean loss of human life, then the warnings have to be taken extremely seriously. I'm not exactly an insider in the construction world, but it looks like the warning signs were not taken seriously enough.

In my software projects we take quality assurance and control seriously and are trying to find ways to improve what we're doing.

Do we miss things?
Of course!

Do we put new bugs into the system when we launch a new project, I think I've got a perfect record on that one, there's always something we have to fix post launch. I'm happy to be in the field where a bug in my system will not cause the loss of human life. I guess I expect a little more from the more dangerous fields of work out there.

The Good, the Bad, and the Ugly: The Reality of Risks in Your Projects

I just finished a great book, titled "Waltzing with Bears, Managing Risk on Software Projects" by Tom DeMarco and Timothy Lister. Risk is something we all deal with in our day to day lives, and probably don’t deal with enough in our professional work. The authors open with the idea that if a project doesn’t have any risk to it, it’s just not worth taking. This notion is especially applicable to the interactive design field that I work in at Flightpath.

The authors share the analogy presented by risk management expert Bob Charette, who proposes imagining your company and its competitors as a set of down escalators.

“You are obliged to climb up the escalator, which is moving against you. And your competitors are doing the same thing on theirs. The faster their stairs move, the faster everyone has to climb to stay even. If you pause, even for a moment, you begin to fall behind. And, of course, if you pause for too long, you will drop off the bottom, no longer able to compete…

Competitors get to enter their escalators halfway up. Falling behind, then, guarantees that the new competition will enter above you.

At the top of each escalator is a level that will allow you to control the speed of not just your escalator, but of everyone else’s as well. If you’re the first to reach the lever, that shows that you’re a better climber than your competitors. So, you can speed up all the stairs so that you can stay even but your competitors can not.

…This is an era in which risk-taking is rewarded, leaving companies that run away from risk as a plunder to be divided up by the others.”

But taking on the most innovative and thus risky projects is not all about being the sexiest agency out there; risks have to be managed. To take on a risky project without a formal plan in place to manage those risks is taking a major gamble with your project, your stakeholders, and maybe even your career.

The book states that risk management is like project management for adults. Something which adults have that children don’t is a willingness to confront the unpleasantness in life, from the little annoying things to the cataclysmic (examples such as putting a band-aid on a cut to keep it from getting infected, or taking out life or home-owners insurance policy as protection against the bigger challenges). Taking note of bad things that can happen and planning for them accordingly is a mark of maturity.

What can you do to make your project sexy (and of course risky) at the same time? Examples are trying out a new technology, working with a third party application that does some incredibly cool stuff, or doing something that nobody else out there has done before. Then there are the core risks that any project (no matter how un-sexy) can have, the book lists these five core project risks:

- schedule flaw, interruption

- scope creep

- turnover

- specification breakdown

- under performance

To ignore any of these is as disservice to your project team, your stakeholders, and yourself.
But risk discovery and planning can be an unpopular task and can make the risk identifier look like a ‘can’t-do’ person or a whiner. Risk management makes a limited amount of can’t-do thinking okay. It’s better to raise the issues early on and be prepared for them if and when they come, then to ignore them entirely.

So, I’m ready to become more of a can’t-do person, and ready to be more prepared for anything good or bad that will come my way. I hope that you’ll join me, and I’ll see you on the escalator!

Including Uncertainty in Estimates of Software Projects, Fort Building, and anything including a Toddler

Early in a project, so many of the specific details of the nature of the software being built, specific requirements, project plan and staffing details are all very unclear. Because there are so many variables early on in the project, it is crucial to include a large degree of uncertainty or variability in the project estimate. This is not about being purposely misleading or avoiding commitment to an exact number with your stakeholders, this is about accepting the reality of software projects that leave so much to be defined early on. To commit to an exact number at the very beginning would be misleading yourself and your stakeholders and presenting a false sense of confidence in something that still has so much yet to be defined.

Steve McConnell, CEO and Chief Software Engineer at Construx Software, presents the idea of a “Cone of Uncertainty” in his book “Software Estimation: Demystifying the Black Art (2006)”.

The horizontal axis shows significant project milestones. The vertical axis shows the degree of error that has been found in estimates created by skilled estimators at various points in the project. What is obvious from the diagram is that estimates created early on in the project are subject to a high degree of error (from .25x lower to 4x higher). As the details of the project become defined and understood, the cone narrows. Obviously the most accurate estimate is made at the very end of the project development, but the challenge in the software world is to find somewhere in between where we know enough about the project to make the best estimate possible while still allowing major stakeholders to plan financially. More about the Cone of Uncertainty, and other estimation resources can be found on the Construx website.

In his book Steve McConnell explains several different techniques used in making software estimates. He also made a very interesting and entertaining blog post recently, where he shared similarities between building a fort in his backyard and problems people run into with software estimates. The general idea here, and very humorously explained, is that in the beginning of a project it’s easy for us to assume that everything will go as planned and the project will proceed smoothly and in a timely manner, but it’s very common for things to take longer than expected. In his case, it was the little construction project in his backyard.

I haven’t built any forts lately, but I’ve managed many projects, and some that have taken longer than the original estimate, for one reason or another. But I also see this concept clearly illustrated in my day to day life outside of my work. I find that it’s almost impossible to make any type of time or schedule commitment when a toddler is involved. I’m fortunate to be the mother (or project manager) of two little girls, and have the pleasure of bringing the older one to preschool every morning. What should take only 15 minutes, can sometimes take up to 40…and this is why:

1. The 2nd and 3rd bowl of cereal (6 mins)

2. Trip to the potty before leaving home, which can sometimes include the mandatory reading of the Dr. Seuss book while waiting for the potty business to complete. (8 mins)

3. Sneakers that get taken off and put back on again, only to get taken off one more time (and of course put back on again) before the final trip out the door. (2 mins)

4. Unexpected meltdown about which jacket to wear, and wanting to wear rain boots and bring umbrella on a perfectly sunny day. (6 mins)

You catch my drift…

So, I’m learning more about how to properly include uncertainty in my estimates at the appropriate times in the project development, both in the projects I manage and the mini-projects I manage at home every morning. It’s a good thing that our preschool allows us a 30 minute window for morning drop-off!

(This blog post was originally published in May 2008 on Flightpath's Digital Insight Blog)