Monday, July 30, 2007

Overtime is a productivity killer

This post may not be one of my most popular with PMs around the world but here it is anyway. Overtime, in the long run, does not help a project. When the numbers are run (and boy do productivity numbers get run...) it turns out that work that is done when mapped out with a scatter diagram across many different projects is essentially the same. [See Slack pg 64, it's cheap in paperback and well worth the read] The work that is done is the same per day... not per hour.

Intuitively this may initially seem strange if not outright wrong. How could a team that consistently works 50 or 60 hours a week end up with the same productivity as a team who works 40 hours each week? The answer lies in the long term effects of overtime, not the short term spike in productivity from a controlled burst. Controlled bursts really can be effective, as long as they are just that, controlled bursts.

Overtime itself is not an evil thing. Many are the stories in corporate lore of the team that pulled an all nighter or pushed through that special effort over the course of the last week to deliver everything on time. Good managers, [project managers, people managers, senior individual
contributors] know when to pull the trigger on overtime to push things over the goal line.

The problem comes because this can be addicting. Both to the manager and the individuals. People like being super stars, like the accolades and recognition of being really dedicated. Believing this to be a great success without evidence to the contrary managers become dependent upon the push to get everything done. Rather than pushing back on scope, push on the people. It is an easier road and you don't have to worry about an unhappy customer. At
least not right away...

With pressure comes a bit more focus. That's a good thing right? Sure, when that pressure leads to cutting out unnecessary steps and trimming requirements that are not needed. But when that pressure becomes an unending stress to deliver no matter what, it starts to become noise.
People stay, because they see others staying. People work, because others work. But the real urgency and productivity goes down. Knowing that they will be there working at night, things get put off, people talk in the hallway, time is spent surfing the web, etc. Why not, they will be there later anyway.

There are of course many other costs to too much overtime, but this is just a blog and not a book, so I will give it a rest now that I have you thinking.

Thursday, July 26, 2007

The principles of Tao Teh Ching in Software Development

You may be asking if I drank a little too much Green Tea to be comparing Software development to the principles of Tao Teh Ching but please bear with me on this one. Honest, it makes sense. (At least I hope it will after I write it down and it's outside of the world inside my head) First, the basic principles. (there is a lot more in the book as its a compilation of a good deal of Chinese Philosophy)


That which remains, is easy to handle.

That which is not yet developed is easy to manage.

That which is weak is easy to control.

That which is still small is easy to direct.

Deal with little troubles before they become big.

Attend to little problems before they get out of hand.

For the largest tree was once a sprout, the tallest tower started with the first brick, and the longest journey started with the first step.

Just as these wise words say, things are easier to handle early on. Once they get rolling or get bigger though many times there is too much momentum to control it. Just like a small snowball at the top of a mountain can become a massive avalanche so too can a small problem ignored early in development become a costly, potentially project killing problem later in the development cycle.


Releaseing early and often during software development makes sense. By focusing our teams on the first things that really matter we can focus our efforts on the things that make a difference. By focusing on the things that we expect to be hard we can ensure we have enough time to manage the risk associated with them. Identifying things early allows us to adapt our plans and make the best set of decisions.

Wednesday, July 25, 2007

My trip to the post office

I have been asked before where my inspiration for blog posts comes from. Sometimes its from things I read, other times it's from events that I am a part of. As a little window into why I blog what I blog I thought I would share one of my "triggers". A recent trip to the post office caused the trigger for my recent post on Process Engineering. Now... on to my rant.

First, a bit of passport news. The US Government recently decided that no matter where you go you need a passport to travel and come back. Not really that big of a deal other than that it hadn't been a requirement for Mexico or Canada, popular destinations for many people. This (of course to those who actually think) caused a spike in demand for Passports. (I found it hilarious that the website for passports had initially stated that due to unanticipated demand for passports there was a delay in processing. Now corrected to simply state processing times have increased due to high volumes. If you change the law to state everyone needs one... demand will increase. duh.)

I recently went to the post office to get passports for my family and renew mine since it expired this year. For my own there is a nice improved process where you can mail your existing passport, a form and the money required and they will ship it back to you. No lines, no muss, no fuss. (Although the page states you must apply in person or by mail, if you go in they will tell you to mail the form... what a great way to waste an hour in line.) You can also fill out the forms ahead of time to simply hand them in and make it fast.

However... if you do not have a passport here is the current process.

  1. Go to the post office. There are a limited number of post offices that do this so check first. (This was the least stressful step in the process)
    [10 minutes - Post Office is close, easy drive]

  2. Stand in the Passport line. It is important to note that you will need a photo of your head. These can be purchased for cheap at Costco etc or $15 at the post office. (How convenient. Of course photo or not you all stand in the same line.)
    [60 minutes - 3 people ahead of my family. 5-7 photos taken, Forms filled out for each person, 1 line, 1 person doing everything]

  3. Talk to the Passport person. One passport handled at a time, stapled Birth Certificate (actual certificate) to form along with check for Passport.
    [10 Minutes - 5 minutes per person w/ 2 kids]

  4. Hold up right hand and swear that the form is truthful. (Humans are apparently unable to lie with their right hand up. Practice in the mirror)
    [2 Minutes - 1 minute per person w/ 2 kids]

  5. Receive ticket to pay post office for service
    [1 minute - Only one ticket for the group, process has been "optimized"]

  6. Stand in Post Office line to pay Passport ticket. This is the same line as people buying stamps, weighing packages and otherwise wishing they were elsewhere. (Most of the articles have long since archived out but if you remember back to early this year some 3700 post offices improved their turn around times on lines by removing the clocks from the walls. Really.)
    [2 hours - really it was just 45 minutes but I have a caveat. Based on the rate of line movement for the people who were in the "passport room" ahead of us in the passport line, they waited 2 hours to pay. However, it was nearly closing time and 3 extra people miraculously appeared and chewed through the line so they could go home on time.]

  7. Return proof of payment to the Passport Office. Receipt for payment needed to be shown before the paperwork would be put in the "to be sent" pile. Now, at this point most people are fed up enough that they just walk in the door and show the Passport person the stub and don't wait in the line so I guess you could say this was "efficient".
    [5 minutes - Had to wait to get attention for the drop as the Passport person was taking photos]

All totaled this accounts for (10+60+10+2+1+45) 128 minutes of my actual time. Just over 2 hours. Considering that we had everything filled out, ready to hand in and walk away without additional photo time and we had an accellerated exit because the "pay line" wanted to go home this is truly disturbing. The people who were in the Passport office when we got there were there for at least 4 hours. If this was a private entity they would be pushed out of business.

Opportunities for improvement abound.

  • Have two lines - One for photos and one for completed forms with pictures. This would have cut out at least 60 minutes.
  • Have a machine take the photos with the cost of credit card freeing the person to just deal with forms. If people can't get it right they can do it again.
  • Transmit automated digitals taken since the Passport office is printing them anyway just attach that.
  • Give People the forms to fill out and they don't get in the line until they are done. This keeps people will filled out forms from waiting for people to remember where their mothers were born.
  • Insist on pre-filled forms. They are available on the internet. A terminal could be set up for filling out and printing.
  • Pay in one place. Let the Passport office collect all of the fees. This would cut out at least half of the time for most requestors.

If these suggestions were put in place my 2 hour passport ordeal would have been a 5 to 10 minute paperwork drop. I would have nice things to say about the easy nature of the excessive instead of wanting to post about Process Engineering and needs for improvements.

RANT DONE.

Friday, July 20, 2007

Know where you are so you can go where you want

Aside from the desire to make a pithy title I did want to blog a bit on Process Engineering. A quick Google define: provides

Process engineering is about applying engineering approaches, techniques, and
tools to the construction of Process Models. [Rolland1998]
en.wikipedia.org/wiki/Process_Engineering

Aside from sounding very technical and confusing this definition really does capture the gist of what Process Engineering is about. Looking at how you do things and applying techniques to improve it. This could be any process really, from how you save a few moments by putting your toothbrush in a cup on the right side of the sink to how data is pre-processed for correctness before loading into the system slowing down initial loads but saving time on back-outs.

Why is Process Engineering important? I am glad you asked. It is important because without having an understanding of what we currently do we cant' figure out why we do it and thereafter improve it. For example, I was involved in a process improvement initiative once where we boiled a process that originally contained 30 steps to one that had 5. How? We figure out that each step (there were really only 5 major actions in the process) was supported by it's own set of steps that validated the information received from the previous step. Each team would send a spreadsheet to the next team, that team would run it's own validation, purging and cleaning and boil it to a new spreadsheet because they didn't trust the data then send the new spreadsheet to the next team... etc. By inserting a system where users could check in the spreadsheet to be pulled apart into a database with referential checks all of the separate validation could be done automatically and viola life was good.

What should we do with this? Similar to many of my posts my statement here is that we should question things. Don't be afraid to do something different than it always has been done. But don't just change for the sake of change. Understand what is currently being done and why. Use this data to attack inefficiencies and fix them. Sometimes it requires code or a system but other times even a people process change will improve things. First and foremost though, understand where you are so you can define where you want to go.

Monday, July 02, 2007

More disruptive tech.. here Wii go

I had another experience with Disruptive Technology this weekend that I thought I would share. First a quick intro story, my wife decided that I spend too much time writing blogs and doing other work at night so she gave me a Nintendo DS to play Pokemon with my son. (We were playing the card version but that is all old school and passe now.) The people at Nintendo are GENIUSES... if you purchase the new Pokemon game for DS you have two options, Diamond or Pearl. The variant between the two is the likelihood that you will run into any particular type of Pokemon. So in order to get the best mix of Pokemon you need to trade with someone else... this is where I come in. I get one type, my son gets the other... GENIUS... now we buy two games.

It get's better though, and this is where the disruptive tech comes in. If you have a Wii (and if you live under a rock and have not heard of this you need to get out more or read) then the new version of Pokemon Battle Revolution for the Wii also allows you to trade back and forth your Pokemon with the Wii version. What a Wii bit of fun. (sorry, I had to, they will kick me out of the blogger's union if I don't hit my pun quota)

This brings me to my point (already). The interface for the Wii is entirely different than the existing interfaces for video games. This has, of course, hit the press and blog pages long ago but I thought it made a great point. The Wii does not support true HD, it's tiny and has no huge sizzle effect like the XBox 360... it's even cheaper and simpler than the other boxes and yet, it is rocking the video game world. Because it changed the interface rules. The Nintendo folk's thought differently and instead of focusing on ubber graphics and interaction view(the standard thought pattern of the day in games) they changed the interaction method. With your Wii wireless controller (it's all Wii small... there I think that's quota) you control standing in the middle of your living room. It's easy enough my 4 year old can play bowling and baseball, fun to watch in and of itself.

What can we learn from this? Don't be afraid to go another direction. Wii is having amazing success and corresponding sales (if you doubt this go try to find one in a store). This causes me to think about basic interfaces and the way our users interact with systems. Not just web versus green screen but form versus map and open search versus controlled UI. This is the gist of Web 2.0 and why the interfaces work. Kids who are growing up now don't think in forms, why would they? Their interfaces are things like iPhones and Wii.