 
                               **Communication Deficiencies: 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

Candidacy

The First Week

The Executive Briefing

One Step Forward, Two Steps Back

A Part Time Project

Going Nowhere Fast

Skirmishing over Scope

Dialogue

Bottom-Up Management

Specialization

Post Mortem

Footnotes

**Introduction**

This case study is loosely based on a real project. My goal in this case study is to help you understand how real projects work in information technology. Everywhere I go the story is the same because people behave in consistent, repeatable patterns. This case study is about the behaviors that shape those patterns.

My intent is not to open a window, but to present a mirror. Friends who have previewed sections of this book initially surprised me with their reactions to my stories. Many years ago Carly Simon wrote a popular song called "You're So Vain" (1). The theme of that tune is that someone had such a self-centered view of their world that he or she thought other people's comments were directed towards him or herself. As a composer, she was insulted. As an author, I take it as a compliment. My goal is to allow you to relate, to see yourself reflected here. Not because you are self-centered, but because you are human and this story is about human behaviors.

This case study is loosely based on one specific project but the characters are composite representations of behaviors. Some people are excellent models for certain behavioral patterns and so I fall back on my recollections of their actions to add color to my stories. You probably know people with similar behaviors. When you place yourself and your friends into this story, then we share a glimpse into reality. If you have been in this business for a while then you are going to recall similar incidents. If you are just entering this career then I give you this story so that you can vicariously expand your understanding.

This book was originally planned to be part three in a longer work. The original work would have been a reasonably long hardcopy book. When I switched to electronic publishing I realized that it was necessary to shorten each work. So I split that original work into four books: _Summary of Best Practices for Information Technology_ , _Survey of HR for Projects_ , this book and _Workplace Ecology: A Case Study in Project Management_. What that means to you is that I sometimes assume you already know what I mean when I mention some otherwise obscure reference. For example, in _Survey of HR for Projects_ I describe Vroom's concept of management styles. If my abbreviated explanation in this book is too vague, I suggest you look in _Survey of HR for Projects_ for a better explanation.

I hope you find this story enjoyable. And I hope you are able to learn something from this.

**Candidacy**

8 January. A friend sent an email about a project management job that requires that the project manager have prior experience as an Oracle database administrator (DBA). I replied that I was interested. Among friends we refer to these types of jobs as a "purple squirrel" job. It is not just that the squirrel must look like a squirrel, act like a squirrel and be technically competent in all aspects of being a squirrel, but there are other requirements loaded on top. Finding a highly proficient project manager is rather like finding a highly proficient squirrel. But finding a highly proficient project manager that also has experience as an Oracle DBA, now that is like searching the woods for a purple squirrel.

Later that day I got a phone call from Harry. Harry is the recruiter searching for this particular purple squirrel. We talked a bit and we discussed an hourly rate. Harry seems friendly and did not seem too pushy. Some recruiters focus on their power and treat people poorly. Harry seems stronger in affiliation than power but I could not read him on his achievement motivations.

9 January. I went through a phone interview with John. John is a "Practice Manager" responsible for reviewing the work completed by the project managers that work for this contracting company. From what I can tell this contracting company has an internal PMO to provide process and procedures to their project managers. John described the tools they have created and asked a lot of questions about my work experience. He then told me that he will be my "mentor" if I get this project. My take is that he is high in achievement motivation, good with affiliation and knows how to use his authority discretely. These are good characteristics for a mentor. I think I will enjoy working with him.

10 January. This contracting company is trying to set up an interview for me to talk with their customer. Their timing is good. I have a couple other interviews with prospective customers coming up fairly soon and my goal is to synchronize whatever offers come out of those interviews so that I can choose which one I prefer. I do not want one offer to come in a week earlier than the others because that would mean either accepting it before I know about the others or rejecting it and then possibly ending up with nothing.

12 January. Someone named Jim called to tell me that my interview with this customer was supposed to begin half an hour ago. Fortunately it was postponed. That is good because I had no idea I was supposed to be in an interview half an hour ago. Jim is the account manager responsible for this customer. This is a typical arrangement. Harry works the external environment to recruit while Jim focuses on the customers. I am a bit concerned about this contracting company because Harry forgot to tell me about the interview. That slip would have eliminated me from consideration with this customer. Thus, that slip in conscientiousness by Harry has increased my neuroticism. So far I have talked with three people in this contracting company. All three seem agreeable and open. All three display behaviors consistent with extraversion and calmness. But if they are this disorganized at getting me to the interview then this could be bad.

19 January. It took another week before I finally had an appointment for my interview. Once I got to this customer location I met with Joshua and Raj. Joshua is the functional manager responsible for this project team. Raj is his assistant. Joshua did most of the talking so this was an easy interview. They asked a few technical questions to verify that I understood what a DBA does and to assess my skill as a project manager. They are true techies. They just want to go create their new application and they need someone to keep them on track. They like me and I like them. We are aligned. Achievement is our goal. Affiliation is a tool to help us get there. Power should just naturally follow because we will be getting things done.

I then met with Dan. Dan used to be the director responsible for this project team but he was recently transferred to another assignment. He stressed his power to fire me if I do not do things his way and discouraged my attempts at affiliation. He then told me that I have four weeks to solve this problem or he will get rid of me.

I next met with Sam. He told me that he is responsible for all of the projects in this company. I asked him for his assessment of the status of this project but he did not know. He told me that he is responsible for all of the templates and project documents in this company. I asked which templates had already been used for this project and which documents had already been reviewed, but, again, he did not know. Like Dan, he then reminded me that it is important that I do what he says or he will have me fired.

This was an interesting set of interviews. I like the achievement orientation from the people doing the work. I will need to remember the power orientation exhibited by the people that claim authority. My goal will be to communicate status frequently to executive management so that they see achievements and keep the egos of these auxiliary managers in check. Hopefully I will spend more time with Joshua and less time with Dan.

25 January. I spent time on a phone conversation with Fred. Fred is the CTO for this customer. I described my approach to project management and told him about the history of some of my projects. When I talk with potential customers I take an unorthodox approach. I tell them about what I accomplished and I tell them about the opportunities that I thought we missed on some of those projects. I would rather they understand the limitations of project management than to get the impression that my projects always succeed. People who have the maturity to understand this like my honesty. People who are immature enough to be turned off by this approach self-select themselves out of my way.

Fred emphasized the importance of this project. In my opinion, he is focused on power and considers achievement important to ensure his access to power. Also, he seems to display affiliation. This is a good balance for an executive. It is a different balance from mine, but this fits his role very well. We should be able to work together.

26 January. I got a phone call and then an email from Harry, my recruiter, that this customer wants me to start right away. I called my boss in the consulting company I was currently working through. I told him that we need to wrap up the two projects I have there fairly quickly. We talked about the transition and he thought it might take three weeks but agreed that two weeks should be sufficient.

Oddly, he only authorized me to work three-hours to wrap up both of those projects with a commitment that he would get back to me soon. I would rather have worked a few more hours to ensure both of those projects were properly closed. But, that is the world of contracting. You get paid to do what you are authorized to do. And if the customer does not value a project closeout, then you do not do it. Years ago I would have done the closeout anyway, but I have come to accept the maxim that you give the customer what they want. I put in the three hours that were budgeted, sent a few emails and left a few messages.

12 February. Both of my current projects were formally closed today although I thought there were too many loose ends. I am still waiting for confirmation on the start date for this new project. Thus, I am entering my third week with no pay. That gives me time to focus on my studies and on this book. But sometime soon my bills are going to come due. I hope this new project gets started fairly soon.

14 February. I had lunch with Harry, my recruiter, and Jim, the account manager. It was a very pleasant experience. Of course they are both professionals in the people business, but I really feel they are genuine in their sense of compassion for others. They told me they want me to meet with the president of their division tomorrow.

15 February. I met with the president of the division of the contracting firm. His name is Boris and he told me about his prior experience as a CIO (power). He told me that he could have been one of the founders of this company (power) but he was busy at the time with something else. He emphasized the tool set his team has built. Personally, when my team builds something wonderful I like to show it off. I think my motivations are a vicarious sense of achievement and a desired to praise my team. Maybe my efforts to praise are a display of power but I think there is an affiliation motive as well. I feel like a proud parent showing off the latest refrigerator art just finished by my foster child. So we came into this conversation with different agendas. Boris seems locked on power, said little about his team and did not reveal any tendency towards affiliation. I will need to be careful when I work with him because we have such different perspectives.

I switched into power mode and dropped a few names of other people I already know, including one of the founders in this company. That put us onto the same wavelength. I mentioned some of the big name companies I have worked at. He topped that. I mentioned the odd use of power I had seen on a recent project. He topped that by telling me about his experience with the executive management team at one of their competitors. We connected. If I had stayed locked into my achievement orientation we would have missed this opportunity.

I then met with the product manager for this contracting company. Her name is Vivian and she and I connected quickly. She focused on her product and her desire to help the project managers working for this company - achievement and affiliation - two motivations that build relationships. I like the functionality offered in their tool and I said so. I look forward to working with her. Like Harry and Jim, she made me feel welcome.

Vivian then took me over to see Mark, one of the owners of this company. Mark and I chatted for a bit. I had worked for Mark about ten years ago and was pleasantly surprised to see his name on an email a couple days ago. We swapped a few emails yesterday and now we had a chance to reconnect. I told him I was impressed by all that I had seen. Just like before, he went out of his way to make me feel important. Naturally, just like before, I plan to return the favor so that I live up to the value he places on my work.

John, my new mentor, called a bit later in the day to verify that everything had gone well in my meeting with Boris. We talked a bit and I told him that I interpret his motivations to be achievement first, affiliation second with power a more distant third. He liked that explanation. I look forward to working with this team.

In summary, I have now met eleven people and still do not have a job. The key skill I have used throughout this endeavor has been my ability to work with people. Lots of people. All kinds of people. This is why I put so much emphasis on the human relationships aspects of project management. And look at the calendar. I first heard about this project on 8 January. It is already 15 February and I have not yet started. These down cycles are tough on a contractor. I did not make enough off those last two projects to save up anything for this drought. On the other hand, this project sounds really interesting. I hope it turns out to be as good as it sounds.

**The First Week**

20 February. I began work today. In my first meetings with Raj we alternated between Vroom's management styles of authoritarian and delegating.

Authoritarian is pretty typical for your first day in a new environment. He needs to decide what I can actually do. Delegating is a trusting vote of confidence. The only problem is that I do not feel like I have enough information yet to act on my own. My response to delegating is to switch into mentoring mode where the relationship is one of peers. My response to authoritarian is to switch into teaching mode. Yes, I know that Raj is the team lead and I am supposed to be a follower. But I am not going to follow authoritarian when it is not necessary and I cannot act on delegating when I do not have enough information. My compromise is to honor his choice of styles, but adopt a role that will allow us to grow out of that style. When he switches into authoritarian behavior I will switch into teaching mode. And when he switched into delegating behavior I will treat this like a mentoring engagement.

21 February. I met with Sam today to talk about some of the PMO templates. He was surprisingly helpful. Sam is the PMO staff person responsible for project compliance. When I interviewed with Sam he seemed a bit too focused on demonstrating his power. Now it seems more like he would be helpful if he were not so busy. I do not understand why he is so busy, but that is a mystery that I will try to unravel some other time.

I then chatted with Dan to solicit his thoughts on one document and he was very helpful. When I interviewed with Dan he tried to impress me with his power. Now his role has changed and he is trying to figure out what power he still has. It seems to me that both Sam and Dan have retained their focus on power, but both are open to affiliation and both seem concerned with achievement.

I then had lunch today with one of my friends from a previous project. As we talked I began to think about Carly Simon's tune "You're so Vain." I made a note to mention this in the introduction to this case study. By the way, I think I have finally solved the mystery about that tune. My guess is that she wrote this song about Eric Clapton. I will need to follow up on that later. But I am daydreaming. What caught me by surprise is the reaction of this friend to the parts of this book that he reviewed. While we waited for our check I explained to my friend that these are now my stories. His character is just an actor in my script. I had to trim details to make the story succinct. Also I sometimes merged multiple stories into one tale because, to me anyway, these stores are a continuation of my efforts to wrestle with a common theme. I then asked him to remember that I have a long history and maybe the particular story that he is thinking of or the character that he thinks I have portraying him might not be the story or character that I was thinking of. And finally I asked for his continued indulgence to use his name to represent the ideals of the role. It is by giving these roles a personality that I strive to give you, the reader, a way to connect. It was a good lunch. I need friends like this to help me with perspective.

22 February. We had a conference call so we could discuss the design of a new interface. The session was highly participative. I thought this was an excellent session and felt it made optimal use of a group of experts. Afterward I talked with Bruce, one of the key participants. I was surprised to discover that he felt this session was dysfunctional. I am baffled by his reaction and will need to listen for further input as to why he feels that way.

23 February. We had a meeting today with an important software vendor. We are very dependent upon the stability of their software and there was an incident a few weeks ago. They have identified the underlying problem and will have a partial resolution in the next release of their software. The stated purpose for this meeting was to get a preview of their upcoming releases and thus better understand how committed this vendor is to the stability of this product. The meeting gave me an interesting opportunity to watch the team.

Bruce led the meeting and the session had a bottom-up orientation. We focused on details and had a hard time getting out of the mud. Eventually it came to me that the purpose for this meeting was politics and not technology. The vendor came here to submit to a public flogging. I felt sorry for the vendor because they said over and over again that they understand the problems we have uncovered and each and every one is being addressed either with a high priority patch or a fix in the next release. They said over and over again that stability is their highest priority. I heard consistency and saw no signs of duplicity.

Eventually I saw an opportunity to probe on one point and I did. I think this was a moderate risk. I think I acted this way to get more achievement out of this meeting. But, maybe this was a high risk and I was actually trying to grab enough power to redirect this meeting. It is a risk for a "project manager" to presume technical knowledge when sitting in a meeting with a group of subject matter experts. Anyway I made my point; we redirected the meeting into a technical discussion that demonstrated the vendor's depth of knowledge and commitment to the product. I felt like I opened a door to show where this meeting could go.

Out of that conversation I gained a better understanding of Bruce. My assumption was that this team of subject matter experts was predominately driven by the achievement motive. But I see now that Bruce is much more focused on power than I thought. Thus a secondary purpose for this meeting was to impress our team with his power to publicly flog the vendor. And his dislike for the highly participative meeting we held yesterday now makes more sense. He disliked it because he did not control it. Joshua is very self-confident and is willing to turn loose of his power and listen to his team. Bruce does not have authority over the team, but maybe he thinks he should.

I need to keep watching and listening. I saw this before in another company where my friend Charles and I would conflict. We used to get into very convoluted conversations. I thought our boundaries were clear. I managed and he executed. But I love having participatory sessions and I prefer to share power. We were fine during those sessions. The conflict would start after we agreed on what to do. Charles had a tendency to go in his own direction. I would need to detect it and then correct it. I wonder if I will have the same conflict with Bruce.

Charles and I used to wrestle for control of the team. The awkward thing for me was that I often thought he was right. But the limiting factor in participative decision making is that it stops being participative if I overrule the team. As the manager it was my choice as to whether I chose an authoritarian, consultative, participative or delegating style. If I wanted to make the decision myself, then I would use the consultative style. If I chose to use a participative style then it is important for me to support the consensus. Charles did not agree. Maybe that is part of what is happening here. Maybe Bruce, like Charles, does not agree with some of the decisions.

Perhaps it is not just managers that resist participative management, but also their teams. Every manager has at least one shadow - someone that wants the authority of managerial power but is not given that opportunity. Perhaps Charles and maybe Bruce actually want to be in charge. Thus they resist the consensus and they resist the participative process because they feel it lacks controls. I will need to keep this in mind. I will watch these relationships going forward. I wonder if Joshua and Bruce have the same conflict that I had with Charles.

Anyway, at the end of the first week I have found the one-page project charter and the preliminary project budget. The project schedule and project status report have been turned over to me and I am trying to get them updated. There were no agendas or minutes from prior meetings so I have implemented agendas for the meetings I facilitate and I am publishing minutes for many of the meetings that I attend. The clock is ticking and I have very little time to figure out exactly what is going on with this project. I need to brief our CTO, Fred, with status and it looks to me like we are about one month behind schedule as of now. I am re-baselining the schedule and I am trying to convince people that if they have not been able to stay on schedule so far then their duration estimates are too optimistic. The problem is that they have a calendar that shows their release schedules and so far no one wants to admit they are not going to make those commitments.

This project has been running for about eight weeks now and it is scheduled to complete in four to six more weeks. I feel like it is a little late for me to make much difference. My hope now is that I can influence this team in such a way as to get closure on this project and then help them prepare for future projects.

**The Executive Briefing**

26 February. I am running into typical operational friction. I must upload my project status report to the PMO archive, but I do not have permissions to post documents to that web site. I must retrieve documents from the web site for a project that is intertwined with our project, but I do not have access to that web site. I must print out a hard copy of a report, but the printer is malfunctioning. These are just typical problems. They will pass.

27 February. I went through an updated project schedule with Joshua only to discover that there are additional deliverables that must be added to our schedule. Our presentation to the CTO, Fred, is just a couple days away and I am concerned about whether or not we will have something solid by then.

28 February. I found the project charter last week. Then I created a template for meeting agendas and meeting minutes. I am now publishing agendas for each meeting that I facilitate and minutes for most of the meetings that I attend. On Monday I finished an update to our project status report. Then I found the PMO template for an issues log and I entered all of the issues that I know about. Next I created a simple project organizational chart and I updated it based on feedback from Joshua. And finally I created a simple executive briefing document that lists the major project deliverables and issues in chronological order. The only problem I have left to solve before our briefing with Fred is the project schedule. That, however, is proving to be difficult. The issues I am encountering are fairly typical.

Since this is the first time anyone has done this project no one knows how long the tasks will take. The best guess on task duration often turns out to be wrong because of issues uncovered in the vendor's software. If the software works as expected, then perhaps the task will finish on time. But when the software behaves differently than was expected our staff is often forced to wait days or weeks for the vendor to evaluate the issue and either clarify the documentation or provide a work around.

When it comes right down to it, the priority is always production support. Thus someone may well intend to work on a new module only to find that they are pulled into troubleshooting production problems.

I am trying to work around these problems by introducing the concepts of buffers from Goldratt's critical chain methodology (2). I am not sure how well this will be accepted so I am gradually introducing it and will explain the concept once it proves successful.

I now understand the disconnect between the techniques used on this project and the methodology defined by the PMO. This project is being managed as an iterative development effort. What we show on this latest project schedule might be pretty accurate for the next three or four weeks. But today we once again revamped the list of deliverables for the subsequent months. Scope is very fluid. If another project team pushes back their work might be re-sequenced later in the schedule to give them more time to prepare. If some customer complains loudly enough then their work will be pulled forward in the schedule at the expense of the work for other customers. None of these changes go through a change control process and no one, besides me, sees that as a problem.

I talked with Joshua and he would prefer to just ignore the PMO methodology. He is too busy getting things done to waste time on needless paperwork. So I explained this to him in terms of risk management. The purpose for a PMO methodology is to generate repeatability and consistency. Consistent documentation then allows the PMO to extract the data they need to assess risks. Thus, the purpose for a PMO methodology is ultimately a technique for assessing and managing risk. Joshua is managing risk via a different technique. He is using iterative development, which manages risk by only committing to small steps. Thus the degree of uncertainty is managed. Each block of a couple weeks of development time builds upon the certainties of what is known so far. When an obstacle is encountered, such as an issue with the vendor's software, then subsequent work is rescheduled. Work that has little risk is pulled forward and work that is impacted by this identified risk - an issue - is delayed. Thus the team is always producing something. We will push updates into production every other week for the next several months. But what it is that will be going into production on any given Friday is anyone's guess. Note that this also means we are going to miss the end date target for this project by several hundred percent. Instead of being a one-hundred day project, it looks like this is a going to be a four or maybe five-hundred day project. Quite a discrepancy!

I am firmly convinced that iterative development is the most effective way to deal with such a magnitude of uncertainties. I am firmly convinced that if we followed the waterfall model outlined in the PMO methodology then we would have far less throughput. But my question to Joshua is whether or not this is going to be tolerated by Fred or by the PMO. Joshua feels that we should just keep on going like we are and not worry about this. Well that is a good answer for him, but I am the person responsible for compliance. So this is not necessarily a satisfactory answer for me.

I am going to need to watch Fred carefully when we meet and see if I can read his preferences. Unless I detect a serious streak of by-the-book tendencies, I am going to do everything I can to support the use of iterative development. I can see that this reflects on my bias towards achievement. We can get the work done if we stay with the iterative approach, but I am taking a risk that I could get fired. On the other hand, I can also get fired if we follow the waterfall methodology and the project fails. My bias is that I would rather be fired for achieving than to be fired with nothing to show for it.

Another way to look at this is to think about this situation from the level of participation that is required. Joshua's approach trusts each of the developers to find their way through this jungle of complexity and then tell others how they succeeded. This only works when the staff has a high level of skill. The safer approach is to define a repeatable process that requires little skill. That approach then aligns with an authoritative management style. I find authoritative styles abrasive unless I am truly learning a new subject. And even then I want to get away from authoritative to consultative or participative as quickly as I can. My guess is that these highly skilled subject matter experts feel the same way.

On my way home I called my mother. It is her birthday. We talked for quite a while. I wish I could go see her, but everyone is in such a hurry to get this project under control that now is not a good time to take off from work.

1 March. Joshua, Raj and I met with Fred and Tommy to brief them on our project status. I had not met Tommy before and I am not sure how he fits into this structure. I do not remember being able to finish more than a few sentences without either Fred or Tommy giving me advice. I found it frustrating as neither seemed to have the patience to listen. I would start to explain one deliverable only to be told that there were other deliverables that were related to this one. Either Joshua or I would then explain that we already have those other deliverables accounted for on the next line down in the list of deliverables only to be interrupted again. It seems that the briefing was not for us to give Fred and Tommy status, but for Fred and Tommy to give us status. This was an odd experience. In my opinion, Fred is low in openness, high in conscientiousness, high in extraversion and high in agreeableness. In my opinion Tommy is high in openness, neutral in conscientiousness, neutral in extraversion and high in agreeableness. Fred may have brought Tommy into this project because Tommy's openness compensates for Fred's weak area. Both acted in an authoritarian manner and I saw no tendency for either to act in a more participative manner. But somehow, out of it all, we got agreement on the sequence of deliverables. If we stick to this list, in this sequence, then I can finally estimate the project completion.

2 March. We changed the sequence of the deliverables again. Joshua is not worried about what impact this will have on the information we gave Fred and Tommy yesterday. Also, Joshua is now confident that neither Fred nor Tommy is concerned about our use of an iterative approach even though we are clearly out of alignment with the PMO methodology. This is going to be a very interesting and highly unpredictable project.

By the way, here's my assessment of Joshua. High on openness, high on conscientiousness, neutral on extraversion, high on agreeableness and low on neuroticism. He prefers a participative decision process but has no problem acting in any of the four styles. His concern is for the organization. I hear indications of a broad span of concern, though only as broad as this one company. But clearly he is concerned with the company and not just with his team or with his own career. He recognizes power and knows how to use it but he really prefers to focus on achievement. He is concerned about his team and expresses affiliation, but I think he believes it is important to achieve first and then use power second, relegating affiliation to third.

5 March. Our deployment of code this weekend seemed successful until Monday morning. Our software stopped working this morning due to data integrity issues. The team worked from 7:30am until 6:30pm to resolve the problem. The key question that Joshua asked was why this bug had not been caught in testing. My response, though unstated, is that this schedule is so aggressive that there is too little time to do proper testing. But that was not the time to delve into those issues as Joshua was far too distracted by this disruption to think strategically.

I represented the team in meetings while they worked on the technical issues. The project managers for projects that are dependent on our project want my project to go faster. This is a symptom of the root cause. The business wants results faster and is not interested in hearing about the need to spend more time on testing.

I went back to my desk and saw a new email from my mentor, John, asking to see my major project deliverables like the project charter, scope statement and project plan. I sent him back my project schedule, issues log and meeting minutes because that is what we have. I also explained that this PMO has other templates, but we are ignoring them because we are doing iterative development.

When I first heard about this project I thought I would be creating all the standard artifacts that go with the waterfall methodology. Thus I picked this project to illustrate what project management should be like. It turned out, however, that this project is actually an excellent illustration of what project management really is. My guess is that only one or two software development project managers out of ten follow the traditional process of defining scope, doing a design and getting everything signed off before starting development. And I am not at all sure that those who diligently create all those documents get better results. Today's crisis illustrates the limitations of trying to plan. There are so many unknowns that I am not sure more testing would have detected these bugs.

And that is why I chose to continue using this project for my case study. It does not illustrate the ideals of project management. But it illustrates the reality of managing a project in the chaotic world of software development.

When things finally calmed down I met with Joshua to outline my recommendation that we delay some of this work to allow more time for testing. I reminded him that outages like this damage the reputation of his team. We also brainstormed about how to set up a more realistic test environment.

6 March. We agreed to delay the next set of deployments for a couple weeks waiting for the software vendor to resolve this latest problem.

7 March. Joshua, Raj and I met with Fred and Tommy for a weekly briefing. Fred was in coaching mode today trying to help adjust my slide presentation to the style he wants for our steering committee meeting next week. This was a good meeting and his style seemed to work well. Fred made lots of eye contact and seemed very persuasive.

