Posts filed under ‘Project Management’
Tricks, Traps and Tips for better Problem Solving
Although you’re more than welcome to send me a note of appreciation and/or order some books as a way to support the costs of providing this service.
Where? Head here for all the details.
If you work for a living, then you solve problems of all types.This session will explore some simple PS concepts and explain how we can use formal, and informal, PS techniques in every day Life.
Peter believes very much in the idea that we learn by doing, more precisely? That we learn by failing at doing.
So??? This presentation WILL be interactive.
1) Make sure you have a deck of playing cards handy.
2) Peter will take ‘questions’ via e-mail as he presents.
Feedback from a similar live session:
Peter … We reviewed the feedback forms this week – of the 90 collected for the Problem Solving sessions, overwhelmingly the ratings were 5s (highest) We summarized the feedback as follows, included member quotes:
‘Over the top’ successful. Very dynamic, excellent speaker.
Members wanted more from Peter; many felt his sessions were too short.
“..energizing & interesting. Very helpful.”
“..too short – was enjoyable & thought provoking!”
“Fabulous, awesome presentation. Great interaction & exercises.
Could have spent the whole afternoon in his session.”
“Excellent session, extremely dynamic presenter! Useful for any level of team member.”
“Peter was the “BEST” part of the day.”
“Please bring Peter back to talk to us.”
Is reading this article the best use of your time right now?
If you can extract the core lesson contained in the above question, then not only don’t you need to read this article, but you never have to attend a course on time management. You’ve just saved a lot of time and money. You can go about your business. Good-bye.
What? You’re still reading? You mean I have to finish this article? I was just about to take a break you know. Okay. Okay. Just for you, I’ll continue, but I have a cold beer waiting on the deck, so hurry up and finish reading… I have better things to do right now.
Time Management isn’t a overly complex topic. When you get right down to it, a good time manager really only needs two sets of information.
1) Which of all the tasks we have to complete, is the most important? And please, don’t adopt the strategy used by some psychotic managers… Everything is Priority #1!
Making everything Priority #1 isn’t possible. When everything on your plate is Priority #1, then the reality is that nothing is Priority #1.
2) How much time do you have available to do the tasks on your plate? If you have time aplenty for everything, then you don’t have a time management problem. Please stop reading so I can leave, that beer is getting warm.
What! Still here? I can see how this is going to play out. Sigh. Okay. On we go.
Since you’re still reading, I can only assume you don’t have enough time to do everything you’ve been tasked to do. (but you have the time to read this article… weird) I won’t ask why you took on more than you can handle, that would be rude.
With more work, than time, we’re faced with a problem. We can’t do everything.
This is perhaps the most important thing to know about time management. Time Management is not about doing everything on our plate, it’s all about deciding what to do, and most importantly, what not to do.
This is where Time Management gets difficult. Prioritizing our tasks is fairly easy, some things are obviously more important than others. Identifying how much time we have, is also relatively easy, since we can start with 24 hours a day and work our way down to a more reasonable/realistic number.
Where we all have a problem is coming to the conclusion that task ‘X’ won’t be done this week, because we don’t have time for it.
Of course, to get to that point, we do need to become proficient at allocating time to the tasks we’re choosing to complete and then focusing our attention on those tasks until they are complete
The most basic tool to assist us in this, is the ‘to do’ list. We all know how that works. List the stuff we must do on top in order of priority, then the stuff we should do if we have time for them, and then at the bottom the stuff we’re unlikely to ever get done (like that rapidly warming beer on the deck).
The mechanics of the TD list aside, there’s an aspect of the TD list that’s rarely mentioned. Part of the problem we have managing ourtime is the overwhelming sense of chaos that swirls around our heads. There’s little more demotivating than the certain knowledge that we’re disorganized, that we’ll never get it all done no matter how hard we work.
This sense of constant chaos cheats us of any sense of progress towards a goal. A daily ‘To Do’ list, compiled during those few calm moments before the day starts with a rushing vengeance, is the perfect solution to our all too common panic attack.
Writing down what we have to do, immediately removes the certainty that we’ve forgotten something. It stops the constant mind juggling necessary to keep everything in memory and allows us to focus on a single task.
Time Management becomes an exhilarating experience as we strike a task off the list with a swooping flourish of a lurid purple marker (am I disclosing too much?). This is such a pleasure, that you’ll find yourself putting things on the list, just so that you can strike them off the list.
The sense of progress we didn’t have before, is now there for all to see as a flurry of purple strokes across the page.
The truth about the heart of Time Management is contained in the opening question. We can’t answer it until we know what we should be doing right now, and how much time we have available. Simple, if not easy. Now, the next thing on my list is that beer. See you later… maybe… if I have nothing better to do. I’m not kidding.
Regardless of our circumstances we often share the same thoughts. The notion “It can’t happen here”, is such a common way of looking at disaster, that even Kissinger got into the act with his famous “There cannot be a crisis next week. My schedule is already full.”
Humor aside, disasters happen regardless of what you had planned for the week. How badly they affect us, is determined by our ability to respond without warning to crisis situations.
The traditional approach to disaster planning is to create a methodology, install contingency plans, ensure that proper backups of crucial data are made, and place all this documentation in yellow binders on a shelf. If we’re diligent, we take it out once a year for some exercise.
This way of planning for disaster, while it provides many benefits, also contains a serious flaw. It’s not so much the cost – insurance of any type always costs money. The flaw is more subtle, but it is potentially serious enough to scuttle the best laid plan.
It is this, Disasters by their very nature, happen unexpectedly. Our success on the day is based upon how we react when we’re confused and don’t know what’s going on. Planning allows us to think through the process of what to do if (when?) something happens, before it actually occurs. That thought process alone is the central core of any contingency plan, but just thinking about it, isn’t enough. We have to go into the water before we know how to swim. We have to live it, to learn from it. Planning for the experience is not the same as experiencing the plan.
How to improve a disaster recovery plan? Given the stated nature of disasters, ‘unexpectedly and without warning’ seems like the right approach.
At 9:00am on a Monday morning, inform 50% (or a mere dozen if that would be too disruptive) of your management team, individually and personally, that they’re leaving immediately for an off site location for an emergency meeting. No prior warning. No details provided. No excuses accepted. All meetings regardless of importance are ignored. No notification to secretaries/assistants or clients allowed. All cell phones and blackberries collected. In other words, just like a real life crisis.
When they arrive via the waiting bus, they’re told of the ‘disaster’ that has taken place. They are to respond to this ‘disaster’ over the next day or two. What is the ‘disaster’? That depends on how severe you want it to be and what you think would provide the best information.
There’s a certain beauty to this exercise – NO PREPARATION IS REQUIRED. (except possibly for the bus) The Exercise starts at 9:00am when your employees are informed. NO hotel is booked – no coffee pre-ordered, no Flip Charts on site.
I already hear the objections… we need to book the hotel in advance otherwise…
Question… on the day our building is on fire, bombed, flooded, the senior exec team all killed in an air crash, captured by ninjas etc. etc. will we already have a room booked? If we cannot manage this minuscule exercise in crisis – then we are fundamentally incapable of handling a real emergency.
Back at the office the remainder of the management team can take the exercise one step further and pretend the entire off site team are victims of a disaster. This secondary exercise might be more than your organization can handle without severely impacting day-to-day operations. The alternative is to merely explain what is going on and cope with their unexpected absence for two days (week?). There is learning even this minimalist approach.
The exercise provides two benefits. First? An immediate and relatively inexpensive evaluation of how well your management team responds to an unexpected crisis.
Secondly? In a very short period of time, with minimal impact to your organization, you highlight those areas most vulnerable to the ‘disaster’ you selected. With that in hand you can now move forward to a ‘real’ contingency plan with specific objectives in mind.
The objections to this exercise are many and obvious. You can’t afford the time. The board would object. You can’t afford the negative impact to the business. Your schedule is full next week.
Okay… I’ll admit it publicly. I’m nothing but a kid at heart. I’m continually astounded by the world around us and tend not to take things for granted. I received a fax yesterday and despite it being an almost ancient technology, I watched with sincere amazement as an image magically appeared out of the little black box, sent to me by a wizard many hundreds of leagues away. (ok, it wasn’t a real wizard. Remember this is a kid writing this article!)
To me, the world is a fairy tale. Did you know that planes can fly? I mean those BIG planes, the ones that weigh hundreds of tonnes. The speed down the runway and make a magical leap into the sky. And more to the point. They stay up there! Must be them wizards hard at work again.
For someone who believes he’s living in a fairy tale, I also read fairy tales. They were around long before user manuals and quite frankly contain more information than most of the poorly written documentation that’s supposed to educate us.
Have you read the fairy tale about stone soup? If you have, then the wisdom it contains just might make you a better manager of technology.
Making stone soup is an old tradition. First you need a stone. Not just any old stone. A smooth stone, river washed until it’s about the size of a large goose egg. Make sure you don’t get one that’s covered in green algae, otherwise your soup will taste foul.
Place the stone in a soup pan and fill with water until the stone is covered by about 2 inches of water, and bring to a slow boil. Taste it. You’ll notice it tastes like hot water. So far? Not very impressive.
Now it’s time to bring out the flavour of the stone. This is not a simple task. A stone is hard and unyielding, it’s not going to present you with flavour unless you find the secret of extracting its natural juices.
First you must dice up some carrots, about 3 or 4 large carrots should be enough. Then 2 potatoes, washed, sliced into1 inch cubes. (Leave the skins on, being close to the earth already, they have a natural affinity to the stone and will entice it to give up a hearty flavour.) Now slice up a beef steak into similarly sized cubes. Finally sprinkle the brew with salt and pepper to taste. Let simmer for about an hour and viola! A hearty stone soup!
Warning! If you try to make stone soup without using the above instructions for extracting the flavour then all you’ll have is a lot of boiling water.
Now stones and sand are mostly silicon, and most technology managers know computers are also mostly just silicon. So we have the beginnings of a metaphor. (work with me on this, I’m working under a deadline here!)
What brought all of this to a boil for me (so to speak.) Was a conference I was fortunate enough to facilitate for Hewlett Packard many years ago. HP had achieved something significant, and was using this meeting to demonstrate that accomplishment. They’d placed some 82,000 PC users onto a ‘Common Operating Environment.’
Those working in a corporate environment know how difficult it is to implement any sort of standards into any niche of their computing community. Getting 1,000 users to use the same word processor is an achievement. Getting 82,000 users to follow any type of standard is nothing short of a miracle.
Here’s the catch. I know a market full of IT managers who’ll want to buy HP’s ‘technology‘(read ‘stone’ for those having difficulty with the metaphor) They’ll ask how much this PC COE costs. They’ll want to buy this stone from HP and they’ll expect the same remarkable results. They’ll want to make HPs stone soup, but won’t want to follow the instructions.
This observation applies equally well to dozens of other technologies from ERPs, to CRMs, from Client/Server environments to Knowledge Management systems to comprehensive Data Warehousing strategies.
They’ll spend the money, buy the stone, put it into their environment and turn up the heat. They’ll expect soup… All they’ll get is hot water. What they need to do to get the benefit from the stone is add the extra ingredients. eg. Leadership, Management, Change Process Control, Planning, Training, Marketing, and of course… Patience.
While there are other ways to define the role of a Change Agent (CA), the CA’s most commonly assigned and practiced mandate is to bring about a pre-determined Change within a community. A CA is typically assigned the task, “Make this happen!” and it is their responsibility to force/cajole/steer/entice/motivate etc. etc. the community to move towards a specific destination. The CA fails in their task if ‘this’ doesn’t happen exactly as envisioned by those who assigned them to their role of CA. In the real world, the CA typically does not have a lot of wiggle room in their assignment.Regardless of the specific task assigned to a CA, all CAs, without exception, must function within the context of how people respond to Change in general. It is this fact (obvious observation?) which spawns the Change Agent’s unavoidable handicap.
How do people respond to “Change in General”? The most honest and accurate answer is that we don’t, or rather we can’t, respond to Change “in general”. We can, and do, respond to specific Changes. We evaluate each Change according to its individual degree of necessity and then, and only then, respond accordingly.
This observation doesn’t stop us from making generalized statements about Change, here’s one, “The only constant is Change”. While this is cutely true (if I’d meant ‘acutely’ I’d have typed it) and ancient in origin, a more useful and more recent observation is that “People don’t resist Change, they resist being changed.”
If presented with the statement uttered by a CA, “I’m here to Change how you do things.” no rational person will gleefully respond “Okay! Do what you have to do!” Instead we immediately try to get specific and respond (retaliate?) with a simple question, “Why should we change?” This in turn, is immediately tagged as resistance, and even as a mild form of insubordination.
If the statement, “People resist Change” is true, then it is true in the same sense that Newton’s 1st law of Motion, The Law of Inertia is true.
Newton’s First Law of Motion:
The Law of Inertia.
An object at rest tends to stay at rest,
and an object in motion tends to stay
in motion with the same speed and
in the same direction unless acted
upon by an unbalanced force.
Like a stone unconsciously (literally) following Newton’s Law, we continue doing what we’re doing, until we’re presented with a reason to do something else.
When we ask “Why should we Change”, we’re not trying to annoy or frustrate anyone, we’re merely following a fundamental law of the universe. We’re just seeking the reason necessary to do something different from what we’re already doing.
The CA’s handicap is not only that they’re here to Change us, for reasons as yet unexplained, but they’re here to Change us regardless of how we feel about it. Remember, the task of the CA is to “Make this Happen” if they don’t, they fail.
So, the CA must Change us, otherwise they fail. This flies in the face of how we decide whether or not a Change is necessary. Even worse, it ignores our earlier observation, “People don’t resist Change, they resist being changed.”
Allow me to introduce you to Bill, he’s a Change Agent, he’s here to Change you.
When a Change Agent is appointed, the decision to Change is fait accompli. Nothing anyone has to say has any bearing on the matter.
There’s an alternative approach to this problem, even if there’s no generally accepted term for the role. Perhaps the term, “Change Coordinator” would work better? It suggests that at worst the person is assigned the task of coordinating the efforts, decisions and the Changes of others, rather than inflicting them with a predetermined Change?
Our desire for Change arises either from the need to respond to a threat, “We must do something about this!”, where “this” is a visible problem, or a perception that there is a better way of doing things, “We could do this in order to achieve a specific additional benefit!”.
The term “Change Agent” has accumulated far too much negative baggage, and isn’t conducive to the notion that real Change is not mandated, but instead grows out of a common understanding that it is necessary, for specific reasons, to respond to a growing threat, or to seize upon a potential future opportunity.
You can see (and order) a better version of this 20×30 poster here
I’ve become a bit of a GPS addict. I now have maps for both all of North America and the UK and Ireland. I can’t imagine driving to someplace new, without the assistance of strange unseen satellites.
Despite the benefits, there is a peculiar downside to these navigation units. With a map, you always have some sense of where you are, with Mapquest type instructions, you have some sense of where you’re going… but with a GPS? You only have a moment to moment sense of where you go next. If (when… I have a story to tell the next time we meet in a pub) the device breaks down, you are completely, totally – almost permanently – lost.
Benefits and disadvantages aside, there are a few things we can learn about project management from the lowly GPS.
This is the very first ‘strange’ thing that I noticed when I first used the GPS. When you make a mistake and go ‘off route’ (or off plan if we’re replating this to PM), no matter how many times you make that mistake, the voice giving you directions remains calm, cool and unfluttered.
“Well of course it does!”, Someone mutters from the back of the room… “It’s a machine!”, and my response is, yes I know that, but when I make a mistake I’ve come to expect that the response will communicate someone’s displeasure. And, that expectation of a negative response to a mistake is the primary reason why status reporting is so difficult. We’re afraid of the negative response so we ‘shade the truth’ to make ourselves look better.
I would not suggest for a moment, that your project is monitored as closely as GPS monitors your location, but the lesson is plain. Knowing where you are, is crucial to getting to where you need to be according to your plan.
Regardless of the effort it takes to where we are against the plan, it’s something we have to do. If it’s not done, then we’re not managing the project. I’m not sure what we think we’re doing, but whatever it is, it isn’t project management.
Track the project isn’t administrivia is the heart of the PM concept. To state it even more plainly; everything done in the name of PM, is done to make it possible to know where we are. To do all the difficult preliminary work and then not track our progress is a form of insanity.
Not allowing time in the plan to track and report progress against the plan, is to state publicly that our planning activities are a farce… something we do to merely ‘look’ like professionals. The solution is obvious; learn what we can from the GPS
Retracing vs. RePlanning
When you go off route with a GPS, it will, for a period of time, do nothing more than try to get you back on the original route. It’s do this, until you get so far off the correct path, that it’s better to replan the trip.
That’s a great PM lesson. If we’re off the plan, how long do we just try to get back on the original plan… before we sit do and replan the project? Frankly, not enough replanning is done, in it’s place there’s a lot of wishful thinking – we’ll catch up on the weekend.
Macro vs. Detail views
If you’re paying close attention to the GPS, and that’s what we usually do, you’ll notice that when the next ‘check point’ is far away, then it zooms out to an overview, but when the next turn is just a little bit ahead, the instructions happen faster, the map zooms closer, proving you more detail of what’s ahead.
Project management can emulate that approach. Having a project status report ‘every three’ months works reasonably well when the work between markers is much of the same… but when key deliverables arrive more rapidly, when they get bunched up on the Gantt Chart, then more frequent status updates are advised.
While this is a tongue in cheek comparison, there’s some truth here. Driving from Dublin to Sligo has much in common with a project where both the starting date and deliverables are known. One difference? There are more Pubs on the road to Sligo.
Regardless of whether we’re politicians, managers or parents, our most valuable relationship asset is “trust”. With a healthy accumulation of “trust” in hand all relationships with constituents, employees and children are easier, simpler and more pleasant. Without “trust” life is difficult. If this is obvious, and it is, then why do we seem to go out of our way to squander these benefits?
Without cracking open our well worn dictionaries and thesauri and digging up a lifeless definition… what is “Trust”? Two images come to mind; a parent standing in a pool entreating a nervous child on the edge of a swimming pool to “jump! I’ll catch you!” and of Charlie Brown running, for the 700th time, to kick the football held by Lucy the Deceitful.
Those simple images sum up what we already know. Trust is our willingness to accept a risk on someone else’s assurance of safety. The reasons behind this willingness are worth dissecting, because hopefully they’ll provide a basis for techniques to both build and retain trust in the workplace.
Benevolence: The child trembling with fear at the edge of the pool will leap into the waiting arms of her parent, because she knows, with absolute certainty, that Mommy won’t let her down. That the parent has the best interests of the child at heart: no deceit; no hidden agenda.
Do those we want to trust us, know that about us? That we have their best interests at heart? That we won’t let them down? Have we demonstrated our benevolence in the past with more than words? Do we put their interests before our own, once we’ve made them a promise or given our word?
Credibility: The child knows that Mommy won’t lie. That if Mommy says she’ll catch her, that she will catch her.
This is perhaps the easiest aspect of trust to avoid violating. Never make a promise, a statement, or even suggest you’ll do something and then not do it. Once upon a time, perhaps in a fantasy land, our word was our bond. Once we said something, then we’d follow through no matter what the consequences. Sadly, today our word isn’t sufficient. We exchange contracts and employ legions of lawyers to ensure that we all agree on what the phrase “I will” really means.
Competence: The child knows that Daddy won’t drop her. That he has the skill, the strength and ability to catch her and keep her safe from harm.
Your knowledge of my competencies is a crucial component of your trust in me. If I say I’m going to do something, one of your first thoughts is “Can he do it? Does he have the skills? Can I rely on him to deliver?” This consideration forces me to do two things. First? I’ll never commit to something I can’t do. Second? I need to ensure you have a good understanding of my capabilities.
There’s more to this thing called “trust”. We could explore the notion of fairness; do we treat everyone equally both in terms of rewards and punishments? Do we adhere to Golden Rule?
We could also include concepts of openness and shared risk. We could explore the notion of trust between strangers and arrangements based on mutually shared consequences, but the bulk of trust is based on the concepts of benevolence, competence and credibility.
Meanwhile… we left Charlie Brown running at that football… you’ve read the comics, you know what will happen this time. Lucy, for personal reasons beyond our ken, will pull that ball away for the 700th time and Charlie will once again launch himself into the air, to land with a sickening crunch on the wet grass. He never learns.
A news flash to all managers – Charlie Brown doesn’t work for you. Good old Chuckie is a cartoon figure. Those working for you are real people, with memories the envy of Elephants. We never forget.
That’s the glass jaw of this thing called trust. It can take years to develop, and then a single betrayal of someone’s trust will not only demolish all we’ve worked to achieve, but it severely hampers our ability to build trust in the future. Unlike Charlie Brown, we’re unlikely to trust people after a single betrayal, never mind constant betrayal.
Understanding trust isn’t difficult, all we have to do is just remember why we were willing to leap into a parent’s arms, and then be willing to trust the reasoning of the child we once were.
With thousands of IT positions unfilled, it must be the best of times. Yet rampant unemployment in the ranks of IT, suggest it’s obviously the worst of times. Blatant contradictions bother me, they suggest that something we know to be true… isn’t exactly as we know it.
As an easily accessible, somewhat prominent, writer and speaker, many people send me their resumes asking for help in getting a job. (This is not a request for more of the same. Sorry.) Generally what I receive indicates a high degree of technical competence. Certainly if the necessary reference checks panned out, these are potential hires in any organization.
Yet, these folks — desperate enough to send their resume to someone they know only in passing — have looked for work, without success for months, sometimes years. If there are too many positions waiting to be filled… what’s going on?
Based on personal experience I’m certain I have part of the answer. Years ago, at those times when I felt compelled to leave an employer for one reason or another. I used the services of those good people we affectionately refer to as head hunters.
They all had me fill out a skills inventory list. As a mainframe programmer they asked what operating system or type of hardware I had programmed on. That’s one of the dumbest questions you can ask a programmer.
If you program in COBOL, (have I just dated myself?) it makes very little difference (it makes some, but not much) as to which platform you’re using. Yet, I knew I would not be presented to ANY employer who was not using the same operating environment as the one I’d just left.
What was crucially important to the head hunter and the companies they worked with was that I was able to program in language ‘X’ Version 2.03462 on Operating System ‘Y’ Version 4.300-202. Nothing has changed except the alphabet soup.
This is the source of the IT employment problem. We define ourselves by our particular set of technical skills, rather than on our technical aptitude. When we finally get elevated to the exalted position of management, we in turn, perpetuate this limiting perspective.
Here’s a disturbing observation. Within six months of being hired to fit one of these exacting, precisely defined, technical positions the chances are extremely good that the new hire will be doing something totally different. So much for the exacting standards we spent so much time trying to fill.
In the past I’ve been asked if I knew how to program in ‘X’. Even if I had never heard of the language, I’d answer honestly “I can!”, because I knew that within a week, with the help of some rapidly acquired books, sample programs, a willingness to ask stupid questions, long nights and an overdose of caffeine that I would be able to deliver on my assertion. I had the aptitude proven by the long list of other languages I’d mastered in similar circumstances.
Likewise, I filled technical positions in my department with candidates plucked (Stolen in the dead of night sometimes) from the secretarial pool and user community. Very few of the people I’ve hired over the years have ever come pre-equipped with the technical skills necessary to do the job. They all had proven ability or aptitude. Not one of these carefully chosen people ever let me down.
Over the years, I’ve responded to advertisements for technical and management positions mainly to keep in touch with how the hiring process is evolving and also, who knows, I might be tempted to get a real job. Sadly I have to report that things haven’t changed much. Regardless of proven ability, my lack of specific technical skills can’t even get me through the door.
Once upon a time you could go to a bank and based upon nothing more than your credit rating and standing in the community, they would grant you a loan. The same was true of technical positions. If you could demonstrate proven ability with similar equipment, and a willingness to learn, you’d get the job.
Today organizations are unwilling to allow credit for ability, aptitude and willingness (even a need) to work the long nights to acquire a skill. Today we look for the shrink wrapped employee, properly certified and stamped.
In many ways, we talk about Change Management just like we talk about the weather. There’s a lot of moaning and groaning about it, but not much in the way of actually doing anything to make it better. It’s as if we’ve given up, and are willing to accept the notion that Change is overwhelmingly difficult. That’s a pity, because the problem of Change Management is as susceptible to rational thought, methodical analysis and problem solving techniques as is any other problem.What holds us back from applying our considerable intelligence to the issue of Managing Change, is that we’ve fallen prey to a flock of myths regarding the Change process. Ironically, these myths fly in the face of what we know personally to be true about how we as individuals react and cope with Change… but we ignore what we know and apply these myths to the behaviours we see around us. The result? A whole lot of fuzzy thinking regarding this very human activity of ‘Responding to Change’
I’m a bright lad. Honest! But even with this as a given, if you give me a set of instructions, then the chances are better than good that I won’t understand exactly what you meant. It’s not that either of us are terrible at communicating, it’s that communicating is terribly difficult.
We do our best to ensure that what we understand is what the other person meant to say. The strategy we use most often is asking for confirmation. We repeat back, or rephrase what we were asked to do, with the goal of getting a nod of agreement. The person we’re speaking with, is expecting this approach and is all too eager to agree that we’ve ‘got it’… then they can get on with their next task. It’s a small room version of Groupthink.