Workplace Ecology: A Case Study in Project Management
Page 8
eventually I could understand his reasoning. He felt that Luke could not understand the steps required to follow our test plan but Luke would be able to understand a list of the tests we proposed. As far as that is concerned I must agree. But I fail to see how this is going to solve the problem.
My inclination is to stereotype Vijay as being narrowly focused on power. My initial reaction is that converting a useful document into a trivial document is just repeating the same exercise that we went through earlier when I changed the process document that no one read. But that is not an accurate representation of Vijay. So my next inclination is to assume that Vijay is thinking linearly rather than thinking in systems terms. Perhaps my discussion with Mahesh about critical path has predisposed me to search for gaps in mental paradigms. Perhaps this is also an unfair assertion about Vijay. I need to be careful that I am not projecting too much of the case study fictional Vijay onto the real person that is one of the owners of this company. Even so, I believe that linear explanations for complex systems is such a common problem that it is worth a few paragraphs of explanation. Consider the following:
--
I like to ride bicycles and I have been knocked unconscious several times when I have crashed. My worse crash caused me to plunge down a twenty foot embankment while traveling downhill at about thirty miles per hour. I argued with the paramedics that I wanted to ride my bicycle home but they felt it best to take me home in an ambulance.
My brother used to ride bicycles but he crashed once while riding at a walking pace and broke his arm.
I used to ride motorcycles at absurd speeds. I crashed a lot because I was always pushing the limit of what I could do. My worse crash was in the mountains when I was traveling at about ninety miles per hour and I hit a patch of sand. The motorcycle and I separated and both tumbled end over end down the highway. This crash destroyed my leather jacket and damaged my helmet and yet I walked over to the motorcycle, checked it for damage, and then continued on my trip as if nothing had happened.
My brother was once sitting on a motorcycle and when he attempted to start the engine he fell over and the motorcycle landed on him. He was hospitalized and to this day has impaired use of one leg.
--
Now if we plot this data we end up with a graph that looks like the one shown below. As you can see there is a relationship between speed and magnitude of injury. Clearly traveling at higher speeds results in fewer injuries. If you doubt that, then just look at the four data points that were used to create this graph. This is valid scientific data.
Well, not exactly. Here we see two problems. First, we have too little data to draw such a broad conclusion. Second, there is little relevance between the four data points that I chose. Thus the best hypothesis that I can now come up with is that Vijay is exercising linear thinking. He has seen situations where giving a customer a simple of list of tests has worked. He has seen situations where giving the customer a complex requirements document has failed. Thus he now concludes that there is a correlation that implies that short lists work and long lists fail.
I think it is understandable that people think linearly. Peter Senge's The Fifth Discipline would not have received as much attention as it did if he was preaching things that everyone already did. (Peter M. Senge) And yet the concept has been around for a very long time. Darwin's work on evolution is an expository on distant causes of nonlinear events. (Charles Darwin) Also consider a work that I recently encountered by Brooks Adams.
In 1913 Brooks Adams published The Theory of Social Revolutions. (Brooks Adams) Adams, in 1913, was already describing the nonlinear effects of remote causes in complex systems. I hope I am accurate when I attempt to modernize his themes. From what I understand, he suggests that the need for power creates a feedback loop. The existence of a disproportionate distribution of power causes resentment from the disenfranchised and fear in those holding the power. The natural reaction to a perceived injustice is a desire by the down-trodden to topple those in power. The natural reaction from those in power is fear of the subjugated. In reaction to that fear the powerful tighten their control which increases the perception of injustice. And thus an inequitable distribution of power initiates a self-perpetuating cycle that eventually leads to a revolution. I think this has relevance in two ways. First, the fact that I have only recently encountered this work means that Adams' explanation has not permeated society. Second, I believe that the fact that Vijay is one of the owners of this company means that he is at risk of initiating a similar feedback loop. I feel that I am not being heard. I feel that Vijay is immune to advice because of his position. In my opinion, the greater the distance between Vijay's world view and my world view the more strident I become and the more resistance he becomes. I need to change this feedback loop.
I thought it interesting that Greg stayed fairly quiet throughout this meeting. He has something else in mind but he did not let us in on his plans. I, however, left that meeting and proceeded to do exactly what I said I would do. I began my efforts to implement iterative development. And, since Vijay owns part of this company I also created the lists that he asked me to create. I gave Luke that simple list of the tests we proposed for this deliverable.
Still I felt that something was missing and I felt like Greg had something else in mind. Thus I was not surprised when he came over to visit Luke's boss. After that visit he told me that he helped Luke's boss understand that they cannot benefit from the economies of offshore pricing if they continue to reject our code. Luke's boss explained this to Luke and I now see a change in Luke's attitude. The first few modules for this deliverable passed Luke's review. There is hope after all. Iterative development coupled with a little friendly persuasion just might turn this affair into quite a pleasant experience.
I told Vijay the good news about our latest modules getting a passing score on Luke's code review and he seemed surprised that I was surprised. He reminded me that he knew all along that creating the list of test cases would solve the problem. And thus we reinforce his perception of linearity, and increase my sense of frustration. I am working with a systems approach and trying to inoluence the relationship between Luke and Kathy. Greg is working with a systems approach and trying to influence the relationship between Luke and his boss. I believe those approaches might work. But Vijay still believes that creating procedure documents that no one reads or converting test plans into bullet points is going to change the environment. He does not perceive the actions that Greg and I have taken as having value and thus he attributes the change in Luke's behavior to the creation of a list of bullet points. This is difficult for me to deal with. I am puzzled as to how I can change his view of the world.
My head was spinning. As I pondered the immense gap between my world view and Vijay's, it finally occurred to me that Vijay is right after all. He short circuited a few steps, but he is right that the checklists are going to get the credit for changing this ecology. When I gave Luke that checklist it gave Luke an excuse to change his behavior. That checklist allowed Luke to save face. He cannot admit to himself that his prior behaviors were costing his company lost time and my company lost revenue. His self image does not allow him to see the impact his behaviors were having on us all. But he feels the pressure that his boss and I are applying. And here he has a way out of our vise grip. All he needs to do is take that list of bullet points and then tell the world that it is the list of bullet points that makes the difference. He now has an excuse to go to his boss and say that while he had been rejecting our code in the past now that he sees this list of bullet points it is safe to assume that our code is good.
I need to remember this lesson. Luke could not change his position without losing face unless we gave him a scapegoat. Changing this one document allowed him to transfer the blame to our document and thereby avoid accepting his role in this convoluted system.
Soon the rest of the code began trickling over. One by one the modules piled up. Kathy still had obj
ections but Luke tempered those objections to a manageable checklist. Luke still changed the requirements, but he did so only after calculating the feasibility that we would still finish on time. I think this just might work.
A Few Small Diversions
We are getting better results with this iterative approach. We also benefit from having two people on-site rather than just one. I can take care of the project tasks such as requirements, schedules, budget and communication. Mahesh then takes care of quality assurance and risk mitigation. When there is a quality issue, we now have two options. Time permitting, we send the code back to the offshore team and they address the issues. But when we are short on time then Mahesh tries to address the issue immediately. The problem is that we do not have enough budget to pay for both me and Mahesh. Greg's solution is to spread my time over multiple projects.
There are weeks when I am out of town working on a project for some other customer. There are weeks when I am in five cities in five days working on five projects. This makes it a lot more difficult for me to stay focused but it means that we are spending at a rate that is closer to our budget.
One