I did note, however, that Fred's use of power seems directed towards an us-them developmental level. I cannot yet assess his world-view, but his words describe the actions we need to take to get the project steering committee to give us what we want in terms of budget and authority. I realize his primary motivation is power as described by a large span-of-control, but I am finding it difficult to accurately read his span-of-caring. My thoughts at this time are that Tommy is operating at stage 3 with a focus on "us". Fred seems to be operating in stage 4 with the ability to shift from one team to another while always staying in the role expected by that team. I think Joshua displays congruency across roles and this leads me to think he is acting in stage 5.

8 March. I noted today that the employees are exhibiting power by being too busy. This means they cannot take on new assignments because they are too busy. And it means they must pick and choose among the work already assigned to them because they are too busy. This is a cultural crutch. The culture tolerates overloading people and the culture tolerates tasks not getting done. Changing either of these behaviors will force a reaction to either restore the balance or to change the other behavior. It is interesting that Joshua portrays me as wanting to slow things down. He even brought this up in our meeting with Fred yesterday. My thoughts now are coalescing around the view that I am being used as the excuse for making a change. That is fine, because this is a change that I endorse and being a "change agent" is one of the duties for a good project manager.

9 March. I spent time today with each member of the project team asking for status on their work. One person was a bit behind on one task. He had requested ten days for this work and it is now past due. I asked how far along he was and he said that he had not yet started. A few hours later he sent me his deliverable. It had taken him about two hours to do this work, not ten days. This is the type of time hoarding that Goldratt describes in his book on critical chain (3). Because their environments are filled with uncertainty, every employee pads their time estimates. When this person estimated ten-days, he did not mean that he would work on this task for ten days. What he meant is that somewhere during a span of ten days he hoped to find the two hours it would take to do this work. Over time I will work to transition this team away from hoarding to buffering, but first I need to gain their confidence. I need them to trust me enough to give me honest estimates and then trust that there will be a project buffer to protect them from repercussions when some crises comes along and takes priority over our project.

Tim, for example, has avoided my continued requests for status. I suspect he is not putting the required amount of time into this project. I saw a similar pattern in emails this week. He was given an assignment to define the requirements for a hardware upgrade. He quickly produced an initial estimate that was incomplete. I requested more information and my email was ignored. Raj then requested the same information. Two days later I still do not see any results. And this was a crisis when the assignment was first given to this developer. My question is whether this developer is truly overwhelmed with other work or is he just using the "busy-ness" of this environment as an excuse?

As a project manager I find it inconvenient when people tell me work will take ten days when it actually only requires a few hours. But I know that I can either squeeze the padding out of that estimate or I can use it as a buffer to help keep the project on schedule. When, however, someone tells me that something will get done and then just avoids me I get irritated. I shift from my agreeable mode to my not so agreeable mode. In a system this is risky. If my frustration triggers a feedback loop then the situation will get out of control. If, however, I just ignore the situation, then I am contributing to it. The project management term is "confronting". Like a psychologist, I must say what I see from my perspective or else the issue will never be discussed. Tim will be on my watch list next week. We need to reach a mutual understanding that he will provide status. This is not about power. Without his status I cannot assess the health of this project. And without an accurate assessment I cannot appeal to the project sponsors for the additional time we need. And without commitment from the project sponsors this project will not survive. Thus I consider my motivation to pressure Tim as altruistic. I think I am concerned about this team (affiliation) and about this project (achievement). Power sneaks into my agenda because I am irritated.

12 March. Our project team met with Fred so he could establish a personal relationship with the team. He explained that he values this team and he talked about seven points.

He says we need to think in terms of five to ten year goals and not focus so much on one week or month at a time. Now, in terms of developmental psychology, that is significant. People in the higher stages of development tend to focus on longer spans of time and five to ten years is a very long span of time for this industry.

He talked about management not meaning control, but I was not sure where he was going with this thread.

A bit later in the conversation he talked about the relationship between responsibility and control. He illustrated this by noting that if a problem is going to get escalated to him then he has responsibility for it. And if he has responsibility then he will assume control regardless of the number of layers of management he needs to work through to get the right results. Personally I have somewhat the same issue as a project manager. If I am the one responsible for the success or failure of the project then I am going to dig as deep as I have to in order to find the person who is jeopardizing the success of my project. The difference is that Fred illustrated his point by explaining some of the organizational changes he implemented to make this work for him. As a project manager I am pretty much stuck with whatever organization is given to me. It seems to me that Fred uses power to arrange structures so he can reach his goals while I need to use my achievement motivation to focus people on our mutual goals.

We talked about the necessity for the project manager to frequently disseminate good news about the project in order to keep the supporters enthusiastic and to keep the detractors at bay.

Fred emphasized the need for vision but he went all around it without using that word or any of the synonyms that I was expecting.

He also emphasized the need to prioritize our efforts, focus on what is important and drop what can be dropped. In his view, we will always be overwhelmed with more assignments than can be completed. Our job is to do what is important. It is the job of the managers and project managers to listen to the business and ensure that our priorities align with their needs.

The seventh point was demonstrated rather than expressed. Fred took several hours out of his very busy schedule to meet with this team. It was an existential experience. He focused on this team and was present throughout the session. He kept his PDA (personal digital assistant - a combination cell phone and email terminal) in silent mode and did not glance at it even once. Joshua looked at his PDA a couple times because he was getting a swarm of emails. Fred probably got more emails than Joshua but Fred focused exclusively on this team for the duration of this meeting. That is an expression of the value he placed on the meeting. Altogether this was an impressive meeting.

We broke from that meeting and Joshua, Raj and I went to another conference room for another meeting with Fred. We worked through another iteration of the handouts we will use for the Steering Committee briefing on Wednesday. In my opinion, Fred shifted today from coaching over to participating and delegating. Perhaps he just needed to see what I could do with the first couple updates. Now he seems to trust me and seems comfortable delegating in small doses.

After that meeting I looped back around to talk to Alfonso. He is the project manager for a project that is supposed to build upon the technology my project is creating. I attended his weekly meeting this morning and he is concerned about some of the technical aspects of an area that overlaps between our projects. He seems to be a good project manager but he has no technical expertise in this area. Thus, he is rather clueless as to which options are valid and which are dead-ends. I agree with the concept espoused by the Project Management Institute (PMI) that any good project manager can learn to manage any project. I have traversed from construction to software development to data center operations and over to business process re-engineering so I know the concept is valid. And yet, in each of those transitions I was initially dependent on the subject matter experts (SMEs). SMEs are often opinionated and often they can be quite obstinate. If the project manager does not have the technical background to know who is right then the project manager is forced to rely upon people skills to read the situation. A good project manager will get this right more often than not which only goes to confirm the PMI premise that project management encompasses a lot more than technical know-how.

Thus a good project manager is always using two senses - one focused on the technical and one on the people. When you shift industries your technical senses needs to be retrained. And if you shift industries and do a poor job of reading people, then you are operating at a significant disadvantage.

13 March. While both Joshua and Fred seem very happy with my work, I still feel a sense of impending doom. John, my mentor, wants to meet with me next week and still feels like the PMO tools that his contracting company has will help this customer. If anything this customer already has too many PMO tools. He really seems like a nice guy, but so far I have not received any "mentoring". So this seems like it is just another burden.

At the same time that I am saddled with the burden of this project and with the expectations set by my consulting company I also feel like I am walking a tight-rope over a pit filled with hungry alligators. We are not making use of the PMO tools. Joshua is comfortable with that choice because he is focused on doing the work required to build the deliverables. But the PMO is justified in asking me to fill out a lot of paperwork because this is the company's response to the Sarbanes-Oxley legislation. I will be in a lot of trouble with Joshua if I fill out the PMO paperwork. But, when the PMO finally catches up with me it will be my job and my reputation that are at risk.

Given my choice I would rather start filling out more of this paperwork. I see no reason to slowdown this project for that paperwork, but there ought to be a bit of free time here and there where I could work on it. The problem is that I am not even sure which documents need to be filled in. I have seen PMO templates in numerous companies and I have never before seen a company with such a vast collection of forms.

I could feel my frustration rising so I went to meet with Joshua. He really wants me to ignore the PMO guidelines on the basis that we 1) are not impacting the financial bottom line and are thus exempt from the Sarbanes-Oxley requirements, 2) have no business-users and thus cannot even begin to fill in most of the PMO templates and 3) we are using iterative development instead of the waterfall method. However, he also said that if the PMO or the Steering Committee raises an issue then I will need to backfill the required documents. To me, the advantage of delaying this paperwork is that further delays might give me enough time to get closure on scope and schedule. Today there are so many unknowns that it is just not feasible to fill out all of those forms.

14 March. We held our first meeting with the project Steering Committee today. It was a highly collaborative effort. Fred initiated the meeting. Then I walked the committee through the presentation. There were lots of questions. I handled some. Joshua elaborated as appropriate. And Fred assisted when required. This was a great meeting. The committee did a little bit of power positioning by occasionally asking questions more to show their knowledge than to get information. But that was rare. I am impressed with the commitment that I see in this company. These executives are definitely focused on improving the organization. I have been in meetings in other companies where the executives spent time sabotaging each other's projects. Those executives were focused on self or team. The executives in this company are focused on the organization. I am impressed.

15 March. Sam feels he is multitasking too much and thus finds it difficult to lead the PMO. This is a systems problem. Pressure comes down from executive management to get results. The PMO then tightens up the requirements on the project managers. And the project managers react by backing away from what seems like an excessive set of requirements.

This creates an amplifying feedback loop driving the PMO to get even more strident and the project managers to become even more resistant. I have observed two outcomes from this in other companies. The PMO might win and all the project managers will become complacent drones. Or the PMO might self-destruct and the concept of a PMO will be devalued. I wonder which will happen here? I wish I could help, but Sam seems resistant to discussion on this topic.

What would I do different? We need to break the amplification loop. Pressure produces regulations which increase resistance. Either the PMO needs to just absorb the pressure or the PMO needs to help executive management see that this cycle is self-destructive. Absorbing the stress is, to me, a good managerial concept. Middle managers need to protect their people from misguided directives. The PMO is in the middle, so the PMO should educate executive management regarding the correct balance of pressure and patience. However, this is a loop. So, from the point of view of the PMO their position is unalterable. They cannot confront management and they cannot convince the project managers.

However, since this is a loop, it makes just as much sense to go to the project managers and make the change there. But the problem there is exactly the same. Just like the PMO is afraid to say no to executive management, the project managers are afraid to say no to the PMO. Even this benevolent PMO makes is clear that they will terminate anyone that does not follow their guidelines. Thus the loop perpetuates until it destructs.

Since my role in this company is that of a project manager, then that is where I will need to make the change. I cannot expect the PMO to change. I cannot expect executive management to change. I am the only one that I have any hope of changing.

And thus we come back to the agreement that Joshua and I have made. We will deliver results and use those results as a tool to help executive management see the value in focusing on results rather than on paperwork. Of course this is a gamble. I am risking my reputation as a project manager on our ability to deliver results. The safer course is to just comply with the PMO. The problem with a focus on achievement, however, is that I find the safer route too boring. I need the thrill of accomplishing and I love the risk of doing it in an unconventional way. Skinner would probably relish my acceptance of the fact that I am wired in such a way that I can do no other. I will support Joshua in doing what he thinks is right. And if we fail, then they can replace me with a drone that does what he or she is told. Thus my path is set. Now I need to get results.

And that brings the circle round to the next community in that diagram - the project team. Ultimately it is the project team that decides whether or not to deliver results. Somehow I need to help this project team learn how to use project management to get results. And I need to do that without triggering negative feedback.

**One Step Forward, Two Steps Back**

16 March. I briefed Joshua and Raj on the latest schedule. We added another two weeks onto the estimated completion date this week through a combination of small scope creeps. Like Frederick Brook's says "How does a project get to be a year late? One day at a time" (4). Projects do not leap from on-schedule to one-year late. Rather like garden snails, they creep down that path at a pace that is barely discernible. And yet, when it is your lettuce patch they are heading for it is amazing just how devastatingly effective those snails can be.

Joshua says he wants to stop the schedule slippage. That is good. But it is not the symptom that needs to be fixed. What needs to be corrected is the process that produces that result. The problem is that "we" agree to scope changes without assessing their impact. Now that I have Joshua's attention I will try estimating the impact from changes so that he can see the likely results before he agrees to the change.

We also need to remember that the project team is part of a system. At the same time that Joshua is learning to use a project schedule, his team is reacting to that change. Janice, for example, called me in a panic. She believes it is impossible to do all of the work that has been assigned to her in the amount of time allotted. I explained to her that this is exactly the type of feedback I need so that we can fix the schedule. I explained that it is better to have a schedule that says we are going to need two extra months than to just be surprised when we finish two months late. We adjusted the duration estimates on several of her tasks and I reminded her that all I want is her honest feedback.

I then had to escalate to Joshua and Raj regarding Tim. This is the third week he has avoided me when I ask for a status update. My guess is that he has not been able to complete any of the assignments given to him in those three weeks and so he is avoiding me. Shortly after I escalated I heard from him. And exactly as predicted, he had been too overwhelmed with production issues to spend time on development. I talked with him about how important it is for me to have that information. I then reassigned some of his tasks to other developers and we reached a compromise on his remaining tasks.

The net effect this week is that rather than being one week closer to project completion we are now two weeks further away. Not only did very little of the scheduled work get completed but so many additional tasks were added onto this project that our total duration has expanded. From the point of view of a project manager, this is bad. But, if I focus on the learning aspects of this week then we actually made progress.

The tradition has been to hide schedule slippages. Then people either work excessive overtime to make up the difference or they push low quality code into production. Either choice means that there are too many defects which then creates a crisis to fix the defects which detracts from the work on the current update and thus the cycle perpetuates. So while I am trying to change the amplifying feedback loop that surrounds the PMO I also need to intervene within this development team. I can help this team learn to use a project schedule as a tool for testing and assessing reality. I can help this team learn to communicate realistic expectations. While this is not traditional project management, this is vital preparation for the time when we will actually be able to do projects.

19 March. I received an email from Fred that he is holding "the Project Manager" responsible for the fact that a disk storage project did not buy enough disk space for our project. First, I was not even here three months ago when that planning took place. And second, I am not the project manager for the disk storage project. Joshua replied back to try to clarify this, but I will need to follow up on this later.

It also sounds like the deployment this weekend went badly. Alfonso is sending flaming emails to Fred. We cannot see the connection between the changes we made and the symptoms Alfonso's team is reporting. Even so, I verified that my team is investigating before I left for Alfonso's weekly project meeting. No one showed up. I found Alfonso and he was in the process of canceling the meeting. He has decided he no longer needs our project because he hears there is another way he can get the data he wants. I explained that the pathway he has chosen is going to take years to complete while our project will be finished in under a year. But he is frustrated with the unpredictably of our schedule. I think he is also tired of the conflictual relationship he has with Joshua. Most importantly, I think Alfonso would rather blame our project than fix his own.

I followed up with Joshua and he doubts that Alfonso has the authority to make that decision. I also talked with Joshua about the symptom where project managers blame each other for their own project limitations. Personally I am very uncomfortable with how my project is going. And personally I am worried about emails like the one from Fred this morning searching for someone to hold accountable. The problem is the system. These people do not know how to be a project team. But even though I am frustrated I am trying to solve these problems rather than blame other project managers.

After that I checked in with the project team. They are still trying to figure out what went wrong this weekend. The users complain that "Things are all messed up." We are trying to get specifics from them. For example, if you take your car to a mechanic and say "it's broken" that mechanic is going to need more information. I setup a conference call to get everyone together but the users did not show up. In the meantime Alfonso keeps sending flaming emails to Fred. So I walked over to his cube and asked him to contribute to the solution by getting someone to show up on this conference call. He told me that this is not his problem and shortly after I left his cube he fired off another email to Fred.

Alfonso is so focused on power that he thinks he can increase his power with Fred by amplifying the problem we are now having. When it comes down to it, he is not interested in solving the problem. He is not looking out for anyone other than himself.

Eventually I got some users onto the call and we confirmed that the problem they are experiencing has nothing to do with our changes. Now that we know what the problem is our technical people are working on it.

And from that crisis we transitioned directly over to another crisis. I setup a conference call today to try to get resolution on the problem that Fred described in his email this morning. That project manager said he could not help us and suggested that I talk to his users directly. What is going on today? I feel like I am in a really bad dream. I keep going to project managers and getting nothing but grief in return. Rather like Alfonso, this project manager seems afraid that he is going to get blamed for something and wants to take cover by quickly blaming me.

So once again I had to take action and bypass this guy. I setup a conference call and then asked Raj to hold the line open while I went hunting. I found some of the key users and convinced then to join the call. And, out of that call I we got a resolution on this one problem. While getting closure on one problem out of three is better than zero out of three, it still means I will start out further behind tomorrow than I was today.

20 March. I put together a root cause analysis for the problem we experienced over the weekend. Then I persuaded Joshua to let me distribute it. The users of our system are internal "IT" people. I am now sending them notification emails before service disruptions on the development and staging systems. I am sending them a monthly newsletter. And now I will begin sending them root cause analysis write ups regarding disruptions to the development and staging systems. We already use the corporate Change Control Board (CCB) for changes to the production environment. Next I will begin pushing our outsourced service provider to give us a root cause analysis for production service disruptions. I guess if I cannot make progress on my project then I might as well do some ITIL cleanup. A few more changes like this and we could end up with repeatable processes.

21 March. I caught myself slipping from proactive into reactive mode this morning. My day is nearly filled with back-to-back meetings. The past couple days have been filled with struggles and squabbles. This morning I had a few minutes of free time before my first meeting and I had to stop and think about what to do next. It was as if I was waiting for a phone call or flaming email to wake me up. It took me a moment to realize I was waiting for something to react to rather than focusing on being proactive. This is a dangerous tendency. I need to be careful not to let this happen again.

Yesterday was a rough day. I kept butting heads with Alfonso. I thought today would be better, but I had a one-on-one meeting with Fred this morning and found myself back in turmoil again - not with Fred, but with what Fred said. Fred took the time today to talk about his vision for the next phase of our project. His explanation confirmed the rumors I had heard from Alfonso. This vision seems flawed somewhere, somehow, but I cannot put my finger on it. Yesterday Joshua told me that Alfonso did not have the authority to make changes to our project. That is all well and good, but I know that Fred has the authority to do just about anything he wants to our project.

So I went to Joshua to get his input. As I describe Fred's vision for our project Joshua pulled up a diagram out of his emails from Alfonso. This is serious. Fred is backing the approach that Alfonso is talking about. And yet, there is something more to this. I remember Fred specifically telling me that some of what is going on is just a thinking process. And I remember him telling me that Alfonso is venturing too far. All of this is confusing. My simple little project is just about more than I can handle because I still cannot get a definition of scope or time. Are we delivering eight subsystems or five? Are we supposed to finish in three more weeks or ten more months? Is Fred going to shut us down and shift my team over to another project based on another vision? And where does Alfonso fit into all of this?

Joshua has staked out his territory. He is going to finish this project or they can fire him for trying. I got into a conflictual discussion with him. I tried to emphasize the authority that Fred has to set direction. I told him about some of the mega-sized projects I have seen in the past and how those projects destroy everyone that opposes them. Out of this I found that my relationship with Joshua is now strained. But I was tenacious enough to keep squabbling until he agreed to meet with Alfonso to try to fix the inaccurate graphics that Alfonso is distributing.

Later that afternoon Joshua and I met with Alfonso. When confronted by the two of us Alfonso melted. He agreed to transfer responsibility for the architectural diagrams to me and to work with us to make this diagram fit Joshua's view while preserving Fred's vision. Altogether Joshua and I got the results we wanted and it was all fairly smooth. But then Joshua had to push Alfonso over the edge. Joshua made it clear that he wants nothing to do with this vision. And that set off Alfonso which will likely result in yet more emails to Fred. He should have just kept quiet and celebrated a win-win agreement.

A short time later Joshua, Fred and I were in a meeting together. When that meeting ended I asked both of them to stay for a couple minutes. Joshua refused and left. I then explained to Fred that I do not see any way to put resources into the work required to implement his vision unless something is cut from the current project scope. We discussed the situation and he noted that I am asking the right questions - a mentoring response. He gave me no direction, but he stressed that I need to find the answer. So at this point my relationship with Fred is solid and my relationship with Joshua is shaky. My trust in Joshua's focus on the company is less assured and my view of Fred as an authoritarian manager has been dramatically overturned. I also see now that Fred is much more open than I had thought, while Joshua is becoming progressively more closed. With this shift in situations, their behaviors and the way we define our relationships has changed.

I walked back to his office with Fred to ensure I understood which objective I am to tackle and then I went hunting for Joshua. I tracked down Joshua and the tone of our conversation was even more conflictual. He told me that I can put anything I want on a project schedule, but he is going to do what he wants with his resources. I asked him to meet with me and Fred to resolve this. He says he will meet with Fred and then tell me what happens. Two difficult days in a row. I can barely wait for tomorrow.

22 March. The scheduled maintenance last night went badly and the development system is down this morning. Once again I am pulled away from project management to work on an incident. I spent a lot of time today on conference calls monitoring the situation and prodding people along. During that time I reworked our project schedule to drop activities that do not fit Fred's vision and to start key activities sooner. This schedule is probably the least defined schedule I have ever worked on. And unless I can persuade Joshua to go along with my approach then the schedule will be quite meaningless. I need to focus on coaching and mentoring. Perhaps by alternating between those two styles I can draw Joshua back into participation. Participation is the only style that will get us where we need to go. He is a brilliant architect. He is the person that needs to take this vision and turn it into a design. We just need to convince him that it is in his best interest to go along with Fred and either make this vision work, or show Fred a better alternative.

23 March. I had planned to meet a friend for lunch today, but these system problems are still plaguing us. I cannot call her now so I sent her an email with a promise to call later. I am tied to this telephone for hours on end listening to the discussion as technicians join the call, discuss strategies and then drop off to go try something to fix this system. We have developers in multiple time zones in the USA and in two countries in Asia. All of them are sitting around right now unable to do their work because they need our system and our software to connect them to our database. Alfonso has been surprisingly quiet. He lobbed a couple emails over to Fred and Fred promptly bounced them to me for a response. I wonder if Alfonso will tire of this game before Fred finally gets irritated.

I can make very little progress on my project. I am tied up on this conference call. I need to keep sending status updates to the users. And I am documenting the events as they occur to create a time line that will go into the post mortem. I escaped my cube for a few minutes to check on my project team. They have all been sucked into this crisis. Joshua and I finally escalated above the heads of the system administrators and got Fred's attention. Then orders came down to the system administrators to either get this system fixed or move us to another system. But all of this is dragging on and it is getting late.

While sitting at home waiting for the next conference call I had a little time to work on this case study. Like I said earlier, this story and all of my stories are loosely based on real situations. It is true that I am sitting at home typing away while waiting for our next conference call. But other parts of this case study are fictionalized. For example, there are just too many characters running around in this story. So some of the names that I am using actually represent the behaviors of a group of people. Janice, for example, represents several people who react similarly. Thus the character Janice is the fictional spokesperson for a small group that needs a champion. Other names used in this book are tributes to dear friends who I admire. But even when I give a character the name of a friend, it does not mean that my friend behaved like the character in these stories. It just means that the types of behaviors my character portrays are based upon the types of behaviors my friend has displayed in certain situations.

And while I am pondering where I am going with this case study, I should take a few minutes to reassess what my goals are. After all, if this was a project, then I should have a defined set of deliverables and I should focus on finishing those deliverables.

Like I stated earlier, I searched for a project that would allow me to demonstrate project management techniques in a real life setting. My intention was to show how a project manager could integrate vision, governance, project management and metrics and have a positive impact on operations. I had four projects to choose from: a business re-engineering project, a Six Sigma project, an operational project and a software development project. I picked the software development project because it seemed to have a clear focus, a high probability of success and it seemed to align well with standard project management methodologies. As I look at this project now I see that it is not at all what I chose it for, but it is a better fit than anything I expected.

I thought the vision for this project was well defined. It is not. It is still being hotly debated. And thus, this project gives me an opportunity to describe vision not as a static graphic being dropped from on high, but as a set of diagrams that I am now responsible for creating. Whether or not that plays out as described is yet to be seen. Alfonso never did hand off his diagrams to me and never did cooperate with Joshua and me in trying to correct his diagrams. Instead, Joshua told me to just go do it and give him something that he can use to show Fred what is achievable. It will be interesting to see what happens. Both Fred and Alfonso are off-site next week for meetings. I wonder if Joshua will be able to convince them to see things his way. I wonder what part I will have in that action.

I thought governance for this project was simple and well defined. Instead I find it confused and I get little support from Sam. I also have a directive from Joshua to avoid the whole governance snake-pit. That is not what governance should be. Governance should be light enough to track status but not so heavy as to impede progress.

I thought I would churn out a bunch of typical project management deliverables, but we are avoiding the PMO templates. Fred surprised me this week when he told me to stop using one of the PMO templates and use his template instead. I thought we would be meeting with users and defining project scope and then building a nice PMI project plan. Instead the requirements are delivered in emails that are interpreted and sequenced in Joshua's head. This is not at all like the traditional software development projects I have worked on. And yet, this is just like the majority of the software development efforts that are currently underway throughout the world.

And thus, as the day ends and "tomorrow" begins I began to realize the value of this case study and of this book. This is not a description of the ideal. This is a snapshot of today. And thus I need to refine my goals. Yes, I want this case study to resonate with people who are in this industry today and I hope they can learn from it. Yes, I want this case study to be a vicarious learning aid for those entering into this industry. And now there is a third goal, I want this case study to be a time capsule for the generations that follow. I want this case study to accurately describe life like it is today in the wild frontiers of data processing.

