Workplace Ecology: A Case Study in Project Management
Robert Perrine
Workplace Ecology: A Case Study in Project Management
By Robert E. Perrine.
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 https://www.robertperrine.biz.
Acknowledgements
I want to thank all of the friends I have worked with over the years who helped me learn about project management and about people. Special thanks go to Brian, Franklyn, Jim and Tom for their support and encouragement while I was working on this book.
Disclaimer
This is a work of fiction. Any resemblance between characters in this story and people in real life is purely a coincidence.
Table of Contents
Introduction
Initiating
Planning
Monitoring and Controlling
The First Deliverable
The Successful Second Work Package
Communication for the Third Work Package
The Failed Fourth Work Package
Re-Planning
Testing the Fifth Deliverable
A Few Small Diversions
Seeking the Sixth Deliverable
Six Scapegoats
Lessons Learned
Bibliography
Introduction
It seems to me that most books written about project management are tall tales. I read about how project managers use their skills and expertise and accomplish great things. In my opinion, most of those stories are fables. I have taught a lot of project management classes. I learned to separate the theory of project management from the reality. My goal in this story is to help you see the reality. The naked truth is that lots of projects fail. Within Information Technology (IT) the number of failed projects exceeds the number of successful projects. Those failures are then typically attributed to technology. I think that denies the truth in the matter. Most IT projects fail because of people.
When I did project management on civil engineering projects I learned that there were vast books of rules that govern how buildings are built, streets are paved and projects are approved. Very little of that applies to IT. So, as you read this story, look for the ways that people are twisting and manipulating the goals of the project. Also pay attention to the way the people who are supposed to be supporting and sponsoring this project often sabotage the effort. I hope that this story helps you understand what project management in information technology actually looks like.
The events in this story are loosely based on a real project. All of the characters and project details have been fictionalized. But the core of the story is intact. I hope you enjoy this story.
Initiating
Here am I back in the consulting game again. The original project that Greg had for me was a business process re-engineering assignment. Then he found this tiny little project that has the potential to become a really great opportunity. My assignment is to go in, take care of this little project, implement best practices and then help grow the opportunity so that we can enlarge the contract. This is typical of Greg's approach to business. He likes to deliver superior customer service and then keep growing the opening one or two people at a time.
Some companies focus on marketing, some focus on engineering and some focus on service. The stereotype of a sales person is someone that promises more than they can deliver. The stereotype for software companies is that they focus on the technology - using the latest and greatest tools. Greg's company focuses on service. We deliver what we say we will deliver. And the company pulls together to make that happen.
As is typical of most projects, the initial negotiations took place while the project manager - that is me - was busy elsewhere. The account manager for this customer found an opening, put a proposal together and then worked with Greg to package a winning deal. Once the contract was signed they called me. My escalation point on this project will be Vijay. Vijay is the technical manager responsible for the programmers on several accounts, including this one. Greg gave me three goals:
Make this customer happy.
Grow our position in this customer site.
Use this little project to set up best practices that we can apply to other projects.
The goals set by the customer are to use contractors to temporarily augment the headcount in a small department. The contract says we will be developing new applications and supporting existing applications. Like most Japanese owned companies, this customer keeps a very tight grip on finances. There are rumors of an upcoming downturn in sales. Hiring a few consultants now will help get some work done. Then, if the downturn materializes, they will cut our contract and reduce their costs. If, instead, they were to hire permanent employees then it would be more difficult to cut costs on short notice. As Lax and Sebenius note in their book on negotiation, the essence of agreement is the perception of differences. (David A. Lax and James K. Sebenius) We are betting that the downturn will not impact this company and that will allow us to not only complete this contract, but to expand from there. They are betting that the downturn might impact their bottom line and thus they are willing to pay a premium for service now bundled with the option to react quickly. This is a win-win agreement.
Planning
The first two programmers that Vijay hired started work today in the offshore location. They are both experts in the programming language specified in the contract. We had a conference call and got to know each other. The key result was agreement on an organizational structure. Vijay will be their technical manager. I will be their project manager. If the team encounters technical issues, then Vijay will either solve them himself or borrow other resources from other projects to find a resolution. My job is to communicate. I need to communicate with the team and I need to communicate with the customer.
One of the lessons that I learned from the prior case studies is that the organizational structure does not always align with the flow of communication. Greg wants me to implement best practices on this project. Well one of the things that I learned from prior case studies is that defining the structure for the communication flow is just as important as is defining the structure for the organization. So the next task I undertook was to prepare a communications plan for this project. In that document I listed the expected meeting schedule and the expected delivery dates for the status reports. I also included a diagram, shown below, that describes the communication pathways that we will use.
The key to the structure shown above is to compartmentalize the communication. I am the Project Manager. I work for the service provider. The heavy dark line that connects my circle with the Project Lead for the customer is the primary communication pathway we will use. Work assignments will be transferred from the Project Lead to me. Finished work will be given by me to the Project Lead. My purpose for channeling communication like this is to ensure that the developers working offshore do not have multiple people giving them direction. I am interposing myself between this customer and that team.
Note that I am not trying to be their only communication pathway. If I did that then we would slide out of a matrix structure and revert to a projectized structure. On the contrary, the structure I propose actually extends the concept of a two-manager matrix into a three-manager cube. Note that there are three arrows connecting the deve
lopers with this virtual organization. I am their project manager. Vijay will take the role of Senior Developer. In addition, the developers also have an offshore personnel manager. This is a three dimensional cube. Vijay is going to focus on achievement, though he also dabbles with power. I am supposed to deliver results - which is achievement. But one of my roles with this customer is to represent our position in the contract - and that is power. The third dimension is the personnel manager at the offshore location. He needs to focus on affiliation while also being available to intervene if either Vijay or I push too hard on achievement or power.
I am proud of this structure. Clearly I am not the first to implement this cubic structure, but I think I might be one of the first to be able to explain why it works. Well, that is a bit premature. So far we do not even have the requirements for our first deliverable. I am confident, however, that this structure is going to help us succeed.
This is a new paradigm for me. I understand organizational structures and I have adapted them in the past to facilitate my projects. I felt comfortable with Fritz's explanation
