Dunbar's Number and Project Management

In the late eighties Prof. R. I. M. Dunbar, in his anthropological studies, discussed optimal group sizes for primates, which seemed to be a function of relative neocortical volume in their brains. According to Dunbar, the number of neocortical neurons limits the organism's information-processing capacity and that this then limits the number of relationships that an individual can monitor simultaneously. When a group's size exceeds this limit, it becomes unstable and begins to fragment. This then places an upper limit on the size of groups which any given species can maintain as cohesive social units through time. In other words, there is a natural limit beyond which the group's functionality and efficiency begins to deteriorate. For humans, the Dunbar's number seems to be around 150 (Dunbar actually calculated the mean group size to be 148). Dunbar also noted that the group has to be highly motivated for such a large number to work - in the absence of intense economic or environmental incentives and "social grooming" such large groups tend to break down into smaller fragments.

Here are a few thoughts on how his study impacts the way work groups should be structured.

• The Dunbar's number indicates the total number of relationships a person can maintain, including family, friends and professional relationships. Many authors on the web take the number to mean the optimum number of people that you may have on a project. I think there are two mistakes these authors are making here. (1) They are confusing the maximum with the optimum. The brain is wired to monitor up to approximately 150 persons. This is not the same as saying that the brain monitors 150 people best. And, (2) that the 150 relationships are exclusively for the work environment. If you take into account relationship slots that may be occupied by friends, family members and professional relationships outside the project environs then an appreciably less number of slots are available for project related relationships. A Facebook study from a couple of years ago estimated that an average user tracked about 40 "friends". Add to this about 20 to 25 people that a person may relate to in some other way but who are not members of Facebook and this will leave a maximum of about 80 to 90 people that a team member may effectively monitor. The optimum number will probably be some where about half of this.

• A macro group may be formed which may be composed of many smaller cohesive groups, each containing the optimum number of members. These smaller groups may communicate with each other through the upper hierarchy levels, which forms the communications/coordination backbone of the organization.

• The larger the group the more "social grooming" that is required. In other words, larger groups need more team building exercises to keep them functioning as a productive whole. According to Dunbar, for numbers approaching the limits the time required for these activities may be as much as 42% of the total time. This means that there is a diminishing rate of return associated with increase in team size. This is another reason why the actual optimum number of team members in a group will be appreciably less than Dunbar's number.

Interesting read: http://www.wikinomics.com/blog/index.php/2009/06/15/diminishing-returns-of-collaboration

Risk Analysis (or, How to Avoid Disaster)

Having a failed project in the portfolio will usually leave a bad taste in any project manager's mouth but failure can also be used as a teaching moment. It is said that it took more than 6000 attempts before Edison found the right material for his incandescent light bulb. When asked how it felt to fail so many times his answer was that he did not fail. He had found 6000 ways to not make a light bulb!

One major lesson to be learned is that every project needs a proper risk analysis before you spend too much money and effort on it... and plan ahead to meet the risks head on when and if they become reality. You should look at the following sources of risks, at a minimum, to analyze and come up with a mitigation plan.

Stakeholder Commitment

Stakeholders need to be absolutely committed to the project. It is no use going into a project if any of the major stakeholders are not convinced that the project will bring benefit to them or if they perceive a conflict with other parts of their strategic objectives. There is nothing more dangerous to a project than a stakeholder who will withdraw its support as soon as the going gets tough or if they see a tactical or strategic advantage in doing so. The stakeholders should ask themselves, “how does the project play into the stated strategic objectives of the company?” Questions should also be asked to determine the responsibilities of the decision makers, and the effect if these decisions are not made in time.

Planning

A project is based on three main pillars - scope, cost and time - and the PM should look at the three to find potential sources of risk. One should always ask: Is the scope well defined? Are the objectives clear and achievable? Do the supervisors know the limits of the scope? How will you control scope creep and gold plating? Can you break down the project into smaller subprojects for better management? Has the budget been well prepared, vetted and agreed to? What happens if the project runs into a cash flow problem? What happens if the estimate is not credible? What happens if the project conditions on site do not match conditions stated in the RFQ? Is the project too long? Is the Cone of Uncertainty a concern? Is the change management plan in place?