Well, my alarm is ringing, so I need to get back onto this conference call. The last I heard the hardware technicians had replaced one of the main boards in our system. Perhaps it is finally ready for us to start reloading our software. If not, then we will spend more hours on conference calls and someone somewhere will go track down more people in far off places where it is still daylight. One of them, somewhere out there will solve this problem. And the rest of us can do little else until then.

24 March. We were on this conference call for a few hours starting just before midnight. It was interesting listening to the change in personality that came with the time of day and situational pressures. Joshua switched his focus from organizational priorities to survival mode. The problems with one of our systems has drug on now for a couple days and Alfonso is getting a lot of mileage out of our misery. Tonight Joshua committed our project funds to cover the costs for a significant hardware upgrade. I am not sure how I will balance this or if he is even authorized to make that commitment. I think his approach is that he would rather be fired for doing the right thing than to be fired for not acting.

Fortunately those actions seem to have worked out. We borrowed the hardware from another project and the move to this other system seems likely to resolve the problem. We concluded the call by congratulating each other on the team work it took to get through this crisis. Now we just need to get clarification on the price. Joshua said the system should not cost more than $80,000. We can probably pull $80,000 out of the project budget and still survive. But one of the technicians told me he thinks the price is going to be closer to $150,000 and could be $200,000. That will leave us really short because we are already spending more on labor than was originally budgeted. What amazed me is that all of these decisions were made with so little planning or process.

25 March. I went for a walk this evening to organize my thoughts for next week. As I was walking along a nearby stream I saw two tortoises swimming there. I have never seen tortoises there before. This was a nice reminder that we get so focused on our daily activities that we fail to see what is right in front of us.

26 March. I went into the office today expecting to get the team refocused on our project. Instead I found that the vendor had decided not to move us to the new hardware after all. Now we have an expensive piece of equipment sitting there and my team is crippled because this vendor insists on making the old system work. I talked with Joshua, but the contract we have with this vendor is clear. They are responsible for providing systems. It is up to them as to which system they pick. So even though this development team cannot develop because our old hardware is still not ready for us nonetheless we are going to be billed for an expensive piece of new hardware that we cannot use, Joshua says there is nothing we can do about it. Personally, I am ready to go over Joshua's head and escalate to Fred, but we have orders not to disturb Fred this week. So we creep along hour by hour as promised deadline after promised deadline comes and goes and this hardware is still not functional. The best I can tell, Joshua is just trying to build a case that he can take to Fred next week to demonstrate the failings in this vendor contract. I am only seeing one battle. Joshua has been fighting a war with this vendor for a long time.

On the other hand, I reached agreement today with Joshua regarding scope and schedule. We will drop the scope items that were not in the original project charter. And we will go with my latest revision to the project schedule. If we stay with this scope and if we stick with this schedule then we will finish this project within this fiscal year. And that is important since project budgets get terminated at the end of each fiscal year. Maybe, just maybe we finally have a handle on scope and time. My next concern is to reach agreement on cost.

Unfortunately there was yet another problem with the production system today. I did not get pulled into this one, but Joshua was tied up most of the day. I am seeing a consistent pattern. When there is a crisis Joshua turns to an authoritarian management style and responds negatively to suggestions. When things are going well he switches back to a participative style. It is as if his "openness" trait shifts from somewhat closed to somewhat open. I am glad I found that window this morning when he was in an open mode so we could agree on scope and schedule.

Now the books on traits say that traits are fixed. A person who is open should always be open. Perhaps, however, Joshua's underlying personality is closed and he has simply learned to act like he is open in order to get the most from his team. I see the same situational behavior in myself. We had a design meeting today and neither Joshua nor Raj could participate. So I started the meeting. We wandered all around the topic. Bruce was there and he seems to have a good sense of closure so I redirected the conversation to him a couple times. But even he could not get closure. So I switched from open mode to closed mode and funneled this conversation down to an agreement on exactly what is to be accomplished by Friday. The situation needed someone to fill that role. Even though this is not my personal style the situation warranted me acting out of my normal style. I took a participatory discussion and I turned it into a consultative session. I went from being the observer to being the facilitator to being the decision maker. And everyone was quite comfortable with those transitions.

Out of this I came to understand why Bruce gets frustrated with these participatory sessions. I think I also understand that Joshua's primary mode of behavior is closed, but he acts open when he can afford to spend the extra energy. Perhaps this is similar to the effort it takes me to act like an extravert when my trait is introversion. But all of this was frustrating, and our system is still not operational. And on top of all that, I am running out work. If we do not get this project moving again I will drop down to part time.

I went for a three-hour bicycle ride when I got home. Then I sat down to type up my thoughts for the day on my Blackberry - a PDA. It is interesting to watch this project as an observer and as a participant. It is also interesting to sit here writing a book on a device that looks like something from a science fiction show.

It is also very interesting to participate in, while observing the relationship between myself and Joshua. I consider it a win-win situation in that we have agreement on scope and time that will give me hope that I can keep my job by finishing this project. At the same time this agreement gets Joshua out of the conflictual situation he was in with Fred. We will move forward on efforts that support Fred's vision. But we will do it by following the map shown in the diagrams I created for Joshua.

My approach with these types of situations is to be a starfish. You see, when a starfish finds a clam, the starfish grasps the clam and relaxes its muscles. When the starfish is wrapped around the clam the starfish is bent. The relaxed shape for a starfish is flat. Thus the starfish exerts force on the clam by hanging on while trying to resume its natural shape. The clam, on the other hand, is at a disadvantage. The relaxed position for the clam is open and now it needs to work at being closed. Eventually the clam will tire and the starfish will have the clam for dinner.

Like the starfish, I focus on being open, I focus on being relaxed and I have a lot of patience. Thus Joshua and I are now in agreement on the scope and the schedule. But, the similarity between starfish and project managers ends there. Joshua holds the power over his resources. And if he decides he does not like this new agreement he can change directions again. The clam, in contrast, has no options left once it reaches agreement with the starfish. I sometimes envy the starfish. But that type of a relationship is win-lose. I believe that win-win is the better choice.

27 March. Our development system is still not ready for use. I would be angry with this vendor, but their people have lived on very little sleep for five days now trying to resolve this problem. I think their biggest problem is pride. They want to prove that they can fix this old system. I also think that their judgment is clouded by fatigue. This is crippling my efforts. Janice and Tim are totally focused on efforts to help the vendor with this problem and to deal with whatever other crisis arises in production. I cannot even get their attention long enough to find out whether or not we have lost any of our code. At the best we have now lost one week of development time. At the worse, we might have lost not only that time, but also some of the code that had been developed during the previous week. My status this Friday will likely report that we are now one week further along on the calendar and two weeks further away from completion.

My conversations with Joshua are brief and abrasive. The answer is no. So I am very careful about which questions I ask. Today I got his attention long enough for a quick review of the presentation I am putting together for our next steering committee meeting. When we got to the slides on scope and schedule he reminded me that he still does not agree with these decisions. I have patience. As long as this agreement does not unravel between now and my next meeting with Fred then there is hope. And once Fred agrees to this updated vision, scope and schedule, then we will be locked in. I clearly remember how Joshua let our agreement with Alfonso slip away because he kept pressing after he had already closed the deal. Joshua and I have a deal. He can squawk if he wants, but I am not going to give him an opening to unravel this deal.

All of this is frustrating me. My project is in limbo because of hardware issues. Agreement on vision, scope and schedule are in limbo because Fred is out of town this week. Agreement on simple things, like this slide presentation, is tenuous because of the strain Joshua is experiencing. And there is nothing I can do besides wait and fill in my time the best I can on other activities. For example, I started working on some of the PMO required documents for the next project in this initiative. I might not be able to fix the documents used in this project, but I can at least try to start the next one off going in the right direction. Of course, even that is stressful. Joshua does not want me to spend time on any of the PMO documents. And as a contractor, I need to do what I am authorized to do. It is not ethical for me to bill Joshua for time spent doing something that he does not want me to work on. So I split the difference. I put a few hours in on those documents and I left a few hours early. A few hours billable on work that the PMO wants even if Joshua does not and a few hours without pay. A compromise. A lose-lose agreement between my conscience and my ethics.

Lately I am so frustrated from the events of each day that I am finding it hard to do the research I need to do to for my next book. What would make me feel better is to come home, go for a nice run, and then get back to reading from the stack of books I have piled up on my shelf. But a couple weeks ago I tore a tendon in my foot (Plantar fasciitis) and I need to give it time to heal. Running is painful right now. I had hoped that I had waited long enough for it to heal, but it was painful to walk on it the other night. That means I need to switch over to a non-impact exercise. And thus I am putting a lot more miles on my bicycle as of late. The difference between running and bicycling, however, is time. I can push hard and feel like I got a great workout after ninety-minutes of running. But I just cannot exert the same effort on a bicycle. It takes me longer to get the same feeling. Tonight I rode for five hours. This is going to slow me down tomorrow because I got home a bit late. But I am not sure it will make much difference right now as my project is basically in hibernation anyway.

28 March. I barely made it to work on time. Our development system is still not operational. Janice and Tim are still focused on the "crisis du jour" - whatever it is this time. Only Bruce understands how to tune it all out. His ability to get to closure allows him to ignore the noise and stay productive.

I began to wonder today if part of what I am seeing in Joshua is not only an alternative pattern of openness and closeness, but an alternation between agreeable and not agreeable. The one thing I know for certain is that until this vendor finally gives us back a system that we can use I am not going to get agreement from Joshua on anything.

I am struggling with this right now. I like doing projects but I cannot get a sense of accomplishment out of this project at this time. I need affiliation, but I have intentionally cut myself off from most of my friends so that I can focus on this book and this case study. They do not understand the complexity of these systems and they want to give me simple answers. There is more to all of this than I can express and the only way I can find that answer is by communicating with people who understand more than I do. I have picked a few authors that I think might help. Otherwise I spend time thinking, conceptualizing and working to find a structural solution. This is very lonely work. I hope the results are worth the price I am now paying.

29 March. The repairs on our system succeeded last night. We lost a week of time that was diverted to this issue instead of to development. We also lost some of the work that had already been completed. The net effect is just what I had predicted. One more calendar week has elapsed and we are two weeks further away from finishing.

In my opinion there are four issues here:

Backups

Finger pointing

Pride

Self-inflicted blindness

I am continually amazed at how few computer experts think about backing up their work. As I talked with the developers today many were not aware that we had even lost data. I asked them to verify that their code had been recovered. Most were surprised to find that some of their files were missing. I then asked each one if they had a backup and consistently each and every one told me they thought someone else was doing that for them. Thus we get into finger pointing. The developers think the system administrators should make backups. The system administrators think the developers are responsible for the development systems. Both sides have collections of emails where they told the other side that it was to be their responsibility. But the net effect was that we had haphazard coverage. Some files were backed up. Some were not. Some were recovered from the backups or recreated from some other source. Some were not. In general we lost data, which is intellectual work turned into code. And that means there is work that will need to be done over again.

By the way, I take care of my own backups. Every morning I copy the files I plan to work on up to another disk drive. Then at the end of each day I post my updates to our web site. If my computer crashes I can go get a current copy from the web site. If I encounter a bug in this office automation software then I can retrieve a copy of my file from the external disk drive. If tomorrow I need to go see what updates I made last month, I can go to that external disk drive and look through the history of changes. I do not "assume" that anyone else is looking after my files. Instead I assume that the worse disaster possible is going to happen sometime in the next hour. How did I get to be this paranoid about backup? Once upon a time I filled in on a project as the product manager for a backup tool. It did not take long to realize just how ineffective most backups actually are. I wish I could give these developers my sense of paranoia about backups. I wish they would at least learn from this latest episode. But that is not to be. Even though they lost files they are universally convinced that the same thing could never happen again. I agree to an extent. I do not think it will happen again until we are at the most vulnerable point in the project. It will not happen again until a time when it will really hurt. It always happens that way.

As for the third casual factor - pride, this is the most dangerous of all. SMEs do not like to admit failure. As a matter of fact, they resist even admitting to weakness. Thus the system administrators assigned to our account persisted in trying to bring a dead system back to life rather than admit that it was going to take an indeterminate length of time. This is like asking a taxi driver to take you to the airport. Traffic is congested and he misses the off-ramp. But rather than go to the next ramp and come back you discover that he has decided to go ahead and drive you from Los Angeles to San Jose. It is unfortunate that he did not plan how to get to that off-ramp. But that does not give him the right to now hold you hostage for a six hour taxi ride. I would not have purchased the airline ticket if I wanted to take a six-hour taxi ride. We would not have spent the money to buy another system if we wanted to spend five extra days waiting for repairs on the old one. But pride gets in the way and techies hold the customer hostage so that they can give them service the way the techies want to do it.

Both the persistence of the belief that the developers have no responsibility and the hostage taking that the system administrators practice are irrational. Yet we look the other way and pretend we do not see what is happening. We deliberately and intentionally avoid facing reality because admitting that we see the flaw implies that we have a responsibility to do something about it.

We do the same in our personal lives. When I was young I rode my bicycle on a route and delivered newspapers. One morning in late December I saw an old man in a red suit going through our trash can. I watched for a few minutes and he moved on to the next home and started poking around in their trash can. Later that morning I saw him in a different part of town still rummaging through the trash cans. I wondered if he was always there and I had just missed him by a coincidence of timing. Or had he just wandered over into our neighborhood recently. And the red suit was something quite distinctive.

I told my father about it when I got home and he said it must be Santa Clause. Now he and I both knew better, but that image has stuck with me ever since. This is a great ironic juxtaposition. Santa Clause is an image of someone so immensely wealthy that he can give presents to everyone everywhere and still have an abundance left over. This man in the red suit was so desperately poor that he was searching trash cans to support his existence. I guessed he had probably found that suit a few nights earlier and decided to make it his standard attire. I wonder if he picked it just to keep warm, or if maybe he was holding onto his own illusions about Santa Clause. That image of Santa Clause rummaging through the trash can has stayed with me for nearly forty years.

The other night when I got home from a long bicycle ride I lay awake for a while and I listened. When I run I can go to sleep almost as soon as I get home. When I bicycle it takes me a long time to get to sleep. So I lay there and I pondered how to work this project, how to assemble the next chapter in this book, and where I fit in this world. As I lay there I heard Santa Clause. Someone had left an old step ladder next to our trash dumpster. And now I could hear that distinctive sound of a step ladder being drug across the pavement, set upright and tested. It must have passed the test because it was gone in the morning.

Irvine is a beautiful community. People here seem so affluent. And yet, there are people living right here in our midst that rummage through the trash dumpsters. We deliberately and intentionally do not see what is in front of our eyes. We do not hear their cries.

About a week ago I heard a car with a powerful engine pull up near my apartment. The sounds that cars make are all so distinctive and when you ride a bicycle you get to be good at using your ears to identify which of these beasts is coming up behind you. There are lots of high performance cars in Irvine, but the sound of a sports car is akin to a well oiled sewing machine - very tight, very precise. The sound of the typical SUV (sports utility vehicle) is also fairly distinct - large, powerful but not tuned for acceleration. The sound I heard this night was the sound of a predator - a car that was tuned for power.

The driver got out and I heard a knock on my neighbor's door. The driver identified himself as a police officer and told the tenet she either had to pay her rent the next day or move out by Saturday. They talked and I heard the car pull away. But the car did not go very far. It was still close enough that I could hear that engine purring. And then there was another knock. This conversation was too far away for me to hear, but I am sure I known the gist of it. Why do this in the middle of the night?

I saw my neighbor the next day but she just looked away. There have been times when I have been able to help someone pay one more month of rent or I put them up in motel for a night. But that was not to be this time. She pretended not to see me. Where do you go when you are already so far in debt that you cannot pay your rent? Probably someplace other than Irvine.

We are very good at pretending not to see. We choose not to hear. Making a backup of my files - why that is someone else's problem. Caring for my neighbor - well that is why they have homeless shelters. Try this sometime. Lay awake at night and listen for Santa Clause. No matter how affluent you are, the poor are there in your neighborhood.

Or try staying awake in a meeting and listen to what is not said. The power of that silence is deafening. If someone asks what you are doing, tell them you are waiting for Santa Clause. Maybe Santa Clause will bring you a scope statement. Maybe Santa Clause will speak up and say what is not being said. Maybe Santa Clause will find a way to get everyone to work together for the good of the project. Or maybe project managers should all start wearing red suits because no matter what anyone wishes for it is up to the project manager to make it happen.

**A Part Time Project**

30 March. I talked with Joshua today and then I sent an email to Jim (my account manager) and John (my mentor). I have run out of work. I have reached the point where this project is no longer going to require my full time attention. Progress is so slow that I only need a few hours a week to check on status. Our ability to help the projects that are dependent on us is so limited that there is little point in my going to their meetings. The advantage and disadvantage of being a contractor is that I am paid for hours worked. And there are not going to be enough hours of work for me on this project. Joshua is going to see what he can do. Otherwise I will pick up another part time project elsewhere.

Since I finally had some free time, I called my friend Rick and we had lunch. Rick and I worked together several years ago and I am continually impressed with his skill as a project manager. I like talking with Rick. Sometimes he treats me like a wise elder with advice to dispense and sometimes he amazes me with the insights he has that I had missed. We talked about the similarities between the project he is now working and my case study project. Both are based on wildly optimistic schedules. Both are falling behind. Both suffer from the blinders that people use to avoid seeing the problems that face them. The difference is that Rick is paid a salary and so he is working far too many hours. I used to do that when I was paid a salary. I do not do that anymore. Now I get paid by the hour. I have worked plenty of sixty hour weeks. I have done my share of eighty hour weeks. And there have been too many one-hundred hour weeks. But now I get paid by the hour.

Customers seldom want to sign a one-hundred hour time sheet because they know what it is going to cost them. Managers seem oblivious to the one-hundred hour weeks that many of their employees work. I once confronted a boss about this and his response was that he had no idea people were working those types of hours. I believe him. He had no idea what the work he was assigning to his team was doing to their lives. Nor did he care. There is so much going on around us if only we would chose to see it.

1 April. My neighbor was moving today and I said hello. I was surprised when she replied and accepted my offer to help carry a few of the heavier items. She had one item that she had to leave behind and I helped her carry it over to the dumpster. She was ready to toss it in and I told her not to. I told her that if we just set it there it will be gone before morning. Sure enough, a couple hours later a young couple was out there trying to figure out how to take this piece of furniture home. I offered to help, but they were confident they could carry it themselves.

Jesus said that the poor will be with us always (5). They are universal. Even in Irvine we have people who struggle. No doubt their struggle here is more comfortable than it would be somewhere else. But hunger feels pretty much the same whether you sit on a dirt floor or a leather sofa. We need to open our eyes and ears to see and hear what is going on around us. Then act.

2 April. I am really short of work so it looks like this is going to be another part time day. Joshua suggests I check around with the rest of the team and see if I can scrape together some additional hours of project management work. I sent a few emails, talked to a few people and then I left early.

I took this as an opportunity to check in with my friend Lesley. She is paid a salary, and, as usual, she has too much work to do. I swapped emails with my friend Lenka and she is working too many hours again. A few minutes later I got a phone call from Greg. Following with my theme for the day I asked Greg about his workload. Greg had been salary and was working too many hours. He just recently switched jobs. Now he is busy, but he looks forward to getting back to a balanced life style again - as a contractor.

The pattern I see is fairly consistent - people are abused. Salaried workers work too many hours. Contractors struggle to get enough hours. Some contractors deal with this by pretending to be busy. I consider padding project time to be a form of theft. But it is easy to see why people do it. They are afraid. And they would rather cheat a little on their time sheets than to come up short on their paycheck.

Note that I am not saying that contractors are dishonest and salaried people are ethical. Several of the people sitting in cubes near my cube are on salary and yet they do little work. We all need a few minutes here and there to take care of personal business. But there are days when I wonder how some of these people find any time to do any company work. So I guess this is the flip side of the situation - workers take advantage of their employer.

Both the workers and the managers are trapped in a system that does not flow smoothly. Workers protect themselves by withholding information and practicing deception. Managers become callous and ignore the pain their workers experience. Successful people feel like they need more and ignore the poor people around them. And while many poor are suffering there are just enough people that pretend to be poor to create confusion.

3 April. Alfonso sent an email asking about our project status. I sent him a summary and he sent me back his recommendations. I replied that we are already doing everything that he recommended and then some. My suspicion is that this conversation had nothing to do with our status and everything to do with Alfonso trying to impress Fred. Most likely he took a few tidbits out of my status update and then told Fred that he was trying to save my project. The key question is what it is that Fred believes. Does Fred see and hear what Alfonso feeds him or does Fred see and hear what is actually going on. Getting spoon feed is an easy choice for a busy executive. Probing and testing reality takes work. People like Alfonso thrive because too many executives take the easy way out.

A few hours later I got another email from Alfonso. He wants to set up more meetings to work on the updated architectural design. Joshua and I are already done. It is a pity that Alfonso did not participate earlier and did not take the steps he had committed to in order to execute a smooth handoff. My belief is that Alfonso has run out of work. And being a contractor he is searching for stuff to fill his day so he can bill more hours.

When I look back on his prior work on this design it now makes sense. It took him weeks to come up with a couple simple diagrams. I redesigned this and drew the diagrams over again in about two hours. The work was not that hard and it is easy to see that Alfonso is a very bright individual. So the only explanation I think fits is that Alfonso is padding his time sheet by allowing his work to take longer than it should.

None of us fits our job correctly. We all deal with the resulting stress in different ways. Alfonso is trying to make himself appear more important than he is. And he is stretching his work to get a full week of pay. I, on the other hand, deal with this stress by focusing on this book and on my outside activities. People sitting nearby deal with their stress by focusing on their personal lives while avoiding work. I tend to think of Alfonso's approach as an application of power. This noisy crowd around me seems focused on affiliation. I am caught in the middle. I cannot get satisfaction from achievement on this project. I am trying to exert power to get more work. But in the meantime I am checking in with my friends and focusing on affiliation.

Joshua is going in a different direction. He is increasingly frustrated by our lack of progress. His response seems to be a redirection of his efforts back into achievement. Every time I go to his cube he is busy writing code. If the team cannot build this software, then Joshua will do it himself.

4 April. I am frustrated. Tim is out this week for training. Bruce had a family emergency and he had to fly out of town. Janice got pulled off the project again to deal with yet another crisis. Raj is busy working on a forecast for next year. And the other team members are scattered about; pulled in a dozen different directions. I cancelled the team meeting today due to the lack of a team. Our progress this week is going to be close to zero.

5 April. I talked with Joshua about the lack of progress and he says it is the project manager's responsibility to get this work done. I then took him on a tour of the cubes and reminded him that every cube except his is vacant because he has sent those team members off somewhere else to work on something else. He was quiet. With zero resources we will continue to make zero progress.

I then talked with him about the series of emails from Alfonso a couple days ago. He was agitated about them at first and was angry about some of the accusations Alfonso made about his management style. I then asked why he had not responded to Alfonso's request for a meeting and he said nothing. And thus we defined a social boundary - a taboo. Rather than take a chance on saying something in anger, Joshua says nothing. Rather than give Alfonso a forum for discussion, Joshua avoids him. This is not good for our team, but today is not the day to try to change Joshua. He is not in the mood for that conversation and I have to drive up to Los Angeles to meet John.

I have mentioned John before. He is the "mentor" assigned to me by this consulting company. He generally works remotely, but had meetings in Southern California this week. We setup a lunch and had a chance to meet. He asked about my project and I told him that I am now working half-time and getting one-half of my expected pay. He was sympathetic and explained that he gets his full paycheck now by working for two different customers giving each about half of his attention.

We then talked about the "functional manager" and the "CTO". I like John, but things you tell someone sometimes come back around in unexpected ways so I decided not to tell him the names of Joshua and Fred. I explained that it takes time to change Joshua's direction. For example, I mentioned a conversation I had with Joshua weeks ago about hiring dedicated quality assurance testers. Finally last week Joshua agreed and I have included two QA testers in the budget for the next phase of this project. It takes time. I am trying to change the culture of this group. I think John understands. It also sounds like he has come to accept the magnitude of the gap between the best practices we see in books and the reality of the projects we work on. It was a pleasant conversation.

We talked through the slides I have ready for the next steering committee meeting and did a quick conversation about project documents. I now have the following:

Project funding request

Return on investment calculations

Project charter

Project budget tracking spreadsheet

Bi-weekly status reports to the PMO

Communications plan

List of project stakeholders

Team roster

High level resource assignment matrix

High level system configuration matrix

List of system performance monitoring thresholds

Systems performance dashboard

Project schedule

Milestones report

Meeting agendas and minutes

List of code deployments with Request For Change (RFC) numbers

Risk matrix

Issues log

List, calculations and a graph showing the estimated project completion date

Trendline showing the percentage completion

Matrix of dependent applications

Organizational chart

Monthly newsletter

Communications to all users about updates

Root Cause Analysis (RCA) documentation on outages

I might not have yet complied with the PMO guidelines, but I have at least created the key documents that I need to manage this project. Now, if I had enough work to do I would have driven back to the office.

Instead I went off in a different direction searching for another bicycle route. I have set a goal for myself - a metric - a way of measuring achievement. And like a typical achievement oriented goal it is big, but reachable. I have set a goal to ride my bike 500 kilometers (311 miles) this week. That is a big number considering I had been focused on running and not riding for the past twelve months. But as long as I need to switch from running back to cycling, I might as well get serious about this.

