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

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.

   

  Monitoring and Controlling

  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.

   

  The First Deliverable

  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 t
heir 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