Elephants can certainly morph into horses and pigs in animation software, but the problem was: this was not animation software!
In a software firm where I worked, it was mandatory for every employee to enter daily time sheets in an online system, with each activity rounded off to the nearest half-hour. The activities were specific to the project and the nature of work on that project. Therefore, naturally, a software developer had a very different set of activities from a person in the Sales team.
In a software development scenario, the Project Leader (PL) defined every possible element and activity of the project in the time sheet system, and the developer picked activities from this list. This was a way for managers to determine how the team members spent their time on a project. All the members, including the PL, followed these steps to enter details in the time sheet system:
1. Choosing a project.
2. Choosing the name of the relevant software element, such as “user interface” (UI) or “database procedure”. For example, changing the background colour of a page meant changing the UI, and finding and listing all products priced under $10 could entail a database procedure.
3. Choosing the activity for this element, such as documentation, design, coding, testing, or bug fixing.
Whenever the specification changed and we had to re-code some or all of a module, we had to enter it under “bug fixing”. This did not make sense to us since it was not really a bug; it was a change in requirement. Whenever we pointed it out to our managers, though, we were told that this was the only category available. After the initial suggestions, all of us just got used to this practice.
About two years into my stint there, Kris, the CEO, held the usual talk with the entire staff (about 100 people) in the large conference room. This was supposed to be a quarterly meeting but, because he was now based in Los Angeles, it happened far less frequently—just whenever he was in town and could spare the time.
This time, he brought up a subject that had been worrying him. He had extracted a report from the time sheet system, to see the hours spent by each person, categorized by nature of work. He had found that for practically every developer, about 70% of the hours were being spent on fixing bugs! He asked us why the quality of work was so shabby in the first place that everyone had to spend so much time fixing mistakes.
“Mistakes were made, but not by me.” The general manager (GM) was quick to make his point: “You see, our middle management and below—all of them are incompetent.” His two project managers (PMs) tried to defend themselves: “Actually, our developers are bad.”
Kris didn’t let them continue. He said, “I want to hear it from all of them.” He turned to us. “What do the rest of you have to say?”
After a few moments of silence, I spoke. I said, “There are bugs at times, but most of the work that you see under bug fixing is really rework due to a change in specs. For example, in the project ‘Becker’, it turns out that our representative in the US had initially misinterpreted the client’s requirement. He recently conveyed what the client actually wanted, so we’re redoing the whole thing now. The time sheet does not capture this, so you think we’re always fixing bugs. In fact, for me, it’s been all rework.”
Kris looked incredulous and amused. “Hmm, I see. So you’re saying that the client wanted an elephant; our representative in the US understood it to be a horse; by the time he documented it, it became a donkey…and your boss conveyed a pig; you interpreted it to be a monkey—so you coded a monkey?”
I replied, “No, I know that my boss and I are on the same page; he has shared…”
“OK. So you’re saying that your boss received a pig, and you coded a pig?”
“Yes, that is correct. And now I’m struggling to convert it into an elephant. And it’s much harder and messier than if I had coded an elephant at the start!”
Kris always relished a challenge. He raised his eyebrows. “Hmmm. OK, let’s see: How many of you agree with Nandita?”
There was silence in the room; people exchanged glances and whispered. He smiled slightly at me and said, “Well, I’m afraid you don’t have much support…”
A couple of hands went up. He said, “OK, I see two. Anyone else?”
A few more hands went up. “Any more? Come on, guys; I want to understand this. If you say nothing, we can’t fix the problem. Speak now or hold your peace forever.”
Before long, 97 hands were up. The three who did not raise their hands were the GM and the two PMs.
Kris picked people at random and asked them their experiences of an elephant-to-pig conversion. Which project? Which module? After listening to six or seven cases, he said, “Houston, we have a serious problem.”
That very day, he issued instructions for the time sheet system to be amended. The next day, there was a new choice in the list of activities: “Rework due to change in spec”. This way, whenever a time sheet entry was found under this head, it would become necessary for Senior Management to investigate if:
1. The requirements were interpreted and communicated wrongly by the representatives interacting with the client, or
2. Communicated wrongly by any manager in between, or
3. If the client was changing his mind. In this case, it could possibly be a billable item.
Result: This simple, commonsense solution put more pressure on the managers to send the right people to interface with the client. In addition, it also stopped managers from making whimsical interpretations and passing them on; it now became easier for them to forward the original communication and discuss it with their teams—and use that saved time to focus on other tasks.
[Disclaimer: The intention is not to belittle pigs. Actually, I find them really cute.]
[My friend Sijo Kuriakose told me that in his project, he took it a step further — he tied the time sheet activities to the requirement spec version number. I think that’s amazing.]
1. Stakeholder commitment: My definition of a stakeholder is:
– A person with a monetary stake (as Kris was)
– A person who is deeply attached to a project, a cause, or a reputation
Clearly, the managers (to whom the issue was pointed out) did not see themselves as stakeholders. This is a common problem. (IMHO, there should be a monetary penalty for managers who ignore undeniably good ideas!)
2. Regular meetings: The culture of a quarterly meeting, in an egalitarian atmosphere, is a good thing. The problem lay in not following the quarterly frequency. Had the meeting been held regularly, these problems would have come to light much earlier.
3. Openness: It is commendable that Kris encouraged people to speak, listened to anyone at any level, summarized the problem eloquently, and questioned people to understand the issue. He also sent a subtle but clear message to the managers who looked for scapegoats rather than solutions.
1. When you are looking for information, how many levels is it travelling before it reaches you? Is there a chance that your elephant is turning into a pig?
2. Are you sure you are using the right information to influence your business decisions? [Refer to my earlier post on data mining.]
3. How are you defining and measuring work performance?
4. You have a lot of project metrics. Are they all meaningful?
5. When you are holding a meeting and asking tough questions, are you prepared to hear something unpalatable? Or do you hope/ expect to hear good news? [Read the excellent book “The Toyota Way”.]
6. How much time are your sales personnel taking to close a sale? If your field representative travels six hours on a weekday to meet a prospect, are you counting that time as travel time or sales time?
Please feel free to add what else works, or what to add to a checklist.