I rested on Saturday and then I rode 10 miles on Sunday as a warm up. Then I rode 85 miles on Monday, rested on Tuesday and rode another 85 miles on Wednesday. Today I drove my car in search of a southerly route. This is a risk mitigation strategy. I am confident that I will not get run over while driving my car. I am not that confident I will survive that same route on my bike until I see for myself whether or not there is enough space for a bike. I have been knocked unconscious before when a car nudged me off the road and so I am more risk adverse than I used to be about heading down a road that I have not previously explored. I still love the road less traveled - but only if it has a bike lane.

Setting a goal like this accomplishes two things. First it satisfies my need for achievement. Second it keeps my mind off the paycheck situation long enough to let other things play out. For example, I have a one-on-one meeting with Fred next week and he might have another project for me to work on. Or Jim, my account manager, might find another project. I will give them a little time. In the mean time I need to avoid worrying about the situation. Part of my strategy is to trust in God and believe that all things work for the best. This is not the same as waiting for Santa Clause, although some people do get the two confused. Waiting for Santa Clause is passive. Trusting in God is active. I am working through my address book in search of another project. But I am doing this without worry because I have confidence that something will work out.

The other part of my strategy is to be busy while the clock ticks away. This week I will focus on rebuilding my cycling stamina. Next week I will focus on my book. In some ways this part time work schedule is a blessing. I really need to finish this book and working part time will give me the time I need.

6 April. I showed Joshua and Raj my new spreadsheet to calculate the project end-date based on a three-week rolling average rate for work completed. They agree that our rate of progress is too slow. Joshua thought about this for a while and found one more item that was not in the original scope. I will ask the Steering Committee for permission to drop that item from this phase.

When I ran out of things to work on I went home and got ready for my bike ride. For an 85-mile ride at this time of year I take 170 ounces (5 liters) of fluids. I calculate my fluids budget parametrically. In the winter I typically consume about one ounce of fluids per mile. In the summer I might consume three ounces of fluids per mile. During the rest of the year I budget two ounces of fluids per mile. I also budget my batteries. The days are getting longer, but it will be dark before I get home so I have a High Intensity Discharge (HID) headlight with a 12-hour battery and light emitting diode (LED) taillights with a fifty-hour battery life. For today's ride I will turn all the lights on at dusk. If I expected to spend more time riding in the dark then I would wait until it got dark before I turned on the headlight. My risk mitigation strategy also includes a very small toolkit and my PDA. The toolkit has been sufficient to make most repairs in the past. The PDA worked well the one time I had to call a taxi. This should be a great ride today.

A long bike ride is rather like a project. You need to plan for it. You need to commit to the duration of the effort. And then you need to stay focused. I like long bike rides, long runs and long walks because they allow me to focus my thoughts. Today my goal is to think through an analogy comparing project management with a long bike ride. The route is my set of deliverables. My project budget is the amount of fluids I packed to sustain me on this trip. In the same way that I set milestones and tasks on a project, I set milestones and miles for my ride. Thus my ride schedule is the planned duration to achieve a specified set of deliverables.

My route for today begins on the trail that runs near my apartment. I run on this trail more often than I ride on it, but it makes a good starting point for a long ride. When I start a new project I like to start out with familiar territory as well. It really helps to get to know the team and to read whatever documentation describes the project. I like to spend a few days learning what the people on the teams do and getting familiar with how this project fits into the corporate goals.

This trail connects to a one-way road that runs along the edge of the bay. It is always peaceful here. The marsh areas are wildlife reserves and migratory birds stop here on their journey. The bluffs screen out the sounds from the city. This is one of my favorite parts of this route - even if the peace is occasionally disrupted by the roar of a jet taking off from the nearby airport. I let this part of the journey remind me to pause and enjoy the beauty around me. We need to do the same on our projects occasionally. We need to stop the hectic pace that comes from completing one task after another and look around to realize that we are on a journey. We are moving. And if we fail to grasp the moment it will be gone. Riding this part of my route is like having lunch with a good friend.

This one-way road connects back into the city grid and with a few zigs and zags I end up on the coastal highway. This is the part of my journey where automobile traffic is the most chaotic. There are a lot of people searching for parking places, looking for restaurants, checking their cell phones and watching the scenery. From my point of view on a bicycle each and every one of these cars is a threat. Unless I focus all of my attention on this traffic my journey will end prematurely. That has happened to me before on bike rides. It has also happened to some of my projects. There are times when I have put all my effort into a project and it still crashed.

A few miles further and this road junctions with a river. When I say river you might be thinking of a large flowing stream of water. In California rivers are large channels that might or might not have water. There is a trail that runs next to this river and I take it. This allows me to go the next twenty miles without encountering any automobiles. This is the fastest part of my journey. I just need to watch out for the mountain bikes that go flying diagonally across the trail, through the river bank and up the other side. Do you encounter that on your projects? You finally hit a long smooth stretch and feel like you are making great progress only to find a few people cutting diagonally across your schedule, hop scotching between tasks and reinventing the deliverables on the fly? We are all different. I try to give the free-thinkers enough latitude to enjoy their journey. But, as a project manager, I sometimes find it necessary to scowl a bit and politely direct traffic so as to avoid collisions.

I found this trail years ago when I noticed it from the back window of an office building I worked in. It took me ten years to get around to riding here. I do not regret those ten years. That was not the time for long bike rides. Now it is. I look back on the projects I did in that building in much the same way. We accomplished a lot. I wish we could have done some of it differently, but today I am a different person than I was then. I try to remember that when I encounter conflict with someone on my team. We are all evolving from what we were to what we will be. Sometimes we cross paths at the wrong time. I look at this office building as I ride by and I think of the friends that were transferred to other companies, got laid off or quit. Occasionally I run into one of them somewhere else and we might even work on another project together.

When I leave that trail I end up on a very busy city street. Again, traffic brings risk. But I picked this street because it goes up hill. It starts off gently, and then it turns into a ten percent grade. This is hard for me, but hills are part of life. We run into parts of our project where we seem to be moving at a snail's pace. Hills like this remind me to persevere. I once missed a small notation on a map and spent over an hour climbing a hill. I could do that because I had spent time practicing on smaller hills like this one. I cannot recall the number of projects where we missed some small notation in the documentation and spent unexpected weeks trying to resolve technology problems. Here is one of the places where a bit of pride comes in handy. I let my pride keep me moving forward because I would lose respect for myself if I turned back just because it was hard.

That is not to say that I do not occasionally turn back. There have been several times when I took a detour off my route to try some new road only to discover that the traffic was too fast and there was no place for a bicycle. I have learned to set my pride aside on those occasions, turn the bike around and get out of there quickly. I have done the same on a few projects. But generally I find that getting through the tough parts of a project is just a matter of persistence. I seek out hills occasionally to remind me that I can climb them. I enjoy the tough parts of projects because they make the others parts seem so easy.

So I climb past the high school where I used to teach extension courses, crest the hill and enjoy the thrill of keeping up with the cars as I go downhill. Then I start up another small hill and end up on the back side of the college campus where I used to teach project management classes for my local PMI chapter. I put this route together by building on material I already knew. I began by riding on a trail that I learned by running on it. I connected that with a trail that I looked at from an office building where I previously worked. I chose a street that goes past a school where I used to teach and then connect that up with a street that goes past another school where I used to teach. We do projects the same way.

There has never been a project that did everything totally new. Every project builds on the pathways, processes and technologies that have been used before. And then we venture off the well traveled routes onto routes that are a bit less familiar. Yet we seldom stray that far away from what has been done before. My case study project is pushing the limits on the vendor technology that we are using. But when we run into obstacles the vendor is there to back us up. We have a guide to help us through the parts of the journey that are new to us. Also, each module that gets deployed into production gives this project team more familiarity with these tools. And soon this temporary, unique endeavor will become almost repetitive.

I have traveled this particular route about a dozen times. The last time I came through this part of town I noticed there was a new road that I had not yet traveled. Tonight I am seriously considering taking a detour to try out this new road. Before I do that I need to check my scope, time and costs. I have now traveled forty-five miles and I am just a few minutes behind schedule. Thus, I am slightly behind on schedule variance. That is tolerable because there is no hard deadline for project completion \- I have no other commitments for tonight. My water bottles still hold about one hundred ounces of fluids. This means my cost variance is positive - I am consuming fluids more slowly than budgeted. That means that my funding - as measured in fluids - could support a small extension in scope. I pause for a moment to consider my options.

Now if I had plans to meet someone afterwards then time would be my primary consideration. But tonight I have no plans following this ride and tomorrow is Saturday so I can sleep in if I get home late. That means that budget is my primary concern tonight.

I budgeted two ounces of fluids per mile because it was hotter than is typical for this time of the year. It looks like I am not drinking that fast. Running out of fluids is a serious concern. A couple times I miscalculated in the middle of the Arizona desert. Once I ran out of water about ten miles from anywhere. I slowed down and I coasted whenever the road looked like it had any downhill grade. But by the time I got to the next town I could not speak, I had trouble thinking clearly and I could barely peddle my bike. I walked into a convenience store, got an orange juice and put money on the counter. The clerk said something - probably trying to give me change - but I paid no attention. I drank that orange juice and felt my stomach cool down. I got another, put more money on the counter and drank it. Now my body started to sweat again. I got another, put more money on the counter and sat down outside to wait for my brain to start functioning again. Thereafter I started including a contingency fund in my budget. On hot days I strap one extra water bottle onto the back of my bike and I only touch that bottle when I am willing to admit that it is an emergency. Project budgets are like water in the desert. When your run out of budget your project dies. A contingency reserve can sustain the effort long enough to bring the project to a successful close.

So now I check my budget. I had not planned a reserve tonight - I broke my own rule. Now I am contemplating a change in scope. Changing my route means it will take me longer to finish this journey. And that means I will need more budget. I check my water bottles again and then I pick one that I am now designating as my reserve. I will try this new route as long as I stay within my original budget - less this reserve. If necessary, I will abandon this change in scope and use my reserve to get me home.

I turned and started down this new road. It looked great. Less traffic and fewer stop lights than my previous route through this part of town. Then it started to narrow and the bike lane vanished. I turned off at the next intersection and took another road. Sometimes we run into the same problems on projects. We see a short cut and we start down that path without doing the right amount of planning. I am still committed to the increased scope, but my estimate was based on a flawed assumption. Rather than having a nice wide road with little traffic I am back onto a busy highway with a long upward grade.

I know this next hill really well. It is a fairly easy grade, but it is amazingly hot. The hill I went over earlier with a ten percent grade is lined with trees and almost always has a breeze that helps keep me cool. This hill I am climbing now faces southwesterly and the trees provide very little shade. I like practicing on hills because they require a different type of effort - they exercise a different part of my muscles. But my ability to exert my full muscular effort is impaired when I am baked by the sun from above and broiled by the reflected heat off the pavement. When I plan my routes I try to get to this hill between dusk and dawn so that I am not contending with the heat.

As a project manager I try to use timing to my advantage in sequencing the tasks. If we know we are going to run into technical challenges with a new tool, then we need to start those tasks as early as possible. We want to work on those tasks before the project heats up. We want to finish those tasks before converging deadlines add pressure. Sometimes, like today, it does not work out that way. Today I am baking and broiling.

The grade flattens out and I turn and ride towards the apartment I used to live in a couple years ago. I have a checkpoint just before I get to that apartment where I always assess my schedule variance and cost variance. I am still climbing upward, and even though the grade here is gentle, I go slower when I am going uphill. I have been tempted to factor that into my calculations. I could look at my time now and say that I am a few minutes behind, but then optimistically plan on making up that lost time on the downhill stretch. I do not calculate it that way.

When calculating earned value you can use several different systems. You can just go ahead and record the percent completion as it is that day based on the best estimate provided. I use that technique when I am bicycling. As of right now I am about eleven minutes behind schedule for the number of miles traveled. If my new route had worked out then I might have avoided the heat I ran into coming up the steepest part of this hill. But that route did not work out, so I ended up traveling a bit further than expected and then had that hot climb. That means I drank more fluids which means that my cost variance is almost even. But neither of these variances is enough to set of any alarms just yet.

On my case study project I learned that calculating variance based upon the estimates provided did not work. I was skeptical at first and so I began using the 20/80 rule. When someone said they started and were making good progress I would set their percentage complete to twenty percent. When someone said they were almost finished then I would set their percentage complete to eighty percent. And only after the deployment into production was declared a success would I update the task to one-hundred percent complete. This is a fairly common technique.

However, after the incident where the ten day task only took two hours to complete I changed tactics. Now I am using the 0/100 rule. I do not show any progress at all until the code is fully deployed into production and running successfully. That change proved highly advantageous when the development system crashed. Work that I would have recorded as eighty percent complete under the 20/80 rule suddenly vanished. If I had been using the 20/80 rule then I would have been required to explain to our CTO and our PMO why the overall project percent completion went down instead of up that week. Because I was using the 0/100 rule I did not need to deduct from the project percentage completion. Those tasks that I had listed at zero percent complete were still at zero. And the tasks that had been one-hundred percent complete before the crash were still one-hundred percent complete after the crash. I use the 0/100 rule when the project is highly unpredictable.

About a mile past my old apartment I make a turn and start down this hill heading south. The first part of my alternate route did not work out and I ended up back on my old traditional route. After a few fast minutes going downhill I again junction with the alternate route I wanted to try. This part of the route looks fine and there are only a few miles to go before I junction with the part of this route that I drove my car on yesterday. I pause for a moment and then start up this next little hill. At the top I turn to the west and speed downward past the veterinarian where I used to take my cat for his checkups. A few miles further and I turn onto the road that goes down to the beach where my ex-wife and I went on our first date. I turn away from the beach when I junction with the state highway that heads back to Irvine. This part of the new route worked out perfectly.

I get very focused when I go on a long ride like this. I feel much the same as when I used to meditate. My mind gets calm and the noise of all the distractions fades away. It is important to come out of that sense of being one with the world and come back to where I am in the here and now. On a project we call this a project review. I know that my fluids are now dwindling faster than planned but unless I consciously focus on that fact I will just keep going until I run out. Similarly, the budget on my case study project is being tapped from all directions. It looks rather like a garden sprinkler spraying my budget out for all the world. We fight that tendency by working with the financial people to account for every expenditure they are deducting from my budget. Earlier today, for example, we found that someone on another project had billed my project for one of their consultants. I sent an email to finance to fix it and Joshua added his emphasis to speed finance along.

My goal on a long project is to get the team into a similar meditative state. We want to minimize the friction. We want the team to come together and get through the team development stages from forming to storming, onto norming and then strive for that final meditative state called performing. My case study team still exhibits signs of storming. There are so many distractions that I am not sure we will get past norming. When I feel like I am struggling with my ride I go slower and slower until the ride becomes frustrating. Sometimes all the distractions in life get to me. I sense that a few people on my team are similarly frustrated with the turmoil. Janice, for example, has so many tasks assigned to her right now that she cannot focus. I need to help Joshua understand that unburdening people will allow them to go faster. Janice can do the five tasks assigned to here in the eight weeks left for this set of deliverables, but only if she can focus on them one at a time. Today she is trying to work all five simultaneously and she is drowning.

As I contemplate the importance of focus I reach the place where I need to exit this highway before it turns into a freeway. I turn, travel up this road about a mile and connect with the bicycle path that will lead me home. I check my fluids and I am nearly dry except for that reserve bottle. I check my time and I am now about twenty minutes behind schedule. I tend to go slower the first couple times I try a new bicycle route. Projects also go a lot slower than expected when people are exploring new technology.

I then check my mileage and realize that I am coming up short. When I turned off that new road I changed my route in such a way that I have traveled less distance than planned. Mileage is my deliverable. I am not going to deliver all of the mileage that I promised to myself. Now if I was out of time or budget then I would need to update my scope to match what was actually going to happen. But in this case I still have a little bit left in my budget and I can extend my time a bit further and not conflict with any other obligations. So I do something I seldom do. I ride past my apartment and keep going. I go back down this trail about five miles, turn around and come back. Now I am out of water - except for my reserve. But the end result is that this was a 102 mile bicycle ride. Amongst cyclists a ride of one-hundred miles is called a "century". Riding a "century" is something you can talk about. Riding 92 or 95 or even 98.5 miles does not count as a "century". Riding 102 miles does. This was a good ride.

7 April. Have you ever done a project closeout? There have only been a couple times when I was able to get enough people to show up to hold a final meeting to review the project and discuss lessons learned. A project closeout gives you a chance to incorporate updates into your process. And yet, people see that the goal is in sight and they make a dash for the nearest exit. I have always been amazed at the number of people that leave a baseball game in the seventh inning when there are two more innings left to go. I remember one game where I argued with friends and finally relented after the first two outs in the ninth inning. I clearly remember watching the ball that tied the game come flying over the stands and land in the parking lot about a hundred yards from where we were now sitting in an endless stream of cars going nowhere. It is not done until it is done.

In the spirit of finishing what I started I got up Saturday morning, dressed and started peddling. I picked a fairly easy route out, connected up with the new road that I had started on yesterday and set out to see where this road went. After about five miles it simply ended. So I turned around and went back home. This ride was 32 miles and that brought my total up past the 311 miles I needed to complete 500 kilometers in one week.

**Going Nowhere Fast**

9 April. It is Monday. Just like most Mondays of late I begin the day by reading the emails to see whether or not our code was successfully moved into production this weekend. And, rather like most Mondays of late, problems were encountered. Rather than spend the weekend struggling with the problem, Janice wisely chose to reverse the change. I thought about that new stretch of road I traveled on Friday and the choice I made to abandon the journey when it got too risky. I thought about traveling that same route again on Saturday thinking that the daylight would make it less risky - only to find that it was just a long road to a dead-end. Janice made the right choice. We are clearly not spending enough time testing this code before trying to push it into production.

What this means, however, is that now we are even further behind schedule. Another week has elapsed. The code that was supposed to be finished this week is not finished. And the time that should now be directed towards the next set of code is going to be used, instead, to find bugs in that prior code. Our percentage completion is barely moving. I loaded the updated numbers into my spreadsheet and took it over to show Joshua.

This chart is fairly simple. The first column is the date from the weekly status report update. The second column is the percentage complete reported on that date. The third column is simply the change since the last week. For example, the percent complete in the first row is 12%. The percent complete in the second row is 15%. The difference between 15% and 12% is 3% - the "gain this week."

The "3-week average" is a rolling average of the "gain this week" over three weeks. Notice that there is no value shown until week four. In week four the "3-week average" is the sum of the "gain this week" for the prior three weeks, divided by three (3% + 3% + 2%) / 3.

The "weeks left at this rate" is just the amount of work remaining divided by the "3-week average". In week four we have finished 20% of the work. This means there is 80% remaining to do. Eighty percent divided by 2.7% yields 30. If we can continue producing work at the rate of 2.7% per week, it will take thirty more weeks to finish this project. If the "3-week average" increases, then it will take less time to finish. If that average drops, then we will need more time. For example, the bottom row in this chart shows that our "3-week average" has dropped to 1.0%. This means it will take 73 more weeks to do the 73% of the work that is left to finish. Clearly that exceeds the original estimate of three or four months. Clearly that exceeds the budget limitations that requires that project funding terminate at the end of each fiscal year. And, quite frankly, that projection is going to exceed anything the steering committee will be willing to tolerate. Joshua looked over the numbers, thought about it for a bit and then decided that we would need to work faster.

I am not yet getting through to him. Everyone is already working too fast. They are working so fast that they are producing poor quality which then requires rework. We disagreed on this. I have patience. I will win this argument. Somewhere, somehow I will finally persuade Joshua that thrashing about at a faster pace is not as effective as slowing down and focusing.

Did you catch that change in my attitude? What I just said is that I am no longer focused on a win-win proposition. Now I am in win-lose mode and I plan to be the winner. This is a dangerous shift in my approach. I need Joshua to back the required changes. He needs to buy into them and he needs to support them. I will not get his support by beating him into submission. So, I will blow off a little steam, and then I need to focus again on finding a win-win solution.

10 April. Alfonso scheduled a conference call this morning to talk about an upgrade that will impact my project. I was on that call for thirty minutes and got no value from being there. The majority of the time was devoted to two system administrators discussing the cabling configuration. Why do we allow this to happen? As a project manager I need to value the time of those participating in a meeting or conference call. It is my responsibility to keep the meeting focused on the agenda and maximize the value to those attending. I sympathize with Alfonso in that it is easy to lose control of a meeting. But the end result is that ten people spent thirty minutes listening to a conversation that should have taken place elsewhere.

In the meantime I got an email from Raj. He is tied up with another problem and would like me to fill in for him in the Change Control Board (CCB) meeting today. I welcome that opportunity as this will give me a glimpse into what this company thinks ITIL should look like. There were only a few minutes between Alfonso's call and this call so I had to scramble to find the details about the changes my team has proposed for this week.

I joined the call just as it was starting and quickly discovered that this meeting follows one of the traditional formats. The Change Manager distributes a one-hundred page report shortly before the meeting. About fifty people then join a conference bridge we spent somewhere between sixty and ninety minutes reading this report and affirming that our changes are "on schedule."

This is a very traditional format and it is a waste of time. At the rate of one-minute per page there is not enough time to actually discuss anything. So all that happens is that the representative restates exactly what is on the report and then says that the change is on schedule. No information is conveyed that could not have been gleaned by just reading the report. But with fifty participants and an average internal charge rate of $60 per hour this call cost the company $3,000 per week or $150,000 per year.

I have encountered the same format elsewhere and tried to fix it in those locations. The method that I recommend is to have the technical staff meet to discuss only those changes that will impact their part of the infrastructure. And if that change will be totally contained within that segment of the infrastructure then the change is approved and implemented by that body. This means that the people discussing the change have the technical competency to know what is going on. That process update results in about eighty percent of the changes being managed locally. In turn that will produce a drop from over one-hundred changes per week to fewer than twenty that actually go to the CCB. And that means that the CCB can then focus more time on what is important. I would love to see that change implemented here, but I cannot seem to penetrate the walls of resistance.

Perhaps you are better positioned than I am to make this change. It is really simple. You find one person in each functional team and designate them as the change manager for that department. They are responsible for running a change control meeting for that department and for ensuring that changes are properly assessed by technical experts. If the departmental meeting concludes that a change is within their scope then they are free to plan and execute that change. If this department thinks the change is going to impact other departments then the change needs to go up one level.

If the department takes responsibility for a change that actually impacts another group then they should receive feedback so they can do better next time. If this department keeps passing changes upward that should have been handled locally, then they need feedback to fix that problem. This is just like any other activity in a traditional hierarchical organization. The manager has responsibility and should only escalate upward when required. That allows the corporate change control board to focus on what is important.

11 April. Another member of the PMO quit. I understand he only lasted thirty days. Perhaps the self-destruct cycle has already begun. Sam seems to be under a lot of pressure lately. I think a PMO is a vital part of an organization and this bothers me. At the same time, I think this PMO is ineffective in how it communicates. I would like this group to change directions, but I do not think they believe it is possible to change. That is too bad. This is another place where I could help, but the resistance to dialogue is so firm that I cannot seem to make any headway.

Coming out of that meeting I saw Fred. He was heading into another meeting himself so he only had a moment to talk. He wanted to let me know that there are additional expenses that will be charged to my project. Alfonso had found some irregularities somewhere and asked Fred for authorization to bill my project for work previously charged to his project. Fred agreed, but does not have time to explain the details to me. He just wants me to be aware that a couple hundred thousand will be charged to my project.

I called Mitch, my contact in finance. He has no details but confirmed that Fred authorized the charge to my project. I will follow up with Fred regarding the details. In the meantime I asked Mitch to shift over the last of the money flagged for our software upgrade to cover this new expense. We will need to drop this software upgrade from project scope. I hope the steering committee does not have any serious objections. Not that it matters. Joshua had already pulled so much money away from that budget item that it was not going to occur anyway. I will follow up with Fred later, and then I will follow up with Alfonso.

Next I went hunting for Joshua. He just nodded his head. He knew he was taking a chance when he billed that work to Alfonso's project. Now he has been caught. I asked if there were other skeletons in the closet. He assured me there were no more.

12 April. Janice has so much work left to do in order to be ready for this weekend that I am concerned. I talked with her and found out that once again there is another high priority request from Joshua that has disrupted her schedule. We discussed the situation and I recommended she ignore the request from Joshua and focus what time she has left on ensuring the code for this weekend is ready. I followed up with Raj and we reassigned this latest high priority request to Bruce. Then I went back to my cube and updated the current work assignments in my Resource Assignments Matrix (RAM). Part of that RAM is shown in the table, below.

I printed copies of the RAM and went to see Joshua. I explained that assigning this high priority request to Janice had put our ability to have code ready for this weekend at risk. I showed him the RAM and highlighted the critical path that Janice and Bruce are on right now. He agreed.

I was ready to start into a long argument with him about the value of balancing the workload, about the value of project schedules and a RAM. I was going to explain the value that project management brought to this process. Instead I just sat there absolutely dumbfounded. He agreed. Finally, after weeks of charts and diagrams and calculations and endless discussions, he agreed.

I explained that I had moved this new high priority task to one of the other programmers and he said that was a good idea. Then he asked Janice to come over and give him a quick update. When she was finished he thanked her and told her that she was doing the right thing by focusing on the work for this weekend.

Absolutely amazing. After all these weeks he finally got it.

13 April. I spent time today trying to ensure that the right code is ready to deploy into production this weekend. I am breathing easier. Joshua and I are on the same page. We agree on priorities. This is fantastic.

