The Orchestra Conductor

Sam Hahn drew a pretty picture the other day in comparing project management and the role of the project manager to an orchestra and its conductor. I do not have much of a musical background, but even I can see the perfect parallel between a conductor and project manager. I started thinking about how the sheet music represents the project plan and is different for the various elements, and how each team member brings their own unique flair and personality.

Is there already a book written using the orchestra conductor as a metaphor for the project manager? If there isn’t, Sam Hahn should write it!

Are you a Star Project Manager?

I came across this interesting video presentation today and wanted to share. It's only about 2 minutes long, and is methodcorp.com's identification of key milestones on the road to a successful project management career.

I especially like milestone 5, which is the silver lining side of when most fairly experienced project managers start complaining that they are being asked to come into the middle of a troubled project. Stop whining, you reached a milestone in your career! :-)

EVM Example Part 3 - Forecasting ETC and EAC

Now, let's find the ETC and EAC.

From part 1:
PV = $450,000 USD
EV = $420,000 USD
AC = $415,000 USD
BAC = $2,000,000 USD

From part 2:
CV = $5,000 USD
CPI = 1.01
SV = -$30,000 USD
SPI = 0.93


We'll use the formula for ETC for typical variance, meaning that we expect progress to continue the way it has in the past.

ETC = (BAC - EV) / CPI
ETC = ($2,000,000 USD - $420,000 USD) / 1.01
ETC = $1,564,356 USD

Now for the final cost estimate based on our EVM metrics:

EAC = AC + ETC
EAC = $415,000 USD + $1,564,356 USD = $1,979,356 USD

So according to our EVM forecast, this project should come in around $20,000 under budget.

What about the schedule? I have never used EVM in practice. I can see it's merit in terms of cost control especially. For schedule however, I think I would use the SPI and SV merely as extra information when controlling the schedule. My first focus would be the critical path, and an SPI lower than 1 would tell me that perhaps I need to start looking at other tasks as well, before they become risks to the flow of the critical path. I'm sure you could take your 10 months and divide it by 0.93 to get around 10.75 months as your projected TAC (Time At Completion, did I just make that up?), but I wouldn't use that as a reliable estimate of completion time. I'm sure there are more advanced EVM metrics geared towards schedule control. If they don't take the critical path into consideration though, they are treating all tasks as equal, which they are not in terms of schedule.

Go Back: EVM Example Part 2 - Finding CV, SV, CPI, and SPI

EVM Example Part 2 - Finding CV, SV, CPI, and SPI

Next, you need to find your CV, SV, CPI, and SPI.

From part 1:
PV = $450,000 USD
EV = $420,000 USD
AC = $415,000 USD


Just plug in the numbers

CV = EV - AC
CV = $420,000 USD - $415,000 USD = $5,000 USD

CPI = EV / AC
CPI = $420,000 USD / $415,000 USD = 1.01

SV = EV - PV
CV = $420,000 USD - $450,000 USD = -$30,000 USD

SPI = EV / PV
CV = $420,000 USD - $450,000 USD = 0.93

Go Back: EVM Example Part 1 - Finding PV, EV, and AC
Up Next: EVM Example Part 3 - Forecasting ETC and EAC

EVM Example Part 1 - Finding PV, EV, and AC

You are the project manager working on building the first prototype of a new whiz-bang gadget. You are about 2 months into the project, which was projected to be 10 months long in the beginning, with a budget of $2,000,000 USD.

Let's take a look at your project with EVM with the goal of making a forecast as to when the project will be done and what the total cost will be.

To start with, you take a look at your project schedule. You count the tasks that should have been done at this time, which comes to 25. Add up the total budgeted cost for those 25 work packages, and you get $450,000 USD. What is your PV, or BCWS?

PV = $450,000 USD.

