A Project Management Firm Principle History | Mission Statement | Contact Us  

Project Management Foundations Project Leadership Foundations Multi Project Environment Project Risk Foundations

TrainingConsultingCustomizationSeminar OutlinesUpdate Your Skills

Update Your Skills

The science of making little problems out of big ones.
Using project management tools to negotiate for your projects position.

Jerry L. Brown, PMP
I noticed as my projects became larger and appeared in multiples, that the problems I faced as a project manager, increased disproportionately. I don't like problems. They cause me to worry and lose hair. They made people angry at one another and at me. They caused me to work late and ineffectively.
In a stroke of genius, I thought that I needed to simply work harder at eliminating problems. I reviewed all my project management tools and techniques and doubled my efforts to become an effective project manager. I even learned a software program that the brochure basically promised would eliminate all my problems. You can guess that the problems didn't stop.
I knew I would have technical problems and I knew the client would change the project request from time to time, but I didn't count on management problems, resource problems, approval problems, miscommunications of all sorts and basically, a myriad of problems that any good, dedicated, educated, motivated, resourceful, respectful, good-natured, success driven project team should never have or at least they should be able to handle these misfires while still on their feet. These problems appeared on an ongoing basis and it seems as if no one trusted me a project manager. No matter what I said or asked for, There was always doubt or some visual apprehension.
Now this shouldn't be, I thought out loud many times. As an experienced project manager, I should be able to meet with the project team and have them dedicate their professional talents to the project needs. I should be able to meet with the client in their Ivory Tower and have them listen to my dog and pony show, ask the questions I purposely left for them to ask and then have them nod agreeably that the progress and product was understood and acceptable. I should be able to approach my management with the requests that I needed for meeting the timeline or quality standards in the form of money, resources, authority, approvals or just plain support of any sort. They should understand from my status reports every thing they needed to know to make decisions that would enhance my project. In fact, I fully expect to be invited to the club to play a round of golf any time now.
None of these Pollyanna things happened as I felt they should. In fact more often that not a problem of the type I mentioned before appeared and demanded my time and effort. I began to sort out my life's work. What's wrong here? How can I stop this from happening? How can I handle these problems quicker, better and with more confidence? If it isn't a lack of my abilities or the software's overstatements, what can I do to live at peace with the seemingly never ending project problems?
I began to study problems I was faced with. What caused them, what made them grow, how were they best solved, did they reoccur, was there a difference in their effect on me and the project? I began to sort out problems and to categorize them.
As I contemplated these problem characteristics, something basic struck me. I learned that of the problems, the smaller ones were the easiest to handle satisfactorily. Now this observation is not worthy of scientific note in and of it's self, because I realized that we all learn this at some degree and through our own experiences. We just never say it or use it to our advantage. Reverting to my problem solving tendencies, I reasoned that I preferred all my problems to be as small as possible. That's good logic and it's more realistic that eliminating all problems. So I set out trying to find the ways to not eliminate all the problems, but to make them smaller.
I want to pause here to take you on a parallel track. During this time of problem examination, something else also struck me. Almost all problems need to be negotiated to a resolution.
I found that I did not have the ability too just wave my hand or threaten to lop off heads and a problem would be attended to by my handy and loyal aid. I had to negotiate with at least one other party to get what I felt the project needed. So I studied negotiating techniques. But all the information I could find dealt with negotiating a better rental agreement or an cheaper investment price. I needed to negotiate within business and project needs. I needed to know how to sit in a meeting and get my team, client, contractor or management to understand the benefits to my receiving my project request and/or the consequences to the project and the individuals, if my request was denied.
The short version of my negotiating theory is this. In order to negotiate successfully within the project community, a project manager needs to have at least one of three following negotiating armaments:
Time. If you are in a time squeeze, if you have to have something quickly, you are at a disadvantage in negotiating. The party who has time to wait has a distinct advantage. If I had time to give as a bargaining chip, I could trade that for a better resource at a later time. If the project was ahead of schedule, I could offer a better testing sequence. If I have time for my project, I can use it to my negotiating advantage in almost every case.
Power. The very thought of negotiating with a higher titled person makes us scream. We can not win by definition. We will surely lose any request we make that might cause the more powerful one give into a position. Power can also be displayed as money. It's been referred to as the "golden rule": those with the gold, rule. The person with the most money to offer or with the highest ranking can usually win a needed commodity to be used to a project's advantage.
Information. The more knowledge I posses at the negotiating session, the more likely I am to make the points that are necessary to validate my request. I want defense if I have to explain my position. I can have that if I have more information. Now more information here not only means more supporting detailed, but accurate information as well.
As I took stock of the weapons I could usually can use to negotiate my project's needs in solving problems, I found I was sorely limited. I can remember very few examples of having enough time to offer in order to gain a project necessity. Extra time just doesn't exist in the world of project managers. I realized that I could not count on this as a method of surviving.
Power would be nice to have. But my title is project manager not Vice President. Even I see the difference here. I will hardly ever have the power to use in negotiating project needs. Besides, we all know how it feels and the afterthoughts we have when power is used on us to get us to perform for someone else. And again, extra money just doesn't exist in the world of project managers.
That forces me to rest most often on information to negotiate my project requests. And the feeling is rather comfortable. I once heard someone say that the best way to beat power is with truth. I didn't understand that fully until recently. I now know that I can stand in someone's very large shadow and listen to very loud words and have daggers of fear coming at me and still feel very comfortable if I have adequate information to shield off any blow.
Now the two discoveries; that smaller problems were easier to effectively deal with and that I could solve these problems by negotiating with correct and timely information, began to drive by management life. I know that I need to get all problems from getting to be big ones or at least break the big ones down into small ones and I need good information fast that I could use to demonstrate to the project community a satisfactory way to solve any project problem.
When I realized this, I also realized that I had all the tools I needed to accomplish my new project management mission. Project management methods existed that just begged me to adapt them to help me create what I needed and wanted. I reasoned that if I could keep the project community not just more informed, but informed as to the real project status and direction, we could discover problems, sometime even just as potential problems, and handle them effectively with every project contributor understanding the situation and helping me with the small quickly identified problem. Yet another discovery. I did not have to deal with all the large problems myself. That's why they call it a project team. I remembered the old coaching adage, "There is no I in the word team". My project management life was about to get easier and in fact did get easier. I started to work at getting better project definitions. Many times it meant making the projects smaller because we could only identify certain things that needed to be met within a project at that time. Quite frankly, it meant that we dropped solving world hunger from our project definition. The single most important thing I started to do here was to publish the project definition; literally. I always made sure that the project charter, mission, objective, what ever we called it was posted several places and certainly a part of every project meeting we held. There can not be doubt in what we are working toward.
I started to involve the individual team members in planning and working sessions. The advantage became apparent very soon. We began to intercept problems before they crystallized. I also made a new discovery for another story. There are degrees of "buy-in". The project teams members bought in at a higher degree and there were fewer big problems as a result.
We established a communication plan that dealt with two basic questions of management and of the client. The questions were: What decisions do you need to make at your level about the project? And, What information do you need to make those decisions?
Once we identified these criteria, we could provide information to the respective parties that would allow them to solve their own problems in many cases. I found that I could negotiate a successful resolution to a small problem quickly or, correction, we could.
I had to step back to create a way to present this information concisely and without time delays. I had to determine the security of certain information and it's accessibility. Another step back told me what information to gather and what to measure it against. I found that it wasn't always what % complete is the task or project. It wasn't always the critical path task updates or the hours charged to the project. We had to determine what distinct measurements would tell us what we needed to know about the project in order to signal any problems while they were small. It worked. The project meetings did not have any second agendas. Every one was well versed on the project status from their preferred view and yet all the information was consistent to the project community. Doubts subsided, cooperation increased, the meetings were shorter and more productive, decisions were made with information not emotion, problems seemed smaller and were dispatched and did not reappear. I still haven't been invited to play at the club yet however.
I never said this was Utopia. Problems still exist and many times I have to go back to the basics when a problem seems to be getting out of hand. The basics include determining why this is a problem. Who or what is the root cause of the problem. What can we do to break this problem into smaller pieces. What information is needed to negotiate a successful resolution for the sake of the project.
The project management tools we learned are not meant to be administrative shackles. They are not rigid forms and methodologies meant to honor someone's authority or control. They are meant to add individual flavors to your project management styles and methods. Just as two trumpeters use the same physical horns and use the same note making configurations, the style, tone, passion and resultant enjoyment can be, and generally is, quite different.
It's very hard to step back and remember what your real mission as a project manager is. There is some appropriate quote here about the draining the swamp and alligators and their relationship. However, if we focus not on just working harder, but working smarter, we can make project problems smaller and deal with them effectively.
I just heard we have a 10:00 o'clock tee time.


Training | Consulting | Customization | Seminar Outlines | Update Your Skills
Principle History | Mission Statement | Contact Us

All content © 2004 - 2007 Project Methods Inc.