16 April. It is Patriot's Day in Massachusetts and the Boston Marathon should be starting in a few minutes. Sometimes I get interested enough to check the web site, but there will be no time for that today. The deployment this weekend never even started. At the requested start time the system administrator noticed an error on the form and rejected the request. This is another symptom of the problem with the hundred-page approach to change management. The technical person doing the work had no involvement in the process. This is why we need to manage changes like this locally and only forward them to the CCB when everyone is in agreement. We just lost another week off our schedule. I am going to need to do an end run around the corporate Change Manager and start running a weekly change review for our department. I sent an email over to the manager responsible for that system administrator and told him to set up a conference call so we can ensure this does not happen again this weekend. It will be twice as critical this weekend because now we are going to need to deploy two sets of code in the same change window. That is risky.

I talked with Joshua and he decided on another change in scope. I made a note to bring this up in the next steering committee meeting. To give you an idea of just how fluid scope is on this project, consider the illustration of our original scope shown below. Then compare that to the approximation of our current scope shown in the subsequent diagram.

Important deliverables keep dropping out and new deliverables get added in. Yes, Joshua is responsive to his customers. And yes, we always manage. But this puts us in reactive mode.

17 April. I met with Fred today to give him a project briefing. We talked about the schedule, budget, scope and the slides for the next steering committee meeting. As I described the fluidity of this schedule he asked for my recommendation on how to solve the problem. I said that the problem stems from the culture of this team. I told him I am working with Joshua to change expectations and behaviors. I see two key problems:

Communication is convoluted and often confused.

Behaviors are reactive rather than proactive.

I quickly described the way this organization functioned before I got here and contrasted the matrix chart we gave the steering committee and the communications chart that I recently drew. The functional chart, shown below, represents a traditional organizational structure. This is the structure that Joshua is accustomed to.

We are trying to impose project methodologies on top of this structure and assume the results should look like a standard matrix organization. If we did that, the results would probably resemble the matrix structure shown below. The disadvantage of a matrix organization is that the team has two bosses. The advantage is that the technical manager can focus on technology and the project manager can focus on project management. This is specialization and specialization is good because few people are competent with both skill sets.

The problem is that we are dealing with outsourcing on top of this. Thus most of the resources actually have multiple bosses within the organization that provides their paycheck as well has having multiple bosses within the organization that pays their organization. A structure for one project might look like the communications chart shown below.

The resources that work for our company have two bosses - per project. The resources that work for the off shore development company have at least two bosses in that organization as well as daily task hand-offs from our resources. The resources in the company that manages our data centers have at least two bosses in that organization, as well as the indirect management they get from our resources assigning work to them. Add on top of this the communication channels for incident management, change management, problem management and service level management and this gets even more complex. And then add on top of that the organizational communication required for the PMO, HR, Finance, Payroll and all those other support activities and the amount of communication that one person receives in a day becomes overwhelming.

The diagram, shown above, illustrates the complexity that people talk about within this organization. Now consider the diagram, shown below, that I drew a couple years ago for another customer. That diagram is a better representation of the true complexity involved within one IT project.

As the project manager on that project, I could request additional disk space by going directly to the Service Level Manager for UNIX systems. The technical manager could request storage space by communicating with the technical manager responsible for UNIX systems. The project team could request storage allocations by going directly to the UNIX administrators or by working through the Storage administrators. Problem management could escalate a problem to the Service Level Manager and trigger actions to add more disk space. Or, we could start with an email from one person to another person and then carbon copy five or six other people who each then added a couple more people and soon we all found ourselves joined onto a conference call taking an hour out of the day for twenty people as we tried to sort it all out.

The ITIL recommendation is to use roles to minimize these communications pathways. Storage space allocations should be proactively initiated by a Capacity Manager and handled behind the scenes so that the project team, technical manager and project manager never get involved.

One of the other reasons our communication is so complicated is that even this "Virtual Organization - Communications Chart" only shows the communication for this one project. Our resources and the outsourced resources also have other technical managers and other project managers tapping into their schedules to complete work on other projects. It is easy to see why communication gets confused. Simply put, the probability of getting it right when everything is communicated as clearly as possible is very low. So the probability of getting it right when there is any noise in the communication drops so as to become too risky to even contemplate.

Oh, and I forgot to mention that the data center resources are located in four countries, the off shore resources are located in four countries and even the steering committee is located on four continents. No wonder people get confused. Janice has more bosses than she can count. And Joshua's view of a simple functional silo became an illusion long before I got here.

Today, for example, we asked for a status update on the move to our new server. The data center manager has assigned a project manager named Diana to that project. Diana and I need to coordinate the work that Janice and Tim are doing. My project is paying for the equipment, but the data center resources want their orders to come from the data center project manager. Both of us project managers agreed on what to do during a conference call today, spent fifteen minutes persuading our internal resources that this is the right course of action, spent another ten minutes persuading the data center technical resources to do the work. Then it all evaporated when the service level manager joined the call at the last minute and decided that it sounded confusing to him so we better schedule a conference call to talk about it. We just had a conference call that he missed, just went through all the explanations, which he missed, and now we will need to do it again. Even so, that was progress. I then updated Joshua and he disagrees with the whole approach we are taking and fired off an email to one of the technical managers telling her to hurry up and get this finished. But all that does is add yet more confusion. Now that technical manager is going to go ask her technical resources for an explanation, give them orders that contradict the direction we were going and then spend time arguing with the service level manager before getting so frustrated that we will lose track of her for a couple weeks. Fortunately we have a recurring conference call and spend thirty minutes every day on this move. If we can just get five minutes worth of progress off each of those calls, then we should be able to wrap up this project before the equipment becomes obsolete.

18 April. The other tendency that impacts this group is reactive behavior. This was illustrated today in a series of events that disrupted what had been a proactive process.

We are planning to deploy a significant set of code this weekend. I sent notification to our user community last week. I followed up with emails containing more details about the planned change and then scheduled a conference call for this morning to answer any questions. I came into the office early this morning to do a few other things and to ensure I was prepared for that conference call. This was all very proactive.

One of those "other" things I needed to do was to join a conference call to get an update on Alfonso's project. When I got in I saw an email from Alfonso cancelling that meeting. Then I saw that Sam had scheduled a mandatory PMO briefing to start at 8:00am. I dialed into that conference call and was trying to understand the PMO mandates when Raj called my cell phone. Raj then conferenced in Janice. I now have a headphone on my right ear listening to Sam and an ear bud in my left ear listening to Raj and Janice.

Janice is scheduled to be the primary speaker in our conference call later today, but she forgot to check her calendar and is off-site right now for a class. We discussed our options and I stuck firm to holding this conference call today. We are only giving the users two and a half days to test and that is inadequate. Moving this conference call any closer to Saturday will give the users even less time to test. We agreed to proceed with the call and Janice agreed to step out of the class long enough to do her presentation on our conference call. Then she casually mentioned a small problem. The code is not done and the users cannot begin testing until she finishes a key interface.

My temperature started to rise but I was not sure if it was because of this news from Janice or if it was the conversation going on in my other ear. Sam had opened the session for suggestions and comments. The answer to the first suggestion was no. The answer to the second - no. No again. And then someone complained that they had not even been able to finish their sentence before Sam said no. Sam calmly explained that in the six months he has been running this PMO he has already thought about everything and there really is nothing that anyone could think of that he has not already considered. Then he again asked if anyone had any recommendations. Surprisingly a few young challengers had still not had enough. I visualized this like a medieval joust. The contenders queued up and one by one came charging forward, swords drawn, shields held high, banners flying. But alas, one by one each joined the ranks of those already crushed. Eventually this ear heard silence and I realized there was chatter in my other ear that could not wait.

Raj had added Tim to our conference call and asked Tim if he could help Janice by finishing up a very small amount of code in the next couple hours. Tim declined. Raj has even more patience than I do and did not volley back to Tim. I say volley because this is a game. There are four of us in this game - Raj, Janice, Tim and me. One of us is going to take responsibility for this problem. Raj can write the code himself, he can assign this task to Tim or can let it fall on Janice. The only other alternative is for me to tell the users that their testing time is going to be drastically reduced. I put the ball into play by reminding Raj, Tim and Janice that it is already Thursday in Asia so we have already shortened the testing window for those users to one day. We either need to be ready today or we are going to have to pay people to work on Saturday.

There was silence. Each contestant seemed to be trying to out wait the others.

Janice blinked first and agreed to leave her class, come back to the office and get the code finished. I owe her for this sacrifice. I am also going to remember that once again Tim has avoided helping our team. Raj and Janice then started discussing the details about this task, but I had to switch my focus back to Sam.

Sam was reminding everyone that he told us about certain changes we had to make in our status reports. Then he said that he had just compiled a report describing all the violations of his new verbal policy and he had forwarded that report to our directors and vice presidents. There was a loud commotion of protests but Alfonso silenced them all. Of course Alfonso remembered the precise directions given by Sam and Alfonso proudly described how his report was fully compliant. The question ran through my mind - how does Alfonso know that his report complies? Almost as one about ten project managers asked for whatever it was that Alfonso got from Sam. Sam explained that he was far too busy to spend time sending reports to us project managers. He suggested we each ask our VP for the list of errors in our reports.

Raj asked me if we were finished. I was barely even aware of what he and Janice had been discussing, but I have complete confidence in Janice's technical abilities. I said I was satisfied and we concluded that call.

The volume of noise in my right ear subsided at about the same time. Sam was now drowning on about how difficult his job is. I doubt there was a tear shed anywhere. The walls between this PMO and the project managers had suddenly chilled and ice was forming on the tone of the conversation. And finally Sam dismissed us.

Now where was I before this circus came traipsing through my virtual space? Oh yes, I was talking about the difference between reactive and proactive. Well, not finishing that code in time for the users to test has pulled us out of proactive mode and thrown us into reactive mode. Having double-booked herself has put Janice into reactive mode. Having the rules changed on us again while refusing to open the channels for communication has put nearly all the project managers into reactive mode. Fortunately the day is still young. We can recover from this.

When Fred and I talked yesterday he picked up on the theme of reactive versus proactive. I think he has probably been struggling to change this tendency among his direct reports. He asked what I was going to do and I said I was going to try to change the culture - starting with Joshua. He encouraged me to do so and wisely refrained from offering any advice. I think we are fairly well aligned. My challenge now is to try to regain some alignment with Joshua. Without some level of trust he is not going to pay any attention to my efforts to redirect him. And the trust in our relationship seems strained lately.

I was catching up on my notes from those simultaneous conference calls when I got an email from Tommy. He asked that I reschedule a meeting with him, Joshua, Alfonso and myself from today to tomorrow because something unexpected came up. I took this as an excuse to go see Joshua to work on our relationship. He was not interested in this gambit and started in again about why Tommy and Alfonso have to do this his way. I wanted this to be a relationship building session and instead I had to switch back into mentoring mode to remind him of the importance of collaboration and cooperation. "No, they don't understand our technology." "True, but they get to make the decisions anyway." "Well that's not right." "Agreed. So we need to persuade them that your idea is better."

I sympathize with him. In the same way that he wants to change this project, I want to change the PMO. I have some expertise in PMOs. Joshua is a brilliant architect. But those in power have decided to ignore our advice. Tommy is pursuing a proposal to get rid of Joshua's application. He thinks he has a vendor that will sell him all of Joshua's wisdom in a shrink wrapped box. If that happens then Joshua and his whole team will be expendable. That outcome is dreaded by some and welcomed by others.

Corporations make these decisions all the time. Some pied piper comes to town selling magic potions that will solve all the headaches now plaguing executive management. They buy his goods, and then the piper leads employees out the door. Sometimes the piper plays a tune called "obsolete" and old employees leave so new employees can come in. Sometimes the piper plays a tune called "layoffs" and employees are jettisoned to cut costs so management can pay the piper. And sometimes things work out just like planned and the piper plays a tune called "celebrate" to distract those who stay while the losers quietly slip out the back door. Joshua has fought numerous skirmishes with prior pipers. This one has him worried.

I left Joshua and went back to my cube. At the appropriate time I opened the conference bridge and greeted our user community. Out of 140 managers and technical leads on our email distribution only 15 showed up on this call. Janice joined a couple minutes late but when she spoke everyone was quiet. They know her and respect her talent. The ambiance was wonderful. There were a few questions and Janice and Raj answered each graciously. We were doing our best to look like a team and show our customers the respect they deserve. I crafted the agenda to build bridges first while burying the troublesome topics at the end.

We worked on the relationships. Then we reminded them about our technical talents. And then I gave them one small item of bad news. We were dropping one of our old interfaces, and would discontinue support in a couple months. They took it well. Everyone agreed that our new interfaces were much better anyway and all agreed that they could make the conversion. Then Joshua asked for clarification. Janice explained that the old interface was still operational even though we had released an update a couple months earlier. Joshua told her to drop the old interface effective today.

It is hard to get out of reactive mode and into proactive mode. Joshua reacted. We paid a price for that later in the day when emails started bouncing around among corporate executives. It does not matter whether or not his decision was right. What matters is the user perception of that decision.

The analogy I use to explain reactive versus proactive is anaerobic exercise versus aerobic exercise. When I miscalculated a bicycle trip one time I spent twelve hours peddling. Surprisingly, I could peddle for twelve hours. As long as I stayed aerobic, and as long as I kept refueling with easily digestible energy stores I was in balance. Human beings are designed for this type of activity. Maybe you do not spend long hours riding a bicycle, but have you spent a whole day tending your garden? Have you spent a day cleaning your house or maintaining your car? Human beings can work very long hours as long as they remain aerobic and focus on tuning out the stress.
When we plan and when we follow those plans we find a balance. We act like the tortoise that beat the fabled hare. Consistency. Relentless consistency. When planned well and executed accurately work is enjoyable. When we act like the hare we may think we are moving faster than the tortoise. But unless we stay on course we quickly squander all that extra effort. When I encounter a hill I need to add my anaerobic muscles to the effort. I cannot sustain that effort for very long. Once my anaerobic muscle stores are depleted my speed drops drastically. Aerobic energy stores can be stretched and extended by consuming carbohydrates. Anaerobic energy stores require more time to recharge. You might be able to run the vacuum over your carpet for a couple hours but you can only spend a few minutes at a time rearranging the furniture.

When we consistently act proactively we can sustain the effort indefinitely. When we become reactive we burn out. Today illustrated reactive patterns in several ways. First, Janice double booked herself and then had to scramble to recover. Second, not having the code finished on time meant that she had to work extra hard to make up for lost time. Third, rushing through that last bit of code means she did not take the time she really needs to think through what she is doing. That probably means we will find bugs sometime after this code is pushed into production. Fourth, making a snap decision on a conference call with customers listening conveys to those customers that we are a reactive organization. Fred picked up on this theme yesterday and said that being reactive is a spiral. Once your customers know you can act reactively they will expect it. And then they will demand it. Thus you get locked into this behavior and the system pushes you back into this behavior every time you try to change.

It takes an external input to disrupt the cycle and allow change. Project managers can fill that role. My goal is to disrupt this cycle and try to push this team out of reactive mode. That will be difficult. What I learned today is that there is less communication going on between Janice and Raj and between Raj and Joshua than I had thought. Also, the events of today have reminded me that Joshua, Raj and Janice are not digesting the emails that I send to them. No one can say that I am not sending enough emails. Even Dan, the director that used to be in charge of this project, commented that he is impressed by the volume of news I am disseminating. But it does no good to send all these emails if the key people are not reading them.

19 April. It took ten minutes of phone calls and hunting to get Tommy, Alfonso and Joshua to join me for our scheduled meeting to discuss the future architecture. The meeting lasted about two minutes. Tommy has decided to put our proposal for next year on hold, but authorized us to continue the activities that we are currently working on. Joshua agreed with this plan and asked me to follow him back to his cube to help with a diagram he is putting together for another project.

As we walked Joshua explained that he now realizes he cannot win this argument with Tommy. Instead he will support this effort while simultaneously trying to deliver results. This is an achievement response. He cannot counter the power that Tommy has so he will accomplish works that draw attention to his team. Perhaps that will allow his team to survive. And if Tommy should miss a step somewhere, then Joshua will be ready to show management his alternative. To get that chance, he needs to survive. And he can only survive by supporting Tommy.

I went back to my cube and joined yet another conference call. The purpose for this call is to review the detailed time line for the deployment scheduled for this weekend. This is critical to Joshua's strategy. All we need to do is to just keep scoring victories while Tommy's project is still a dream and Fred will eventually come around. This is easy. This is what Joshua's team excels at.

We started working through a checklist of tasks. Everyone agreed that the first several tasks were defined accurately. Then Bruce asked a few questions about the next task and it was like he had pulled a loose piece of yarn on a knit sweater. It was such an innocent question, rather like that one piece of yarn that protrudes just a few millimeters too far. But as he kept pulling on that thread our beautiful sweater began to unravel. And soon it was too late to do anything but agree that we were not ready for this weekend.

Raj and I went over to see Joshua to give him the bad news. He took it fairly well. He even commented that this will give us more time to test. Joshua today is thinking deeply about the long term. Joshua yesterday was reactive. Joshua today is on the verge of becoming proactive again. This is the team that I came here to work with. Sadly, Tommy's decision to cancel the planning for the next project means that my work load is going to decrease even further. I will give it a few more weeks and then I will need to start searching for another project.

20 April. I do not have much to do today. I reserve Friday mornings for one-on-one project status reviews with the team, but almost everyone has taken today off. I stopped by to say hello to Alfonso and we talked about work load. I told him that I am running short of work and he suggested I volunteer to help the PMO. I tried to explain my issues with this PMO but I do not think he understands. I drew the systems diagram I have been using lately to help people see the problem. He seemed to understand, but also seemed to think this is the way it should be.

Then I drew a second illustration of how things could be.

Can you see the difference? The first drawing is the traditional approach. The second drawing is my recommendation. Alfonso was not sure that just changing a few arrows on a diagram would change anything. What is your opinion?

In my opinion these diagrams show two simple changes. First, communication needs to be bi-directional. Second, communication needs to be networked and not sequential. In my opinion, changing the communication pathways will change the organization.

I once provided feedback to an author writing a book on portfolio management and the key feedback I provided was that all of the arrows on the communication diagrams needed to be bidirectional. I received a curt reply that this is not at all how a corporation works. Sadly, there is truth in that reply. But that does not mean that we cannot fix it. If, for example, Sam would listen to our advice then we would be more receptive to his decisions. But Sam is focused on power and that is a very traditional role for a PMO. Power is displayed by issuing orders. Communication is one-way only - until the project managers stop listening. Then there will be no communication.

The other problem is to realize that the culture needs to change. Just piling more regulations on the backs of the project managers does nothing to help the project team learn how to work like a team. When I meet one-on-one with the members of this project team I leave each with an updated printout showing the tasks assigned to them for the next five or six weeks. We discuss the list and I get agreement from each and every member of this team that those are exactly the tasks, in exactly the order that they will work on so that our project can move ahead. Now when I go back to see Janice mid-week and check on her progress, she will show me my list and tell me that she is not actually doing any of the work on that list. That highlights the problem I am having in getting Joshua to pay attention to the schedule. But at least Janice has her schedule and is cognizant of the gap.

When I check with Bruce he consistently tells me that he has misplaced the sheet of paper I gave him, but he is confident that he is doing the work we agreed on. This is both good and bad. It is good that he is focused on doing the right things. It is bad that he does not value the schedule enough to put it somewhere where he can find it.

However, when I check with Tim the results are very different. Consistently I go through his tasks with Tim on Friday. Consistently when I check back to get an update he has no recollection of our prior conversation. As I slowly jog his memory he vaguely remembers something about a project schedule. And if I wait a few minutes he can usually find the sheet of paper that I left with him. But if I ask any questions at all he is at a loss to understand. Tim is a free spirit. Schedules and emails and other tools of corporate America are lost on him. Tim will work on what Tim will work on and get it done when he does. My patience with Tim is running very thin so I need to stay calm. The problem is not Tim. The problem is the system.

If there was one Tim, then I would move him off my project. But as I participate in the conference calls run by other project managers I realize there are a lot of Tim's in this company. Goldratt gave them a name in The Goal - he called low performers "Herbie" (6). Like the poor, they are all around us. Like the poor, they will always be with us. What Goldratt suggests is that we alter the system to deal realistically with Herbie - or in my case Tim. I am careful to keep Tim away from the critical path. When something comes due and Tim has drifted off in another direction, then I escalate to Raj and move the task to someone else. In the meantime I am trying to awaken Raj to the problem he has with Tim. Now, if I was Tim's manager, I would have a serious conversation with him. However, this organization would not tolerate that from a project manager. Instead, I keep showing Tim the gap between the schedule and his actions. At first he was truly unaware there even was a gap. Now he senses that something is amiss, but he cannot quite figure it out. Maybe in a few more weeks he will understand that I have one very consistent theme. I expect that what is on the schedule is what will be done. And if that is not the case, then I need to know what is actually happening so that I can re-plan.

Tim thrives on the chaos in this organization. He plays the multiple bosses against each other. When I ask why work is not finished, he says that it is because Joshua gave him something else to work on instead. When I take him over and sit with Joshua then Tim remembers that there was other work that Raj gave him that delayed his ability to start on Joshua's assignment. If I follow up with Raj I typically find that Raj thought the work should take a couple hours and he is puzzled as to why it took Tim several days. My goal is to help Raj and Joshua see the game that Tim is playing. My secondary goal is to help Tim realize that just doing what I ask is easier than avoiding me and having me escalate.

At the same time, Tim is highlighting a problem with reality testing. People paint a picture and then motivate others to behave as if it is real. When done properly this is visioning. Tommy has a vision for a future state that excludes Joshua's product. Tommy is being successful today at leading others to implement that vision. Tim has a vision of working at his own preferred pace on the types of things he wants to work on. By portraying his work in a particular way he is being successful at getting by-in from Raj and Joshua. I am not convinced that Tommy's vision will work - but I will support him as he tries to achieve those results. I am very much convinced that Tim's vision is bogus and I am trying to get others to see just how bogus it is.

It takes effort to probe a vision and decide if it is likely to succeed. Joshua has spent considerable time exploring Tommy's vision and thinks he can poke holes in it. But that is not his job. I need Joshua to spend time poking holes in Tim's stories. Joshua, Raj and I need to share a common vision. Then Tim needs to join up with us or go find another project. This is the same choice that Tommy has given to Joshua.

**Skirmishing over Scope**

23 April. It was just last week that I finally locked down the scope on this project. Well, I thought I had locked down the scope. This morning I got an email from Joshua that we need to add another module onto our list of deliverables. I went over to talk with him and he suggested we have Tim work on this. I asked about the deliverables that Tim is already working on and Joshua looked puzzled. He had given Tim a different module to work on last week and is now willing to delay the work on that new module in exchange for this even newer set of code. I worked hard at staying silent. I agreed to look at the project schedule and see what I can do.

As I walked back to my cube I pondered the situation. As long as the scope keeps changing we will never finish anything. On the other hand, as long as Joshua keeps tossing these new items at Tim that leaves the rest of the team free to focus on the real priorities. Personally, I doubt that Tim will finish any of these tasks. But if allowing him to go chase after mirages keeps him away from my critical path, then I am not going to complain. Even so, I am not going to update the project schedule. One thing I have learned about this project is that if you just stand still long enough something else will change.

And sure enough that premonition proved true. Joshua, Raj and I met with Fred today to review the presentation for our meeting with the Steering Committee. As we looked over the slides Fred commented on the unpredictably of our schedule. I followed his lead and noted that at least we have a firm end date. "It will complete on the last day of this fiscal year. What I am not sure of, however, is what we will have finished by that date."

Sure enough, Joshua took the bait. "We know exactly what we will finish on that date." "I'm not so sure. For example, I am not sure we will be able to finish that new deliverable you described this morning." "Oh, you must have misunderstood. We won't start work on that new functionality until we finish all the work we already agreed to." And with that, Fred slipped in a gentle inquiry about our project change control process. I suggested that we tell the steering committee that the scope we showed them in our last meeting is the defined scope and assure them there will be no changes without their authorization. Fred liked it and Joshua had little choice but to agree.

That was a very subtle move by Fred. He opened with a seemingly innocent question, allowed Joshua to box himself into a corner and then allowed Joshua to confirm that he fully supports the decision. Maybe my scope really is locked down this time. We then discussed the blank space where I was supposed to have slides about our future architecture. Joshua and I recapped our two-minute meeting with Tommy in which Tommy said we should put the next project on hold. Fred told me to put some of the slides back in. I explained that I am concern about surprising Tommy with the resurrection of slides he thought he had killed. Fred smiled and said it should be an interesting meeting. Subtle. Fred is very subtle.

24 April. When my alarm goes off in the morning I think through what I want to accomplish this day and then I thank God for a new day. Those few minutes of thought get my brain focused and give me motivation to start the day. Today I came up empty. I would love to spend time on my book, but I need to get to work. I would really love to go see some of my friends or visit some of my relatives, but my morning is packed with meetings. It took a while to come up with a reason to reach for the light switch instead of just pulling the sheet back over my head.

I got to the office just in time for our daily phone call about that new system we bought a few weeks ago. We spent nearly an hour going through all the reasons why no one can work on this project. One by one we worked to eliminate those issues. I call this type of exercise "removing the excuses". This is just another corporate game. People line up excuses like bottles in an arcade then they hand you a basket of softballs and wait to see how many excuses you can knock over. My project funds paid for that system and I want it operational. There were no excuses left standing when I finished my turn.

Then it was time for the weekly CCB call. I only spoke on a couple issues, but I wanted to scream. How can people spend over an hour on this call and accomplish so little? Honestly, I do not care if the office in Philadelphia wants to swap option two with option three on their voice mail system. Nor do I see why it takes fifty of us to agree that the file server in Hong Kong should be rebooted to apply a security patch. These things should be delegated to the people responsible for those locations. Empower the people that will benefit from each change and unshackle the rest of us.