Now, you see that you are actually finished with only 23 work packages. (Personally, I wouldn't give any earned value unless a task is fully finished) Add up the total budgeted cost for those 23 work packages you actually did, and you get $420,000 USD. What is your EV, or BCWP?

EV = $420,000 USD.

Finally, add up the actual cost for those 23 work packages you actually did, and you get $415,000 USD. What is your AC, or ACWP?

AC = $415,000 USD.

Go Back: EVM Forecasting
Up Next: EVM Example Part 2 - Finding CV, SV, CPI, and SPI

EVM Forecasting

EVM is meant to be used during project execution to monitor progress and hopefully find problems early so that adjustments can be made. Forecasting is an important part of finding out how big of a deal your CPI or SPI is at this point in the project.

We'll use the same numbers from the last post, so:

• PV = $100k
• EV = $90k
• AC = $85k
• CPI = 1.06
• SPI = 0.90
  

BAC - Budget at Completion

• This is the total planned budget for the project (no EVM calculations)
• Let's say we estimated the total cost for this project to be $200k.
  

ETC - Estimate To Complete

• How much is it going to cost to finish this project?
  
• 3 ways to get this (choose the best one for your situation):
• New estimate - go and re-estimate the work remaining. Most accurate, most time-consuming.
• EVM based on atypical variances - past performance is expected to change, use ETC = BAC - EV (or ETC = BAC - BCWP) $200k - $90k = $110k
• EVM based on typical variance - past performance is expected to continue, use ETC = (BAC - EV) / CPI (or ETC = (BAC - BCWP) / CPI) ($200k - $90k) / 1.06 = $103.8k

EAC - Estimate At Completion

• This is simply what the total project is expected to cost given what you know right now
• Use the ETC from whatever method you chose to use.
• EAC = AC + ETC (or EAC = ACWP + ETC)
• So for atypical, we would say $85k + $110k = $195k
• For typical, we would say $85k + $103.8k = $188.8k

Go Back: EVM Variances and Indexes
Up Next: EVM Example Part 1 - Finding PV, EV, and AC

EVM Variances and Indexes

I'd like to first discuss calculating variances and indexes from those fundamental EVM numbers I discussed in my last post.

Variances

Variances are always expressed in currency. They are just what they sound like, the difference between where you are at and where you had planned to be.

CV - Cost Variance

• CV = EV - AC (or CV = BCWP - ACWP)
• Tasks 1-20 are done. You planned on that costing $90,000, but it actually cost you $85,000. $90k - $85k = $5k
  

SV - Schedule Variance

• SV = EV - PV (or SV = BCWP - BCWS)
• Tasks 1-20 are done, but you planned on getting 1-23 done. 1-20 was planned to be $90,000, and 1-23 was planned to be $100,000. $90k - $100k = -$10k

Indexes

Indexes are used to measure performance on a ratio basis which could actually be compared across projects regardless of their comparative sizes. If you are working perfectly to plan, your indexes will both be 1.00. Greater than 1.00 means you are doing better than planned, less than 1.00 means you are doing worse than planned.

CPI - Cost Performance Index

• CPI = EV / AC (or CPI = BCWP/ACWP)
• Using the numbers above, $90k / $85 = 1.06

SPI - Schedule Performance Index

• SPI = EV / PV (or SPI = BCWP / BCWS)
• Using the numbers above, $90k / $100k = 0.90

So, looking at these variances and indexes, you can see in the example above that we are behind schedule, although it looks like we've managed to keep our costs down so we are actually below budget too.

Go Back: EVM Basics
Next up: EVM Forecasting

EVM Basics

I would like to start my foray into EVM by doing some definitions and basic formulas. I'll give my paraphrased descriptions as to what's what and why.

No formulas today, just the 3 core inputs necessary to do all the EVM calculations we'll get to later.


PV - Planned Value AKA BCWS - Budgeted Cost of Work Scheduled

• This is a time-specific estimate only. What was planned to be spent at this time if the schedule was perfect?

EV - Earned Value AKA BCWP - Budgeted Cost of Work Performed

• This is a task-specific estimate only. What was planned to be spent on tasks actually completed right now?

AC - Actual Cost AKA ACWP - Actual Cost of Work Performed

• This is reality. What did you actually spend? Make sure the method for auditing cost matches up with how you made the original plans (did you include indirect costs, or just direct, etc?)

Go Back: Itchy for Earned Value
Next up: EVM Variances and Indexes

Point 12 - Deming in Project Management

Enable Pride of Workmanship

Deming claimed that the sense of having helped other people is the most significant motivator and source of job satisfaction. It is one of the biggest enablers for pride of workmanship.

Of the projects you have worked on, think about the ones you are most proud of. What is it that makes you look back and say, “Wow! Look what we did!!!”

Does meeting an arbitrary project deadline set by a sponsor make you proud of the project? Does fulfilling the written requirements even though the customer expectations were not met make you feel like you’ve really done something important? Probably not.

Personally, I feel the most pride when (1) a really significant positive impact was made and (2) I helped people and know they are grateful for what was accomplished. I want people to think and say “wow!” even if it is only to themselves about something the team did, big or small. These criteria are true for me whether I am managing the project, or am participating as an individual contributor.

Project managers should be looking for the great things their teams are doing. People on their projects should know that when they go above and beyond, they will be recognized. A huge part of this is that the PM must be unselfish and there to serve their people. Servant leadership, that is what is required. The PM should start with the viewpoint that the multitude of talent on their team is going to come up with better ideas than the PM can alone, and not be afraid to embrace those ideas.

Another key point is the avoidance of micromanaging projects. Tasks should be broken down to a certain level where the individual contributor can apply their expertise, and no further. Let them execute how they wish based on their talent and expertise. Be there to guide and serve, yes, but not to micromanage. Micromanaging is one of the quickest ways to kill the soul of a project team.

(Back to Deming's 14 Points)

Point 6 - Deming in Project Management

Job/task-related training

A quality organization understands the value of the people who work in it. The same goes for project management. Training project managers, analysts, and everyone else who regularly works on projects in the company methodology, soft skills, etc. can bring significant rewards.

Many companies use the cop-out of "on the job training" to sidestep any responsibility to have a formal system in place to ensure their people are constantly learning how to do their jobs better. I am not saying that OJT isn't valuable, but it can't be the only training "effort" put forth by the powers that be.

The companies I have experience with that get this have the following resources and programs in place:

• A project resource center with books, periodicals, and other materials
• Time specifically scheduled for training and learning each month
• Presenters, either from the team or externally, giving a talk monthly to the whole group
• A significant amount of funds in the budget earmarked for training
• Sending a few people each year to seminars and events like the PMI Global Congress, etc. --And then those people present what they learned to the whole group when they get back
• A formal mentor program whereby new employees are paired with a vetran
• Company methodology and process training

There are many other ways to show commitment to project management training and education, these are just a few. Please leave your ideas and experience about best practices as a comment below.

(Back to Deming's 14 Points)

Quality Perspectives in Project Management

In Managing for Quality and Performance Excellence, Evans and Lindsay point to 5 distinct perspectives when defining quality. They are transcendent, product-based, user-based, value-based, and manufacturing-based. The authors discuss the topic in terms of defining quality within organizations and products. I see parallels to defining quality when running projects.

Transcendent Quality

This perspective makes a judgment as to quality in comparison to a “standard of excellence”. This is a highly qualitative measure of quality, and is normally a function of all aspects influencing the perception of quality combined. On projects, this is your complete package, and could be judged by whether or not sponsors want you to manage their projects, customers ask for you by name, or team members love to work with you on your projects.

Product-Based Quality

Are the details taken care of? In manufacturing, product-based quality could be the thread count in textiles, or well things fit together. In a project, I interpret this perspective as looking at:

(1) Did the project manager do a great job of managing the details (communications, risk planning, resource planning, etc.) and

(2) Did all the solutions satisfy the requirements fully, or did some of the solutions only solve the problem 80%?

User-Based Quality

The customer is always right. Or at least from this perspective, quality is based on whether or not the customer got what they wanted. Suppose the exact same IT solution is implemented for two groups. For group A, this is the perfect solution for their needs and so it represents high quality. Group B is impacted by limitations that don’t matter to group A, and so they perceive this as a low quality solution.

Additionally, this relates to how well the requirements are written and implemented. Do they truly address the customer needs? Poorly written requirements can be executed on perfectly and still represent a poor quality job from the user-based perspective. This would happen if the requirements were poor to begin with and did not accurately reflect the customer needs.

In short, the user-based perspective all comes down to the accuracy and precision of requirements, and how well they are executed.

Value-Based Quality

Many times people jump towards a custom-built or proprietary solution to a problem when there are commercially available alternatives that would meet the same needs for much less cost. Project A and Project B solve the same problem and have comparable value added when finished, but Project B costs twice as much. Project A has twice the level of quality from this perspective.

This could also play into resource allocation. When people and tools are used in the right place at the right times, they work more efficiently and cost less than disorganized, adhoc projects. Whether it’s the solution or resources involved, this perspective is all about return on investment.

Manufacturing-Based Quality (or Specifications-Based Quality)

In business, this is defined as the level of conformance to specifications. A tolerance specification of .236cm +- .003cm is a standard of quality. In projects, I see this as conforming to the original scope and plan. Scope creep reflects poor quality in this regard, and so does being over (or under) budget or time constraints set forth in the beginning. EVM practitioners and project controllers may be able to relate with this very well. If you stick to your original plan, then you’ve got high quality on your project from this perspective.

Another angle on this might be how closely the actual solution matches up to the requirements. Although the User-Based perspective speaks to requirements also, it is geared more towards what the stakeholders actually want. This perspective assumes that if the stakeholders signed off on their requirements, and you provided solutions that address those requirements, you have high quality. This could result from taking a pre-conceived solution from a customer and running with their requirements, without worrying about what business problem you are actually trying to solve, and if there is a better way. In that case you could end up with poor user-based quality, but high specifications-based quality.

I'm looking forward to delving into the rest of this book. So far it is very promising and I believe it will provide many insights into how to create and manage quality projects.

It Was An Itsy Bitsy, Teeny Weeny......

Finding the right balance of documentation and methodology can be challenging on small projects. Here are some tips.

I have been managing small projects for some time now. Some of my project are really tiny, I'm talking about 8 hours of work max. Others can be 2 week or month-long projects. Some span several months, and then you get up into the 6 month and year plus undertakings.

As a student of project management, I have often struggled with finding the right level of planning and documentation for these various sizes of projects. Some things are obvious, as in I'm not going to go through a formal project plan and communication plan, etc. for an 8 hour project.

As a rough guideline, here is what I use:

Level 1 (Projects longer than 6 months in duration)

-Full blown project planning and documentation for whatever is appropriate to the project

Level 2 (Projects 1-6 months in duration)

-Simplified project planning document, which includes brief communications and risk plans, along with scope definition, limitations, objectives, and deliverables. Also containts a simple WBS and Gantt-style task list with dependencies, owners, estimates, and a timeline.

-Weekly status reports to stakeholders

-Project meeting agenda/minutes template - I use this to document the agenda before meetings about the project, then update it immediately after the meetings and send it out to all the stakeholders. It includes a section for decisions regarding agenda items, and a seperate section for action items.

-Project Closure report at the end which summarizes the business benefits gained and effort spent. This is a good post-mortem look at ROI. Lessons learned are also attached to this.


Level 3 (Projects 1 to 4 weeks in duration)

-Simple project request form, where the requestor fills out their definition of requirements and business justification. Since these requests are fairly simple, I normally work out the details of the requirements over the phone with the customer, and just make updates in my project documentation log (which I keep for all projects big and small)

-Weekly status reports to all stakeholders (sometimes yes, sometimes no - depends on the project)

-Project Closure Report

Level 4 (Less than 1 week)

-For this I still have the simple project request form

-Email when the deliverable (usually 1) is ready for validation, asking for approval


I keep detailed activity logs for all levels of projects, even if it's a 2 hour job. My department has a sharepoint site set up that works really slick for this.

I find that using these guidelines, and the templates I've developed, really makes it easy for me to keep my ducks in a row and keep my stakeholders informed about what is going on, for any small to medium project I am managing. For more information, check out this great article by Simon Buehring which I found today and very closely matches my style for managing small projects.

This article was originally published at http://projectmanagementlearningcenter.com/.

Old School Bas De Baar

I wanted to have a great new article ready for today's post, but I am applying for scholarships through PMI and so had to put some effort into the required essays.

So, today will be a lazy post on my part. Here is an interesting video I found that Bas put out back in 2004. Much of this is in the spirit of his book which I am reading now. Check it out!

Interesting camera work Bas!

Master Plan

In the April 2007 edition of PM Network, there is an article titled "Master Plan: IT executives need to develop an eye for project managers" that I would like to comment on.

The article is mostly based off a study done by Gartner Inc., in Stamford CT, USA. One sad but true statistic stated that 20-30% of IT executives "have a 'dismissive attitude' toward project management". Those are the same execs that suffer "from poor quality, late delivery and unrealistic project costs." I can related to this information from my personal experience, and would venture a guess that when you move into executives in operational areas, the dismissive attitude towards proper project management increases. The majority of IT execs seem to have seen the light and made the realization that there really is value to be delivered by well run projects by individuals who have the right skills to do so in a formal manner.

If I had to guess at a percentage, I would say that more like 40-50% of operational executives have a dismissive attitude towards formal project management, although the number seems to be decreasing. There are still a majority of director and above level people who seem to not perceive value in formal project management. I see the trend towards realizing project management adds value as positive reinforcement for my decision to enter the discipline.

But I digress. Back to the article in PM Network, I found a few points insightful and worth sharing here. First, the report by Gartner classifies IT project managers in 4 categories:

1. Novice - Some project experience, lacks formal training
2. Apprentice - Some project experience, shows initiative towards managing projects, has sought out and attained some formal training, ready to manage a low-risk project.
3. Journeyman - 2 years of project management experience or more, formal training in scope and risk management, advanced scheduling and best practices.
4. Master - 5+ years successfully managing projects, usually PMP or other certification attained.

Only 15-20% of project managers are in the Master group. I would place myself either in the high Apprentice or just barely Journeyman category. I've had a good amount of formal training and several years of managing projects, albeit projects managed without knowledge of the discipline of project management.

I feel the categories above are a bit tenuous, as I have met project managers who by the definition above would fit into the Master category, but do not display what I would refer to as Mastery skills in managing projects. The last box in the article goes into five characteristics of masters that I feel are much more accurate:

1. Diplomacy - ability to manage the business relationships effectively
   
2. Strategic Vision - ability to see the big picture and eliminate "silo paradigms"
   
3. Policy Responsibility - seek process improvements and question existing policy constraints
   
4. Collaboration - cross-functional leadership skills
   
5. Risk Management - advanced risk management goes beyond a risk management plan checklist

I would like to add a few to this list:

1. Effective Planning - see my previous post on Alpha Project Managers and how they spend twice as much time planning as non-alphas.
2. Superior Communication - Again a reference to Alpha PM's - This goes with diplomacy and collaboration, but everyone knows the successful project management comes mostly from excellent communication.
3. Decisiveness - the ability to make tough decisions quickly and stick to your guns
4. Conciseness - the ability to drop pretenses and execute. Many junior project managers I know seem to throw around a lot of jargon in meetings to try and wow those not educated in the discipline. Masters I have worked with drop the unnecessary, speak on the client's level, and get to the point.

Please leave comments about this post!

Videos from Bas De Baar

Kudos to Craig for leaving the link to this in a comment he left on the last post. Videos from Bas related to the book that I'm reading now. Enjoy!

Part 1


Part 2

Surprise! Now You're A Software Project Manager

I started reading Bas De Baar's book today, "Suprise! Now You're a Software Project Manager!" Bas is a fellow contributor over at PMLC, and after hearing his interviews on Controlling Chaos and The PM Podcast, I had to pick this one up.

In the introduction, Bas touches on many key points that I could relate to, and some that I am not sure about yet. Bas makes several references early on regarding how important it is to focus on the stakeholders in any project. He discusses the relationship and progression of interests, expectations, and requirements (which he terms "The Flow of Stakes". I found this part very interesting as my last post was about soliciting good requirements, and a project I am involved with right now is having some issues creating great requirements.

He also touches on the delineation between project management and software development. This piqued my interest as I currently work on many small software development projects in which I am one of or the sole developer, in addition to managing stakeholder requirements and simplified project management. As I mentioned in my interview with Cornelius on The PM Podcast, once I started applying formal project management methods to my projects, my productivity increased dramatically. I can see the parallel with what Bas is asserting, because essentially I just split my software developer role into 2 roles. Now I am a project manager AND a software developer, even though I'm in the same job as before. By forcing myself to separate the two roles, I have become more proficient at both. I understand my expectations for each role better, and can focus on one mode of thought at a time instead of trying to both functions at once. (If anyone is wondering, I am not schizophrenic, I have just admitted the duality of my job and confronted it!)

Bas provides simple, elegant figures throughout the first chapter to illustrate his discussions. These are very helpful in understanding him fully. If the introduction is any indication, this should be a good read. I'll keep you posted!

Please leave comments about this post!

Good Requirements ARE SORTA NUTS

Have you ever let someone down even though you had tried your best and thought you were doing what they wanted? Few things are frustrating as putting forth tons of effort only to find out you were working on the wrong things.

Expectations are such an essential and common component of human relationships and communication that most of the time they are taken for granted. Taken for granted is exactly what expectations should not be.

In project management, we have a plethora of tools and techniques to help us understand expectations and meet them. We understand and fulfill those expectations through good requirements management.

Every stakeholder in a project has expectations for it, including the sponsor, team, customers, and even upper management in many cases. These expectations need to go through a review process and possibly become requirements, which in turn may lead to derived requirements that arise solely to support the main requirements. So what should come out of this review process? What makes a good requirement for a project?

I put together my own acronym based on the old standard SMART goal setting components, combined with sources on soliciting great requirements (see citations at the end of this article). I hope you like these items although I have to warn you, they ARE SORTA NUTS.

Accounted for	Documented! Documented! Documented!
Ranked	Prioritize for when you can't do it all
Empathetic	No conflicting requirements, understand diverse stakeholder needs
Specific	Clear, concise, to the point
Owned	Who's expectation is being filled, and/or is an SME for this requirement?
Realistic	Is it feasible?
Time-specific	Dependencies and timing taken into account
Actionable	Is this something you can execute on?
Need-focused	Focus on needs, not preconceived solutions
Useful	What is the business justification?
Testable	How do you know when the requirement is satisfied?
Sufficient	Enough detail to tell what they really want?

What factors do you look for in great requirements?


Sources and links:
The Art of Requirements Gathering, George Spafford
Eliciting Software Requirements, Presentation by Jesse Borschel - Sioux Empire PMI Chapter

My Interview On The PM Podcast

Cornelius Fichtner over at The PM Podcast surprised me a while back by inviting me to be an interview guest on his show. I was obviously flattered as he puts out the grand daddy of project management podcasts, and I've been listening to the show for many moons. In my opinion Cornelius' The PM Podcast and Dina Scott's Controlling Chaos are in a league of their own.

The interview focuses mostly on my background and the differences between the academic and working worlds of project management education. I also mentioned one of my favorite project management books, "Project Management in the Fast Lane" by Robert Newbold. It is one of my favorite because it does a great job at teaching the mechanics and "how to" of doing Critical Chain Project Management.

Take a listen, and if you haven't already discovered The PM Podcast, I highly recommend going back to listen to past shows. Cornelius does an interview format for most of his shows, and has a lot of great guests. Don't worry, most of them have much more project management experience than I do!

The PM Podcast Episode 065: BS and MBA in Project Management


Please Leave Comments about this Post!

Book Review: Human Resource Skills For The Project Manager

Human Resource Skills for the Project Manager: The Human Aspects of Project Management, Volume 2


This book by Vijay K. Verma provides a good overview of various project aspects regarding relationships, communication, and human capital in general. I personally found it helpful in the descriptions of various theories out there, and a good starting point to branch out and seek more specific research and information.

The book is split up into 6 main sections: Communication, Motivation, Conflict, Negotiation, Stress, and Leadership. Some of the areas of interest for me I took further and branched out on, and you may recognize some of the topics from posts I have been writing.

Specifically, the communication, motivation, and negotiation chapters prompted me to take further action in seeking out academic and industry research and thoughts on these topics.

This made a great textbook for my HR Project Management class this semester. I recommend it to anyone who wants to be able to better understand these areas within project management as a good place to start on the journey to self-improvement. It may help highlight some counterproductive practices you are engaging in and do not even realize.

It is set up much like you would expect a text book to be however, soft cover and short novel dimensions notwithstanding. It is not something I would classify as an easy or casual read. (It's not quite as dry as the PMBOK guide though!)

Negotiation in Project Management

Planning and change management regarding scope, resources, scheduling, budgeting, etc. can benefit from good negotiating skills. I recently studied an article titled "Social Perception in Negotiation", published in the journal “Organizational Behavior and Human Decision Processes”. The article looks into the different types of agreements that can be achieved, and makes some conclusions about the factors that make an agreement most valuable for both parties. I will discuss the article here, and share my thoughts on how great negotiating skills can be applied in project management.

AGREEMENT TYPES

The study first defines the difference between compromise and integrative agreements. Basically, in an integrative agreement both parties find they are receiving more value than they are giving up. This is mainly a function of compatibilities between what each side wants and what they can give up. This is the famed “win-win” scenario.

I visualize the iterative agreement like a zipper, where individual items up for negotiation are simultaneously perceived to have high value for side A while having less for side B. Side B is thus willing to give that element in exchange for another where the value perception is switched. Each finger in the zipper represents a negotiated element, and the further the element reaches toward the other side, the more integrative and mutually beneficial. The combination of multiple compatible elements culminates in a strong and stable agreement with high mutual benefit. An integrative agreement provides a compelling answer to the “what’s in it for me” question, for both sides.

The compromise agreement pops into my mind as more of two flat surfaces butting up against each other. Both sides are trying to compete against each other on the same items and so they reach an agreement that is unstable and provides minimal value for either side. There are no or very small fingers because neither side is giving up less valuable elements to gain more valuable ones. The split could be at the 50-50 mark, or move depending on positioning inequities or other disproportionate advantages. The result is that both A and B end up holding onto provisions of low value that might be of higher value to the other side. It also means the agreement is tenuous and doesn’t “stick” well of its own accord. These types of agreements may result in frequent arbitration or litigation to resolve disputes, because the relationship and value exchange is not strong enough to support cooperative resolutions.

JUDGMENTS

The study identified two key factors critical to optimal negotiation. They are priority and compatibility judgments. Both of these judgments are based on assumptions and information about the other party. It’s all about how well you know the needs of the other side.

Priority judgments are made regarding particular items up for negotiation and how important they are to the other side. How important is element 1 as compared to element 2. Not to you, but to them.

Compatibility judgments are made regarding the various alternatives available for negotiated items and how compatible those alternatives are for both parties. I believe it ties into the priority judgment because there is consideration on whether or not they will go for this or that proposed provision, which plays into prioritization.

CONCLUSIONS

The study concludes that accurate perceptions of compatibility or priority lead to more mutually beneficial outcomes when the potential for join gain exists. It also finds that the earlier those perceptions become accurate, the more beneficial they become towards a positive outcome.

All of the conclusions point to sharing as much information as possible, as early as possible. This results in mutually beneficial negotiations with a higher probability for an integrative agreement.

For project managers, here are some ideas on how these conclusions could be applied:

1. Scope Definition: It is important to dig into the assumptions and root causes of user requirements as early as possible. If you do this, you may be able to negotiate a different approach that will make the project run more smoothly while also giving the stakeholders a better result.
2. Resource Acquisition: When an integrative agreement is reached initially, there is more mutual benefit to be gained and therefore the party providing resources is more willing to allocate them to your project. You can also look for talent that is undervalued in their functional role and find those places in the project that are a great fit, and make the case for why they will provide more value to the functional manager by leveraging their strengths on the project.
3. Scheduling: Understanding the relative importance of deliverables to stakeholders is critical to reaching an integrative final schedule. If you only look at the task dependencies and what is most convenient for you, be prepared to miss out on great information about an optimal schedule.

If the stakeholders really care about the dates of specific deliverables, focus on those first where possible. Sometimes an output may lie stagnant for months when it could have provided value to the business, only because the project manager did not understand the significance. You may even be able to get a later project completion date because you are providing the value that really matters in an incremental fashion and playing to stakeholder needs.

4. Budgeting: One opportunity here would be where there are multiple cost centers and departments involved. By understanding and playing to stakeholder needs, you may be able to get a higher chunk of money by appealing to the group which has the most to gain. The important thing here is to tie the expense to the value they will enjoy.

Another key is the importance of understanding the true problem being solved by your project and doing a great job at the scope definition. If you just implement the wiz-bang software they asked for without knowing much about the pain you are trying to soothe, you have no bargaining power when it comes to the budget. You can not articulate a proper value proposition or appeal to the true needs of the business. How can you ask for more money unless you can link it directly to the bottom line? How can you link it to the bottom line unless you have developed a quality understanding of the true purpose being served?

REFERENCES

Thompson, L., & Hastie, R. (1990). Social perception in Negotiation. Organizational Behavior and Human Decision Processes, 47, 98-123.