Dear PM Advisor. May 19, 2014

Dear PM Advisor,

I work at a consulting firm that is developing a lot of small IT projects at one time. I've been trying to get the steering committee interested in using the Software Development LifeCycle (SDLC) that I used at previous companies but my proposal got squashed immediately. Enclosed is a project plan template that is very similar to what we used at UPS and Medco which made IT DEV project management run very smooth (not to mention both were multi-billion dollar corporations). 

My point is, if it worked successfully there, I don’t see why we cannot implement this strategy/methodology here. I understand that we have a SDLC methodology here (scaled down – that NO ONE uses) but adding this release calendar to just the IT dev projects would add tremendous value to both the PMO and IT. 

Personally, I think IT would love this methodology in place (I know I do). Let me know your thoughts.

Tied up in Morristown, NJ

Dear Tied up.

It all seems quite reasonable. Why not use these tasks when you plan your projects? You can guide the team members to come up with the wording you want. Sometimes they’ll balk and you use their wording but it means the same to you. That’s what I do when I plan projects. Here’s the conversation:

“So the first thing we need to do is plan this project, right? How about we say Concept proposal? Have you done that already? You have? Good. Then we have to Identify vision and scope. That’s what we’re doing now. Do you know the deliverables? OK, from there we create the project plan.”

And so on until they are using the deliverables and tasks you are familiar with.

I always do that with my projects so that I know what is happening on the project I plan and execute. Often people will add tasks that I don’t have in my template which are specific to that project and the way they do things. I’ll compromise there. 

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

The Art of Project Management - Chapter One

Having recently read Sun Tzu's 'Art of War' I saw many similarities between war and managing projects. Call the enemies risk and chaos and most of the 2,500 year old advice applies quite well. So I am going to dedicate a few posts to what I humbly call: 'The Art of Project Management.' I give Sun Tzu full credit for his observations. I simply paraphrase him to shift the advice to my field.

Chapter One

Laying Plans

1. Sun Tzu said: The Art of Project Management is of vital importance to the company.

2. It is a matter of survival or bankruptcy, a road either to success or to ruin. Hence it is a subject of inquiry which can on no account be neglected.

3. The Art of Project Management, then, is governed by five constant factors, to be taken into account in one's deliberations, when seeking to determine the conditions obtaining in the field.

4. These are (1) The Moral law; (2) Heaven; (3) Earth; (4) The Project Manager; (5) Method and Discipline.

5,6. The Moral Law causes the Project Team to be in complete accord with the senior staff, so that they will follow them regardless of their careers, undismayed by any danger.

7. Heaven signifies night and day shift, winter and summer, times and seasons.

8. Earth comprises distances, great and small and the technologies used to cross these distances.

9. The Project Manager stands for the virtues of wisdom, sincerity, benevolence, courage and strictness.

10. By Method and Discipline are to be understood the forming of the team in its proper extended teams, the graduations of rank between leaders, extended team leaders and team members, the maintenance of vendor supply lines and control of budget.

11. These five heads should be familiar to every Project Manager: he who knows them will be successful; he who knows them will not fail.

12. Therefore, in your deliberations, when seeking to determine to best project, let them be made the basis of a comparison, in this wise:

13. (1) Which of the two projects is most in accord with the Moral Law?

      (2) Which of the two Project Managers has the most ability?

      (3) With whom lie the advantages derived from Heaven and Earth?

      (4) On which side are methods and discipline most rigorously enforced?

      (5) Which Project Team is stronger?

      (6) On which team are the leaders more highly trained?

      (7) On which team is there the greater constancy both in reward and punishment?

14. By means of these seven considerations I can forecast success or failure.

15. The Project Manager that hearkens to my counsel and acts upon it, will succeed: let such a one be retained in command! The Project Manager that hearkens not to my counsel nor acts upon it, will fail: let such a one be dismissed!

16. While heeding the profit of my counsel, avail yourself also of any helpful circumstances over and beyond the ordinary rules.

17. According as circumstances are favorable, one should modify one's plans.

Dear PM Advisor Aug 27, 2012

Dear PM Advisor,

I was just given a global project to manage and notice how you advise that all team members should be present during the planning session. But my management are notorious skinflints. How can I justify the expense of bringing the three Japanese and European team members to Chicago for the two days of planning?

Local in Chicago

Dear Local,

