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
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.
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.
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.
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.
Download this book for your ebook reader.
(Pages 1-23 show above.)