The Motorola Method - Using Quickie to Manage Software Team

Managing a team is already challenging enough, now managing a distributed is a bigger challenge!

Long time ago, one of my friend told me something which stuck in my mind like forever. He said that you can manage 100 computers, but try to manage 10 people - you might just give up! Its been more than 14 years since he said that, and I couldn't agree more...

What I am about to share here is called as a Quickie, and what I have been using to manage my geographically (often, around the globe) distributed software development and deployment team. This method was taught to me by my first Project Manager in India. It proven to be one of the most effective way to manage my team, regardless of where they are, which time zone, what role they play. I was able to use this method, to get updates from around the world, use the information to understand the challenges faced, and mobilize solutions and deliver projects, with most of the miscommunication problems resolved.

Now, managing a team is already challenging enough, managing a distributed is a bigger challenge, and this practice started in 2000, when I began my career at Motorola's software excellence center in Bangalore India, then in Schaumburg, IL, and back to Malaysia, when it all began for me.

This is going to sound funny, but the report is called a "Quickie". This is probably because of the nature of the report, which is meant to be easy and fast to be written. The goal of the report is to have a structured method of reporting your day's or week's work status, as well as let the audience know of your next plan.

How does a Quickie work?

The method is fairly simple (sometimes too simple). We have 4 lights. Red, Orange, Green and Blue. (The original version had 3 lights, I improvised, added the blue light).

Details of the Quickie:

1. Format
• Red Items (Blocking Issues), stands for issues in your work, which has totally stoped you from achieving and completing your planned work of the day (the previous day's Blue Items).
• Orange items (Potential Issues), stands for potential issues at work, which may or may not be an actual issue yet, but either way, you think that this potentially will disrupt your work and will become a Red Items in few days time.
• Green Items (Achievements), stands for what work was accomplished for the day. Ideally speaking, these should be what was written as Blue Items on the previous day.
• Blue Items (Plan for next week/day), by now you should know that this is where you write on what are your plans for the next day.
• This typically is typed out in a simple mail, with the subject of the mail in this format: W52-Quickies, the W number refers to the number of the week (a typical year has 52 weeks).
2. Frequency
• I used to request the Quickie from my engineers, Project Leads, Architects, Project Managers on weekly basis, with the above subject line, but over time I have come to realized that a Quickie is much more effective to be done on a daily basis due to the mammoth data which needs to be compiled if done on weekly. 
3. How it works
• Hence the goal is for everyone in your team to complete a Quickie on daily basis and send it to your before 5pm (or end of your business hours).

Advantages:

Simple & Fast

• Miscommunication or worse no-communication is one of the major mistakes done is most software projects. In most cases, by the time the issue is caught or brought to surface, damage would probably been done already. Hence the challenge here is to detect the issues (Red Items) or possible issues (Orange Items) as early as possible. I can't think of a faster method for anyone to get status from a 100 man team, and to identify all of the major statuses, whcih needs attention.

• Red and Orange Items
• Now, most people may argue that isn't it obvious that when you have an issue, you would point it out, and ask for help? Now, that is not the case in most software projects which I have seen:
• Some engineers tend to think that if they highlight their difficulty in getting the job done, they are incapable. (not realizing that suffering in silence gives a major impact to the project progress). Hence a protocol is established that any issues faced (technical or non-technical like lack of documentation, API not available, laptop malfunction, server too busy, etc.) are highlighted by the end of the day, in the Red Items section, failing which, it becomes the responsibility of the Project Manager to question the delay caused by the engineer, for an issue which was not highlight before, when delays are detected.
• Some engineers are just too proud to let go of their tasks to others. They feel that once a task has been assigned, they and only they alone should solve the tasks, no matter how long it takes (even if the project suffers). 
• The goal of the Red Items is for the Project Manager or Project Director to be able to receive probably hundreds of Quickie, and be able to browse through quickly, and identify the Red Items which are blocking the progress of the project on a daily basis.
• Can you imagine how much time will be wasted by having a status meeting with 50 man team - 2 hours if you are lucky. Now, with something like Quickie, you will be get to read read status from 50 people in a structured manner within 10 minutes - at most.
• Now, the Internal Service Level Agreement or SLA for a Project Manager should be to allocate resource or find a way to solve the Red Items of a team member by the next day, morning. Simply because when a team member has a Red Item issue, he or she simply can't continue working. Hence the faster the PM reacts and solve it, the smoother the project would be.
• Now, for the Orange items, while it is not a major issue (yet), a Project Manager has to keep tabs on these items, as these are the possible Red Items within the next few days. So, again a SLA should be established as to by when a PM resolve all of the Orange Items in a project.
• Green and Blue Items.
• The Green Items and Blue Items are for monitoring. These are areas where you get to monitor the work progress of your engineers. Are they designing and developing according to your briefing few days ago. While these items may not be seem as critical as Red and Orange Items, it is vital to monitor these, specially for the Project Leads, Architects, Technical Leads or anyone who plans the technical work items for the engineer, and for those who are responsible for the final delivery of the work items. It is very common that some engineers tend to go off tangent, and goes unmonitored for days, and just imagine the time and cost impact for the rework once the deviation of scope or functionality is detected. Whereas with a Quickie, you get to monitor them on a daily basis.
• Blue Items can also be used to plan for holiday - letting your PM and Management know of your plans OR actual next day, which you wont be in.Sometimes a leave may have been approved, but the Technical Lead Project Lead may not be aware that the engineer may not be around (they can't be checking the calendar of everyone, every day)
• Empty Blue Items indicates that the engineer does not have any more work (and that he or she has completed all tasks as of today). While rare, this does happens, and there are times, when gone without monitoring, engineers may have a vacuum slot, where no tasks has been assigned, simply because the team does not have a tool to monitor the day to day activities - like Quickie!
• A Quickie is also very useful, as not everyone may be available at the same time for a status meeting. Hence getting a status from everyone using the same format, is a great tool for project monitoring.

Disadvantages:

Too Simple & Too Fast

• Yes, if there has been comments on the way I use Quickies, it would on the amount of details which goes into the Quickies. You see, the quickie is meant to be, well Quick, as short as possible, without the micro details, like how much of time has been spent on troubleshooting, who are the resources  which we have approached, what are the techniques used so far to troubleshoot it, and so on.
• But on the other hand, my argument is that if we are supposed to write a 2 page essay every day or a 10 page every week, we simply wont. And that will eat into our productive hours, and also people will tend to drift off in their own ways of describing their statuses.
• Too fast refers to some who have informed me that daily Quickies has too little updates, and sometimes repetitive updates on daily basis, as some work tasks, takes days, and only percentage of completion changes on daily basis. My answer - Good!
• My view is, it is better to have a tool to communicate on daily basis, use few minutes to send out a status, then not having a method all together, and only to land in trouble when issues arises.

More to write, but will stop here, to get comments from all....