Resources

Resources are the backbone of all projects. Do you have adequate staff with proper experience and qualification? Have they worked with a similar client before? What is the risk of disruption due to staff turnover? Is there a proper HR plan in place? Are the roles and responsibilities of everyone clear? Have team members worked together before? If not, is team-work a concern? Are adequate resources available locally? Will [on job] training be required? Is there a correct balance between the direct and indirect resources? Is there a procurement system in place? What is the plan B in case one of your subcontractors does not perform according to expectations?

Monitoring and Control

This is where all projects succeed or fail. It is imperative that the PM ask themselves the following: Have adequate resources for control and monitoring provided for in the plan? Are processes in place?  Is the flow of information clear to everyone? Are the reporting requirements and responsibilities clear to everyone? Are the quality requirements clear to everyone? Is the ITP in place and being followed?

Closing

The most difficult part of a project happens to be the closing phase. I can speak with experience that if not properly planned for, the closing of a project can turn into a hellish, long, drawn out process without bringing in any income to the project. Please ask yourself if there is a proper process in place to close the project to everyone’s satisfaction.

There are other questions you may ask while performing a risk analysis for your project but these should point you in the right direction. Above everything else a PM should realize that there are no certainties in a project - the best you can do is to plan for known risks and be flexible enough to be able to meet unknown challenges if they arrive. Keep in mind, too, that risks may also be positive and be prepared to take advantage of such risks should they materialize.

A great tool for basic risk analysis is available on the Leading Answers blog. Although the excel spreadsheet (available for free download) is geared towards the IT industry, it may inspire you to come up with something similar for your own needs.

Project Manager vs. Construction Manager

A good friend of mine and I were having this discussion the other day when he said, "The only difference between a PM and a CM is that the construction manager does not care about the cost of the project because he just wants to get things done, while a project manager does care about the cost of the project."

Although I do not agree with the part about this being the only difference, I do agree that this is at least a major distinction between the two positions. Temperamentally speaking, a good construction manager needs to have a perfect understanding of industry codes and best practices geared towards resolving a technical problem. He or she is the embodiment of what engineering means - practical application of scientific theories and methods. A good project manager, on the other hand, needs to go beyond the engineering aspects of the job. The practice of the art and science of project management needs you to be a meld of an engineer, an accountant and a lawyer!

I have seen more than one project fail because the PM did not exercise an adequate control over the costs of the project. In one of my recent projects the PM had come from the construction side of the business. He was a genius in finding solutions to technical or construction problems. But he utterly failed to grasp the concepts of project management techniques that are taught in the various institutions around the world (PMI in the US or the PRINCE2 in the UK, for example). For him the earned value numbers and the performance indices were just some random numbers, not worth giving much thought. This attitude led the project to hemorrhage money till at last he was shuffled sideways and a new PM brought in to staunch the flow.

You as a project manager, more than anyone else in the project, have to be aware of the following: You are there to make money for your bosses. Every other condition is subservient to this aim. A successful completion of any project involves, in equal measure, cost control, schedule control and scope control – cost control just happens to be the first among equals. At the end of the day everything leads to a cost. If your project takes longer to finish it will cost you more unless you can persuade your clients to pay for the delay. If you do more than you were contracted for you will not recover your additional costs unless you can show – using change management processes – that your clients made you work more. If the quality is shoddy, if the resources are not adequate, if your plan was not the most optimum, if you did not do your risk analysis, at the end of the day it will all lead to higher cost for your business, either today as your project loses money or later as you lose business due to poor deliverables.

15 Ways to Demoralize and Demolish Your Team

