Whenever I have a chance to teach a project management course at BCIT (British Columbia Institute of Technology) or in corporate environments, I usually start my class by presenting my students with the following scenario:

”Imagine, that I walk into the most upscale and exclusive car dealership in your city and ask for the latest model of a Ferrari with a number of custom features. I also specify that I will need a car by tomorrow and that I am willing to pay $5,000 for it. What do you think would be the reaction of the salesperson?”

By the time I am done with my story, most of the students in the class are giggling and exchanging puzzled looks. Finally one or two of them present me with the following scenarios:

• A car dealer would kick me out of the showroom 
• He would call the police 
• He would call an ambulance to have my mental facilities checked.

After the excitement subsides, I ask another question, “How many of you have witnessed a variation of this in your project management career?” This question is usually greeted with silence and somewhat painful expressions on people’s faces.

So, why do we keep seeing scenarios like this one in our professional lives? Are we not doing our jobs properly or are we just extremely unlucky? What’s wrong with our estimation efforts and what can we do to fix them? In this article I intend to analyze the key root causes for our estimation failures and provide some tips that should make life easier.

What are the Root Causes? We are Bad at Estimating

It has been proven by numerous studies that humans invariably tend to underestimate the time and the effort required to accomplish certain tasks. This phenomenon is applicable even in the situations when the person providing the estimate is an expert in the technical field.

Another contributing factor is that the estimation process, no matter how sophisticated, is a guessing exercise similar to weather forecasting or stock market predictions. Our everyday experiences confirm the fact that either one of the above undertakings is prone to wild variations and inaccuracy.

We Ignore All Available Degrees of Freedom

Projects in the technology world are frequently measured (sometimes for the purpose of false simplification) on a one-dimensional scale, i.e. time. Most of the projects usually start with a supervisor or customer approaching the project manager and saying: “Hey, I have a project for you; it needs to be completed in six months … Can you do it?”

For the rest of the journey the only variable in the project is the deadline. It either can or cannot be moved along the time axis to the right or to the left of the desired completion date. Needless to say, the more it is moved to the right of the desired milestone, the higher the rate of customer dissatisfaction. All other dimensions of the software development project including effort (manpower), scope and quality are usually ignored, thus removing additional (and very valuable) degrees of freedom.

We are not very good at understanding our counterparts and at negotiating

Finally, there is another key obstacle that both IT and business sides find very difficult to overcome. On one hand, business people usually do not have any expertise in technology, requirements gathering or project management. While it is fairly obvious to an “average” person that a customized Ferrari cannot be sold by the dealership for $5,000, he will usually have a very hard time understanding why a “simple” web development project can cost $100,000.

On the other hand technical people are either too intimidated or too lazy to explore different options that will allow them to properly align the technological capabilities of their departments with the business needs of their customers.

Do not set yourself up for failure even before the project has started

Warning: in order to understand this concept we need to revisit university statistics!

If you assign the same project to identical teams, repeat the experiment infinite number of times and plot the cumulative frequency of project durations of the XY plot, here is what it would probably look like

Note, that the area under the curve shows the probability of finishing the project on or before the specific date. In this particular example, six months is an absolute minimal time needed to accomplish the project.

For the purposes of our exercise let’s assume that the expected duration of the project is nine months; i.e. there is a fifty per cent chance of finishing the project before the nine-month mark and 50% chance of finishing after. This point is marked as the “Fair Estimate” in Figure 1.

What happens if you succumb to the customer’s pressure and agree to deliver the project in, say, seven months? (Figure 2) Suddenly the chance of delivering the product on time decreases from a relatively comfortable 50% to approximately 20%.

What would happen if you come under even more pressure and agree to a four-month deadline? It is obvious that the chances of finishing the project on time are now zero! The ironic aspect of this situation is that you haven’t even started the project yet …

In some cases project managers “cheat” by padding their estimates. Let’s examine what happens in those cases. (Figure 3)

