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

before it becomes a crisis. He does not understand that concept. From his point of view if you measure you might find something you do not like, thus it is better to not measure. From my point of view, the reason for measuring is to find things to change so that you can get better and better. Vijay has the power approach - claim victory immediately and then avoid testing that reality. I have the achievement approach - probe until you find something to tweak and then work to make it better and better. Greg is caught in the middle. He is achievement focused, but he is overloaded. And, most importantly, there is one detail I forgot to mention earlier. Greg is an employee while Vijay is one of the owners. And that tips the balance. I will stop assessing meeting effectiveness and do what Vijay requests.

  Meanwhile, Srinivas and Mahesh (our newest programmer) are making good progress but their efforts seem scattered. I took some time to meet with Mahesh and go through the project schedule with him. As is typical, there is something about a project schedule that seems to create a mental block. So I copied the tasks out of Microsoft Project and pasted them into a spreadsheet. Then we met again and like I have seen before, the light went on. From now on I will communicate our schedule to Luke, Vijay and Mahesh using a spreadsheet.

  I was beginning to get concerned that something similar was happening to my weekly status reports as well. Fortunately the standard template this customer uses for their weekly status report is a word document and it is fairly simple and easy to read. But I have noted a couple issues there and raised them in our weekly meetings and nothing seems to be happening. So I followed up with Luke and found that he does not have the time to read the status reports that his company requires that I submit. Nor has he had the time to read the requirements and testing documents that his company requires that I prepare. Here we have a disconnect.

  When we next met I took the time to walk through all of the items where I needed a response from Luke. This annoyed him but it opened things up a bit. As a matter of fact, it opened things up a lot more than I had expected. It turns out that the requirements that we had originally discussed no longer aligned with what Luke was expecting. Somewhere during the prior weeks Luke had decided on a fairly significant design change and simply forgot to tell us about it. This worries me.

  There are four standard means of communication: written or verbal, formal or informal. Examples of each are shown listed below.

  --

  Written and Formal: A contract

  Written and Informal: An email

  Verbal and Formal: A command

  Verbal and Informal: Conversation

  --

  Because our focus is on doing as much of this work as possible offshore, I need to rely on formal, written documents - things like project schedules, requirements documents, test plans and status reports. Luke, on the other hand, really prefers informal verbal conversation. He likes to just spin his chair around and tell Kathy to go do something. When he gives me informal verbal instructions like this I need to turn those instructions into formal written instructions so that the offshore team has a way to understand what is required. I always copy Luke and Vijay when I send out those communications and I have been following up with Luke and Vijay regularly to ensure that what I have been documenting is what they think we are supposed to do. What was becoming clear in this conversation is that Luke has not been reading those documents. I pushed on this issue to make it clear how catastrophic that can be to our offshore effort. To my surprise Vijay came to Luke's defense. It seems that Vijay has not been reading any of my documents either.

  Luke likes to give informal verbal directions and then verbally change directions a couple times a day to get the results he wants. This is fast and efficient. But Luke's company wants a cheaper price for services and they want this work done offshore. Luke is not going to phone the offshore team and even if he did we are out of synchronization with their time zone. The way to make this work is to take the time to document what we are going to do in writing. Now it is clear as to why Luke "knows" offshore will never work. Unless you communicate effectively with the offshore team they can never succeed. This is going to be an ongoing problem. Fortunately Mahesh and Srinivas were able to correct the misalignment between my documents and Luke's expectations before the due date for this work package. We got lucky this time.

   

  The Failed Fourth Work Package

  While Mahesh and Srinivas were busy on the third work package Sanjay was doing fantastic work to finish the fourth work package. I had documented this work package far more extensively than I had the prior work packages. But based on what I had just learned about our third work package I am now concerned. I asked Sanjay to send me all of the code that he had finished so far and I passed it over to Luke to test. Luke installed our code, tested it for a couple hours and told me he was pleased. He added, however, that as he was testing he came up with ideas for a few changes. I was not surprised, but as he described those changes I began to worry about the size of the change compared to the amount of time we had left. I wrote up a description of the required changes and sent it over to Sanjay. When we talked later that night he was also concerned but promised to do everything he could to finish on time.

  Sanjay did exactly what he said he would do. He delivered. He gave me the complete package nearly a full week before the scheduled delivery date. I passed this code over to Luke and asked that he verify that all of his changes had been incorporated. The next day I asked Luke if he had any issues with our code and he said none so far. The next day I asked Luke for an update and he said he would get back to me if there were any problems. We continued this dance right on up to the date when the code was to be put into production.

  At 10:00am that morning Luke said that he had decided upon a fairly significant design change and asked that I have the offshore programmers make the required changes sometime in the next couple hours. I reminded him that they were asleep. He was a bit frantic, but he said he was sure Kathy could take care of it. About an hour later Luke called me and Kathy into a conference room. Kathy explained that none of our code worked and that she was going to delete it and start over again. I offered to show both of them that our code worked just fine in our test environment. They did not have time right now to look at those screens because they had a tight deadline to make. I reminded them that Sanjay is a very good programmer and it had taken Sanjay several weeks to make the changes he had already completed and thus I was skeptical that Kathy would be able to start over again and finish in two hours. Luke agreed and asked that I have Mahesh assist. Again I tried to get them to slowdown and look at the fact that our code was working correctly in our test environment and then troubleshoot from there. I lost on that one.

  Mahesh looked through the work that Sanjay had done so that he could understand the approach Sanjay had taken. Mahesh then tried reasoning with Kathy that the work Sanjay had finished was quite complex and not easy to do over again in two hours. Kathy and then Luke told both me and Mahesh that they had already made their decision and what they needed now was for Mahesh to get busy writing new code.

  Two hours later Kathy realized that she was not going to finish in time to move the code into production that night. She and Mahesh kept coding until late that night and then they started again early the next morning. When he got in that morning Luke tested Kathy's code and found significant issues. As Luke started explaining the requirements to Kathy it dawned on her that the work Sanjay had already done was, after all, the best approach. So Mahesh copied Sanjay's code from our test server and overwrote the code that he and Kathy had just spent ten hours frantically writing. He and Kathy then started to work on Sanjay's code, not to redo everything, but simply to apply the changes that Luke had requested. In a few hours they had things working well enough to push it into production. Luke then called me, Mahesh and Kathy together for a meeting.

  Luke again reminded me that offshore development never works. I countered that the code that had been delivered exactly matched the requir
ements we specified. Luke responded that this is the heart of the problem. All he wants is a couple programmers sitting here so that they can do what he tells them to do. He does not want programmers working offshore and he wants nothing to do with project managers. "Project managers add no value. Programmers are the people that do real work."

  Earlier in this chapter I explained that the purpose for contracts like this is to insure the customer against risk. The primary risk that this customer faces is continually fluctuating requirements. In my opinion, the best way to mitigate against indecisive requirements is to use iterative coding. This customer, however, also wants lower costs. And the magnitude of the cost savings they want can only be obtained by working offshore. Poor Luke is caught in the middle. His users can change the requirements on his project right up until a few hours before the code is scheduled to deploy. But his management wants the cost benefit that comes from working offshore. Luke cannot change the users and Luke cannot change his manager. Luke can, however, express his anger at the situation.

  I learned a technique called “evaporating clouds” by studying Eliyahu Goldratt. (Eliyahu Goldratt) Consider