A while later I bumped into Bruce. After our change failed to get acted on two weeks ago he decided to dial into the CCB conference call himself and see what happens there. We talked for a while and both agreed this call is a waste of time as long as it is structured like it is. The people on the call are not the people doing the work. That means that the real issues are never raised for discussion. And it means that the flaws are not discovered until the technical people actually start the work. We both felt better knowing there are other people that think like we do.

That feeling only lasted five minutes before Raj came looking for me. Alfonso had called a meeting with Joshua, Raj, Tommy and one of Alfonso's developers. Joshua wanted me there. I checked the body postures when I got there. Joshua's arms were crossed and he had a scowl on his face. He looked like a wrestler trying to restrain himself from pouncing on his opponents. Alfonso and his developer looked tense and both had their legs crossed. That is supposed to be a defensive posture, like they expect Joshua to spring out of his chair and come at them. Tommy and Raj were calm and detached.

We went in circles for a while and I interrupted a couple times asking for an explanation about the problem. Eventually I gave up and accepted the fact that this latest confrontation is not about anything - it is just an opportunity for Alfonso's team to complain about my team and for my team to complain about Alfonso's team.

I took notes and came up with three action items. When it was done I asked Alfonso if he would send out meeting minutes. He said yes, but meant no. I persisted and Tommy authorized me to go ahead and send out the meeting minutes - with the provision that Alfonso review them first.

I ate lunch, sent Alfonso the meeting minutes and participated in a few more conference calls. I never did get a response from Alfonso, but then I never expected to see one. Either tomorrow or the next day I will annoy him a few times and then I will distribute those meeting minutes. They will be distributed.

Eventually I got in my car and started for home. I find myself switching from proactive to reactive. I am switching from being an instigator of change to a passive observer. I do not like this. As I drove home this evening an old Pete Seger song came on the radio as a remake by some new group. "To everything turn, turn, turn. There is a season, turn, turn, turn. And a time for every purpose" (7).

A few minutes later Nisi called. She had just interviewed for a new project and came away frustrated. She was telling me how difficult it is to explain project management to people that clearly do not understand what it is. To everything there is a season. She and I share a frustration that must be felt by thousands of other project managers. We know what project management can do for a company. We know that we can help the company and make life better for the people that work there. And yet, we end up taking assignments just to get a paycheck, feel frustrated at not being able to improve the situation and burn out trying to use project management in places that are not ready. This will change. There will be a time for every purpose under heaven. We just need to keep working at it. We need to trust that we are making a difference. We need to stay focused on making a difference. Maybe tomorrow I can get motivated again. After all, I really want to see the Steering Committee reactions when we get to the discussion about the next project. Now that might be a pretty good reason to get up in the morning.

25 April. I joined our daily conference call to discuss the migration to our new server. As is typical, Diana and I were the first two on the call. Diana is the project manager representing the data center. I offered a gambit and commented on the amount of confusion that distracts people on our projects. She seemed to welcome an opportunity to discuss her frustrations with the process. What she sees is that people use the confusion as an excuse to avoid responsibility. When she asks for status people tell her they had no idea those tasks were assigned to them. At first she assumed they were just making excuses. Now she is not sure. Maybe the problem is the way she explains things. Maybe her schedules are not clear enough. Maybe she needs to hold more meetings.

I suggested that people have so many tasks that they cannot get everything finished. They either ignore everything but the one or two things they want to work on, or they just thrash about trying to do everything and accomplishing nothing. Diana mentioned a couple tasks where people told her it would take weeks to do the work. Then nothing happened. But once it became a crisis all the work was finished in a couple hours.

"They knew they could have finished back on the same day that I gave them the assignment. But they sat on it. They did nothing. And then, wham, everything gets wrapped up in a couple hours and I am left hanging there. I have no credibility with my boss. If I escalate then everything is already finished by the time he checks into it. And if I don't escalate then the deadlines slip by and it is all my fault."

Janice joined the conference bridge, so we had to stop what had been an interesting conversation. I look forward to another opportunity to chat with Diana. She sees reality and wants to change it. We continued the call and eventually Diana's team joined. We are set to add this server to the network tonight. Everything is finally ready.

I stopped by to see if Alfonso had looked over the minutes I sent him yesterday. He said that as gentlemen there is no need for meeting minutes. Our word is our bond. I said I agreed and asked if that meant I could go ahead and distribute those minutes now. He said he would get back to me. We went our separate ways. I know I was muttering under my breath about how he surely does not think I am stupid enough to trust any verbal agreement with this guy. I assume he was probably muttering something to himself about there being no chance that he is ever going to agree to me sending out those minutes. Altogether it was a pleasant enough conversation.

Shortly thereafter Alfonso sent off an email to Fred complaining that we have already reneged on the agreement we made yesterday. From my point of view this is why the statements made yesterday need to be in writing. What I wonder is whether or not Fred actually believes what he reads in Alfonso's emails.

By then it was time for me to set up the conference room for our Steering Committee meeting. I checked my email quickly before leaving and saw an email from the technician that was supposed to do the change tonight to connect our new server to the network. There is some confusion so the change has been postponed. I do not remember hearing this person on the change management conference call yesterday. Clearly he has not been following this request for change as it as traversed the bureaucracy. But at least he detected the problem before he started the work. Well, this will be the topic for discussion on Diana's conference call tomorrow.

I took my laptop, got the projector and went to the conference room for the Steering Committee meeting. As is typical, most of the people showed up late. But Fred likes to start on time so I started even though only Raj, Fred, Tommy and I were present. I like to achieve things. This is my strength and my weakness. I can easily get lost in the details. Over the years I have been on numerous sales calls as a technical advisor. What I have learned out of those experiences is to focus on the real objective. My objective for today is to get this group to authorize the planning for the next project.

As I started through the slide presentation more people joined the conference bridge and others found seats around the conference table. The experience this time was rather similar to the prior meeting. Everyone had to chime in with one comment somewhere to demonstrate their expertise. The comments were directed to the topic and not meant as a criticism of anyone. All of this is good. Some of their comments are chatter and some are insightful. Like Joshua says, they all need to feel like they are contributing.

And then I came to the page that described the financial condition of this project. Here I am clearly vulnerable. We are running out of funds faster than planned and some of the biggest expenses have not traversed the financial system. My slide was copied directly out of the latest financial report because those numbers do not look as bleak as where we really are. I want to break this news to them gently. But sure enough, one of the vice presidents picked this slide to be her chance to shine. I dreaded having to explain why money is going out faster than planned, but I was as prepared as possible.

My prepared speech started playing through in my mind as I waited for her to slowdown. "We bought a new system because of a severe crisis that required immediate action. We have expenses that we thought belonged to Alfonso's project but actually belong to my project. And we encountered problems that meant we burned through part of our labor budget without being able to put modules into production. Our cost variance is negative and getting worse. But we are working on it. We have turned the corner and we should still be able to finish within budget. It is going to take a lot of hard work but as of now it is still achievable." OK, I am ready. When will she stop this diatribe?

As I came back from that momentary lapse in focus I was surprised by what I was hearing. She was not questioning the numbers, she was attacking my format. "I have never in my whole life seen such a ridiculous representation of financial data. This format is totally unacceptable. Are you trying to confuse us with this chart?" Fred intervened and asked if she had a suggestion for improvement. She made a few suggestions and I focused on writing it all down in my project journal. I focused hard. She became more irate and started berating me for the absurd layout of this chart. I focused really hard on making notes and did not dare look up. Deep down inside I was laughing my head off. This VP has picked this slide to be her challenge for the day and she does not even recognize that this is an exact reproduction out of the financial reports sent to her every week by our corporate finance department. She can accuse me of anything she wants and I am going to just keep on laughing inside because this senior level VP does not even recognize the standard financial report used by this company.

Focus. I just kept reminding myself to focus. Our goal is to get authorization to plan the next project. Nothing else matters. I cannot allow myself to get drawn into a confrontation now because we need her to join the clamor when we tell her the sad news about the next phase being put on hold. Eventually she ran out of steam and I assured her I would correct this problem for the next meeting.

A few slides later I got to the section on scope. I explained that we were resetting the scope back to that defined in the project charter, we were going to now lock that scope and would not adjust scope again without authorization from this committee. They were quiet. They knew there was something else I was not saying.

The next slide showed the list of modules that we discussed in prior meetings but were now being dropped. There were a few comments to just confirm that what they understood what I meant to say. Yet they still seemed to sense that there is more that I am not saying.

I went to the next slide and told them that all of those other deliverables would have been included in the next project, but that project has been put on hold. Tommy sat there very quietly looking like a cat that had just eaten a canary. Then he smiled. He knew what would happen next.

The best analogy I can give you for this situation is to think about a pride of lions on the prowl in the African savanna. They have gone a couple days without a meal and they spot a herd of gazelle. They savor the meal and carefully position themselves. They wait. They attack. They pick their victim and pounce relentlessly until it succumbs to their blows. This prey is theirs.

As they gather round the beast a lone project manager comes strolling across the grasslands, picks up the young gazelle and starts back towards the trees. At first the lions stare in disbelief. This has never happened to them before. They puzzle over the situation and seem perplexed. But they get over that quickly enough and as one the entire pride drags down that foolish project manager, retrieves their gazelle and carry it off to where they can enjoy their hard earned meal in peace and quiet.

It was pandemonium. How could a foolish project manager think he could withhold this functionality from a pride of vice presidents? They must have all those extra modules! Joshua explained that we are just following corporate guidelines to wait for questions about architecture to be resolved. The pride of vice presidents pounced again. And Fred stepped forward to lead them to the logical conclusion that, as much as we wish we could follow the corporate guidelines, clearly we will need to make an exception in this case.

We got what we came here for. I took a beating on several of the subsequent slides, but we got what we wanted. There is a clear mandate that we must do the next project. Tommy has no interest in placing his body between these lions and their prey. As a project manager I take this kind of beatings all the time. Project managers are adept at herding cats. Some of our resources are domesticated felines. Some are a bit wild. And some of the big cats behave aggressively. Project managers work with them all.

I talked with Tommy after the meeting and he suggested that he and I get together sometime next week to start planning the next phase. I look forward to that meeting. While I had his attention I mentioned that Alfonso had still not reviewed the minutes from our meeting yesterday. Tommy told me to go ahead and distribute the minutes.

Later I sat with Joshua and discussed the situation. From his point of view all the people who knew how to create things are gone except him. Most of the people that built the systems that drive this company were laid off and replaced by outsourced programmers and outsourced data center personnel. From his point of view, none of the remaining people know how to get things done.

From my point of view, what I see is that outsourcing eliminates the achievers and leaves the power brokers. Then, like in an arms race, the service provider needs people adapt at power to manage their side of the contract. They also squeeze out the achievers. I saw the same pattern when I worked for an outsourcing company

That company began with a few people who had some innovative ideas. I helped them achieve some of their early victories and then I went in a different direction. Years later I came back and worked there. I thought we had a mixture of motivations - power, achievement and affiliation. I focused on getting things done - achievement. Our sales force focused on closing deals - power. And some people just enjoyed life. During the "dot com" explosion there was plenty of money to go around and everyone found a niche.

When the "dot com" bubble burst many of our competitors went out of business. This company stayed alive, but went through some layoffs. First to go were those most focused on affiliation and the atmosphere became dark and dreary. Then achievement ground down to an abysmal level. We could not buy the software we needed. We could not buy the systems we needed. And it became harder and harder to accomplish anything. But during this time many of the people most adapt at power actually rose in the corporation. As our customers became more demanding it was more and more important that the person managing their account knew how to use power to get results. After all, we were not going to get results by releasing new software.

Yet even there I found islands of achievement amongst the fiefdoms of power. Perhaps the same tendency has happened here in this company as well. The groups that were achieving were laid off so that the service providers could do that work for a lower cost. A few islands survived. Joshua's group was not tempting enough to appeal to the outsourcers. No one understood what they were doing so they were left behind. Now Joshua speaks about achievement and accomplishment to an audience that prizes power. The translation is not always effective.

Personally I feel as out of place here as Joshua does. I want to accomplish things. This project is stalled and not accomplishing anything. Instead I find myself focusing on power. There is a constant power struggle between me and Alfonso. It is a constant battle of wills to get that new system up and running. Our communication with Tommy is all about power. Tommy is accomplishment agnostic. He has business needs and he just wants to check the boxes on his spreadsheet to say that each type of system is accounted for. He does not care if it is Joshua's system or a system that the pied piper promises to deliver. It is just a system and, to him, one system is just as good as any other. But to me and Joshua, it is the craftsmanship that goes into each system that matters the most.

Today's meeting with the steering committee was yet another power struggle. We got what we wanted out of that meeting. If I was focused on power, then I would claim this as a victory. But to me this is empty. This is lose-lose. We now have a mandate to plan the next project. I got that mandate by re-opening the discussion on scope. So once again we have no clear definition of the scope for this current project. Joshua is going to use that opening to slip more functionality into this current project. Then I will need to push again to trim scope so that we can finish on time. Tommy lost in his bid to trim scope by eliminating the next project. I lost my ability to manage the scope on this project. I do not like lose-lose.

I wish I could say that I have never before worked on a project where scope was so unclear. Sadly, I have worked on lots of projects where scope was defined retroactively. People just kept on coding until the deadline and then told the customers that whatever we finishes was exactly what we had planned to finish. This is absurd.

I find myself becoming more and more depressed as I struggle with the absurdity of it all. I thrive on accomplishment and I am not accomplishing anything right now. I am so de-motivated when I get home that I cannot focus on reading the last few books that I need to read so that I can finish off the final chapter in my book. Yet this book consumes all of my free time. I miss my friends. I want to just set this book aside for a month and go catch up on my social life. But I will persevere. I guess that even a modest possibility of finishing this book has such mental satisfaction that I cannot escape it.

The other reason that I feel depressed is that there is so little dialogue in this organization. Conversations with Alfonso and Tommy are pleasant, but they resemble a diplomatic exchange. None of us say what we mean and none of us mean what we say. All of the real communication is subterranean. Conversations with the steering committee are typically pleasant but in those meetings we speak the language of power. That is not my native tongue and I feel handicapped in those conversations. Nothing is open. There is no intent to level the conversation and treat all as equals. Those meetings are all about people trying to assert their superiority over others.

I honestly think that this company would be much better off if everyone would just say what they mean and then mean what they say. I also think this company would be better off if there was a more balanced mixture of power, achievement and affiliation. I do not have any idea about how to change this organization, so I need to focus on me. I need to open more conversations like the honest exchange that Diana and I started the other day. I need to take this opening to meet with Tommy and begin building trust so that we can speak openly to each other. And I need to keep working on my relationship with Joshua.

**Dialogue**

In the section called "Going Nowhere Fast" I examined the communication patterns and began experimenting. My hypothesis is that we have subversive communication polluting our communication channels. People do not say what they mean and they do not mean what they say.

The solution is "dialogue". I am firmly convinced that the problems with this "initiative" are communications problems. Thus I am going to stop focusing on project management and begin focusing on operations. I will continue using those project management tools that seem to work, but I am now going to augment that effort with the Six Sigma DMAIC approach. My problem definition is: "Communication about project scope is confused with the technical manager, technical resources, support resources, architectural resources and executive management each having a different concept of our scope." Now that "define" is settled, I need to work on Measure, Analyze, Improve and Control. To do that I am going to start two parallel efforts. First I am going to start collecting metrics (measure) so that I have hard data to analyze. Simultaneously I am going back to the book by Robert Kegan and Lisa Laskow Lahey called How the Way We Talk Can Change the Way We Work: Seven Languages for Transformation (8). I hope that the combination of DMAIC along with Kegan and Lahey's technique will provide insights into how I can change this operation.

Kegan and Lahey's technique begins with four probing questions. I do not want to detract from the full explanation you get in their book so I have restated their questions in my own words with my own focus. I recommend you buy their book and work through their exercises.

Question One: What experiences related to this initiative would help me grow? (9)

More dialogue with Joshua, Raj, Bruce and Janice.

More dialogue with Fred.

Better communication with Tommy and Tim while trying to open dialogue with each.

Question Two: What do I need to do to make that happen? (10)

Get the discussion about scope out in the open.

Build trust so that I can challenge us to behave differently.

Make a point of communicating with Tommy.

Expand the depth of my conversations with Fred.

Help Joshua and Raj with reality testing on this initiative and with people like Tim.

Question Three: What causes my internal conflict? (11)

Pride - I am used to being in charge as a project manager, a functional manager, a senior manager or an IT Director. I needed to come back to the role of project manager to have credibility with the recommendations in my book. But my pride makes it hard for me to live without the power that my role typically brings with it. I do not feel these people recognize the value a project manager brings to an organization.

Identity - I feel constrained by this role. Because my role defines who I am in the eyes of others I cannot get anyone to listen to my suggestions. At the same time I am constraining myself via this role. I am trying to avoid getting sucked back into coding. Also there is no mandate to change anything. I would need to step out of this role and I am not sure I want to. I am too busy right now just trying to unravel this problem while simultaneously writing a book. If Fred asked me to come to work for this company as a Director I am not sure I would want the job. While it would give me power by way of position, I would lose my identity as a project manager and I want to hold onto that identity long enough to finish this book. Anything less is cheating. If the premise of my book is that every individual in a corporation can change that corporation, then I need to prove that by being an individual and not an executive.

Fear - I dislike failure. When I write or teach I spend time researching and preparing to ensure I am right. In a meeting or conversation I sometimes say something that I later regret. Thus I hold myself back from speaking until I have time to think and plan.

Stress - This project is hard work. Analyzing this project to the extent required to write this book is even harder. And trying to change people is extraordinarily difficult and stressful.

Question Four: Why am I afraid to change this system? (12)

Pride - If I surrender my pride I am afraid I will lose my status. Thus I struggle with my pride as a project manager and feel that people do not respect that role. I think that the best way forward is to turn loose of this role and begin to delve deeper into the operational quagmire that envelopes my team.

Identity - I am afraid that if someone connects up this project with this case study they will either prevent me from publishing my book or sue me after I do publish. I am trying to mitigate that risk by fictionalizing the details and keeping the two separate. I am doing everything I can to protect the privacy of the real people while preserving the realism in the fictional characters.

Fear - I am afraid that I will swap motivations and begin striving for power. I could easily slip out of my detached state and once again become a materialistic seeker of status and power. I have chosen to use power as lightly as I can. I could coerce more of these resources into putting my project first. But I want their participation to come through their free will. I want to teach so that they see that my way is the best way. I want to learn so that I am open to see when their way is the best way. I would lose my detachment from the situation if I was drawn in more tightly. I would lose my objectivity if I had a bigger stake in the outcome.

Stress - I am already working three jobs: my real project, fictionalizing this project and doing research for my book. This has already crowded out most of my social life. And, quite honestly, I am mentally drained from trying to live the parallel existences of the real project and the fictional project simultaneously.

In conclusion - I need to focus on overcoming my internal resistance. Then I need to intentionally strive to change this system. I am going to try to change this system by focusing on dialogue.

30 April. The new server is still not added to the network. They ran into problems and have spent four days working on it. I updated Joshua and as we talked I sensed that we were finally transitioning from the Storming phase of team formation over to Norming.

It began simply enough. We talked. After a while Joshua agreed to reclassify some of this work as operations and he agreed to pull those tasks out of my project schedule. He acknowledged that this had been bothering him all weekend and said that he had also been trying to find a solution. This brings us closer to a matrix. He is acknowledging his accountability to the steering committee on project tasks but at the same time he needs a way to continue doing research efforts. He will manage those tasks himself. This is better for the project and it is a more logical arrangement. A win-win solution. It is also a good indication that he and I are beginning to synchronize our thoughts. Both of us realized this weekend that much of what is in the current project schedule is actually operational work. This was an excellent conversation.

I went back to my cube, checked my email, and found an illustration of dysfunctional communication. I had sent an email to Stewart, one of our system administrators, asking for status on vendor patches. His service level manager responded back to my email and told me that I had no authorization to assign work to his resource. This is an example of redirection. A magician, for example, shows you his open hand, waves a magic wand, and then shows you that the coin, or bird, or whatever has vanished. Those hand motions are redirection. He is diverting your attention from his other hand where the act of concealment is taking place. This email is a diversion to guide me away from the real issue.

I responded back to the service level manager with my own redirection. I challenged his understanding of the technology. This diverted him off into a thread of emails about the technology. Then I called Stewart and got the answer I needed to the original question. The answer, as I suspected, is that they are quite far behind.

This confirms that the earlier conversation was dysfunctional. I know the reality is that key patches have not been applied. And I know that the service level manager is trying to avoid that issue by raising other issues. If this was a project issue, then I would use project management tools like minutes and agendas and meetings to clarify this situation. Now that I recognize that this is an operational issue I switched tactics. I loaded all these facts into a table that showed the bug report data, the vendor patch numbers and the status regarding whether or not these patches have been applied to our system. Then I sent this spreadsheet off to the vendor for validation. Their representative added a few more patch numbers to my list and sent my spreadsheet back. I then distributed this spreadsheet and asked our outsourcer to provide a schedule for when they will apply these patches. I transferred that responsibility to them. This is not impacting my project and this is not my responsibility. I was careful in those emails to avoid any linkage to my project. But I am pushing this issue anyway because it fouls the communication pathways that my team needs. The subterfuge used to hide this issue blocks communication.

The technique I used in this exchange is called the "Neutral Document" negotiating technique. I created a document that simply states facts and contains no opinion. I validated those facts by leveraging the expertise of the vendor. I further validated those facts through phone calls to Stewart. And then I disseminated the document. I made no accusations. I ignored the earlier responses that told me there was no problem because arguing over those responses would close communication. My goal is to open dialogues.

I think I made progress today in opening a dialogue with Stewart. I tried to build on that opening later in the day when I pulled him into a conference call where people were ready to blame their issues on him. Dialogue requires that people be respected as people and not as objects. Blaming someone behind his back would treat him as an object. I got Stewart onto that call and he addressed their concerns.

I like the neutral document approach to negotiation, but it has been failing me lately. Maybe the problem is not the technique, but the fact that I am speaking project lingo to operational people. I wonder what will happen if speak operational lingo instead?

1 May. Raj called a meeting with key resources to get an update on whether or not our next set of code is finished. The answer was that it is not ready. Now I already knew that, but it surprised Raj. Raj and I then updated Joshua. Joshua was not surprised. He noted that any time both Raj and I come together we always bring bad news. But this time Joshua spent more than an hour with us trying to understand why this is happening. I gave him my analysis of his key team members.

Janice is an excellent programmer. She is dependable and hard working. But she has too many things assigned to her and she is thrashing about trying to do all of them. I suggested that we try again to get a comprehensive list of everything Janice is working on and then start taking assignments away from her until she can regain her focus.

Bruce is a flawless programmer. But he is flawless because he will not turn loose of his code until he has tested it beyond reasonable requirements. Thus he takes longer than budgeted to complete every assignment because he wants every module to be perfect. I recommended that we give him firm deadlines and then threaten to put the code into production whether he is ready or not.

A few of the other programmers are just struggling with overload. They are overloaded with communication and they are overloaded with assignments. Joshua is going to meet with each of them one-on-one and find out what is causing their perception of overload.

And then we talked about Tim. Joshua agreed that he is not getting results from Tim.

This was a fantastic conversation. We are finally getting down to the issues. And again I focused on being an operational manager and not a project manager. Joshua needs to address the operational environment and deal with his resources. My role here was that of a peer manager helping my friend diagnose a problem in his department.

When I got home this evening I did a quick survey of the metrics I am now tracking. First I have the data I am collecting on percentage completion and on the three-week average rate of progress. The data in that spreadsheet was illustrated some pages back. The charts included below show that data in a graphical form.

I mentioned earlier that I was also tracking delays on this project and trying to help Joshua understand the impact that scope changes are having on schedule. The third chart in this set, shown below, illustrates the way our end date changed during the course of this project. The line is plotting the end date on the vertical axis and the date when I made each estimate on the horizontal axis. Notice how the projected completion date finally settled down to match the end of this fiscal year. We are keeping it there by making exchanges. If something new absolutely must come in scope, then something old must go.

Time was finally defined when we agreed that this project must finish by the end of this fiscal year. Scope is now being managed against the constraint of time. I still do not know what is in scope and what is out, but I know that whatever it is, it must be finished by the last day of this fiscal year.

The third element in the triple constraint is budget. The evening was still young, so I called Mitch, my contact in Finance. I asked for his candid assessment about what is happening to my budget. What he said is that once Joshua told Fred that we are not going to do the software upgrade leaches began dropping out of the sky. These leaches are sucking money out of my budget. Both he and his vice president have tried to block these transfers, not to do me any favor, but because they corrode the financial controls around projects. However, since Fred is authorizing these adjustments there is little Mitch, his VP, Joshua or I can do to squash these leaches.

In a sense this is a sacrifice for the greater good. This project has some surplus funds. Other projects are over budget. Rather than make them look bad, which might make Fred look bad, we will share. Communism might have died off in the USSR, but communalism is doing just fine in the USA. Sharing is good. Of course Mitch could not just leave off with a cynical attitude. No, he had to push it over the edge and remind me that if my project does finally go negative then I will be fired. Everyone loves the word "fired". But I have heard it so many times lately that I do not pay any attention to it at all. What does it even mean? Are they going to force me to give up an intensely frustrating project where I am getting paid about half of what I was promised so that I can go somewhere else, work in peace and get paid a full salary? The word "fired" is nothing to fear. Instead, rather like the Christian belief in a life after death, I have been converted. I believe that my mortal life will one day end and then I will see the glory of God's kingdom. I now believe there will be life after this project and I no longer fear the end.