It is obvious that, by padding their estimates, project managers can increase the chances of finishing their projects on or ahead of schedule. Typically, while somewhat effective in the short run, this technique usually backfires in the long run. Eventually management and/or customers will notice that, for some reason, your projects take longer and cost more money than similar projects handled by your peers.

Having said that, there is at least one scenario where padding is justified, providing it has been communicated to the customer. What happens if you are responsible for a regulatory project that has to be completed by a specific date? Would a 50% probability of finishing on time be sufficient to the customers? Probably not. In such cases giving your team 12 months to deliver the project (see Figure 4) would most likely be more appropriate than nine months.

Cone of uncertainty

One of the most counterintuitive things about estimating is the principle of uncertainty. We are used to think of estimate as a single number, e.g. “we will finish this project in six months”, “this project will cost us $15,400”, etc. Interestingly enough, the guide to Project Management Body of Knowledge (PMBOK) defines the estimate in the following manner:

“An assessment of the likely quantitative result. Usually applied to project costs and durations and should always include some indication of accuracy (+/- x percent).”

This definition implies that the estimate, although a solitary number in our minds, is actually a range with an implied minimum and a maximum. If we look up the PMBOK guidelines for estimation we will discover that recommended estimate ranges are:

• +75/-25% for the Initiation stage 
• +30/-15% for the Planning stage and 
• +10/-5% for the Execution and Control stages

In other words if the actual cost of the project turns out to be $100,000, it is absolutely acceptable for the project manager to provide the customer with an initial estimate ranging from $175,000 to $75,000.

The study of IT and software companies conducted by Barry Boehm (the “father” of software economics and estimation) demonstrated the funnel for software development projects was even wider. Among other things it showed that even good software development companies were in +300% -75% accuracy range when estimating early in the project life.

Work with all the degrees of freedom: Understanding The PM pentagon

Approximately five years ago I was introduced to the concept of the project management pentagon (I was using a triangle before). While it is very similar in its concept to the PM triangle, the pentagon differentiates between the concepts of “Cost” and Effort” and between “Scope” and “Quality”.

The first differentiation is explained by the fact that some companies (especially government agencies) usually have a fixed headcount (i.e. effort) but frequently have enough funds to outsource work to contractors.

The second differentiation is, in my opinion, more important for project managers because it acknowledges the fact that the number of features produced and their quality do not necessarily go hand-in-hand. If you are having difficult time understanding this statement, try to remember the first Windows 95 release. The operating system had a lot of new features when compared to the previous versions of Windows. The quality of the program, however, was far below the level required by customers.

Transition from the one-dimensional approach, described earlier, to the five-dimensional picture provides project managers with more flexibility and opens more options. Once the project is assigned to you, start analyzing alternatives and asking questions like:

1. Do we have a fixed or a flexible deadline? Can it be moved? 
2. What is the size of the team assigned to this project? If we discover that we need a larger team can we get extra bodies relatively easily? 
3. If we can’t increase the team size, do we have enough money to outsource some of the work? Will this be permitted? 
4. How flexible is the scope? Which features are “Must-have” and which ones are “Nice-To-have”? 
5. What about quality? Will we have to fix all the bugs or just 95% of the key ones?

Obtaining the degrees of freedom

I like to call this a game of “How Badly Do You Want This Project To Succeed?” With proper preparation this is one of the most exciting tasks a project manager gets to do in any project! Once you have formed your initial opinion of the project and have analyzed the above questions, try channeling your curiosity towards customer and/or your own management. Here is a list of sample questions that you can use to improve the chances of the successful delivery of your project:

