create our own development environment. We lost time searching for replacement developers. Those risks are part of the deal. We agreed to do this work with the risk that the unexpected might happen. This customer is paying us a premium because they like the ability to change direction frequently but they want to transfer the downside of those changes to someone else. In essence, we provide insurance to protect them from the side effects of their mistakes.
A few days later Vijay setup a conference call and I talked with Sanjay and Srinivas - our two new offshore developers. They both impressed me with their willingness to adapt as required by this customer. They had both reviewed the requirements and examined our development site and they were ready to start. We lost a little time, but now, as Jim Collins puts it, we have the right people on the bus. (Jim Collins) A few days later Sanjay sent over the code for the first couple modules and I passed them on to Luke - the project coordinator representing this customer. Luke said thank you but then casually mentioned that he did not need these modules. Luke stated that offshore development has not worked on any of the projects he coordinated in the past and he does not expect it to work now either. He was not going to look at this code because he knew it would not be acceptable. Instead, he had asked Kathy to go ahead and do this work and he knew that Kathy would get it done in a couple weeks. Further discussion was futile.
While in his opinion we had "failed" with our first assignment, Luke agreed to give us another chance and sent over a brief description for our second assignment. I forwarded that preliminary specification to Sanjay, Srinivas and Vijay. Then I set to work to turn those rough notes into a requirements document and a test plan. I will give Luke the benefit of the doubt. They had changed the programming language we were using, but there was some fine print in the contract that said things might change once in a while. He had rejected our first set of code without even looking at it because he has a prejudice against work that is performed offshore. Well, those are exactly the types of risks that caused Greg to think of me when he put his bid together for this work. All I need to do is build the relationship with Luke and clearly communicate the quality of the work we are performing. I cannot expect to overcome Luke's prejudice against offshore work all at once. That will take time. And this is going to require a change to the ecology of this environment. It might be permissible to change the programming language after we hired our staff, but those actions do harm to the ecology. It might be permissible to reject our code without looking at it, but that action harms the ecology. I need to use the tools I have as a project manager to repair and then revise this ecology. And the two tools that I find most suitable for this purpose are neutral documents and effective communication. I will document our plans and communicate with Luke to make this work.
The Successful Second Work Package
About a week later I gave Luke a requirements document and test plan for this second coding assignment. He glanced through them and said we could proceed. These were fairly small code updates and Sanjay and Srinivas both understood what was required. I setup a shared workspace and asked that they each post an update every day to describe what work they had finished. Then I waited. Nothing happened. I followed up, got their commitment to use that shared workspace to post status updates. I waited but again there were no updates. I asked Vijay why I was not getting updates on status. I reminded him that our first work assignment had been rejected and explained that it is vitally important that I give Luke frequent status updates and send him samples of the code as soon as possible. Vijay replied that programmers are just not interested in status updates. Writing code is important. Providing status updates is too much like doing paperwork and real developers do not do paperwork.
How can you persuade the developers to give you status updates when their technical manager thinks it is meaningless? Ah, here is where the cubic organizational structure came in handy. I sent an email to their personnel manager and explained that I need a daily phone call from Sanjay and Srinivas. Vijay replied to my email that he also supports this approach. The personnel manager then replied that he thought this was a good idea and so I got a phone call that night from Srinivas. We agreed on a schedule and I now get a status call every business day.
This second code change went well. I tested it thoroughly and transitioned the code to Luke. Luke again grumbled and reminded me that he already knows that offshore work is never going to succeed. So I showed him that the code worked in our test environment. He agreed to ask Kathy to set it up in their test environment. It worked. He had Kathy review the code. It matched our requirements, matched their coding standards and matched the testing criteria. Kathy updated Luke and Luke moved our code into production. By over - achieving on the documentation and by insisting on a daily status update we succeeded. Luke is now using code developed offshore. Note that I never confronted him to challenge his belief. If I had told him he was wrong, then he would have been more determined to prove his was right by finding fault with our work. Instead, I accepted Luke as he is and then strove to give him evidence that would change his behaviors. His opinion has not budged. But when he put that code into production he created a dissonance between his actions and his beliefs. That dissonance will change Luke.
Communication for the Third Work Package
Luke and Kathy feel the pressure most developers feel to either stay current with technology or get left behind. There is a new project that the business wants implemented and Luke sees this as a great opportunity to try out a new programming language. Luke invited me and Vijay to a meeting where he outlined the requirements for this third work package. Both Vijay and I have some prior experience with this software and agree it has benefits but we expressed our concern that it might take too much time for Srinivas and Sanjay to learn this new language and then build the application. Luke believes this new language is the right tool and wants us to use it.
Vijay connected with Sanjay and Srinivas that night and both were reluctant to take on another programming language with such tight deadlines. Vijay reached a compromise. Srinivas will learn the new language and start the work while Sanjay continues to work with the other languages. Extending my prior analogy, we will now be working in French, Romanian and Swahili.
After a few days Vijay realized that we were going to struggle to meet the delivery schedule on this third work package so he began doing a lot more work himself to support this effort. This is taking him away from his other work assignments and his labor is an expense with no offsetting income. After a while he decided that the only way we could meet the schedule defined by Luke was to add another programmer. Vijay assigned Mahesh to work with us on this project and the work began to take shape. I extended our weekly status meeting with Luke to now include a review of the work already completed for this work package. I want Luke to see results quickly.
After one of those meetings Vijay and I talked about my weekly metrics report. First, while our contract says we need to respond to incidents so far none have been assigned to us. Vijay recommended dropping that metric from our weekly status report and I agreed. Then we talked about the cumulative flow diagram. Vijay explained that Luke does not understand this chart and I explained that I expect it to take time for him to absorb the concept. Vijay continued with this theme and it occurred to me that the real issue is that Vijay does not understand this graph. I spent some time telling Vijay the types of things I would tell Luke to help Luke understand. It made no difference and Vijay asked that I drop this metric from our weekly status meeting.
Following that discussion I thought about the value that these metrics provide in creating a common understanding of progress. Greg has asked me to define appropriate metrics for best practices and I have done that. But if we cannot use those metrics then what is the point of tracking them? To me this is a pivotal issue. Do we want best practices or not? I need to probe that issue and find out where this company stands. I put together a proposal for implementing best pract
ices as a way of probing for feedback. I sent that proposal over to Greg and Vijay and to two of the other project managers that I worked with in the past. I got no response. I waited a week and then sent a follow up email. I got no response. I then stopped by the office and asked Greg for his feedback. Greg is an honest, honorable person and he told me he simply had no time to read my proposal. We talked and he raised the implication that if he is so busy reacting to new opportunities then he will never have the time to implement process improvements. He promised to get back to me in the future and I thanked him for his honesty. I had the answer I was looking for. We will not be doing best practices at this time. I then dropped the service level metrics on incidents and I dropped the cumulative flow diagrams from our weekly status meetings.
I updated Vijay and he suggested I also stop assessing the meeting effectiveness. In his opinion, all the meetings are effective. And if a meeting is not effective then we do not want to tell people that it was not effective. I explained that these metrics give me immediate feedback and allow me to take corrective action