Even so, I am tracking the rate at which my labor funds are being consumed. Mitch was impressed that I have a chart that I update weekly to assess the rate at which employees are billing for "internal labor" and contractors are billing for "external labor". The trend line looks good so I have not delved any deeper. If I was more concerned, then I would go ahead and set up a control chart to track the weekly expenditures. For now, as long as the leaches focus on my software budget and leave my labor budgets alone, this project is going to come in within a few percent of the original budget allocation. Who knows, I might survive. They might even "reward" me with another project just like this. Mitch thought that would be poetic justice. Unravel this tangled mess of a project and the company will hand me another even more tangled mess as a reward.

Well at least I know where I stand on that issue. I then went back to my effort to inventory my metrics. At this point in time I have four charts. I use those diagrams to help people visualize what is happening to our project. But some data sets are clearer without the diagram. For example, there is a work flow I mentioned earlier with the following steps:

We find a bug in the vendor's software and report it to the vendor.

The vendor investigates and analyzes it until they can reproduce the problem in their testing laboratory.

The vendor creates a patch and sends it to us.

We put the patch into our test environment and prove that our problem is resolved. Occasionally the vendor fixes a side-effect rather than fixing our problem. When that happens the vendor goes back to their laboratory and tries again.

When the fix passes our tests then we need to move it into production.

This is a work flow. An ideal chart for monitoring progress through a work flow is the cumulative flow diagram. I am not using that chart on this project because the biggest issue here is politics, not productivity. The vendor is responding in a timely manner. But our outsourcer is not moving the fixes into production. Note that I did not say they are not moving the fixes fast enough. A cumulative flow diagram would show the rate of progress. Here there simply is no progress. The bug gets identified, the fix arrives, we test and confirm the fix and everything stops there. If I plotted this on a cumulative flow diagram then Stewart's magician boss would use my chart to create confusion. Instead I just use a simple table, like the one shown below.

Notice that the right hand column is blank. Not a single one of these patches has yet been migrated into production. A cumulative flow diagram would obscure, not highlight this issue unless you are already knowledgeable about cumulative flow diagrams. By itself, however, this table speaks loudly.

Another use for a table is the list of scope options that the steering committee will vote on in the next meeting. This table, shown below, lists the module, an estimate of the duration of the effort and the cost. Note that I am not showing the estimated labor hours. That number keeps getting us into trouble. No one on this team is working full time on this project. Instead, I calculated the number of labor hours per week that this team has been able to historically apply to this project. Then I prorated the estimated labor effort using the historic rate. The historic rate of effort so far is fifty-percent. Approximately half of each persons' time is charged to this project and half of their time is charged elsewhere.

I applied that factor to our inherently inaccurate task estimates because the same people that estimated this project also calculated the estimates for the next project. I know that some of those estimates show ten days on tasks that will only require two hours. I know that some of those estimates show one day on tasks will end up keeping people up late at night for a week or more. I cannot fix the inaccuracy in our estimating method. But, I can use the historic data to give me an average rate that compensates for the average inaccuracy. Historically we have earned value at approximately fifty-percent of what was planned. I took the labor estimates for these new modules, in hours, divided by the fifty-percent productivity rate we tracked so far on this project, and then loaded the resulting duration estimates into the table, shown below.

In our next steering committee meeting the vice presidents will get to vote on which of these modules they want in the next project. My guess is that they will vote for them all. After all, a pride of lions can never have too many gazelles. Then we will begin the real tussle. Which goes first? I can already tell you which two the operations people will want first. I know which two the analytics people will want first. It will be interesting watching the trade-offs they make to come up with the best sequence for the overall needs of the company. I trust they will do that well. They are amazingly well focused on doing what is right for the company.

After that I began focusing on our communication flows. Consider the two diagrams shown below. The first one represents my view of the communication pathways now used by our change management process. The second one illustrates the pathways I recommend activating. We need to bring everyone into the process. But we need to segment the communication pathways to reduce the noise level. It is amazing how many network technicians understand the importance of dividing an Ethernet network into segments without realizing that the same concept applies to people.

The next thing I did is to begin measuring communication effectiveness. I started with surveys for my meetings. The first survey consists of ten questions and if focuses on the structure of the meeting. This is simplistic. And yet even something as simple as this was hard to make work. When I emailed my survey people ignored my emails. So I then began handing these out at the conclusion of meetings and I kept people there until they filled it in. The questions I used are shown below.

Did you receive the invitation to attend this meeting in a timely manner?

Not early enough

So early I forgot about the meeting

The invitation came at the right time

This meeting was unusual in providing timely notification

Did you receive the meeting materials in a timely manner?

Not early enough

So early I forgot about the meeting

The materials came at the right time

This meeting was unusual in providing the materials in a timely manner

Did the meeting start on time?

The meeting started late and I had to wait

The meeting started early and I missed part of the content

The meeting started on time

It was unusual for a meeting to start on time like this one did

Were the right people invited?

Key people were missing from the invitation list

Too many people were invited

The right people were invited

It was unusual to see the right people on the invitation list

Did the right people participate?

Key people were missing from this meeting

Key people were present but did not participate fully

The right people were present

It was unusual to have all the right people present

Did the meeting follow the agenda?

The meeting wandered and did not follow the agenda

The meeting generally followed the agenda

The meeting followed the agenda

It was unusual for a meeting to follow the agenda as well as this one did

Was the agenda relevant?

The agenda was not helpful

The agenda was a good plan but it did not work out

The agenda was properly planned and used effectively

It was unusual for a meeting to follow the agenda as well as this one did

Was the meeting effective?

This meeting wasted my time

Not enough got accomplished during this meeting

The meeting accomplished all that should be expected

It was unusual for a meeting to accomplish this much

Did the problem get solved?

This meeting impaired our ability to solve the problem

This meeting did not contribute towards problem resolution

This meeting did all that should be expected towards resolving the problem

It was unusual for a meeting to accomplish this much

Do you have any suggestions or comments?

The measurements did not reveal much. Nearly every score on every question was a three out of four - a rating that indicates that we are doing acceptably well. If this survey had revealed a weakness, then that would need to be addressed. But there is a secondary purpose for this survey. I want people to begin to think about our communication. Then, maybe we can begin to insist upon effective communication. Towards that goal I created a second questionnaire. This one only has one question.

Which is the best answer? This meeting:

5 Resolved the issue

4 Facilitated resolution

3 Provided little value

2 Detracted from resolution

1 Stifled communication

I stacked fourteen of these questions onto a sheet of paper, made photocopies and cut those sheets into small individual questionnaires. I then started taking them to the meetings that I ran. In the meantime, I began rating every meeting that I attended. The results at the end of the first week are shown in the scatter diagram shown below.

The majority of our meetings actually accomplish something. Some meetings provide little value, but we can fix that. What hurts are the meetings that actually detract from forward movement. All three of the meetings that I rated at "two" this week were meetings where key people did not show up. This detracts from the work that we could have accomplished and leaves the team with the impression that this conversation is not important. Diana really struggles with this and two of those meetings this week were conference calls with Diana's resources to discuss progress on our new server. Three or maybe four of us would connect in, spend ten or fifteen minutes chatting and then hang up without hearing from the people doing the work. Later we would get emails from the very people that had missed the call saying that they had to abandon their work on our server because we did not give them the required information in a timely manner. This demoralizes the people that were there and were ready to provide the necessary information. It also means that more time then had to be devoted to rounding everyone up yet again for another conference call to do what should have been done on the first call.

The two meetings that I rated at "one" were both meetings where someone actually blocked communication. Rather than bring up any more of those stories, I suggest we think about the email exchange that I had with Stewart's service level manager. The intent in that email exchange was to prevent me from probing for information. Occasionally we have meetings where people display similar behaviors.

Personally, I would like to get closure on something. I would like to have fewer meetings and fewer conference calls and get things done. If that happened, then some of these meetings that now rate at "four" would move to "five" and lots of these meetings that rate at "three" or "four" would just disappear. That might happen if this team reaches the performing stage. For now, however, we need all of these meetings because people arrive with preconceptions. It takes time for them to realize that their preconceived design will not work. Then it takes time for them to work together to come up with an alternative. People can only absorb knowledge incrementally so we are forced to spread this thought process out over a series of meetings. We are fighting for synchronization of thought while traipsing through a quagmire of confusion.

In the meantime, I am going to see what I can do to push those meetings that rate at "three" up to a rating of "four". People cannot afford to waste their time and get nothing out of the meeting. From my perspective, our weekly change management conference call rates as a "three". I get nothing out of that call. Perhaps the corporate change manager thinks he is getting value by having us read the report to him, but I have not yet detected any improvement in the literacy rating among those doing the reading. Maybe we can automate this once text-to-speech gets a little better. We can all configure the software on our computers to read our requests for change to the change manager. And once speech-to-text improves then the change manager can just let his computer listen to our computers reading the report and his computer can type it all up into meeting minutes. The next logical step would then be to have the meeting minutes automatically delete themselves and the entire process could be fully automated, accomplish nothing, and yet do no harm to the environment. Well, that would be a nice improvement. For now I I am stuck with at least one meeting every week that is going to continue to rate "three".

The meetings that rate "two" are offensive. They damage our company. I plan to use my one-question surveys to focus peoples' attention on this issue. This needs to stop and it is going to take a team effort to make it stop.

Sadly the most damaging meetings of all are those that rate as "one" - and those are the meetings that are going to be the hardest to change. For now I intend to leverage my reputation for persistency until everyone that shuts down our conversation realizes they cannot make me go away. The problem is that those people who behave like this are the ones most likely to escalate over my head when I maneuver around them. On the other hand, I have nothing to lose. This "project" is going nowhere. The only way forward is to deal with our communication issues.

2 May. Only Bruce showed up for a design review session today so I had to reschedule. That meeting scored really low on my effectiveness ranking.

3 May. At 7:30pm last night Alfonso sent an email with handouts for our 8:00am PMO meeting. I might be the only west coast person that gets in early enough to see this email before the meeting starts. We are supposed to study this material before the meeting and come prepared to discuss it. I quickly glanced through the material and then dashed to the meeting, expecting the worse. I was surprised. Sam had organized a team of four volunteers to provide feedback and they had updated one of the templates. The results look good. The changes all make sense. And the meeting itself was more interactive and bidirectional than our prior meetings. This is good.

All during this meeting my PDA kept buzzing. When I got out of the meeting I scanned through my PDA and saw several emails and phone calls from Greg. In brief, he is ready to start his new project and needs me there today. I thought about the choices. I could really use that income. It is a fantastic project that would really draw on my CISA training. But I cannot just drop this case study project. And I cannot commit to several days full time on Greg's project when my schedule on this case study project is so unpredictable. I called Greg and told him that I need to decline. I hope I made the right choice.

When I got back to my desk I saw an email from Tommy. Sam had asked Tommy to come to the PMO meeting to do a presentation regarding architecture. Then at the last minute Sam told Tommy that the meeting was already overloaded with content and asked if Tommy could come back next time. Tommy decided to email his presentation to us. I looked it over and replied. Everything he described follows the waterfall approach. They have agreed to let us use the PMI framework now and only mandate RUP on pure software development projects. I asked about iterative development and mentioned my case study project as an example. Tommy replied that this is a traditional problem. Interesting response. His reply is open and vulnerable. I need to think about this. This just might be an opening for me to feed him a new approach. All I need to do is figure out how to solve this problem. That should be a great problem to meditate on during a long bicycle ride.

Speaking of problem solving, the hardware technicians replaced one of the network cards on our new server and it is finally functional. We still need to get our software installed and configured, but this is good progress.

**Bottom-Up Management**

4 May. Diana and I had a nice dialogue this morning. It was unfortunate that no one else joined our daily call. While we were chatting I got an email from Raj asking for an update on some tasks so that he could prepare for a meeting. I got off the phone with Diana, collected the required information and emailed it to Raj.

I then went over to conduct my weekly one-on-one meetings. Tim was there. I gave him the latest copy of the RAM and asked for his status. He said that he has no idea what I am talking about. He is not working on any of these tasks and has no plans to start on them now. I suggested he chat with Raj because the team needs his help. He gave the RAM back to me and I gave it back to him. "Hang on to this. These are the tasks that the team is working on." He dropped it into the trash and went back to surfing the internet.

Kegan and Lahey's seventh communication technique focuses on perspective (13). They challenge us to consider whether our interpretation of events is "the truth" or just our point of view. My point of view is that Tim is avoiding the assignments that I give him. I have mentioned before that I would like to have a serious conversation with Tim about this, but Tim reports to Raj. And there-in lies part of the confusion. Tim thinks he reports to Joshua and does not believe that Raj or I have the right to give him work. Joshua thinks it is clear that Raj is Tim's supervisor and I am the project manager. But Joshua has a tendency to bypass both Raj and me and give work to Tim. Now Janice, Bruce and just about everyone else on the team understand that they all have lots of bosses. Tim does not recognize that fact. More and more I am beginning to understand that Tim is not pretending ignorance. Nor is Tim pretending that he does not remember the assignments that I have given to him. Tim is being honest about the fact that he does not recognize my authority. To me, anyway, that is the issue that needs to be addressed.

I took a couple minutes to cool down and then went to see Raj. We had agreed that Raj was going to survey the team and give Joshua and me an update on what it is that everyone is doing that occupies so much of their time. My goal was to see the data he had collected from Tim and then setup a discussion with me, Tim and Raj. But Raj was on a conference call and could not be interrupted now. So I went over to see Janice.

I gave Janice the latest copy of our RAM and asked how she was doing. The look in her eyes said it all. She is on the verge of panic. She has so much to do that she can hardly even figure out where to start. And yet, she always gets everything done. She executes flawlessly, every time. And that is why she is overwhelmed. Given a choice between assigning work to Janice and Tim who do you think most people pick? Aside from me, no one wants to spend their time trying to get work out of Tim.

I continued on my rounds and found that Bruce was all tied up with the crisis du jour. I left a copy of the RAM for him to look over and I mentioned that we would talk about it in Raj's meeting in a couple hours.

All the other cubes were either vacant or the person in it was on the conference call discussing the crisis du jour. I wonder how Janice missed out on this one? I went back to see Raj and we talked briefly. He was frantically trying to get ready for a meeting. I asked if the material I emailed him earlier was what he needed and he had a blank look on his face. I reminded him that he had sent me an email asking for status on a couple tasks and I told him that I had sent back a reply. He groped about in his email but could not find it. "When did you send it?" "Right about 8:30am." "Was that today?" "Yes". More groping. Then he sorted his list by time of arrival and started scrolling. In the two hours since I had sent that email he had received nearly one hundred emails. The vast majority of them remain unread. At last he found my reply, opened it, looked it over and said thank you. I said that we need to discuss status on our project during his staff meeting today and he said that he was going to cancel because he was too busy today.

Those few conversations demonstrate how management of this organization has shifted from being led from above to being controlled from below.

People decide whether or not to participate in conference calls and meetings and have the option to choose. This impacts everyone else, but there are no repercussions to those who fail to participate.

People decide whether or not to remember which tasks have been assigned to them and whether or not they feel like working on them. This means that work spills over onto others, but there are no repercussions to those who avoid doing the work.

People who accept responsibility are quickly overloaded and risk burn out.

Reactive crisis management prevents people from proactive crisis prevention.

Communication overload prevents people from processing the information they do get. If Raj received nearly one hundred emails in two hours then he is receiving emails at the rate of about one per minute. No one can be expected to deal intelligently with that load. Key issues will be missed. Important topics will not get enough focus. Maybe this particular two-hour window was an anomaly. Maybe Raj only averages twenty emails an hour instead of one hundred. But even that is too much!

When I got back to my cube I did a quick check on the number of emails in my email folders. Last month I received 3,800 emails from our automated monitoring tools. With an average of 173 work hours per month that amounts to approximately twenty-two emails per work hour. I filter those emails and send them to a folder so that I can use them to support post mortem write-ups. Most of the team just let those twenty-some emails per hour flow into their email in-box and add to the clutter.

Over the past several weeks I have averaged twenty scheduled meetings per week. That is an average of four scheduled meetings per day. Add onto that the numerous impromptu meetings where we just gather in someone's cube, or where a simple phone call turns into a conference call and it is no wonder why people have so little time available to work on this project.

And thus I illustrate the most devious problem of all. As I was rambling on about email overloads, meeting overloads, work load overloads, etc I completely forgot to talk to Raj about the continuing problems with Tim. Whatever. It is not like Raj has any time today to focus on the problem. Sadly, Raj is in the same spot as Janice. Raj is reliable, dependable and conscientious. And thus Raj is buried so deep in tasks that he cannot focus long enough to change the situation. It is as if he was so busy mopping the spill on the kitchen floor that he cannot even think about turning the knob on the kitchen sink to stop the water from spilling onto the floor.

7 May. I followed up with Joshua to discuss the RAM. I asked him about the work that Tim was responsible for and Joshua told me that he is personally managing Tim's work load. "Go ahead and remove him from those tasks." "But he is the only person with the privileges to connect to the servers where we get our test data." "Well then you need to leave him on those tasks." And thus we find that "reality" is not Tim's view, my view, Raj's view or Joshua's view but some variation on those themes. I need to keep resurfacing this topic until we get to the point where people know what it is that they are supposed to do and managers all communicate the same expectations.

In the mean time I went back to work on my metrics. I mentioned earlier that email is a problem so I took my prior two months of email and copied it into an archive folder. Then I sorted it. From that I was able to determine that the single largest generator of email is our automated monitoring tool. I used tools to count the number of alerts per week. Then I plotted them onto a graph similar to the one shown below.

The good news is that we are trending downward. I summarized my observations and sent this in an email to Joshua. He replied without digesting the content so I replied back to try to get him to test reality. We are not trending downward because of a change that Janice made last week. We have been trending downward for nearly two months. All of the hard work that everyone is putting into resolving our production issues is paying off. The system is becoming more and more stable all the time.

I gave him a little time to digest that and then I sent over another email with a graph showing the volume of email I have received each week during the past two months. Even after the improvement in the volume of email from the automated monitoring tools, my average is still about one thousand email per week. For a forty hour week that works out to about 25 emails per business hour. Now if I am getting 25 emails per hour as the project manager on one project, imagine how many emails Janice and Bruce are receiving as workers on multiple projects. And from there is it easy to see how Raj received one hundred emails in two hours. I described this problem in my email and recommend that we start by reducing the number of emails we send to mass distribution lists. Raj replied back with a few other excellent suggestions. Suggestions are great. Now, will we follow up and make this happen?

By then it was time for another conference call. Diana had invited the system administrator for our new system to talk about the operating system patches he needs to apply. I expected this to be a meaningless meeting and I was surprised when the system administrator actually showed up on the call. I was even more surprised that the system administrator came prepared, asked the right questions, we gave him the right answers, and he finished his work while we were all on the call. I thanked Diana. This is the first conference call I have been on in several months where we resolved the issue while on the call. Diana scored a "5" on my one-question meeting evaluation form.

From there I went off to one of our design meetings. I took updated copies of the RAM with me and gave everyone a copy. Tim and a couple of the junior programmers were missing, but everyone else agreed that these are the tasks they are working on and Joshua and Raj agreed that these are the right tasks for them to be working on. This is significant progress. While no one seems to understand a project schedule, they all seem to comprehend the RAM. And, for this type of effort the RAM might actually be a better representation of reality anyway. Like many iterative development efforts, work on this project is done by a swarm of people not by individuals. Janice might pick a task, and then hand it off to a junior programmer. Bruce might start a task and then discover that he needs Tim to get test data for him. The team shares the tasks. A RAM allows you to display that. A project schedule can show that as well by only tracking milestones. But even when I reorganized the schedule to only report milestones people still seem to have a harder time reading a schedule than they do a RAM. Thus I am committed now to the RAM as my communication tool for status updates on this project.

We spent about fifteen minutes discussing the RAM and reviewing status and then jumped into the design. We were there just over an hour. Janice inadvertently highlighted our email problem for us during this session. Normally she clips her PDA onto her belt but today she wore a beltless outfit. She had no place to attach her PDA so she set it on the conference table. It buzzed at least fifty times during our meeting. Even Joshua commented on how frequently it was buzzing.

Everything is iterative. Helping people adjust from their prior view of reality to a new vision takes time and effort. We made great progress today on project status tracking. I have learned that the RAM works for this team and the project schedule does not. The team has learned that the RAM is a tool that gives their managers visibility into the work load they are all carrying. Joshua has seen graphics on our email problem and those graphics and emails opened his ears to hear the buzzing of Janice's PDA. I have no doubt that his own PDA buzzed even more frequently than Janice's did, but he has become immune to the buzzing of his own PDA. He recognized the problem that Janice's PDA indicates.

I went back to Bruce's cube after the meeting and we finally had a chance to get caught up on some of the status updates I needed from him. While we were chatting I asked if he knew how many emails he gets in a typical day. He thought about it for a bit and then he remembered that he had over 4,000 emails in his in-box when he got back from vacation a few months ago. That works out to 50 emails per hour when spread over ten business days with eight hours in each.

8 May. Today we ran through a drill that demonstrated how reactive we have become. Our new server has more system memory than does our current server. Joshua had looked over some of our tuning parameters and decided to increase the amount of buffer allocated to our application. But rather than wait until we move to the new server our system administrator made this change last weekend. Today we realized that our system performance was suffering. We pulled several people off their normal work to run diagnostics to try to figure out what was wrong. Then it took a couple conference calls before we connected up with the system administrator and he remembered changing that parameter. We cannot change it back until the next maintenance cycle and our system response time is unacceptable right now. Since we cannot increase the amount of memory in this system we needed to find jobs that could be stopped so that more memory would become available for our application. Eventually we killed off enough jobs to get the system back to "normal". This weekend the system administrator will reset that parameter. Once again the team members are all heroes for their awesome technical abilities. Of course, only you and I and a small number of other people will ever know that we actually inflicted this crisis on ourselves.

9 May. During our project meeting today I pushed on three points. First we cannot fail to get this latest set of code successfully deployed into production this weekend. Second, we gave Stewart a firm deadline by which he must put the vendor patches into production. And third, I got verbal commitments from the team that the work on the RAM is what they are doing.

My first point was more of a pep talk than anything but it is important to keep reminding everyone that we now have less than sixty days before the fiscal year ends. Getting closure on the second point came down to me bluntly telling Stewart that this is mandatory. Bruce backed me on this and I think we can make it stick. Getting closure on the third point was easy with everyone except Tim. Once again Tim started off by saying he has never heard about these assignments and then he started listing the reasons he cannot work on them. Raj politely reminded him that they had already had this conversation and Tim had already agreed to work on these tasks. Tim then did a quick u-turn and said that of course he was already working on all of these tasks and he does not know why I keep bringing it up. I wonder if it will be harder to get Tim or Stewart to fulfill their commitments? Well, the important thing is that both are now on record as being committed.

As I was driving home I heard a news story about one of the other companies where I had interviewed. It was the most solid company with the best job offer. But that project had not looked like it would make a good case study. Even so, I still wondered if I would have been happier if I had gone there. The answer is now clear - they announced massive layoffs tonight. Contractors and new hires always go first.

10 May. Last week I realized that the solution that would allow Tommy to define a project management framework for iterative development is to use the steering committee meetings as the supervisory process. I had been so busy this week that I did not have time to put that into an email until this morning. I wonder if he will reply to this or to my offer to meet with him to get his feedback on our proposal for the next project. I will keep searching for openings to build dialogue.

I next checked my survey site for responses to my latest survey. I asked our 130 technical leads to provide feedback regarding our product. Very few people have responded, but the results align well with our expectations. I plan to include these responses in the next steering committee briefing as they will help justify the next project.

Most of the rest of the day went as most days now do. I bounced from conference call to conference call with an occasional meeting sprinkled in. And every once in a while we all put on red hats and ran in circles pretending to be firemen while we dealt with whatever crisis now has our attention. It is all becoming repetitively boring.

We did, however, make a small bit of progress related to communication. We had a conference call last week with a couple key users to clear up some confusion about our current functionality. I set up a follow up call today and invited additional users. It was interesting listening to the confusion. Joshua reminded them all that he has conducted multiple briefings to give them updates. He also reminded them that I am now publishing a monthly newsletter and that we have a web site where they can go to get the latest news about our project status. Most likely they are all just as overwhelmed with emails and meetings as we are. But they attended this meeting and they learned more about our application. In turn, we learned more about their assumptions. I documented this in meeting minutes and I sent the minutes from the prior meeting and this meeting to everyone that attended as well as our project team and Fred. This is good communication. We were all surprised at the gap in knowledge. Since these conference calls seem to be working I will continue scheduling them for the next several weeks.

**Specialization**

11 May. My status checks this morning were abbreviated. Everyone reports they are ready for the deployment scheduled for this weekend and yet everyone seems frantically busy with last minute preparations. Everyone, that is, except Bruce. As usual, Bruce is an island of calm. He even commented on the fact that we probably could have moved his code into production a couple weeks earlier.

When I finished those one-on-one sessions it was time for a meeting to work on the design for the next release. Joshua, Janice and I were the only three that could pull away from the deployment preparations to work on this design. It was a good session. Afterward Joshua and I spent some time talking about the tremendous commitment that Janice makes to this effort. Joshua noted that she is overloaded. This is fantastic. He is seeing the symptoms. Then he asked me to ensure that the schedule for our next project builds in more time for each deliverable. This is wonderful. He recognizes that this project was poorly planned and now he wants to do better next time. I believe he is realizing the value that project management can bring to the effort to build his application.

