Workplace
Ecology: A Case Study in Project Management
By Robert E. Perrine.
Smashwords Edition.
Copyright 2010 Robert E. Perrine.
Copyright
Copyright held by Robert Perrine and Marlene Weldon, Long Beach, California. You may not copy or distribute this document without advanced written permission from the document authors. Contact Robert E. Perrine at http://www.robertperrine.biz.
This ebook is licensed for your personal enjoyment only. This ebook may not be re-sold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each person. If you are reading this book and did not purchase it, or it was not purchased for your use, then please return to Smashwords.com and purchase your own copy. Thank you for respecting the hard work of this author.
Acknowledgements
I want to thank all of the friends I have worked with over the years who helped me learn about project management and about people. Special thanks go to Brian, Franklyn, Jim and Tom for their support and encouragement while I was working on this book.
Disclaimer
This is a work of fiction. Any resemblance between characters in this story and people in real life is purely a coincidence.
Table of Contents
Introduction
Initiating
Planning
Monitoring and Controlling
The First Deliverable
The Successful Second Work Package
Communication for the Third Work Package
The Failed Fourth Work Package
Re-Planning
Testing the Fifth Deliverable
A Few Small Diversions
Seeking the Sixth Deliverable
Six Scapegoats
Lessons Learned
Bibliography
It seems to me that most books written about project management are tall tales. I read about how project managers use their skills and expertise and accomplish great things. In my opinion, most of those stories are fables. I have taught a lot of project management classes. I learned to separate the theory of project management from the reality. My goal in this story is to help you see the reality. The naked truth is that lots of projects fail. Within Information Technology (IT) the number of failed projects exceeds the number of successful projects. Those failures are then typically attributed to technology. I think that denies the truth in the matter. Most IT projects fail because of people.
When I did project management on civil engineering projects I learned that there were vast books of rules that govern how buildings are built, streets are paved and projects are approved. Very little of that applies to IT. So, as you read this story, look for the ways that people are twisting and manipulating the goals of the project. Also pay attention to the way the people who are supposed to be supporting and sponsoring this project often sabotage the effort. I hope that this story helps you understand what project management in information technology actually looks like.
The events in this story are loosely based on a real project. All of the characters and project details have been fictionalized. But the core of the story is intact. I hope you enjoy this story.
Here am I back in the consulting game again. The original project that Greg had for me was a business process re-engineering assignment. Then he found this tiny little project that has the potential to become a really great opportunity. My assignment is to go in, take care of this little project, implement best practices and then help grow the opportunity so that we can enlarge the contract. This is typical of Greg's approach to business. He likes to deliver superior customer service and then keep growing the opening one or two people at a time.
Some companies focus on marketing, some focus on engineering and some focus on service. The stereotype of a sales person is someone that promises more than they can deliver. The stereotype for software companies is that they focus on the technology - using the latest and greatest tools. Greg's company focuses on service. We deliver what we say we will deliver. And the company pulls together to make that happen.
As is typical of most projects, the initial negotiations took place while the project manager - that is me - was busy elsewhere. The account manager for this customer found an opening, put a proposal together and then worked with Greg to package a winning deal. Once the contract was signed they called me. My escalation point on this project will be Vijay. Vijay is the technical manager responsible for the programmers on several accounts, including this one. Greg gave me three goals:
Make this customer happy.
Grow our position in this customer site.
Use this little project to set up best practices that we can apply to other projects.
The goals set by the customer are to use contractors to temporarily augment the headcount in a small department. The contract says we will be developing new applications and supporting existing applications. Like most Japanese owned companies, this customer keeps a very tight grip on finances. There are rumors of an upcoming downturn in sales. Hiring a few consultants now will help get some work done. Then, if the downturn materializes, they will cut our contract and reduce their costs. If, instead, they were to hire permanent employees then it would be more difficult to cut costs on short notice. As Lax and Sebenius note in their book on negotiation, the essence of agreement is the perception of differences. (David A. Lax and James K. Sebenius) We are betting that the downturn will not impact this company and that will allow us to not only complete this contract, but to expand from there. They are betting that the downturn might impact their bottom line and thus they are willing to pay a premium for service now bundled with the option to react quickly. This is a win-win agreement.
The first two programmers that Vijay hired started work today in the offshore location. They are both experts in the programming language specified in the contract. We had a conference call and got to know each other. The key result was agreement on an organizational structure. Vijay will be their technical manager. I will be their project manager. If the team encounters technical issues, then Vijay will either solve them himself or borrow other resources from other projects to find a resolution. My job is to communicate. I need to communicate with the team and I need to communicate with the customer.
One of the lessons that I learned from the prior case studies is that the organizational structure does not always align with the flow of communication. Greg wants me to implement best practices on this project. Well one of the things that I learned from prior case studies is that defining the structure for the communication flow is just as important as is defining the structure for the organization. So the next task I undertook was to prepare a communications plan for this project. In that document I listed the expected meeting schedule and the expected delivery dates for the status reports. I also included a diagram, shown below, that describes the communication pathways that we will use.
The key to the structure shown above is to compartmentalize the communication. I am the Project Manager. I work for the service provider. The heavy dark line that connects my circle with the Project Lead for the customer is the primary communication pathway we will use. Work assignments will be transferred from the Project Lead to me. Finished work will be given by me to the Project Lead. My purpose for channeling communication like this is to ensure that the developers working offshore do not have multiple people giving them direction. I am interposing myself between this customer and that team.
Note that I am not trying to be their only communication pathway. If I did that then we would slide out of a matrix structure and revert to a projectized structure. On the contrary, the structure I propose actually extends the concept of a two-manager matrix into a three-manager cube. Note that there are three arrows connecting the developers with this virtual organization. I am their project manager. Vijay will take the role of Senior Developer. In addition, the developers also have an offshore personnel manager. This is a three dimensional cube. Vijay is going to focus on achievement, though he also dabbles with power. I am supposed to deliver results - which is achievement. But one of my roles with this customer is to represent our position in the contract - and that is power. The third dimension is the personnel manager at the offshore location. He needs to focus on affiliation while also being available to intervene if either Vijay or I push too hard on achievement or power.
I am proud of this structure. Clearly I am not the first to implement this cubic structure, but I think I might be one of the first to be able to explain why it works. Well, that is a bit premature. So far we do not even have the requirements for our first deliverable. I am confident, however, that this structure is going to help us succeed.
This is a new paradigm for me. I understand organizational structures and I have adapted them in the past to facilitate my projects. I felt comfortable with Fritz's explanation of the impact structure has on organizational change. (Robert Fritz) I have been working with Roger's explanation of communication for several decades now. (Carl R. Rogers) But this is something new. I am now experimenting with the concept of communication structures. For example, consider the following diagram that I drew when a committee I was on displayed some odd side effects.
I am a Deacon and my good friend Mark is an Elder in this Presbyterian Church. There was a problem that was brought to the attention of the Session - the governing body for the church. A committee was formed and we studied the problem and recommended a solution. But the process of getting there was emotionally difficult for Mark. This puzzled me and I love puzzles - especially when they relate to organizations. I pondered this and drew the diagram shown below. Do you see the stress that this communications structure placed on Mark? My recommendation to the committee was to divide this work between two Elders. The simplicity with which I could illustrate that problem and come up with a recommendation helped me realize the power of communication structures. Not organizational structures, but the structure used for communications.
Thank you for allowing me to digress. Now getting back to the focus for this chapter, the next thing I did was to document the metrics we would use to measure this project. I setup a spreadsheet with the following tabs:
--
Issues Log: a summary of the issues we are facing and our status on each.
Milestones: a quick overview of what is due when.
Labor expenditures: time tracking with costs.
Budget forecast: estimate at completion versus income.
Invoicing: tally of invoices issued and payments received.
Materials: tally of expenses related to hardware and software.
Cumulative Flow Diagram: tracking the constancy of our work effort.
Service Level Agreement Compliance: a list of incidents, the time required to resolve the incident and comparison of the time required to the time allowed by our service level agreement.
Meeting Value: my tracking of the results from surveys on meeting effectiveness.
--
I also created a procedural guide to explain each of these metrics. Then I met with Greg and Vijay and described this approach to best practices. Greg was impressed and said that this was exactly the type of documents he needed so he could implement best practices on our other projects. Vijay was not impressed and felt that all these metrics would do is highlight our failures and not provide value when we succeeded. And here we see the difference between a focus on power and a focus on achievement. Greg wants metrics and he wants this company to get better and better. Vijay has an aversion to metrics. People who are motivated by power know that metrics are a two - edged sword. If you measure and report impartially there is always the chance that what you report will be bad. Even so, we reached agreement to give this a try.
But one of the key lessons that all three of us learned years ago is to experiment in a controlled environment. We will implement these new structures and track these metrics on this tiny project because this is safe. I believe in this approach and I will use this experiment to work out any bugs in my process. Greg believes in this process but knows it will be difficult to sell governance to his other project managers. And while Vijay is skeptical, he is willing to give it a try as long as we minimize the risk in case his misgivings prove true.
I then scheduled a kick off meeting. I invited Greg and Vijay from our company. I invited the Project Lead and Technical Lead from the customer's organization. The Project Lead is named Luke. The Technical Lead is someone named Kathy. I know their boss from prior work I did for this customer a few years ago so I invited him as well. When the meeting occurred, Luke and Kathy and I met for the first time. They seem nice. I have always enjoyed working for this customer. They have a good ecology. They value people and treat them well. We told them we are ready to start work. We gave them the resumes for the two offshore developers and we briefly outlined my prior experience in using the methodologies that this customer requires. It was a good meeting.
The PMI process groups include "Initiating", "Planning", "Monitoring and Controlling", "Executing" and "Closing". (PMBOK) On this project, "Initiating" was the negotiation and bid process that culminated with the signed contract. That contract serves as our project charter. During "Planning" we hired two programmers, created the communications plan, documented our process and held the kick off meeting. Our process document will serve as the project plan for this project because this is an iterative development effort. We do not yet know what we will build. The business users will process requests and we will deliver code to implement the agreed functionality. There is some risk in agreeing to build an undefined product, but that is just part of what makes this agreement mutually beneficial. The company I work for likes a challenge and is happy to respond to the unknown. The customer does not like risk and does not like the unknown.
At the conclusion of the kick off meeting we transitioned out of planning. I, as the project manager, will now focus my efforts on "Monitoring and Controlling" this project. Our developers will focus on "Executing" and turning requirements into deliverables. We hope to avoid the "Closing" process for a long time by delivering high quality work on time and thus win successive extensions to this contract.
A few days later Luke gave me a brief explanation of our first coding assignment. Unfortunately he also told me that his employer has decided not to give our offshore team access to their development systems. I updated Vijay and he was not surprised. This is a fairly common occurrence when working offshore. So he pulled a programmer off another project and assigned that programmer the task of copying the customer's code to a development server we setup in our local office. Going forward I will copy the requirements, test data and updated code to that location, as needed. The offshore developers will work in that environment and either modify existing code or develop new code as required by the customer. Then, I will test the results and copy the updates back into this customer's development environment. Setting up that environment took time.
While Vijay's team worked to set up our development environment I collected the requirements for our first assignment and created relevant project documents. This first assignment is just a few weeks of work to modify a few screens. I created test scripts to describe exactly how to test each update. And once our development environment was setup the two offshore developers read through the requirements for this project.
When the customer put this project out to bid they specified a specific set of development tools from a specific vendor. We hired two developers who were experts in that programming language. By way of analogy, suppose we wanted to open a new office in France. We would need to hire someone to head sales in that office. We would expect that person to be able to communicate with the staff in that office by speaking French. And, buried underneath those requirements is the expectation that someone proficient at sales in Europe should be able to work with people that speak one or two of the other common European languages. When we hire programmers we do not search for specialists that only know how to use one language. We search for programmers that are strongest in one language but ready and willing to use other languages as required. So, if this French speaking sales manager wanted to transfer to Germany, we would expect him to become sufficiently fluent in German to be able to make a sale. I expected these two programmers to be able to fend for themselves with a couple programming languages and I expected them to be willing to learn new languages as required. We missed.
Neither of these programmers was willing to work in the language required by the customer for this first assignment. This put us all in an awkward spot. Vijay had asked these two people to quit their previous jobs and come to work for us to do programming in their preferred language on this project. I assumed their ability to use other languages had been discussed, but it turned out that it had not been raised in the hiring process. I then went back and I probed what this customer actually expects. I learned that they had changed their plans but did not change the request for bids because it had already been distributed. We bid on a project with the expectation that we would work with one programming language. We hired people to work in that language. But the customer had already changed their plans and decided on another language. By analogy, we hired French speaking experts and now find that they need to learn Romanian.
Here is where the cubic reporting structure works. My project has no need for resources that will not program in the language now specified by this customer. Vijay currently has no other work assignments that call for the language that these two people prefer. Their third manager, however, knows that we lured these people out of their prior jobs and thus we owe these people an opportunity. The decision was made to keep them both on our payroll while searching for projects that will make use of their talents.
Vijay then scrambled and found two other programmers that want to work in the language that this customer is now specifying. All of that effort cost us time. We lost time because of the work required to 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 practices 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 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 requirements 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 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 implementation. Next I will show those results to Luke and Kathy and they will gladly tell me just how far we are from the target. They still might not tell me where the target is, but if they just keep on telling me whether we are getting closer to the target or further from the target eventually we will get it. But I need help on this. I am going to focus on the people. I am going to enlist Mahesh to focus on the technical. In essence, I am going to exchange Vijay - one of the owners of this company for Mahesh - our newest employee. We will still have a managerial cube. But the three managers will be the personnel manager, myself and Mahesh.
Consider the parable told in Matthew 13.
“That same day Jesus went out of the house and sat beside the sea. Such great crowds gathered around him that he got into a boat and sat there, while the whole crowd stood on the beach. And he told them many things in parables, saying: ‘Listen! A sower went out to sow. And as he sowed, some seeds fell on the path, and the birds came and ate them up. Other seeds fell on rocky ground, where they did not have much soil, and they sprang up quickly since they had no depth of soil. But when the sun rose, they were scorched; and since they had no root, they withered away. Other seeds fell among thorns, and the thorns grew up and choked them. Other seeds fell on good soil and brought forth grain, some a hundred fold, some sixty, some thirty. Let any one with ears listen!’” (NRSV)
I cast the seeds of best practices in several prior organization but as soon as I left all of my work ceased. It was as if the birds came in and ate up all my metrics and all my processes. I came here to work with Greg to implement best practices. But, once we encountered resistance the effort was abandoned. Greg's desire for best practices fell on rocky soil, withered and died. Here my effort is being choked by thorns. The way around that is to find the good soil where these efforts can succeed and nurture that soil so that it will support the effort. Mahesh, Sanjay and Srinivas want to grow. They represent the good soil that can yield a hundred fold. If I can invest the time into teaching them how to make this work then they will carry that message with them to other projects and our success will grow. Now, by implication, that implies that Luke and Kathy are the soil that is choked with thorns.
“He put before them another parable: ‘The kingdom of heaven may be compared to someone who sowed good seed in his field; but while everybody was asleep, an enemy came and sowed weeds among the wheat, and then went away. So when the plants came up and bore grain, then the weeds appeared as well. And the (workers) came and said to him, “Master, did you not sow good seed in your field? Where, then, did these weeds come from?” He answered, “An enemy has done this.” The (workers) said to him, “Then do you want us to go and gather them?” But he replied, “No, for in gathering the weeds you would uproot the wheat along with them. Let both of them grow together until the harvest; and at harvest time I will tell the reapers, Collect the weeds first and bind them in bundles to be burned, but gather the wheat into my barn.”'" (NRSV)
Luke, Kathy and Vijay are not thorns. They are just caught in soil that produces thorns. And any action that I would take to destroy the thorns is going to do harm to the wheat that they can produce. What I need to do is to continue to fertilize and water this soil and allow the thorns to grow along with the wheat. Later the harvesters will separate the wheat from the thorns. That is not my job. On the contrary, my job is to try to minimize some of the stereotyping that I see going on here. Even though the environment here is much better than it was when I worked a couple blocks down the road at their competitor's facility, there is a class structure here that corrodes the relationships. Employees consider themselves superior to contractors and contract programmers are superior to contract project managers. Similarly, on-site work products are presumed to be better than are products from offshore.
We create these environments. We nourish these ecologies. When I worked in construction, we rewarded workers for their muscle power and reinforced the stereotype that construction workers do not use their brains. In data processing we encourage people to focus on the technology and reward them with labels like geek and nerd. We reward people for distancing themselves from who they are. We amplify the feedback loops that cause people to abandon their efforts at integration and wholeness. Vijay is caught in this spiral. If he was the technical manager for this company then he would soon find himself challenged from multiple directions by people who are technically his superior in one narrow discipline or another. But as part owner of this company he is immune from those challenges. He does not get the feedback that would tell him that he needs to learn to listen and collaborate.
I have made a few allusions toward the barbarian behaviors of IT professionals. Here is the reason those behaviors exist. We reward those people for amputating their personalities and help them stunt their social and emotional growth. We treat programmers like a machine that can only produce one product and we work them twenty-four hours a day to create more and more of that same product. We need to change this.
I need to change this ecology and help these people grow out of the shells they now inhabit. I have some ideas, but today I do not feel like I have answers. Therefore I am going to first change myself and then try to change this ecology. I am going to water and fertilize this ecology and let time tell where the wheat grows and where the thorns dominate.
The first change that I need to make is to start running again. You might wonder what running has to do with resolving our project management issues. The connection is that I am not acting like an integrated whole. I have given up important aspects of my life in order to put more time into this project. But that is counter-productive. I resent the time that this project takes and I resent that I am putting time into this effort to the exclusion of other parts of my life. Tonight I am going to start running again and make it a point to do so at least five nights a week.
It is time to go back and check my alignment with the goals that launched this journey. Please indulge me while I do a quick mental comparison of where I am now. After all, the reason for doing a case study is to assess whether or not the processes that I propose can survive in the real world. So here we go.
We need to start with a vision of what this project team can be. What I now see is that this system perpetuates negative behaviors. We reward people for seeking dominance to the exclusion of cooperation. We reward people for focusing narrowly on achievement to the exclusion of their own maturity. We freeze people out of the decision processes and then act surprised when they feel alienated. These behaviors are normal responses to the environment.
I believe that a properly defined vision has six elements:
Download this book for your ebook reader.
(Pages 1-24 show above.)