• Can we deliver only the “Must Have” features? (Scope) 
• Can we split the project in two phases and deliver certain features later? (Scope) 
• Is it possible to even cut some of the features? (Scope) 
• Do we really have to perfect and hone all the requirements? Can we relax certain design attributes? (Scope) 
• Can you (your boss) provide me with more programmers? (Resources) 
• If you (your boss) can’t provide me with more programmers, can you assign more experienced ones? (Resources) 
• Can you (your boss) provide me with a more experienced business analyst, tester, architect? (Resources) 
• Can you (your customer) be more involved in the requirements elicitation process? (Resources) 
• Can we set a schedule goal but not an ultimate deadline? (Time) 
• Can we use estimation ranges, and agree to refine them as the project progresses? (Time)

As I have mentioned earlier, there are two surprising aspects to this methodology. Firstly, you would be surprised how many different doors open for you when you ask proper probing questions! Secondly, if the answer to all of the above questions is an emphatic “No, I can’t do that!” you can draw your own conclusions about how much your customer and/or boss are interested in the successful delivery of the project.

Change your strategic approach: Presenting your estimates properly

We have already discussed the fact that an estimate is not usually a single number but a range that typically includes a minimum and a maximum. Here is a list of other options for effective estimate presentation:

• Plus-or-minus qualifiers – e.g. “6 months ± 2 months” 
• Ranges – e.g. “4 months to 8 months” 
• Cases – e.g. Best case – 4 months, Most likely – 6 months, Worst case – 8 months 
• Coarse dates and time periods – e.g. “three-quarters” instead of “270 days” 
• Confidence factors – e.g. “We are 95% sure the project will be done in between 90 and 118 days

Pre-packaging available options for better understanding

Here is how you can take your estimation methodology one step further and really impress your management and clients. Let’s assume that you have been given a project described in Figure 1 i.e. there is a 50% chance of delivering the project in nine months. Your boss, of course, expects you to deliver the project in seven months. Instead of saying “yes” or “no”, you can prepare a list of possible scenarios that may look something like this:

OPTION 1:		OPTION 2:		OPTION 3:
Scope:	Remains the same	Scope:	Decrease number of features by 20%	Scope:	Decrease number of features by 10%
Time:	Seven months	Time:	Seven months	Time:	Seven months
Effort:	Add two developers and replace the business analyst with a more experienced one	Effort:	Remains the same	Effort:	Replace the business analyst with a more experienced one

Beware of these difficulties:

So, what are the drawbacks of these methods? I have to be honest; there are a couple of aspects associated with this approach that can make your life a tad more complicated.

Firstly, you will have to be more courageous than before. Your bosses and customers may be somewhat “surprised” if you start grilling them with questions outlined in the “Obtaining The Degrees Of Freedom” section. I have personally been in situations where customers’ and/or management’s reaction to such questions ranged from surprise to utter outrage. However, the good news is that it only takes one successful run through the project to completely win these people over and have them convinced of the effectiveness of this technique.

Secondly, you have to do your homework every time you meet with the customer. You need to be armed with some historical data and/or PERT estimates to be able to prove your case. This implies dedicating a certain amount of time for going through “what if” scenarios, and having enough academic knowledge in the estimation methodologies.

Finally, you have to be able to put on a “business thinking” hat. Your manipulations with the project management pentagon have to make business sense; otherwise your whole effort will be wasted.

Conclusion

To sum up, here are the steps you will need to take to greatly improve your estimation efforts:

• Understand the relationship between estimates and probabilities 
• Use the “Cone of Uncertainty” to your advantage 
• Understand the project management pentagon concept and utilize it to obtain various degrees of freedom for you and your project team 
• Learn to present your estimates properly 
• Do your homework 
• Be brave and don’t forget to put your “business thinking” hat on when talking to customers!

Good luck with your projects!

---