When I ran out of work for the day I went home and prepared for a nice bike ride. I was only about ten miles out when I got a flat tire. I changed the tube but my air pump would not inflate the tire to the proper pressure. So I rode slowly back to a bike store I had passed a mile earlier and bought a new air pump. I got about ten more miles down the road when my rear gear cluster came loose and only the middle gears would engage. So I peddled slowly about three miles further out to the next bicycle shop and asked the mechanic to look at it. He said this was rare, but once in a while the gears rattle themselves loose. He popped the tire off the bike and reassembled my rear gear cluster. By then the time I allotted to this ride was consumed so I turned around and went home. Altogether this was a nice reminder of how dependent we are on specialization. My ability to ride my bike depends on shops that sell parts and mechanics that know more than I do about bikes. Joshua's ability to build his application is dependent on the technical skills of Janice and Bruce and on the availability of Tim, Stewart and a host of programmers. And, at long last, Joshua is recognizing that the specialization of project management adds value to his efforts.

It is possible that the system is changing. I have found tools that this team understands - like the resource assignment matrix. They have learned that a RAM is not a club project managers use to beat the recalcitrants, but a lever they use to manage their workload. I am getting their attention regarding the overly optimistic commitments that were made regarding our release cycle. They are learning to speak up and tell us what is possible and what is ludicrous. I know they are still padding their estimates, but I have learned that they are actually not padding them enough to account for all of the chaos. We have learned that the prior communication to our users was inadequate and we have learned that even the significant increase in communication that I implemented is still not as effective as it needs to be. We have more dialogues open now than ever before. And yet, communication is still confused.

Perhaps the deployment this weekend will go smoothly. Perhaps my increased use of metrics will help the steering committee understand the urgency of our next project. Perhaps this team is learning the value of project management. All of this is good progress. My one concern is that I am losing my detachment.

When it turns out that I am one of the key people in our design sessions then I have slipped out of my role as a project manager and I am drifting back into a design role. I am going to need to make some decisions fairly soon. The fiscal year ends in a few more weeks. Do I want to try to find a home here while waiting for funding on the next project or is it time for me to start looking elsewhere? I see advantages to staying here and continuing my efforts to change this system. On the other hand, a system will only tolerate so much change before pressures build to restore the prior balance. Am I now at the peak of gain? Will all that I now see as progress be wiped out when the system strikes back? Or, has this change been gradual enough that people are comfortable with it? I wish I knew.

14 May. The deployment of our new modules executed on schedule this weekend and promptly ran into problems. Some of these modules were two months past due. Most of this code was finished over a month ago. I had persuaded Joshua to give the team more time to test and I believe that time was well spent. But once the code was moved into production more bugs showed up and several people worked through the weekend to resolve the most critical of those bugs.

The tension between my hopes for this project and our ability to deliver is becoming troublesome. I can help this team learn about project management. I can help this team improve their communication practices. I can persuade Joshua, Fred or even the steering committee that more time is required for testing. But just giving this team more time is not enough. They are so distracted with so many other priorities that they cannot focus.

I could insist upon a written test plan and then insist that it be followed. But I doubt that will succeed. The gap between where we are now and what is required for a mature process is large. This was dramatically brought home today when one of our users opened a conference call to make sure we understood the impact these new bugs are having on the business. The conversation was wandering so I stepped in and got everyone's attention by bluntly stating that we had better solve the most critical of the remaining bugs quickly or we will be forced to pull this new code out and put the old code back in. Joshua was furious, but someone needed to point out the obvious. Eventually we agreed to an alternative, yet I am skeptical that we can get the right people focused enough to resolve this bug before it gets escalated.

After that call I took some time to reassess. Basically, I have run out of ideas. This project is floundering and I see no way to fix it. The only hope I have left is that we can do better on the next project. Perhaps specialization will help. I included two dedicated testers in our proposal for the next project. My goal is to keep those people isolated from this chaos and then hold them accountable for finding the bugs before they get into production. For now, however, that is just a dream.

On the positive side, Tommy called a couple hours later to thank me for speaking up on behalf of the users. I appreciated the time he took to call and it was gratifying to hear how much he values my opinion. He reiterated the appreciation our users have expressed to him about the status updates, newsletters and conference calls I initiated. He also let me know that the clock is ticking. Either the hurried effort to solve this bug is going to produce results by tomorrow night or the users are going to demand that we revert back to the prior version of our code. If that happens we will be even further behind schedule.

As I pondered the root cause I realized there are multiple issues. First there are issues regarding process maturity. We do not have optimized processes (level five). We are not following best practices (level four). We are not following repeatable processes (level three). We do not even have processes (level two). Basically we are at maturity level one or below and we need to work our way up to at least level three.

The second issue we face is push back. I agree with Robert Fritz that the harder you push for change the greater the resistance (14). Our users want more change. But Joshua wants things to go back to the good old days when he was not accountable to the users. It is going to take a lot more work to avoid losing what progress we have already made. I want to avoid the rebound that is typical in an oscillation pattern. Fritz notes that the rebound is not an expression of the team's desire to return to the prior state. Instead the team is acting in a manner consistent with the system they live in.

"In fact, they (the team) usually are responding to other forces in play, structural forces that are not of the individual's own making: conflicting rewards and penalties, conflicting loyalties, unclear direction, mixed messages, and so on." (15)

"Process maturity" and "push back" are organizational issues. My third and fourth issues are personal. Issue number three is my attitude - I am discouraged and not sure I am interested in continuing to push this hard for so little result. I can send out newsletters. I can host conference calls. I can publish status reports. But none of it means much of anything because we are not delivering usable code on time.

Also, I feel like I am fighting a losing battle in my efforts to improve communication. Today, for example, I hosted a follow up call to get a status update regarding the users' ongoing struggle with the fallout from the changes we made this weekend. Tommy was there to represent the business and we discussed the business perception of the problem. Most importantly, we discussed the impact this problem is having on our ability to sell products. We started exploring options for improvement. And then Joshua bluntly told Tommy that we are not changing anything. "It is not my problem that you weren't prepared for our change." "Joshua, all we are saying is that these changes are impacting sales." "Then you should get busy addressing those problems instead of wasting my time on conference calls." "Joshua, if we cannot resolve these problems fairly soon, then we need to think about withdrawing these changes until we have a solution in place." "Tommy, I am not withdrawing my updates. You need to deal with it." I am not sure that I want to spend any more of my time trying to bridge the gap between Joshua and his user community.

At the same time I am concerned that this third issue is not the real issue. I have the feeling that my pride, the forth issue, might be the biggest issue of all. I do not like being associated with a project that is going so badly. Nor do I want to put effort into something with so little achievement. And I am getting completely frustrated at the spot I am in as the project manager for this project. I feel like I have almost no ability to control this project. I have tried to express this situation in the evaporating cloud shown below.

Fritz has a similar diagramming technique. Looking at this situation as a structural conflict I used Fritz's technique to come up with the diagram shown below.

As my friend Pia noted, this is an infinity loop - which she quickly sketched as shown below. In that one observation Pia summarized my frustration. Every cycle through this process drains my energy and diminishes my enthusiasm - and this loop is going to run forever.

Fritz also has a great allegory in which he describes an organization as an orchestra (16). In his allegory the musicians are the team. Their instruments and talent are the skills they bring to the effort. The musical score is the plan and the conductor is the change enabler.

I see weaknesses in each aspect of our implementation of Fritz's allegory. Our musicians are trying to perform in multiple simultaneous concerts. The music in each concert is challenging and trying to perform multiple pieces simultaneously is beyond the skill level of most of these musicians. At least one of the conductors does not like using sheet music. I am supposed to be conducting this orchestra in a new, highly complex work. I cannot get these musicians to look at the music that I give them partly because they see no value in having sheet music or project plans or any other type of documentation. The other reason they do not value the music I provide is because Joshua continues to simultaneously direct them on a different musical work.

15 May. I met with Fred today and he is frustrated with our lack of progress. We talked and I explained that the technological challenges are much bigger than anyone has acknowledged. I also described the problem I see with multitasking. Fred is going to schedule meetings to ensure Joshua is aligned with Fred's goals.

The remainder of my day was devoted to facilitating conference calls to start dialogue so that we can resolve the problems we introduced over the weekend. Our users are very frustrated and they are escalating their frustration up the management chain. I gave Fred a quick overview in anticipation that this will eventually come to him.

16 May. The users escalated over Joshua's head and gave him orders to begin preparations to withdraw our latest code deployment. I heard the orders being given. I heard Joshua agree to do as told. After the meeting I saw no effort to fulfill that commitment. Each of these incidents shifts the corporation further away from Joshua's vision and closer to alignment with Tommy. My last conversations with Tommy and with Fred have convinced me that management has a basic understanding of what is happening. They are not ignorant, they are just patient.

I went back to my cube and saw an email from Alfonso. He wants an update on one of our deliverables. He says he already got a reply from Joshua and now he wants my opinion. I am not in a mood today to play games with Alfonso. I sent back a reply and said that the particular deliverable he is searching for was due two months ago and is now in limbo. "Since we only have about four weeks left to finish our deployment, I honestly do not know whether or not this code will be finished as part of this project. The work on it might need to wait until we agree to fund the next project." I did not hear back from Alfonso, but I expect he will forward my email to Fred.

Later that day Fred followed up on our conversation from yesterday and called a meeting with me, Joshua and Raj. The conversation focused on our project status and that deliverable that Alfonso needs came up in the conversation. Fred asked for an explanation of the actions we propose to take to solve our problem with schedule slippage. We all agreed that multitasking is a problem. I described some of my observations, and Joshua agreed that there are other projects distracting our team. But no one seemed to know which of the other projects is trivial and which are major offenders. We brainstormed and I offered to tally up the time allocations for the past four months to document where the team is spending their time. Fred thought that was a good idea and suggested that Joshua then transition more of the support work over to the outsourcer. Fred described a process for documenting those tasks and then transitioning them gracefully.

This was a good meeting. Fred simply painted a vision for what he wants and allowed us to buy into that vision. Then we worked through an analysis of the gap between where we are and where we need to be. Then he asked for our recommendations. I like his style - participative, and yet guided. He made it clear that he will take action if we cannot resolve this ourselves. Yet, he gave us the freedom to find our own solution.

We left there and Joshua called a team meeting to relay Fred's concerns. Fred's guiding principles were translated by Joshua into concrete actions. Joshua bluntly told his team to stop all support work immediately. I asked if that was an effective transition. Joshua replied "Fred wants us to stop doing support work." "But the outsourcer has no clue as to how to maintain some of our software. If we just stop answering the phone without doing a transition I am concerned this will impact the business." "You heard Fred. We need to get this project back on schedule now." We talked some more and Joshua told the team to do their best to minimize the impact on the business.

I wonder exactly what that means. I also wonder what this is going to buy us now. Can four weeks of frantic effort allow us to finish the six months of work we have left to do? My "fight" tendencies seem to be stronger. More and more I am in direct confrontation with Joshua. More and more I am coming into alignment with Tommy's vision. I have reached the point where I no longer believe in this project. My quest now is to find a solution that will address the business need. Tommy's proposal to just terminate this effort is as drastic an action as was Joshua's directive to terminate support activities immediately. The business will suffer if either of those actions happens. It is not my problem as a project manager to redefine corporate strategy. It is not my problem as a virtual operations manager to set strategy. But I cannot just walk away from this without giving it my all.

17 May. Greg called. He needs my help on his new project and he wants me to consider working full time as an employee. Today that offer is really tempting. Maybe "flight" will win out over "fight". In the mean time I finished my analysis of the prior four months of time accounting. The breakdown, shown below, reveals a lot.

35% of the team's time is focused on my project

15% of the team's time is charged to administrative tasks

15% of the team's time is devoted to other projects

35% of the team's time is going to production support

First, the team is spending 35% of their time on my project. The project proposal put together last year anticipated key contributors working 75% of the time on this project. My prior analysis of productivity indicated this team was earning value at a rate of about 50%. So this is both good news and bad news. The team is putting in less time than budgeted and yet producing more results than should be expected for that amount of effort.

Second, 15% of the team's time is too much time on administrative tasks. This is an indication of the amount of time the individuals are spending on training and days off. It might also be an indication of the amount of time these people need to spend on keeping up with their email backlogs and meeting overloads.

Third, 15% of the team's time is going to work on other projects. This is a much smaller number than I was expecting to find. It is difficult to save much out this. The team needs to participate in the planning for other projects. And if they are spending no more time assisting other projects than they are spending on administrative tasks then this does not seem to be the area we want to focus on.

It is the fourth area that needs more exploration. Putting 35% of their time into supporting production applications is too much since the outsourcer is supposed to do that work. Joshua hit the target in his discussion with the team yesterday. He did it by instinct rather than through metrics. But whether or not he guessed right, I still do not agree with his approach. In my opinion, our discussion yesterday typifies the problems I see. First, the reaction occurred immediately without analysis or data. Second, there was insufficient communication to the team for them to understand what it is that they are actually supposed to do. Third, there was no communication to the other parties that will be impacted. And that leaves me with the impression that once again there will be no follow through. Consider, for example, the list of issues that I am now tracking.

In our first meeting with the steering committee I was asked to assemble system performance metrics into an executive dashboard. I was almost immediately hooked into the email distribution used by one of our service level manager to provide weekly reports on the systems managed by his group. After three months I still cannot get the service level manager for our other servers to put me onto a distribution list. It typically takes me multiple emails and multiple phone calls to just get a response. The response is always a serious commitment to make it happen in a couple weeks. But it never happens.

I already mentioned the list of patches we received from one of our software vendors and the difficulty I am having in getting our outsourcer to move those patches into production. Last week I got a commitment from them that they will do the work next week. This week they told me they want to postpone. It takes me more hours per week to pressure them to do the work than it will ever take for them to actually do what I have asked.

We had a meeting with Alfonso and agreed to a simple list of actions. Alfonso resisted my efforts to distribute those meeting minutes, but then relented. Alfonso then did the work to complete the first action item. But, the best I can tell, no one is even working on the second action item.

We have been working for many weeks to move our application over to the new server. It turns out that Janice is doing most of the work. Janice should only be an advisor. We are paying our outsourcer to do this work. This is one area that needs to be transitioned over to the outsourcer. But Diana is on vacation this week and Janice is going to be on vacation next week. I can try to get them connected after that and get this transition underway. Of course that will further delay our migration to the server. Well, as fast and efficient as she is Janice just might finish all this work before she leaves on vacation anyway.

There are a series of batch jobs one of our user groups created that are supposed to upload data into our database. The way the code was written is causing some of the data to be discarded. This issue is over three months old, and while some of the batch jobs have already been corrected, other jobs cannot be changed until other higher priority work is finished. This issue is being well managed, but it is going to continue to be an issue long after this project is over.

We discovered a couple months ago that our outsourcer was not making backups of our software on our development and testing systems. We reminded them that our policy is that every server must have a backup. Production servers need to be backed up so that they can be recovered to the "point-in-time" when the failure occurred. Development and testing servers are not as critical, but they must still be backed up at least once a week. I spend an hour or more every week following up on this and every week we are a little closer to being finished. Yet, we are still not there. It should have taken less than eight hours to do this work. Instead we have spent nearly twenty hours swapping emails, holding conference calls and exploring alternatives. But, like several of these issues, this is actually a power struggle disguised as a work assignment. The outsourcer does not like Joshua telling them what to do or how to do it. Also, the outsourcer seems to be lacking both in head count and in technical skill. So we play this game rather than fix the problem.

I have been coordinating design sessions for one of our modules. We all agreed early on that this was an easy module to build and it could be done in about four weeks. We have now been working on the design for six weeks and still do not have agreement. I doubt that this code is going to be finished before this project ends. And the more I probe, the more I see that the original schedule was unrealistic. Yes, if someone could go focus on writing code then this could be finished in less than two weeks. But if no one can get free from all of their other tasks to focus on this module then we will never finish it.

The interesting thing about this list is that none of these tasks are in our project charter. None of this work is within our scope. Only one item on this list is connected to a deliverable - and even that deliverable is not in scope. Yet, each of these items consumes one or two hours per week out of my schedule and more than that out of the schedules for the people doing the work. We are thrashing. We spend time swapping emails about the fact that we did not yet finish rather than just doing the work. Somewhere, somehow I need to find a way to help people focus.

18 May. I bumped into Fred as I was leaving a meeting and he was going into one. He asked how I was doing and I said "Frustrated". "So you can imagine how frustrated the company is after going through two years of what you have been going through." "I'm not sure I understand." "The product that Joshua is building has been underway now for more than two years. Millions of dollars have gone into the effort. And we still do not have a product." That was enlightening. I am not alone in this struggle. Nor is my struggle just an indication of the poor planning that was done on this project. As I had previously suspected, the issue is not a project management issue. Indeed, the issue that has plagued this company for two years is considered to be an operational issue.

But as I thought about that an insight came to me. The solution is not in project management. The solution is not in operational management. No, the solution to this quagmire is going to require a structural change. And thus I realized my solution to this problem.

My recommendation is to break up this initiative into four components. Leverage the existing outsourcing arrangement to focus all support into one organization. Split this project team into two parts. The most senior people will work exclusively on requirements definitions and designs - and they should report to Raj. The more junior people can be assigned to Joshua for problem management tasks like diagnosing bugs, performing root cause analysis or recommending proactive enhancements. But all development and testing should be transitioned to the existing offshore development team.

Next we need to ensure that boundaries are clearly defined, well documented and communicated to all parties. We need to agree to a list of modules and publish that list. Then we should use project management to ensure that there is an agreed schedule. Requirements gathering and design tasks will be performed by Raj's team and they will be held accountable for the accuracy, completeness and timeliness of those results. All coding will be done offshore. All unit testing will be performed offshore. No one on Raj's team or Joshua's team is to change the code.

The swarm approach might be useful in agile programming, but it is used here to allow people to freeload. Janice is doing too much work. Tim is doing too little work. Also, mixing support and project work in the same organization is not working. It is always awkward, but here it is simply not working. Additionally, even though I like rapid application development, it is not getting results here. Thus I recommend going back to the traditional approach of formally documenting requirements and designs. But I still recommend doing that work in an iterative manner. I recommend creating work queues. Requirements are defined and queued up. Requirements are popped off the queue, turned into designs and those designs are then pushed onto the next queue. Designed are popped off that queue and turned into code. This is an approach I have used before, but rather than me elaborating any further I recommend you read Agile Management for Software Engineering by David J. Anderson (17).

At last. I am convinced that I have a solution. I started typing it up when my PDA began buzzing. It is Greg. Now he has an offer I cannot resist. Well, I am achievement oriented. I have solved this puzzle and I am content. Now is a good time to move on. I will document my recommendation and try it out on Fred next week. But right now I need to drive off to meet Greg and see if we can close this deal.

**Post Mortem**

Greg and I talked and continued to negotiate for a couple days before we got to a deal that I wanted. I then packaged my recommendations into a nice report and met with Fred. I gave him two weeks notice and then presented my recommendations. He congratulated me on solving the mystery as to what was actually happening in that department and arranged for a meeting with Joshua, Raj, Tommy and myself to discuss my proposal. In the time I remained on that project I saw no movement on my recommendations, no progress on the project and no end to the standoff between Tommy and Joshua.

I checked back about four weeks later for an update. The development server had crashed again and once again all of the code updates were lost. Even so, the project continued until the fiscal year ended. Then the team just kept on working using operational funds instead of project funds. They continue to inch forward and expect to finish this project sometime in the next twelve months. However, the good news is that whatever was deployed during the last change window before the end of the fiscal year was declared to be what had always been planned for this project. I always find this approach amusing. Allow me to illustrate.

You want to get a good score in archery. Aiming at those little targets is annoying because the targets are never put in the right place. So, instead, you find a nice big building with wood siding. You aim carefully and hit the building. Then you walk over and put a small dab of red paint at the point where the arrow enters the wood. Next you paint a small white circle around the red dot. Follow that with alternating circles of red and white and then impress your friends with your amazing accuracy. You see, the problem is not that Joshua's team was not good at archery; it is just that the steering committee had put the target in the wrong place.

As for the tug-of-war between Joshua and Tommy, both won. Joshua gets to keep on coding away and pushing more stuff into production by using operational funds. And Tommy got what he wanted because the next project was killed and has been blocked from funding.

As for my recommendation to do designs before coding, that never happened. I recommended hiring dedicated testers to find the bugs before they went into production but that never happened. And when I bumped into one of the executive vice presidents a few weeks ago she introduced me to her friend as "a project manager we sometimes use". That phrase, I think, sums up my experience on this project quite well. I was an "It" trying to create dialogue. The system bent just a little when I applied pressure. Now, however, the system has returned to "normal".

By coincidence, I heard from Boris a couple weeks ago. Boris was the PMO VP for the consulting company that I worked through on this project. Boris was searching for clues about how to get more business from that company. He explained that they had cut my pay rate and agreed to a lower billing rate because they were going to get a deal from Fred to give them additional opportunities to place people in Fred's organization. Unfortunately that never happened. Even so, they accepted it when my hours dwindled down to about half-time. In the same way that billing fewer hours at a lower rate made it hard for me to pay my bills, it also made it hard for this contracting company to make any profit off this placement. But they held up their part of the bargain because Fred promised that he would send offshoring projects over to them. Boris knew that once he had an exclusive deal with Fred on offshoring that he would be able to place over one-hundred programmers onto their projects. Thus, Boris accepted the lower rate and reduced hours because he had a deal with Fred that was going to pay off big time. Now Boris was calling me. It seems that they have not had any additional placements from Fred and Fred has only returned one of Boris' numerous calls. In that call Fred said he was quite pleased with my work and that he would get back to Boris soon. Boris wanted my insight. How could he get Fred to return his calls? How many placements should he expect during the next year? How many programmers should he prepare for the offshoring deal? Based on what I have presented in this chapter, how would answer Boris?

A few weeks later I heard from Raj. It turns out that Fred had not been returning anyone's phone calls because he had been busy interviewing for another job. The rumor was that he had finally reached his frustration tolerance. Joshua was right after all. All he had to do is hold his position and outwait the bunch of us.

And that concludes this case study. I hope you enjoyed it. Please remember that this is a fictionalized story. Please remember that I created these characters by blending a collection of behaviors and assigning those behaviors to stereotypes. I actually enjoyed working with these characters in my fictional project nearly as much as I enjoyed working with the real people on the real projects that created this story. Well, that is almost entirely true. I found nearly all of them to be interesting though challenging people and I have endeavored to stay in touch with many of them. Occasionally, however, one or two of them got a little annoying. But that is the part of an ecology that allows us to learn and grow.

In summary: for a brief period of time I was able to change the behaviors of the people in this organization. I had no authority. My only tool was communication. Even so, I talked with Raj a few weeks ago, he remarked on the amazing impact I had on his group. You can do the same.

The key point that I got out of this case study is that initiatives like this are integrative. The tools I used were a mixture of project management tools, operational tools, people skills, governance and metrics. I really believe that we could have succeeded at changing this company if vision had been more fully integrated. Even so, I changed the ecology of this project team. You can do that. Avoid getting trapped into thinking that every project problem requires a project management tool. Accept the fact that IT shops are continually thrashing about between operational issues and project issues. And then learn from Joshua – pure unadulterated stubbornness usually wins when pitted against intelligence, no matter how cunning or how superior that intelligence might be.

As for me, I learned when to walk away. Too many companies say they want project management without even knowing what it is. My job is to grow projects. Sometimes they give you soil with too many rocks. Sometimes they refuse to give you water. And once in a while you find some soil where projects can grow if you just tend them carefully. The next time I find a miserable, rocky patch of desert like this, I plan to just keep on walking.

**Footnotes**

1 Carly Simon Official Website - You're So Vain; "Carly Simon - You're So Vain"; C'est Music; http://www.carlysimon.com/vain/vain.html.

2 Eliyahu M. Goldratt; Critical Chain; North River Press; 1997; ISBN 0-88427-153-6.

3 Goldratt; IBID.

4 Frederick P. Brooks, Jr.; The Mythical Man-Month; Addison-Wesley Publishing; 1982; ISBN 0-201-00650-2.

5 Division of Christian Education of the National Council of the Churches of Christ in the United States of America; The Holy Bible, New Revised Standard Edition; Holman Bible Publishers; 1989; Mark 14:7.

6 Eliyahu M. Goldratt and Jeff Cox; The Goal; The North River Press; 2004; ISBN 0-88427-178-1.

7 Wikipedia; "Turn! Turn! Turn! (song)"; Wikipedia; http://en.wikipedia.org/wiki/Turn!_Turn!_Turn!_(to_Everything_There_Is_a_Season). The Holy Bible; IBID; Ecclesiastes 3, verses 1-8.

8 Robert Kegan and Lisa Laskow Lahey; How the Way We Talk Can Change the Way We Work: Seven Languages for Transformation; Jossey-Bass; 2002; ISBN 078796378X.

9 Kegan and Lahey; IBID; page 15.

10 Kegan and Lahey; IBID; page 33.

11 Kegan and Lahey; IBID; page 48.

12 Kegan and Lahey; IBID; page 72.

13 Kegan and Lahey; IBID; page 123.

14 Robert Fritz; Corporate Tides: The Inescapable Laws of Organizational Structure; Berrett-Koehler Publishers, Inc.; 1996; ISBN 1-88105208805.

15 Fritz; IBID; page 113.

16 Fritz; IBID.

17 David J. Anderson; Agile Management for Software Engineering; Prentice Hall; 2004; ISBN 0-13-142460-2.

#####

If you enjoyed this book, please contact Robert E. Perrine at <http://www.robertperrine.biz>. Also, please logon to Smashwords.com and check for other titles by Robert E. Perrine.