It's been my experience that few global projects have a budget of less than $250,000; most run into the millions. But let's assume yours is worst case. Let's compare the cost of bringing in the non-local team members to the overall budget. Three overseas flights at about $5,000 each. Three night's accommodations plus meals and taxis in Chicago can't cost more than $1,000 each. You're talking about $18,000 total. That represents 7% of the budget, less if the budget is greater. That's the cost.

Now let's look at the benefit. Having the entire team present during planning is huge! The team building aspects aside, you get every team member seeing what each other does, seeing how their activities lead into another member's activities. They see the critical path being built in front of them, work together to refine the timeline to crash that path. They identify potential risks together and start on early problem removal, they identify all the tasks on the WBS, rather than forgetting those tasks the out of towners would have brought.

All of these things bring about a huge improvement in the planning plus the team building that takes place, the ownership of activities in front of their peers and the camaraderie, all bring about benefits that easily outstrip the 7% deficit you started with.

So run the numbers and determine the exact % of budget that this travel represents. Then show the benefits you will achieve as I've outlined above. If they still object, do the project anyway but keep track of each instance of misstep that could have been avoided if the planning had been done properly. Compile all these mistakes in your project's final report. Maybe your next project will be planned properly.

Good luck,

PM Advisor

Send your questions to bfieggen@gmail.com

Dear PM Advisor July 23, 2012

Dear PM Advisor,

I am running a project that includes members off shore.  The Subject Matter Expert (SME) that was working with the off shore people has left the company so the one of the other SMEs is now responsible for the off-shore work getting completed.  However that SME does not have the confidence in the off-shore that the old SME did and feels he needs to redo all the work the off-shore person does.  How do you get one of your team members to have confidence in the other members?  Or is it a matter of time?  I'm not sure the project can wait until that happens.

Bad Karma in New Jersey

Dear Bad Karma,

This is why team building exercises and co-located project planning sessions are so valuable. You get the team to see each other in action and develop confidence in each other's abilities. Your problem isn't specific to off-shore workers though that helps aggravate things. Because the off-shore team members are not in the meetings to present their work, the SME is able to criticize it without a fair defense. It's your job to defend your team members. I don't believe you can directly get your SME to have confidence in the off-shore workers but you can get him to act as though he had that confidence.

Your SME may have a prejudice against the off-shore team members or he may have a legitimate gripe. Your problem is how to deal with it. Let's start with what not to do:

1. Don't challenge him in the open forum of a team meeting. He will feel attacked and forced to justify his decisions.
2. Don't let it go and hope that time will correct it. Few project problems go away on their own.
3. Don't agree with the SME and have him repeat the off-shore work. Your project budget won't support this.

Instead, take the SME into an empty conference room and ask him to tell you what exactly is wrong with the quality of the work being done by the off-shore folks. Remember that any project is constrained by the following: Cost, Schedule, Scope, Quality, and Risk. Off-shore resources were assigned to a portion of the project with the assumption that they could perform this portion with a lower cost while maintaining the minimum quality standards. Those quality standards should be set on your project or may be found in your corporate policies.

If the SME can show you that the tasks being performed do not come up to those required quality standards, he has a point. Perrhaps the work does need to be revised or even redone. So reassign the work to a competent resource or have the off-shore people beef up the quality of their work before submitting it.

However, since neither you, nor the old SME had a problem with the work in the past, I suspect this is not the case. If the quality is fine, tell the SME that he is adding unnecessary cost to the project budget and perhaps even delaying it by redoing work that was already completed. Show him the negative impact his rework is having on the project's cost and schedule.

If that does not work, remind him that the final arbiter of the project quality is not him but the steering committee or sponsor or whoever is paying for this project, not him. He hay be in the position of determining if the task meets the quality expected when the project was planned but he does not have the authority to add project cost or schedule to bring it up to a higher level of quality that satisfies only him. The implied threat here is that the negative impact you showed him he is having on the project will be shown, by you, to the project sponsor at the next opportunity.

He should back off at this point. Most people are only trying to do the right thing. They forget that they are spending the corporation's money when they try to improve the project they are working on. He's probably a perfectionist at heart and takes this to work. If he doesn't back off, follow through on your threat in the next meeting. Don't throw him under the bus, simply ask the steering committee this question: Should we add x weeks and y thousands of dollars to increase task quality to z or do we maintain the cost and schedule and the original requested quality level? (Any bets on what their answer will be?) Then use their authority to get the SME to trust the off-shore resources.

The last possibility is that the SME has a deep-seated prejudice against the off-shore resources and declares it in your meeting with him. If that happens, it's time to report him to Human Resources to give him a little free education.

