Workplace Ecology: A Case Study in Project Management, Page 5

the evaporating cloud shown below. This is Luke's dilemma. His managers insist that Luke must react immediately when the users decide on a change. And his managers insist that Luke use offshore workers because they cost less. Luke wants workers sitting a few feet away from him so that he can immediately redirect them in reaction to changed priorities. Management did not give Luke what he asked for, yet they still hold him accountable for the results. The only way Luke sees to escape from this conflict is to help his managers see that offshoring did not work in the past, is not working now and will not work in the future.

   

   

  Once I understood this cloud I called Vijay and I explained the reasons as to why Luke does not want us to use offshore workers. Vijay replied that it is my job to make this work. I asked Vijay which was more important - prove that offshoring works or get a renewal on this contract? I should have known better because he replied that it was up to me to ensure that both happened. Thus, my cloud is only slightly different from Luke's cloud.

   

   

  Even so, I persisted and soon the conversation got a little loud. We will not get the benefit from lower offshore costs if we need to do all the work over again two or three times. We will not get the contract renewal unless we make Luke happy. And the only thing that will make Luke happy today is to put more programmers on - site and help Luke deal with the chaos that his managers have created for him. We then both reverted to our primary orientations. I quoted from my metrics report that shows that our labor expense is over budget and our forecast went negative a couple weeks ago. I emphasized that these metrics show that we are losing the advantage of lower offshore labor rates because we need to keep doing the work over and over again and Luke is not motivated to solve this problem because he believes his is better off demonstrating that offshoring does not work.

  I should have known better. Achievement speaks metrics. Power is adverse to metrics, especially metrics that are negative. Vijay told me to stop distributing the financial metrics and to stop collecting the data. That ended my gambit to use metrics to make this operation better and better. Now I am still going to collect that data anyway, but I will no longer be able to use it to help Greg understand what is happening here.

  Next it was Vijay's turn to propose a solution. True to his preference for immediate impact he decided that all I need to do was to update the procedural document and our problems will be solved. I asked if he had finished reading the prior version and he said he had not. I reminded him that Luke has not read the prior version either and I asked him how updating a document that no one reads is going to fix the problem? He replied that this is the solution and it is up to me to make that update and then get results. This is linear thinking. Consider the following statements of cause and effect. Which are true and which are only partially true?

  --

  If all the programmers work in the same building they can get more work done.

  Using offshore labor costs less than using on-site labor.

  Increasing the size of the team means we will get better results?

  --

  In my opinion, statement one is only partially true. I have worked with offshoring efforts where the time zone difference was an advantage. I have worked with offshoring efforts where the isolation was an advantage because that team was better able to focus. That, after all, was the key element in the proposal I gave Fred in the prior case study. In general, there are advantages to having everyone communicate verbally and there are advantages to requiring that communication be formal and written. For example, if Luke would help us revise the requirements document that I prepare and if Luke would sign those documents then my offshore team could work is isolation and be judged solely by how well their results match the requirements.

  Similarly, in my opinion, statement two is only partially true. We are not getting this advantage today because this is a fixed price contract and we need to keep doing the work over and over again. It is also clear that as long as this customer minimizes the requirements process we will need to continue to do the work over and over again.

  And I also think that statement three is at best only partially true. First, we need to remember Brook's Law: “Adding manpower to a late software project makes it later.” (Frederick P. Brooks)

  Then, beyond that, adding more gasoline to a fire is typically noted as a way to increase, not decrease the spread of the flames. Putting more resources into an effort that already allows the users to redesign the application hours before the production release is only going to encourage the users to be even more irresponsible in their actions. If anything, we need a dampening effect.

  That is the magic word - dampening. This system is currently running as an amplifying loop. I need to dampen the negative feedback. Consider the diagram shown below. Luke does not believe in offshoring. Therefore he sees little incentive to give us a full description of what is required because he assumes the effort will fail anyway. This means we are working with incomplete requirements. Then magnify those communication gaps with the inherent communication problems that come from working offshore and the net effect is that the work is poorly specified and incompletely understood. The natural result is inadequate work results.

   

   

  Every time we deliver a product that does not meet Luke or Kathy's expectations we reinforce their prior assumption that this is a doomed effort. Add onto that the fact that Kathy has very high expectations - expectations set so high that even Luke cannot do work good enough to please Kathy. Add onto that the fact that Kathy often has her own design in mind for the code but never participates in the requirements sessions and never tells us what she was thinking. Every step of the way we add to the problem. What we need to do instead is to dampen - we need to start subtracting. Vijay wants me to work on the top most step in this double loop. He wants me to enhance the requirements. At best that would help us better align our work with Luke's expectations but it does nothing to change Kathy. Thus I reject this suggestion.

  There is an approach to artificial intelligence called neural networks. The premise for that technique is that pathways that lead to success are reinforced while pathways that fail to deliver should atrophy. You represent those pathways through nodes with branch points and assign probabilities of success to each branch. My mental model of this situation is being adjusted and the probability of success I assign to our current pathways is being decremented. I then began searching for another pathway.

  The approach that I came up with is that I will do the opposite of what Vijay recommends. Instead of trying to get better requirements I am going to spend less time trying to guess what Luke wants. After all, I only have a fifty percent accuracy rating so far. So instead of working on the top part of this system, I am going to interpose myself into the juncture where Luke and Kathy collaborate. My plan is to bring inadequate work results to those sessions and allow Luke and Kathy to critique. Thus, I will finally be able to get requirements from them. And they, in turn, will see that the offshore effort increases their importance and is not a threat to their jobs.

  Today we refer to software development like this as iterative development. Few developers, however, are able to intentionally strive for inadequate results. Our pride gets in our way and we put more and more time into trying to make our code perfect for the requirements that we understand. In this situation that effort is a waste. I cannot get adequate specifications when all I have is a five minute verbal exchange with half of the team that will judge our results. My problem is going to be forcing that offshore team to give me code that they know is inadequate. I am going to need to force them to give me junk that they are ashamed of so that Luke and Kathy can tell us what it is that they are actually expecting. I will fail in that effort unless I dampen the communication between here and there. I need to absorb the insults and prejudice in these meetings and suppress that tone in my conversations with Sanjay and Srinivas. I need them to focus on the value they
are delivering. I need to continue amplifying the positive reinforcement that they receive so that they understand how much I value their effort.

  Years ago engineers used iterative techniques to solve problems that were too complex for their slide rules and calculators. One such technique was the Hardy Cross technique for analyzing a grid of water pipes. The core of that approach is to accept our inability to know the results in advance. I entered the engineering profession at the juncture where computers were just beginning to penetrate the industry. One of my first programming jobs was to put the Hardy Cross technique into a computer program. I spent considerable time studying the process and the implications. What I found is that inadequate initial guesses had little impact on the eventual solution. Perhaps the computer had to repeat the iterative cycle a few more times, but those few extra cycles took less time than it would have taken the engineer to prepare better initial approximations.

  That is the technique that I am going to use here. I am going to spend the minimum time required to document my initial guess at our requirements. I then need the offshore team to spend the minimum amount of time possible to give me their first pass at an