1. Be unpredictable. Unpredictability breeds confusion and insecurity in people. 
2. Change responsibilities at random. Not being clear on what you required them to do to perform their job is like applying a powerful brake to productivity. 
3. Make the work environment uncomfortable - windows are overrated, screaming is good. Discomfort in the work environment is a surefire way to make your team lose any desire to do their jobs. 
4. Give instructions and then change them after some time. Make your team members feel that they are idiots for doing what they believe they were told earlier. 
5. Do not communicate the stakeholders' wishes to the team and, later, berate the team members for not divining and producing desired results. 
6. Play favorites. There is nothing like knowing that the boss likes some more than others, especially if the feeling is based on personality more than on knowledge and competence. 
7. Ignore your team members. Ignoring people can be infuriating and disempowering at the same time. 
8. Make people responsible for something but then withhold their power to demand inputs from other team members. You’ll be able to claim incompetence when they find themselves unable to comply with your instructions. 
9. Be stingy with praise. Praise is a valuable commodity; do not waste it on everybody. 
10. Praise someone but then criticize them behind their backs to others. This way people will know that if you praise them you will be plunging your knife in their backs as soon as they turn away. 
11. Earn their fear, not their respect. Fear is one of the greatest demotivators that exist. 
12. Show emotional outbursts and don't follow through on your pronouncements. 
13. Schedule maintenance work on their equipment just when they need it most. 
14. Make sure to let them know that their works are worthless pieces of junk and that their knowledge counts for nothing when compared to your years of vast experience in the industry. 
15. Put a lock on your door - you do not need to talk to all the riffraff working under you. 

If you liked the article please click on the +1 button below.

Performance Indices – A Primer

After my post on the utility and applicability of CPI and SPI I was asked by some of my readers, not very well versed in PMI terminology, what exactly did these terms mean and how they were calculated. I thought I’d dedicate this post on explaining in laymen’s terms, in as much as possible, what these indices did, where they came from and what the numbers, once calculated, meant.

What are they?

The Project Management Institute (PMI) defines the Cost Performance Index (CPI) as the ratio of the value of work that you have performed and the actual cost that you have incurred in performing that work. The Schedule Performance Index (SPI), on the hand, compares the value of the work you have performed at a certain point in your project to the value of work you were supposed to have performed by that time according to your plan. The value of the work performed or Earned Value (EV), the Actual Cost (AC) of the work performed, and the value of the worked planned at that time or Planned Value (PV) may be represented by either dollar values (money) or the number of resource hours for each of these values. The reason resource hours (or man-hours) may be used in place of real dollar figures is because in most projects the resource hours very closely parallel the dollar value of the project. There might also be confidentiality issues where you may not want to release figures representing money.

So, okay, how are the CPI and SPI calculated?

Suppose, at a certain stage of your project, your schedule was planned to be at 100 man-hour level. However at that particular point in time, in the real world of project execution, you have already spent 120 man-hours. Does this mean that you have overspent your budget? Not at all – you don’t have all the information yet to decide one way or the other. You still need to know what is the value of the work, as per your plan, that you have completed while spending these 120 man-hours. To get this number you go back to your plan and add up all the numbers of man-hours that you had originally budgeted for the activities that you have completed till now. Suppose you have completed three activities where you had originally planned to spend 30, 40 and 20 man-hours respectively and you are 50% done with an activity where you planned to spend 50 man-hours. In this case your total EV will be 30 + 40 + 20 + 50% of 50 = 115 man-hours.

Now you have three numbers: your Planned Value (PV) equals 100, your Actual cost (AC) equals 120, and your Earned Value (EV) equals 115. You use these to calculate your performance indices as follows:

CPI = EV/AC = 115/120 = 0.96

SPI = EV/PV = 115/100 = 1.15

Okay, now I have the numbers but what do they mean?

Generally speaking, values over 1 are good and the values below 1 are bad. In the above example a CPI value of 0.96 means that you are slightly over budget and maybe you should start looking at ways to optimize your resource use without compromising quality. On the other hand, your SPI of 1.15 means that you are ahead of your scheduled progress.

Now it is time for you to start evaluating the various scenarios – can you reduce your work force and make them more efficient so that you get more production out of them without falling behind in schedule? Do you need to streamline processes so that your labor may not need to waste time? Is it possible to use local resources instead of importing material and expertise? Are there any signs of gold plating and scope creep that may be affecting your costs? This is when the second part of real project management comes into play – go, have fun!