Good luck,

PM Advisor

Send your questions to bfieggen@gmail.com

Dear PM Advisor July 2nd, 2012

Dear PM Advisor,

What % of resources on a project should typically be allocated to Project Management?  For example, if I plan a project with 2000 hours of work, how many additional hours should be allocated for project management?

Planning in New Jersey

Dear Planning,

There's a quick question with a long answer.

Start by taking off the technical work that the 'Project Manager' will do on this project. Quite often we wear two hats: that of the PM and that of a technical expert of some aspect of the project. That second part will vary greatly with the project but I'm sure you're already planning for those activities anyway. That leaves you with the pure Project Management activities that will take time.

Let's split these activities up:

1. Planning the project. This depends on how many similar projects you've planned. One project I'm currently running simply required me to pull out the previous Gantt chart and run through it with three key team members for two hours. Other projects require planning from scratch. A 2,000 hour project can be planned using the methodology I teach in about two days. So add these hours in at the beginning. (16 hours so far)
2. Running Status meetings. These require planning, scheduling and preparing as well as the time required to run them. While I keep the actual meeting to 30 minutes, they take an average of 30 more minutes of my time to prepare everything to make it run smoothly for the participants. Run these on a weekly basis until the project is running smoothly, then cut it back to every two weeks during the long stretches when not much happens. Then back to weekly during the busy moments again. If your project lasts 6 months, pretty typical for a 2,000 hour project, plan on about 18 meetings for another 18 hours. (That's 34 hours to date)
3. Putting out status reports. If you use a good template, the first one will take some time but after that, you should be able to update the template and send it to the distribution list in about an hour, less if you're not doing Earned Value reporting. Do one per status meeting for another 18 hours (We're up to 52 hours)
4. Managing the Project. This is the most variable part of the equation. How much management will this project actually require? How reliable are your people? How new is the work being done? How stretched are your resources? How many ad-hoc meetings will you have to set up to resolve project issues? How much time will you have to spend doing Risk Management, Stakeholder Management, etc? The simple project I'm managing, the one where I just dusted off the old Gantt, requires no more than one phone call on average per week. The other two I manage, where we are doing things from scratch, requires my presence about 10 hours per week. The range is so large, I'm not sure I can give you a percentage. So let's break it down further into a menu you can pick and choose from:
1. Risk Management. If your project is formal enough to require this, Risk Identification can take place at the end of a couple of status meetings using the Crawford slip method, then two hours for you to sort these out. Add two session on Risk Qualification for another four hours of your time plus four more hours of Risk Management. (That's 10 hours)
2. Stakeholder Management. Meet with your team for about an hour to identify your Stakeholders and  to decide how to deal with them. Your dealings with stakeholders shouldn't add any time to what's listed above and below, but it may add to the complexity and variety of your communications. (One hour)
3. Managing regular tasks. Walking around, ensuring tasks are going according to plan, warning people when their tasks are coming up. This should be bout an hour a day for projects that require your management, zero for those that don't (0 - 130 hours)
4. Removing Obstacles. This is entirely dependent on how many problems your project is likely to face. The more times you've managed a similar project, the fewer problems. Let's figure 1% of the project time on average. (20 hours)

So what does that all add up to? 72 hours minimum on a 2000 hour project with another 11 for risk and stakeholder management and up to another 130 for managing a newer project or team. Doing the math brings it to 4% for a known project and 10% for a new project with an untried team.

Notice I have only counted up the time spent by the Project Manager. If you want to allocate time spent by team members in these activities, (Project Planning, Risk Management and Status Meetings) add them in multiplied by the number of team members attending. I usually don't. I allocate their time spent in PM tasks to the project tasks they are working on at the time.

Have I forgotten anything?

PM Advisor

Send me your questions at bfieggen@gmail.com

Earned Value Case Study

Using the Earned Value method of monitoring and controlling budget as described in the previous post, I have had almost entirely positive experiences with my clients. One experience didn't start out so positive.

Our project was to validate a computer system. We proposed the project carefully, using past information but making some assumptions based on information given us by our client. One of these assumptions was that the requirements document was in good enough shape for us to write a functional specification. As always, we made these assumptions visible as part of the proposal. (I'll have to write a separate post about the importance of doing this but you'll see how it helped in this case study.)

When we started the project, we found that the specification couldn't be started because the requirements document was in no shape to use as a starting point. We would have to rewrite this and then move to the specification. This meant more time spent on the project and more money.

So, when I showed up at the first status meeting with the earned value numbers, I shocked the client by predicting that the project would end two weeks late and cost an extra $10,000. They were livid!
"You're one week into the project and already you're two weeks behind schedule and $10,000 over budget!" was their response.

They were used to vendors keeping quiet about the overages and schedule delays until the project was almost over and then asking for the extra time and money. My boss was angry at me also because, frankly, that was the way he was used to doing business and he had warned me that being open with the customers was a bad idea. He was afraid we'd be fired from the project.

I met with the customer and explained the situation. I told them it was a good thing to find this problem early because they had the power to do something about it now. By explaining the cause of the overage and delay, I gave them three choices on how to proceed:

1. Continue as we were going. We would rewrite the requirements, then the specification and continue the project. The project would cost an extra $10,000 and take an extra two weeks.
2. They could rewrite the requirements document while we stepped away from the project, then return to restart. This would take at least 2 weeks (the client was super busy) but would cost no extra money.
3. We would rewrite the requirements but the client would take over some of the later tasks (when their workload had diminished) to recoup the $10,000. This would cost them no money or schedule but would take some of their people's time later.

My client was amazed. They were given options on what mattered most to them: time, money or internal resources. They chose option 3 and the project finished on time and on budget. They confided with me later that they were so appreciative of the transparency of our methodology and their ability to influence the course of the project; something they had never experienced with any other vendor. The customer is loyal to us to this day.

The Great Escape Project

As a boy growing up in Australia I loved reading my father's old World War Two books. One of my favorites was "The Great Escape,' a story of a mass escape by Allied POWs, causing a huge recapture effort that diverted German troops from the war effort. Since this was the objective of the project, (the prospect of many of the prisoners actually making it to safety was slim) the project was considered a success. Unfortunately, the German chose to punish the escapees by executing 50 of the 76 who escaped.

But what a project this was! The preparation and planning and duplication of effort to mitigate risks. The incredible details that went into forging all the documents, tailoring the fake uniforms and civilian clothes, the rails for the tunnels, the air circulation system, the radios, the list goes on and on. All of it was amazingly planned. Too bad the execution failed by them ending the tunnel about twenty feet shy of the forest. The whole story was well depicted in the classic movie. Here's the original trailer:

But an article in this week's paper showed just how incredible the tunneling itself really was. A group of British-based engineers, battlefield archaeologists, historians and modern-day Royal Air Force pilots, tried to replicate the work of the prisoners using their techniques and were unsuccessful. They couldn't safely make the tunnels in that sandy soil and had to quit.

Did the prisoners simply have more time and more incentive than the recreators to complete their project? One of these days I'm going to have to study this project in detail from a Project Management perspective and write it up properly.

Anyway, if you have time, check out the four videos below that detail the making of the movie.

Banner-making machine

Ever been waiting for someone special at the airport and seen others there with those big welcome banners and wished you'd been just that little bit more organized? Help is on the way for all us procrastinators.

A vending machine that allows you to create your own banners sits at Schipol airport in Amsterdam just waiting for you to type in a greeting. You choose the size and design and the machine will print it out for you in less than three minutes.

It will create a banner in whatever language you want. The banners cost between $5 and $20 depending on size.

Congratulations to Oliver Janssen and Thibaud Bruna who invented this machine. I wish them much success. Hopefully one will be at the next airport I find myself waiting for a loved one.

Read more about this project in this NY Times article.

Project to capture Bin Laden

No American was yet inside the residential part of the compound. The operatives had barely been on target for a minute, and the mission was already veering off course. Photoillustration by John Ritter.

There was a great article in the New Yorker recently that laid out the details of the mission to capture Bin Laden. One of my students, Pete Thompson, showed it to me while I was teaching him about Project Management and pointed out all the good PM techniques used there. I decided to post about it and do the same for all of you.

Planning: The SEALs trained for months, repeating the steps needed for the raid under all conditions, creating 'memory in the muscle' so that they would be ready for any contingency

Uncertainty: Not knowing what was inside or under the buildings made the project risky. As unknown as any other project. As usual, members of the project team would have to think on their feet and be ready for any obstacles that arose.

Risk: They were unsure that Bin Laden was even in the building when they attacked. Their certainty level ranged from 40 % to 95%. But they knew that waiting longer would likely result in his detection being discovered and the certainty dropping to zero. This is a classic dilemma and best resolved doing exactly what they did. You make a decision based on 80% of the data. If you wait for 100%, you'll never get there and cause massive delays. If you make your decision with less than 80% of the information you need, you'll likely make bad decisions.

Lessons Learned: Carter's disastrous 'rescue' of the Iranian hostages and 'Black Hawk Down' lessons from Somalia gave the team mountains of data on how to create back-up and contingency plans. These all paid off when the first helicopter crashed in the compound. Any worse situations were anticipated by having two back-up teams of helicopters ready to move in from Afghanistan and an unpopulated area of Pakistan.

Stakeholder Analysis: The detailed stakeholder analysis they performed resulted in the decision not to warn the Pakistani 'allies' of their plans. They decided that the risk of Bin Laden being tipped off by this group was too high so they went with secrecy, knowing that there would likely be serious diplomatic repercussions.
Also, when making the decision of burying Bin Laden at sea, they contacted members of the Saudi royalty to see if they would rather take his body. “Your plan sounds like a good one,” the Saudi replied.
Experienced Team Members: Not only were the SEALs in this operation superbly trained, many were veterans of previous rescue operations including the rescue of Richard Phillips, the captain of the Maersk Alabama, from Somali pirates.

Executive Sponsorship: The orders for this operation, from its inception to the 'Go' decision were made at the highest levels of the military: the commander in chief. Obama stayed in touch with the operation all the way through and was ready to take the fall for any failures.

Alternatives Analysis: They decided against blowing up the compound with huge bombs because of the likely collateral damage. Bombs big enough to blow up any bunkers under the compound would be equivalent to a medium size earthquake in the town.

Problems: All projects experience problems and this was no exception. All the practice runs they had done in Nevada used a compound surrounded by a chain link fence. The real compound had thick stone walls that heated up during the day and resulted in a phenomenon known as 'Rotor Wash' downing the first chopper. The team members worked their way around this problem  by changing the landing places of the other chopper and taking more time to get to Bin Laden. They had to destroy the stealth parts of the downed chopper but had enough room on the remaining chopper and the rescue choppers to get out. A tough commander on the ground made the call to continue with the mission rather than abandoning it. Good Project Management! Get through the obstacles that appear.

Self Sacrifice: One SEAL wrapped up two of Bin Laden's wives and moved them away from his team in case they were wearing explosive vests. This would allow his team to succeed, even if he died in the process. Few projects have this kind of life-or-death choice inside but often we are faced with the situation of sacrificing a night with the family or a weekend to meet a deadline. Good team members make these tough decisions with the thought: 'The Project Must Win.'

Project Closure: Obama met with the team, down to the dog, thanked them for all their contributions and presented them with gifts that they valued. He never asked who fired the shot that killed Bin Laden, thereby emphasizing that it was a team operation.

All in all, a well-planned and executed project. Well done SEALs and well done to all the people in the government and military involved.

How to plan a project

Here's an article I wrote a few years back showing how to plan a computer systems validation project. The methodology works for any project and it's the way I've been successfully planning projects for twenty years.

Project management techniques are universal. The proven, time-honored disciplines that make up project management can be effectively utilized and applied by virtually any manager, leader, or team member—regardless of industry, profession, or job title. The same skills I have used to develop and bring medical devices to market I have used to remodel my home and, most recently, validate pharmaceutical systems.

As Vice President of Project Management at QPharma, I train my project managers in a system I have developed over the years called Progressix^SM. The word is derived from three concepts central to my teaching:

1. Progressive elaboration. The concept that a project needs to be elaborated progressively as we move from Idea^*, to Purpose^*, to Objective^*, to Work Breakdown Structure*, to Responsibility Matrix^*, to Schedule^*, to Budget^*, to Risk Analysis^* to full Project Plan^*. The project continues to be elaborated through execution and into closeout. (I first learned this order of project elaboration 9 years ago through a class I took from Cadence Management Corporation and have used it successfully since.)
2. Six honest serving men. I use a poem from Rudyard Kipling to illustrate the key things that need to be known about a project to ensure a good, manageable plan.

I keep six honest serving men

(They taught me all I knew)

Their names are WHAT and WHY and WHEN

And HOW and WHERE and WHO

3. Progress. Using the Tuckman Model, progress is made when the team moves from an awareness phase (which Tuckman refers to as FORMING*) through a conflict / control phase (STORMING*), a cooperation phase (NORMING*), and, finally, a productivity phase (PERFORMING*). This concept is evident with any group and is particularly useful in project teams.

So how do I go about this progressive elaboration? Let me use the example of a computer system validation we recently planned for a client. I became involved in a project that was already underway, because it was in trouble and the client had seen the success I had at projects in other departments.

The project was a corrective action tracking system. I was present at a very contentious meeting where two sides, the Clinical and the Information Services departments, were pointing fingers about how the project should progress. The meeting was very acrimonious, with little likelihood of any work being accomplished in the future.

Someone suggested I intervene, so I asked a simple question: “Who is the project manager?” Two hands rose, and I nodded, expecting them to glare at one another. But they had a different problem. One said she was the project manager from the programming group, and the other claimed to be the project manager from the users’ group. They added that they loved working together. I announced, however, that there can be only one project manager, and they needed to decide who it would be. The programmer was decided upon.

I requested that all the project participants, including the users and heads of the clinical and IS^* departments, be present the following week at an all-day project kick-off session, which I would facilitate. They all agreed and, when the meeting time was decided, I sent out an agenda as shown below:

AGENDA

Time	Item	Led by..
9:00 – 9:05	Check in at room, Introductions	Bruce
9:05 – 9:15	Icebreaker exercise	Bruce
9:15 – 9:30	Project Background	IS & clinical heads
9:30 – 10:00	Project Objective	Bruce
10:00 – 10:30	List of Deliverables	Bruce
10:30 – 10:45	Break
10:45 – 12:00	Work Breakdown Structure	Bruce
12:00 – 1:00	Working Lunch
12:00 – 2:00	Responsibility Matrix	Bruce
2:00 – 2:15	Break
2:15– 4:30	Schedule	Bruce

I arrived early, and posted my responsibility matrix and schedule charts on all the walls. People were slow to arrive (is this an IT thing or is it just me?), but they were all present just before 9:30. I scanned the room and, sure enough, Clinical was on one side, IT on the other.

I started with introductions and then we went into a quick icebreaker exercise, which melted rather than broke the ice in that room. The one I chose was participant bingo, where I had a 5 x 5 matrix filled out with things like: “Drives a red car; Has more than three children; Loves the show Survivor,” etc. People tried to achieve Bingo by taking it around and getting people to sign their names in the appropriate box.

Next, I entered the six serving men scenario by answering the first question: WHY? Both department heads were able to speak their piece. Why are we doing this project? Why is it important to the company? Why is it important to the various departments and participants?

During this project background session, the location of the project, WHERE, was easily answered as only the US offices, nowhere else in the worldwide offices of this company

Then I took over. The room was clearly in a FORMING mode,

No leadership dooms Biggest Loser competition

It amazes me to see how a simple project can be doomed by the lack of a clear leader.

Last night's 'Biggest Loser' featured a simple project. The team had to construct a pontoon bridge out of a stack of large, heavy, inflatable rafts that could be attached to each other to reach an island in the middle of a river. On the island was another stack of rafts with which they had to construct another bridge to reach the other side of the river.

Their rival team had already completed this task and had set the time to beat of 39 minutes.

The team were given a few minutes to strategize and it became clear immediately that they were going to fail. Many people asserted their right to be the leader but no-one allowed themselves to be led by any others. I saw several reasons why no leaders emerged:

1) The game is set up to have the contestants compete against each other in the long run so there was a lack of trust in the short run
2) There was no one vocal leader who asserted their leadership at the beginning
3) Many different people put forward different strategies but no one grasped anyone else's strategy

When the time for planning had ended and the horn sounded to start the competetion, all the contestants knew and even said out loud that they had no strategy. Yet they all started running around with their own plans to complete the project. A couple of minutes of focused planning would have solved this but they all ran straight to their jobs, using competing strategies and getting in each other's way. At times some were standing around waiting for others to do things, some were floating rafts, others were dragging them.

There was no communication before or during the project. People were shouting competing commands but no one was listening to anyone else.

What lessons can we get from this episode?

A) If no clear leader is assigned or emerges during the planning session, you must take the reins yourself or advance the leadership of the person you think is most suited for the job. This leader must be respected enough by the group to allow them to follow him/her for the duration of the project.
B) Even if you are competing with your peers in the long run for that promotion, that key project, that bonus, don't let this get in the way of short-term goals like project success. If the project fails, another PM may get blamed giving you a short-term gain but you also might all be out of a job.
C) Spend enough time to plan the project so that you have no-one working at cross-purposes, even if that time is taking away some of the execution time of the project. You will finish the project earlier in the long run.
Communication means listening to others, not just talking. The old adage of two ears and one mouth applies to project management.