Jamal Moustafaev, BBA, MBA, PMP is president and principal consultant at Thinktank Consulting (www.thinktankconsulting.ca, an industry leader in providing management consulting services to North American software development companies and IT shops. Services include: project management and requirements engineering; business analysis consulting and outsourcing; process improvement programs and audits; business process re-engineering; change management; requirements engineering; estimation; project management; portfolio management; IT business alignment and training. Jamal Moustafaev can be reached at [email protected] or at 778-995-4396

Will polar bears die because of global warming? Most likely not, as they, like any other living creatures, are capable of adapting. Of course, if global warming turns out to be extreme, no adaptations the polar bears make will help them find suitable habitat. Nevertheless, the ability to adapt is a distinctive feature of all life.

Adaptive management is a structured and systematic process for continually improving decisions, management policies, and practices by learning from the outcomes of decisions previously taken.

In the 1970s this power of adaptation was researched by a group of ecologists that included C.S. Holling and Carl J. Walters. They did this to find the answers to the questions such as how to predict fish stocks when they are dependent on many uncertain factors related to human activities. The scientists came up with the idea of adaptive management or adaptive resource management. Essentially adaptive management is ‘learning bydoing’. It is a structured and systematic process for continually improving decisions, management policies, and practices by learning from the outcomes of decisions previously taken. Since then, adaptive management has become one of the key approaches in environmental engineering. Examples of adaptive management implementation for large-scale natural resource management projects include the Everglades and Grand Canyon National park. The US Department of Defense has been exploring adaptive management concepts for environmental cleanup at Navy facilities. The National Oceanic and Atmospheric Administration has utilized adaptive management for coastal habitat restoration activities.

Many engineers from different fields are using a number of basic principles of adaptive management without actually understanding the work done by Holling and Walters. In 2001, a group of prominent software gurus met in Snowbird resort in Utah and discussed effective software development processes. They came up with what is called “Manifesto for Agile Software Development”. This document offers a number of basic principles, which are similar to the adaptive management concept:

• Regular adaptation to changing circumstances, including changing requirements 
• Constant collaboration in project teams and with clients 
• Iterative development processes

At the same time, authors of the Agile Manifest suggested a new idea: effective adaptive management is possible only in creative business environments with self-organizing teams and trusted and motivated individuals.

Ideas related to agile project management spread rapidly beyond software development. Many teams and organizations are actively applying the agile approach to complex projects. One of the ‘relatives’ of agile project management is flexible product development. Flexible product development offers an ability to make changes in the product even later in the development cycle.

Agile project management and other similar methods are focused mostly on the organizational aspects of adaptation process. Two principles are the most important:

• Iterative decision-making or making choices based on learning from the outcomes of decisions previously taken. 
• Strategic flexibility or avoidance of irreversible decisions

Adaptive management processes originally developed by the ecologists were much broader. In addition to organizational principles, they include quantitative analysis methods, which would help to make better choices based on actual project performance, particularly:

• Multi-model analysis and hypothesis testing 
• Actual performance measurement 
• Quantitative project risk analysis

Here is the essence of adaptive project management: projects are managed based on learning from actual project performance and these learnings are obtained and analyzed using quantitative methods.

Why Adaptive Methods are not Widely Accepted?

There is only one living species in the world that often actively resists adaptation – humans. In particular, project managers often do not realize that adaptive methods will most likely bring better project results than traditional project management processes, where the project plan is defined upfront. 

Many organizations embrace adaptive management methods and techniques. Many software development companies and teams actively use some principles of the agile approach. Nevertheless, traditional project management processes still dominate the field.

Why are project managers so reluctant to embrace adaptive management? The answer lies in human psychology. There are a number of psychological biases that act to prevent people from accepting adaptive principles.

Tendency to be Consistent

Very often politicians blame each other with being inconsistent and this inconsistency is often interpreted as a character flaw, “Three years ago you supported something, now you are against it, are you a flip-flopper?” In reality, inconsistency may be not so bad, if it is based on changing circumstances or new information. For example, if a politician initially did not accept a human role in global warming, but changed his mind after reading new scientific evidence, this is probably a good thing. The world is always changing; new or additional information is revealed and decision-makers must adapt to the new information. In fact, the best politician would be somebody who adapts to changing circumstances rather than sticking to outdated strategies or policies

When people are accused of inconsistency, they tend to become very uncomfortable, something often used by police interrogators and lawyers to uncover information. They try to put people in the position when they make inconsistent statements and then extract necessary information.

The tendency to embrace consistency is very common in project management. When there is new information about the project and it is important to make changes very fast and without any hesitation, the tendency to consistency is often an obstacle to making these crucial decisions. If a device does not work, sometimes it does not make sense to fix it. Building a new device could be a better solution. Project managers have to be willing admit the error and adapt to the new circumstances.

In addition, even if individual project managers are capable of making U-turns, the corporate culture may not support it. Senior management often frowns upon managers who stray from the project plan.

Sunk Cost Effect 

In 1996, NASA selected Lockheed Martin to design, build, and fly the X-33 Advanced Technology Demonstrator test space vehicle. The X-33 was to be launched vertically from a specially designed facility and to land on a runway at the end of the mission. 

The construction of the X-33 was more than 85 percent complete; however, in 2001 the X-33 project was cancelled. What happened? The composite liquid hydrogen fuel tank failed during testing in November 1999. In response, Lockheed Martin proposed to complete the development of the X-33 by replacing its two composite liquid hydrogen tanks with aluminum tanks. However, NASA concluded the benefits of testing the X-33 in flight did not justify the cost. The X-33 would not be able to reach space with aluminum tanks.

NASA’s investment in the X-33 program totaled $912 million. Despite the huge expenditure, NASA cancelled the program. They essentially resisted the sunk cost effect: The tendency to invest more money in a venture in an attempt to recover previous losses. This psychological effect usually prevents project managers from performing adaptive actions. Instead of stopping work on an ineffective project or course of action, they pump more and more into it with the hope of somehow reviving the project.

One of the examples of sunk cost effect is the Concord aircraft project. French and British government continued to fund this aircraft even when it became apparent that it was no longer economically feasible.

Guilt of Indecisiveness

Organizations expect managers to make decisions, even if the managers do not have the reliable information required to make these decisions. Instead of collecting information and analyzing data, which may give the appearance of indecisiveness, project managers make irreversible decisions intuitively, based on their “gut feel”. This style provides an appearance of decisiveness and leadership, regardless of the quality of the decisions. 

In reality, it is very important to analyze when and what additional information is required, how much this additional information will cost, and how waiting for additional information would affect the project’s bottom line. In other words, it is important to use adaptive management.

How Adaptive Management Work? 

Traditional project management processes include the phases of project planning, execution, monitoring, and control and evaluation. If, as a result of an evaluation, it was found that something did not go well, this learning may be used in future projects. 

Adaptive management processes can be active and passive (Figure 1). The main objective of passive adaptive management is to incorporate the process of learning into existing management approaches. The information obtained from each iteration of the project can be used on subsequent iterations. This way, risk and uncertainties associated with each iteration, can be significantly reduced. Passive adaptive management is used as a part of the agile approach.

Figure 1. Traditional project management process versus active and passive adaptive management processes.

The goal of active adaptive management is to learn by experimentation to determine the best management strategy. The process starts with hypothesis generation, which involves the selection of multiple alternatives for the strategy. The next step is the creation of multiple models. In practical terms, these models are usually project schedules with a set of risks and uncertainties for the particular iteration. All alternative models should be evaluated using quantitative analysis. The outcomes of this analysis are duration, cost, chance of meeting deadlines and other parameters of the iteration that may help to select alternatives for execution.
In most cases, only one alternative model will be selected and executed. However, in cases with significant risks and uncertainties, especially in software development projects, it may be more efficient to execute a number of alternative models at the same time.

Here is an example how active adaptive management can be used:

1. Define a project strategy and high-level project plan. Make sure that you provide strategic flexibility: leave room to reverse previous decisions if necessary. 
2. Split this project plan into multiple phases or iterations. 
3. Define a more detailed plan for the next phase or iteration. Do not create detailed plans for future iterations, as they may change due to the outcomes of previous iterations. This plan should include a schedule and list of risks. You may choose to create multiple alternative project scenarios (project schedules and risks list) for the same project phase. 
4. Perform quantitative risk analysis. Different project scenarios may have similar cost and duration, but have a different risk profile. Quantitative project risk analysis will help to determine what will happen with project schedule if certain risks occur. By analyzing this ‘realistic’ project schedule you may choose a scenario to execute. 
5. Execute one or a couple of project scenarios and continuously measure actual results versus original plan. Then perform quantitative risk analysis again. If the project is partially completed, you may have a better idea of which risks actually occurred, and which ones did not. Also, you should be able to calculate the chance that a risk will occur using the performance data. Figure 2 shows how the results of such analysis may look.

Figure 2. Actual project performance measurement and quantitative risk analysis of partially completed projects.

Currently there are a number of advanced project management and risk analysis tools available to perform quantitative analysis. These tools are easy to use: complex math will be hidden inside the software.

Conclusion and Recommendations

Adaptive management is a structured project management framework. It is not a formalized process that must be strictly followed. This framework can be tailored to different types of space system design and acquisition projects. Principles of adaptive management are strongly endorsed and actively used in many industries, such as information technology and environmental protection. 

Rule number one of the adaptive management is simplicity. If adaptive management does not bring tangible benefits and causes extra organizational burdens, ineffective procedures should be abandoned as soon as possible.

Adaptive management includes the basic principles of agile project management, such as iterative processes and creative business environments. In addition, adaptive management involves the active use of quantitative methods to measure project performance and apply learning to improve decisions.

Below are practical recommendations related to the implementation of adaptive management for both hardware and software projects: 

1. Whenever possible, do not define a detailed project plan upfront; instead, use an iterative project management approach. 
2. Always identify multiple project alternatives or hypotheses; model these alternatives and, if it is deemed beneficial, start implementing a few alternatives at the same time. 
3. Use quantitative risk analysis at each phase and iteration of the project. 
4. Integrate original assumptions and new learning when planning next project iterations. 
5. Try to minimize the cost of decision reversals; minimize risk by keeping the option to change project direction available. 
6. Ensure that adaptive management is implemented within a creative business environment characterized by a collaborative structure for stakeholder participation and learning.

Future Reading

Holling, C. S. (ed.) 1978. Adaptive Environmental Assessment and Management. Chichester: Wiley
Kodukula, P., and Papudesu C., 2006. Project Valuation Using Real Options. A Practitioner’s Guide. Fort Lauderdale, FL: J.Ross Publishing
Project Management Institute. 2004. A Guide to the Project Management Body of Knowledge
(PMBOK® Guide), 3rd ed. Newtown Square, PA: Project Management Institute.
Virine L., and Trumper, M. 2007 Project Decisions: The Art and Science. Vienna,VA: Management Concepts.
Walters, C. 1986. Adaptive Management of Renewable Resources. New York: Macmillan.

 

---

Lev Virine has more than 20 years experience as a structural engineer, software developer, and project manager. In the past 10 years he has been involved in a number of major projects performed by Fortune 500 companies and government agencies to establish effective decision analysis and risk management processes as well as to conduct risk analyses of complex projects. Lev’s current research interests include the application of decision analysis and risk management to project management. He writes and speaks to conferences around the world on project decision analysis, including the psychology of judgment and decision-making, modeling of business processes, and risk management. Lev received his doctoral degree in engineering and computer science from Moscow State University. You may reach Lev Virine at [email protected]

 

Part 1: The Last Planners

Lean manufacturing programs like ”Achieving Excellence” are being implemented at an increasing rate now in North America. They promise to improve competitive positioning and increase profitability in the global economy. In their pursuit of excellence, more and more companies are also looking to Lean Project Management (LPM) as the next big thing to implement to better manage non-recurring activities.

Hence, the words lean project management are used all over the place by a lot of people nowadays. LPM is really not well understood, however. In this context, a few blog entries presenting the main rules of LPM, as I see them, might help us all better understand under what conditions project managers can really claim to use and live by lean principles.

Last thing comes first in LPM. So I’ll start with the “Last Planner.” The worst I heard about this is that it was a software package. So I guess some explaining is necessary. The Last Planner is a principle originally promoted by the Lean Construction Institute¹. Its systematic use “Last Planner System” was developed by Glenn Ballard for his PhD thesis². The last planner is defined as the person who will execute the planned work in a project. One of the most important last planners is ultimately the end-user of the product of a project, because he is the one who will materialise project benefits.

Simply put, the last planner approach states that “the one who will execute the planned activity is the one who must plan the planned activity.” As simple as that! Why? Project success is achieved through a series of planned promises made by some people who work very hard to meet the promises they have made! As we all well know from our failure to make our spouses, best friends, children, etc., keep promises we have made for them, making promises for others does not work. And this becomes a certainty when we try to make promises for the almost pure strangers around us, like our employees, co-workers, collaborators and business partners, regarding how they use their time. .

This principle of the last planner first came from the realisation that centralised planning did not work for construction projects, among others. Project managers using centralised planning have to admit that, very often, a time comes when the project is in complete turmoil, with the building falling apart, water pipes bursting, the construction workers and very expensive machinery waiting (while being paid for) for conflict resolution. They finally realise that it would have been less costly to win the collaboration of their stakeholders while they were at the planning stage than later while witnessing destruction work. So the last planner principle is about getting the right people making the right promises as early as possible. It is about negotiating a plan that people adhere to because part of it is their personal plan, their sacred promises for which they truly feel responsible. And more important, both the project and its last planners are bound to benefit from those promises, a sine qua non condition to meet for effectively building and mobilising project teams.

So LPM rule No. 1 is: The one who executes the work is the one who plans the work

¹ www.leanconstruction.org/
² www.leanconstruction.org/pdf/ballard2000-dissertation.pdf

It’s April 28 and I am sitting in a breakout room at ProjectSummit * BusinessAnalystWorld in Philadelphia, PA – our first event in this beautiful city – and thinking about the keynote we just heard as well as the keynotes at our Toronto event two weeks ago.

There are some very strong messages in all of them.

Michael ‘Pinball’ Clemons opened the Toronto event. I would have to say that in the 12 years I have been running these events, he was the most powerful, exciting speaker of all! The messages – there were many – focused on the TEAM. Working with people is the key to our success, he suggested. Treat your ‘peeps’ well (my terminology, not his) and you will be rewarded. Say thank you – say you are sorry, admitting a mistake when necessary. Show some vulnerability. We are all human and the sooner some of us realize this, the better off we will all be. Pinball challenged us all to think about the TEAM around us. We cannot do it alone.

Simon Cotter opened day two in Toronto and talked about humour – making it work for us in the workplace. He was funny himself but his message was clear – humour can work for you. However – his warning was very clear as well – don’t blow it – because a weak attempt at being funny can be very dangerous.

This morning in Philly, Susan Miller opened with a speech called “I’m Working in the Positive Zone”. It was a very lively and amusing look at how to stay positive and work in a zone that encourages a kinder, gentler approach to our projects that will benefit everyone around us.

I liked an acronym she threw out – AIA. All human beings want to feel Appreciated, want to feel Important and want to be Admired. If I look at my fellow workers with this in mind, she suggests, my world will change.

She also threw up the acronym – START.

Smile – first thing every day – before you even get out of bed – like a daily exercise.
Thank someone or something every day for what you have and what you might be able to do out there
Anticipate – expect the best – work your plan – have a plan
Remove any doubts – believe you can do anything
Team – you can’t do it alone – respect the potential contribution of anyone and everyone around you.

Three speakers – three different messages but some great advice for all.