September 22nd, 2014
[Note: This blog post was previously published on the PMI Montreal website. I will be giving a follow-up presentation entitled "Not Just a Buzz Word: What Enterprise 2.0 Might Look Like" at the PMI Montreal Symposium on October 8, 2014. If you're in town, check it out!]
Org chart or obstacle chart? Whenever I take on a project in a new division or company, my first reflex is to look at the organization chart. I spend no more than 5 minutes on it, with a motive that may, or may not, surprise you: I am trying to understand who will stand in the way of my pursuit of Done. You see, for me, the org chart is an “obstacle chart”: it depicts the people who feel they are important enough to interfere with Done. (Sure, there are exceptions. But not many.) After this cursory 5 minutes, I then proceed with building my network. I look for the people within the organization that I absolutely need in my pursuit of Done: the admin who has been with the company 20 years and knows everybody, the anti-social Technical Expert who has no one reporting to him and yet is the reason that customers throw money at your company, the shipping guy who can ship your big system in a truck and get it across the country in two days because (surprise surprise) your current schedule doesn’t allow the “proper” time to ship.
It shouldn’t be this way. But it is.
Once upon a time in capitalism. In order to understand the origins of the org chart, we need to go back to the birth of managerial capitalism, which I detail in this blog post. In summary, the second industrial revolution, which took place from 1860s to 1914, arose from a perfect storm of four significant simultaneous events: communication technology (the telegraph), electrical power replacing steam power, the growth of the railroad and technological advances in manufacturing interchangeable parts.
This perfect storm meant that making lots of the same thing resulted in a dramatic decrease in unit cost, as long as you kept making lots of those same things. This gave birth to factory assembly lines, which spawned large and complex corporations, which required managers to manage the resulting complexity. And what was the structure we came up with to organize the managers who were organizing the complexity? The only one we had, which we borrowed from slave plantations and the army: the command-control hierarchy.
We need a different shape. While the command-control hierarchy was particularly effective in organizing the work of early twentieth century assembly lines, it was totally ineffective in organizing the work of projects. As a way to compensate for this ineffectiveness, the matrix structure was born.
And we all know how well matrix works, don’t we? (Rolling my eyes…)
Is there a project manager who has not lived through the pain of all-the-accountability-and-none-of-the-authority of The Matrix? Of course, functional managers everywhere embraced this structure, and why wouldn’t they? What’s not to love about all-of-the-authority-none-of-the-accountability, or what I fondly call “have your cake and eat it too”?
When you look at these two organizational structures, they essentially boil down to two shapes: a triangle (command-control) and a square (matrix).
But seriously, don’t our teams look more like this?
Does this look like a square (or a triangle) to you? Of course not. Let’s look at that again without the clutter of the obstacle chart:
Ah. So, instead of triangles or squares, we need to think “circles”. Lots of Interconnecting circles. Like in a web. Like The Web.
Welcome to the 21st century.
21st century leadership. In a networked organization, an Enterprise 2.0 organization, the power shifts from the executive team to the networks. This shift is explained by Deb Lavoy in this most excellent article (emphasis in bold is mine):
“Enterprise 1.0, with command and control, is limited in its capability by the intelligence and capability of the Executive team…In 1.0 enterprises, the workforce is there to amplify the capabilities of the executives. Looked at another way, executives are the constraint. After a certain point, it is the executives that restrain growth and capability because the organization cannot amplify what the executive can’t see. In Enterprise 2.0 power and capability flows the other way — from the network to the leadership. In Enterprise 2.0, executives (leaders) inquire and align collective intelligence and capability. They can access the collective capabilities, resources and observations of the workforce and beyond.”
In other words, power shifts away from the executives towards networked teams, because it is the teams that have the knowledge and capability. Most importantly, the role of the executive moves from commanding and controlling in an Enterprise 1.0 organization, to inquiring and aligning in an Enterprise 2.0 organization.
Next generation leadership will have absolutely nothing to do with authority and with telling people what to do.
If you’re an old-school command-control executive reading this, you’re scared out of your mind.
If you’re a project manager reading this, you’re nodding your head. Because you know what?
We already do this.
Next generation leadership. Somehow we project managers get the job done and deliver projects, and this despite being constrained by dysfunctional organizations poorly structured for collaborative work. How do we do this? We build networks that circumvent irrelevant “org charts”, we motivate and influence team members over which we have no formal authority or power, we share information and communicate despite inadequate 80s-style technologies and tools, and we do it with very little or no help from “bosses” and “functional managers”. Somehow, we deliver business value and successful projects by getting people to work together, to collaborate, despite the limits of command-control structure.
Project managers are already next-generation leaders.
Let’s show those executives how it’s done, shall we?
Go forth and change the world. It’s about time, don’t you think?
June 8th, 2014
It should be criminal. Does this sound like a meeting that you’ve attended?
1. You arrive at the meeting on-time, then sit around waiting for 15 minutes for the other attendees to arrive. Some of those people who show up late are so-called “leaders” in your organization.
2. When everyone else finally arrives, you spend another 15 minutes talking about last night’s hockey game or what you did last weekend.
3. When the meeting finally starts, you spend another 15 minutes discussing what the meeting is about.
4. Several of the meeting’s attendees spend the whole meeting on their smart phones reading emails and texts.
5. The meeting finally adjourns because someone has to leave for their next meeting. (This is most likely the person who arrived 15 minutes late and/or was on their smart phone for the entire meeting.)
6. Since nothing got done, you agree to have another meeting.
If you exhibited behaviours like these in high school, you would get sent to detention many times over. And yet, in our corporate world, these behaviours are so common that they are considered the norm. Meetings suck, we say. We can’t get work done because we are in meetings, we lament. “Meetings are toxic, terrible, poisonous things”, Jason Fried proclaims in this TED talk. “Hell is other people’s meetings”, says Merlin Mann. Let’s stop having meetings, we say, let’s “hit the delete key on meetings”.
There’s no question in my mind that meetings have become criminal, far exceeding email in their capacity to sap our productivity and our creativity.
But, do meetings suck? Or do we?
In defense of meetings. Having been burned by bad meetings from the very start of my career, as a budding project manager, I avoided calling meetings. (Yes, meeting crimes have been going on for a very long time.) I thought I was doing my team a favour and helping them to be more productive.
One day something happened that changed all that.
For one particular project, we had received comments from the customer on submitted drawings. (Lots of comments.) The next action was, I felt, rather straightforward: the configuration engineer was to simply update the drawings so I could resubmit them to the customer.
I followed-up daily. And every day, the engineer had more questions understanding and interpreting the customer’s comments. They were good questions. I tried to get them answered for him by discussing them with my Lead engineer. But, given the volume of comments, this was slow and labourious.
So, finally, I got fed up and called a meeting, just the three of us: the PM (me), the Lead engineer, and the configuration engineer (let’s call him Joe.)
The meeting agenda was simple: go through each comment on each drawing, answer Joe’s questions and assign action items where we didn’t have the answer. After about one hour of this, Joe exclaimed in the middle of the meeting: “Wow! This is such a great meeting! I’m getting so much work done!”
No. I am not kidding.
We ended up having two more meetings that week until we had covered all of the drawings. And, wouldn’t you know it, we got more work done in less time.
That experience was eye-opening for me: I learned that meetings can be a powerful tool in any project manager’s quest for Done. I’ll even go further and say this: a well-planned and well-managed meeting can make the difference between a stagnated project and one that successfully attains its objectives.
Key words here? Well-planned and well-managed. Productive meetings are not an accident: they are the result of unrelenting and coordinated efforts towards attaining a clear objective. (Gosh, sounds like a project, doesn’t it?)
Meetings don’t suck. We do. This early experience of the power of meetings taught me an important lesson: meetings are not the problem. We are. Just as you can’t blame PowerPoint for bad presentations, we need to stop blaming meetings for our own bad behaviour.
Over the course of my career, I have made a conscious effort to plan, and run, productive meetings. Things like the video “Meetings, Bloody Meetings” (I was fortunate enough to watch the John Cleese version in a training course) or this excellent You-Tube video have helped. I don’t always succeed. However, I succeed more often than I fail. How do I know? I am rewarded with comments like this: “Wow, that was a really good meeting”, “Gee, that was such a productive meeting, I know exactly what my priorities are.” How many times have you heard this type of spontaneous feedback?
And so, in response to Jason Fried’s call to ban meetings, I’m here to tell you that it’s pretty much impossible to get work done on a project without meetings. But just because meetings are necessary doesn’t mean that they have to suck. Here’s my most-of-the-time-no-fail guide to making meetings a powerful and efficient way to get things done.
Three roles make meetings successful. There are three major players responsible for successful meetings: the meeting planner, the meeting attendees, and the management team. (Let’s pretend they are also the “leadership” team but we all know that’s not true, don’t we?) I’ll be addressing the roles of meeting attendees and the management team in a second and third blog post. This post will focus on the role of the meeting planner. Let me be clear: if you are a project manager and you don’t know how to run a productive meeting, then you are missing out on a powerful tool that will help you in your unrelenting pursuit of Done.
What is a meeting? Before we discuss how to plan and manage a meeting, let’s agree on what a meeting is: it is a scheduled synchronous conversation between at least two people. “Synchronous” is the key word here: you need people to participate in the conversation together in real-time, not asynchronously using email, text or chat. (A scheduled video conversation, using say, Skype, is definitely a meeting.) The other elements of the definition are self-explanatory: a meeting is scheduled, and you need at least one other person to attend in order for it to be a meeting.
There are five parts to running productive meetings: Avoiding, Planning, Running, Ending, and Following Through.
Avoiding? Say…what? You might wonder why I sing the praises of meetings and then begin by advising you to avoid them. For one simple reason: even good productive meetings cost money. They take time to organize, plan, run, attend and follow-through, which makes them expensive. In fact, the single most prevalent meeting crime being committed is believing that you can wake up on a Friday morning, and have a meeting on Monday for 30 people in your department. (I wish I was kidding about this. Sadly, I am not. We’ll get to this heinous crime in part three of this blog series.)
A sledge hammer can be a powerful tool in helping you to start off your renovation project; improperly handled, it can also wield much damage. In the same manner, meetings should only be used judiciously, with care, in order to move your project forward. Used poorly, meetings become weapons of mass destruction.
For this reason, the first rule about productive meetings is to avoid them like the black plague. If you can solve the problem, make the decision, get the action item done, move the project forward with phone calls, a couple of emails, a quick water-cooler or an at-the-desk conversation, then do so. Try every trick in the book before you resort to calling a meeting. Whatever you do, don’t become a meeting junkie, who at the first sign of an obstacle or a problem, jumps up and says “Let’s have a meeting”. As Al Pittampalli (author of this book) explains, an addiction to meetings is caused by the anxiety of making a decision. Calling a meeting takes the burden off of your shoulders. It also allows you to shirk your responsibilities as a leader and a project manager. Remember: your goal is not to have meetings, it’s to get work done. And sometimes, you can only get work done in a meeting.
Meetings don’t have to be the “practical alternative to work”. Just do what I tell you…
Your first reaction to someone suggesting “let’s have a meeting” should be to ask many questions: “Why? What would be the objective of this meeting? Why is this objective important to our project? What will we gain at the end of the meeting? Can’t we accomplish that by just calling X on the phone or writing X an e-mail? What will happen if we don’t have the meeting? If we have the meeting, who will we invite? Who really needs to make this decision? Do we need to have all of these people present?” In other words, make sure that the meeting is truly the only way to move your project forward.
Because as a good meeting organizer, you know how much work is involved to run a productive meeting.
So, when your email chain grows out of control (you know what these look like), if your water-cooler or at-the-desk conversations reveal that the issue is a little more complicated than you thought, if you discover that you need Jane, Paul and Jack in a room at the same time because they are not on the same page regarding a path forward, if you are running in circles and the issue in question is in exactly the same place as it was before you started running, then you know you have no choice. You need to call a meeting.
Planning. Once you have come to the conclusion that the only way to move forward is via a synchronous, scheduled conversation between more than two people, then you must proceed with planning your meeting. Before you even send that meeting invitation, ensure that you define these five items:
1. Meeting Objective. The meeting objective is the thing you have right after the meeting is over that you didn’t have before the meeting started. If you didn’t accomplish your objective, then the meeting failed. Period.
For this reason, the meeting objective must be specific enough that it can be achieved by the end of the meeting. “To discuss project issues” is too vague, “To make a decision regarding the technology choice for widget A” is better, “To make a decision if we are going with ethernet or wireless” is probably even better. Be specific and granular. Remember: it’s the thing you have this at the end of the meeting that you didn’t have before you started. If you need to consult with a project stakeholder to better define the meeting objective, then do so.
2. Agenda. The meeting agenda describes the steps you will go through to meet the objective. While an excellent agenda would have time limits for each agenda item, this is not absolutely necessary. The agenda can be as short or as long as necessary to outline how you intend to meet your objective. Think of it as your roadmap towards your meeting objective.
3. Homework. Be clear about what preparation is required before the meeting. In fact, write “Homework” right in the meeting request. I don’t know if it’s because I work with engineers (I am one) but I am always pleasantly surprised that when I assign homework before a meeting, the attendees arrive with it already done. By assigning homework, you are making it clear to your attendees that they contribute to the success of your meeting.
4. Attendees. I usually choose the attendees once I have the Objective and Agenda set. By narrowing the objective, some attendees drop out. Only invite people who will contribute directly to achieving the objective. As a rough rule of thumb, I try to keep the number of attendees under five (which is close to Bob’s magic number) in order to keep the meeting in control. If necessary, narrow your objective to reach this optimal number. Also make sure you differentiate between the people who are necessary to achieve the meeting objective and those that need to be simply informed of the meeting outcome: you can send the latter a copy of the meeting minutes. (Uh. Yes. There will be meeting minutes.)
5. Timing. There are three things to consider when choosing the timing of your meeting.
- Advance notice. It is as rude to call a meeting with one day’s notice as it is to fart loudly in public. Calling a meeting on short notice is basically saying to the world “I suck at planning” and “I am not a leader” and so should only be done on an exceptional, and truly exceptional basis. That exception? Something earth-shattering happened TODAY. You’ve sent emails, texts and you’ve called. But now you all need to get together to figure out how to react to this earth-shattering event. If that something happened two weeks ago and you are only reacting now? Then you suck. You really, really do.
- Attendees availability. It is also just as rude to plan a meeting without checking your meeting attendees’ calendars. Whether or not you share calendars in your corporate culture, you can at least see if the attendees are free for the time slot you’ve chosen. If they are not free, have the courtesy to ask if they can accommodate your meeting. If your meeting is worth it, they will. If they can’t, then pick a time slot that works. And if that time slot is two weeks from now? Make sure everyone knows why you have chosen the date and time that you have for your meeting.
- Conference room. It sounds simple but you need a place for your meeting. Ensure that you choose a conference room with enough room for everyone. (Standing or sitting, it’s your call.)
Once you have items 1-5, you can send out your meeting invitation. I usually write an email and the meeting invitation at the same time: the email explains the homework in more detail (including links to the documents which need to be read) and additional context regarding the meeting (the business value that we are seeking). I like to keep the meeting invitation short and sweet: “Objective: XXX Agenda: YYYY Homework: ZZZZ” with a reference to my email for more information. Once both the email and the meeting invitation are complete, I’ll send the email first then the meeting invitation.
Running. Gosh, with all that planning, how can your meeting go wrong? One word: humans. It never ceases to amaze me how the most cartesian of engineers (remember: I am one) can behave in the most irrational and illogical manner in a meeting. I cannot tell you how many times have I sat in an empty conference room after a disastrous meeting, for which I had a clear objective, detailed agenda (with time limits), assigned homework and enough advance notice to do it, and it still was a complete disaster. The reason? The people attending, of course. The humans. Who do not follow the lovely logic of a mathematical equation. While I could easily write one or ten blog posts on this subject itself, here’s a quick summary of how to run a successful meeting (or die trying):
1. Start on time. You must arrive at least 5 – 10 minutes before your meeting. If you need a projector, make sure it is set up before everyone arrives. If you are contacting someone on Skype, Lync or some other video messaging technology, be sure you have made the arrangements beforehand (and include those instructions in the meeting invitation). Do not fiddle with your technology at the start of your meeting. Whatever you do, do not arrive late for your own meeting. Don’t ever do this. Never. Ever. Never.
2. Why we’re here. Start your meeting by opening your meeting request, because it’s all there. Start with the objective. Then run through each item in the agenda. This reinforces the value of your meeting request. And, if you are in North America try to minimize the “How you doin’” stage: skip the small talk and get right to it. (Depending on which part of the globe you are in, you may need to allow time for small talk before starting your meeting in which case you need to adjust your agenda accordingly.)
3. Keep an eye on the time. Do a time check at 10 minutes left. Do another one at 5 minutes left and, if the objective has not been attained, ask if your team members can stay. If not, then agree on what is needed to meet the meeting objective: more homework, a smaller or different meeting, or the same people meeting again. And if they actually want to stay instead of running away, then consider yourself awesome.
4. Keep the discussion on the agenda. Interrupt any discussions that go off-topic and bring it back to the agenda, with comments like “maybe you should clarify that off-line” or “that’s not really in the scope of this meeting”. Note that sometimes it is useful to let these discussions go a little off-topic: listen and decide if these off-topic discussions are more interesting and valuable than what you had planned on the agenda. This can happen, and it’s good when it does. Use your judgement.
5. Do not tolerate bad behaviours. Do not be afraid to channel your inner Mom and bring order back to your meeting. This is such a deep subject that I will be covering it in the second blog post on meeting attendees.
6. No devices. The only laptop allowed is your own and even then, you are only using it to show the agenda and anything else required for the meeting, such as documents or presentations. Ensure that your use of technology is not disruptive to the flow of the meeting. I personally find that typing during a meeting is very disruptive and actually interrupts the flow of the discussion. Lately, despite my love of gadgets, I have rediscovered the power of “old-school” tech, such as pens, notebooks, white boards and sticky tabs. Especially white boards. What, you don’t have meeting rooms covered in white boards? Why ever not?
Ending. As Project Managers we know that Endings are as important as Beginnings so this should come as no surprise to you: how you end your meeting well is as important as how you begin it.
1. Why were we here again? Remember that meeting objective you spent so much time crafting? Before you end your meeting, read your meeting request with your attendees (it’s already open because that’s how you started your meeting, right?) and ask all that attended one simple question: “Did we meet our objective?”. If the answer is “no”, don’t be afraid to declare your meeting a failure. This usually wakes people up to the fact that you mean business: you are interested in having meetings that add value. If the answer is “yes”, the congratulate your meeting attendees. This simple act of referring back to your objective is very powerful because it reinforces the message that your meetings add value.
2. What’s next? All meetings have action items, even if the meeting failed. If the meeting failed, then your actions will describe how you still intend to meet the meeting objective. If the meeting succeeded, then the action items will describe what happens next in your quest for Done. Before closing out the meeting, I usually broadly outline the actions. I find that I need time to craft meeting minutes with clear action items so my preference is to be more specific and clear in the meeting minutes.
3. It’s not a meeting if there are no minutes. If you do not send meeting minutes immediately after the meeting (not two months after), then you have essentially wasted your time as well as that of your meeting attendees. Minutes keep the momentum going as your project moves towards Done and cements the business value that your well-planned meeting delivers. Remember: many of your attendees will be reading these minutes on their smart phones, so keep your meeting minutes short, sweet, to-the-point, Twitter-style. Write them directly in email (do not attach a Word document) and be sure to include this information:
- Thank the attendees for their time. There’s always room for manners at work.
- Attendees: Who was there (and who wasn’t)
- Decision(s): One sentence or bullet form, confirm the decision(s) that were made, such as “Technology chosen: wifi” or “Schedule is ready for baselining.” There is absolutely no need to give a play-by-play replay of who said what in the meeting: it adds no value and, worse yet, makes your minutes too long, and doomed to be unread.
- Actions: List the action items, including who is responsible and a target date. Put the names and the dates in bold so that they stand out.
Following Through. Productive meetings add value, and for that value to be realized, the action items that resulted from the meeting have to get done. That is the point of having a meeting: to get work done. Do whatever you have to do: on the due date of the action items, send a quick email to follow-up, drop in on the person or have a follow-up meeting (yes, another meeting), but whatever you do, be relentless. Do not stop until those actions are done.
Not an oxymoron. So there you have it: the secret to running productive meetings is Avoiding, Planning, Running, Ending and Following Through. If that sounds like a lot of hard work, you are right, it is. If “productive meeting” sounds like an oxymoron, then you’re doing it wrong. Good productive meetings do not happen by accident: they are the result of coordinated and constant effort on the part of the meeting organizer. Maybe if you follow these not-so-simple steps, you’ll be rewarded like I was not long ago. When we reached the time limit in one of my meetings, I heard this from someone who complained constantly about meetings: “Let’s keep going, we’re getting work done.”
Hear that Jason?
“We’re getting work done.”
At a meeting.
June 13th, 2013
Not one of my finer moments. Once upon a time, not so long ago, I had a rather unfortunate conversation with a junior project manager-in-waiting. Two months prior, my Project Sponsor had delegated an action item to this junior PM (let’s call him Junior). Given that I knew that he was interested in pursuing the career path of project management, to the point where he was preparing to write his PMP exam, I figured I could count on him to finish it off.
I was wrong. So very, very wrong.
That action item went undone for 2 months until it came back and bit me in the ass. And when it did, I had a…ahem…conversation with Junior. I’m afraid that it was far from one of my finer moments.
I was tired, overworked, profoundly annoyed (profoundly) and, as a result, not very patient. And when he kept repeating over and over “It’s not my fault” (and I mean over and over and over), I lost it. I said things that someone who has put “passionate about mentoring” on her CV and in her LinkedIn profile should not have said. And I am pretty sure that I broke rule 1, which is absolutely unforgivable.
I am not proud of that conversation. I missed a golden opportunity to teach a junior project manager the error of his ways and put him on the path of project management righteousness. Don’t get me wrong: I still feel and will always feel that Junior did not display the qualities that will make him a good Project Manager. Sadly, because of how I handled that conversation, the only thing that Junior might have retained from our unfortunate discussion is that I am…well…the Psycho Project Manager instead of the Passionate Project Manager. I often look back on that conversation and wished I had said something else.
So this is my Do Over. This is the conversation I should have had with Junior.
A little background please. So here’s a little more information on how Junior irked my ire. I was responsible for delivering a certain deliverable, let’s call it Widget, that ended up being way more complicated than we originally intended (*sigh*). Basically, the choice of technology combined with the business process resulted in a widget that was not very user-friendly. In fact, it was so un-user-friendly that, quickly after we deployed Widget for general use, we discovered that the users had use a “trick” which, if not followed, meant that Widget couldn’t be used and I would have to do change some code in order to fix it. (Gee, that makes me sound like I actually know how to code, doesn’t it?) After the third call to fix code, I recommended to the Project Sponsor, and he agreed, that his group publish The Trick on our company intranet in a place where it would be easily found. As a person with “lean” and “business process optimization” in her profile, I am fully aware of how far-from-ideal this solution was, but it was the best way to resolve an unfortunate situation. There were other issues at stake and, without losing sight of the bigger picture, we agreed that this would be the best way to move forward. And, to make it super-duper easy for them, I wrote the draft of The Trick complete with plenty of pretty pictures. The Project Sponsor delegated the action of publishing The Trick to Junior, who enthusiastically agreed, and even commented that I had “done his job for him”. Which I had. On this we all agreed.
Two months later, I received a call from another user who had not followed The Trick.
I checked. The Trick was not published.
Junior had failed me.
Do Over. So here it is, my Do Over. Here’s the conversation that I wish I’d had with Junior on that unfortunate day.
Me: “Junior, I got a call from Janet. She opened Widget wrong. I looked for The Trick: it wasn’t there.
Junior: “Uh. I asked Communication to publish it two months ago.”
Me: “I see. How did you ask Communication?”
Junior: “I forwarded your email and told them to make the grammar changes, translate it, and publish it.”
Project managers stand up in front of a group of people. Unless they’re on vacation.
Me (thinking): “Forwarded? Gee, make an effort, why don’t you?”
Me (taking a deep breath before speaking): “I see. To whom did you send the email? Who in Communication?”
Junior: “I sent it to Margaret. In my email I asked her to publish it as soon as possible.”
Me: “And did Margaret write you back with a committed publish date?”
Junior: “Uh. No.”
Me: “Did you call Margaret and ask her when it was scheduled for publication?”
Junior: “Uh. No.”
Me: “So let me get this straight: it was your responsibility to see that The Trick was published. And all you did was forward my email. Is that right?”
Junior: “It’s not my fault.”
Me: “I beg your pardon?” (No f-bomb this time, but I’d use my “pissed-off Mom” voice.)
Junior: “It’s not my fault. Margaret didn’t do her job.”
Me: “Did you do yours?”
Junior: “But…but…it’s not my fault. Margaret…”
Me (thinking): “Namaste. Namaste. @!!&!!@@!! Na-ma-ste!”
Me (out loud): “How many times did you call Margaret after your email?”
Me: “Let me guess. You sent her an email and didn’t call her. Not once.”
Junior: “Yeah but it’s not…”
Me: “Please don’t say it’s not your fault.” (See? I’d say “Please”. I like me in this Do Over. Cool As Ice.)
Me (still Cool As Ice): “Do you know how many times I call Margaret to get her do take care of my stuff? It takes a minimum of three calls. Three. That’s because Margaret is busy. She gives me date. A couple of days before, I follow-up. Then she tells me that some VP needs this, that or the other and my stuff will have to wait another week. A few days later I call her again. We have the same conversation. Around the third try, she gets tired of me calling her and then she does my stuff.”
Junior: “It’s not…” (Then he’d stop. Because, in this Do Over, he’d remember that I said Please. And so he would not keep saying the same thing over and over that will make me lose it.)
Me: “Are you still studying for the PMP exam?”
Junior: “Yes, why?”
Me: “So, you are still interested in being a Project Manager?” (I’d resist saying “when you grow up” at the end of that sentence because I am Cool As Ice.)
Me: “What is it that you think project managers do?”
Junior: “Initiating. Planning. Executing. Controlling. Closing.”
Me: “That’s how we do what we do. But what do we do?”
Me: “Let me explain to you what a Project Manager does.”
And then I’d say this.
This is what we do. A project manager is a master in the art of Done. If there is an obstacle in the path to Done, we remove it. Or we talk to the person or the people who can remove the obstacle. And bug the hell out of them until they remove it. Then we repeat for the next obstacle. And then again. Over and over. Relentlessly. Until we reach Done. And then, and only then, do we stop.
And, being masters in the art of Done, we stand up in front of a group of people and we say “You can count on me. I will do this.” And we mean it.
Sure, we tell them what we need (a qualified team would be nice), we learn to say “No” (No, you can’t have more anything unless you give me more time, more people, more money), and we know the right time to ask for help (We failed this test three times, we’re stuck, we need The Expert to help us.)
We make plans and schedules and lists. Lots of lists. We organize and prioritize those lists. We protect those lists from those that keep trying to add items to those lists when we’re not looking. We make sure our teams know what is on these lists. And we protect our teams from those people who keep trying to add to or rearrange those lists when we’re not looking. And we’re always looking.
We let people know how far from Done we are. We never “don’t know”.
When our project fails, we stand up in front of those same people, with our team behind us, and we say “It’s my fault.” And then we fix it.
When our project succeeds, we stand up in front of those same people with our team in front of us and we say “They did this.”
We live between a Rock (getting to Done) and a Hard Place (telling those same people who want Done, usually VPs or CXOs, that they can’t have any more, sir.)
We have balls of steel. We have no egos. And we’re as Cool As Ice. (Okay, maybe not that last one. At least not all of the time.)
But, Young Grasshopper, this is the most important thing we do.
We stand up in front of a group of people and we say “I will do this”. And we do it.
Which means that we never, ever, under any circumstances, ever, utter the words “It’s not my fault.”
Because it’s always our fault. That’s what being accountable means.
And if you can’t do this, if you can’t stand up in front of a group of people and say “I will do this”, and mean it, you cannot be a Project Manager. No amount of studying for any exam will help you to become a Project Manager if you cannot do this.
This is what we do.
Yeah. I really wish I’d said that.
One more thing. My blog post was supposed to end there. But there is an obvious contradiction in my story which stares me in the face every time I read it. You can see it too, can’t you?
The contradiction is this: If Junior failed because he relied on Margaret without following up, did I not fail because I relied on Junior without following up? Just as much as this was Junior’s fault, was it not also mine? Was I not accountable? Am I not a Project Manager? Do I not stand up in front of a group of people and say “I can do this”?
Was this my fault?
The answer to all of these questions is: yes. And in writing this story, I realize that the true reason I reacted the way I did with Junior, the true reason that I broke rule 1, was that I knew that I had made a mistake. I trusted a boy to do a man’s job. Yes, I was disappointed as all hell and, yes, every once in a while I’d like people to act like adults instead of children at work. But I know better. I am older, wiser and more experienced than Junior. I am Master Po. And it was the realization that I had failed that was the true reason for my bad behaviour.
It was my fault. Because I am accountable.
And you know what? I really wish I had said that too.
January 6th, 2013
Yes, I am still here. I am perfectly aware that I have not published a blog post since Mother’s Day (May 13, 2012), a whole 7 months ago. So I thought I’d kick off the New Year with a blog post about…well…blogging. Since I have had a blog since 2010, I figured that makes me an expert. (Why not? Everyone else is.) Never mind how many posts I have actually published…
So if you’re interested in blogging, here’s my best advice to you.
1. Clearly define your objective. As I explained in my blog post about LinkedIn, before you embark on any social media site, or any activity for that matter, you must have an objective. In the case of blogging, ask yourself these questions: Why do I want to blog? What is the purpose of my blog? Who is my target audience? If the answer is “to share stories about my life on a working ranch in Oklahoma”, then your blog will be different from “sharing my obnoxious opinions about what is wrong with life in a corporation”. And if your objective is “to make money”, see point 2.
2. You will not make money from your blog. Let me kill this right now: you will not make money directly and only from blogging. If you have any doubts about this, I’ll let Penelope Trunk talk you out of this ridiculous notion. Sure, there are some successful for-profit (at least, I think they make a profit) blogs out there: Dooce, Ali Edwards and Zen Habits but, as Penelope notes, you are not them. Don’t be fooled by the low start-up costs, especially if you choose to do everything yourself. Because the revenue stream is also low, even if you use your blog to sell products or even advertising. No matter how I run the numbers, I don’t see that revenue stream as being more than I what I make working full-time as a project manager (or as Penelope puts it “flipping hamburgers”). In fact, the only successful blogging business model I have seen is trying to make money off of people who want to make money blogging: “Buy my seminar for $700 and you too can become a millionaire working from home”. Still not convinced? Chris Guillebeau explains how, after 279 days, and a lot of hard work, he was able to make $49K a year from blogging (p. 13), less than he made running his own business. $49K? Ummm…I can make more than twice that just keeping my head down and my mouth shut. (Oh boy…)
Blogging allows me to stay sane as a corporate slave so that I can take pictures like this (Barrea, Abruzzo, Italia)
3. Starting a blog is easy. Keeping a blog is not. Gone are the days that you had to know html in order to start a blog. Remember that opening scene in The Social Network when Jesse Eisenberg (playing Mark Zuckerberg) is writing in his blog and it doesn’t look at all like English? That’s because he was typing in html. Nowadays, with absolutely no knowledge of .aspx or html, you can start a blog in less than 5 minutes by using platforms such as Posterous, Blogger or WordPress.com. Even if, like me, you choose the self-hosted route, which is a little more work, most web-hosting services have install scripts for WordPress and other platforms that make installation literally as easy as 1-2-3. So starting a blog is easy. Keeping a blog? Not so much. Which brings me to the next point.
4. Writing is hard. A blog is all about creating content on a regular basis. (And I loosely define the term “regular”.) Sure, you can create a video blog: if you like wine and understand French, this québecois blog will have you drinking more wine and maybe even speaking more French. Frankly, it doesn’t matter: speaking is just as hard, if not harder, than writing. And writing is hard. It’s goddamn fucking hard. It’s way harder, in my opinion, than managing projects. As Scott Berkun, an ex-project-manager-turned-full-time-writer (*sigh*) puts it: “In a regular job, you show up, there are piles of things that need to be done and people to do them with, and off you go…[Writing] is harder than doing most other kinds of work because you have to make everything up: the page is blank every time you start.” Don’t kid yourself: even for professional writers, blogging is way harder than it looks.
5. Nobody is reading your blog. Most SEO snake-oil salesmen will define success in terms of the number of subscribers and the number of clicks…and then sell you their services to increase both. (Remember: their business model is to get you to give them money.) Don’t listen to them. My blog has (wait for it) 10 subscribers. TEN. I can’t even get my husband to read my blog. Compare that to, say, Zen Habits who claims to have a million+ readers. Jeez. And before you think you can do better than me, go back and read the Penelope Trunk link I gave you in point #2. (You already read it, didn’t you?) Because even among successful bloggers, success in blogging is not defined by the number of readers but rather “influence, connections, friendships, the ability to lead a conversation that matters to people, [and] business opportunities.”
6. Forget blogging every day. Look, everyone says you have to blog regularly. I know this. But I find it practically impossible to work full-time at a challenging job, then come home and work full-time on my marriage and raising my children and still have time and energy to blog. Quite frankly, there are a lot of nights and weekends when all I want to do is lose myself in a good movie or TV show or play around with my scrapbooking supplies. So, if you accept that there is no money to be made from blogging and you have a clear objective, I give you permission to decide how often you want to blog, even if that is once every few months. In my case, I decided early on that I would only publish when I have something of quality to say. (I am not Seth Godin: I cannot come up with top-notch quality every single damn day.) Any random thoughts that pop into my head go to Twitter or my Posterous blog.
Now that you understand these basic bits of advice, here’s how blogging has worked out for me.
1. It changed my life. When I walked into my job interview in 2010 after being out of work for 18 months, everyone present in the interview had printed out the “About Me” and “About this blog” pages from my blog. And they still wanted to meet with me. (Huh.) And after meeting me, they wanted to hire me. (Double huh.) A few months later, the IT Manager sent me an email whose subject read simply “good blog post”. A few months after that, that same manager came into my office and changed my life. “From reading your blog, I figure that you know something about project management” and then asked me to manage a project for him, even though I was not in IT at the time. I did. A job was posted a few months later…and one internal transfer later, here I am: a bona fide IT Project Manager. Considering that back in 2009 when I was trying to break into IT I couldn’t get ANYONE to even interview me for an IT Project Manager job, I credit my blog with helping to change my career path for the better. Of course, my blog is not entirely responsible for this sequence of events: it does help that I happen to know a thing or two about project management. But my blog helped to establish me as an authority in project management, exactly like it says in the report that you can download here.
2. I can continue the argument all by myself. I have a lot of arguments with a lot of people at work. Because I work with a lot of really smart people who like to argue. They drive me up the wall. They annoy me endlessly. Mainly because they come up with counterarguments to which I don’t have an answer. Which really pisses me off. Then motivates me to think of a counter-argument. And, months later, I’ll finish the argument on my blog and send it to them by email with a note like “Remember when we were arguing if project managers should be technical and you said that you have to be technical to manage technical people? This is my answer to you.” And, if they answer me back with a comment that proves that they read my blog post, then I consider it a small victory. Even if they still disagree with me. And come up with another counter-argument. Which they do. Because they are very annoying that way. Which starts the whole cycle again. Which gets me writing again because I am stubborn as all hell…
3. It really is cheaper than therapy. I really love project management. I really hate being an employee. However, I have come to the conclusion that I like vacations in Italy more than I hate being an employee, so I put up with a lot of stuff that annoys me. The problem is: there’s a lot of stuff that annoys me. Tons. I find being a corporate slave really hard. And sometimes (okay most times) it just gets the better of me. And, on those days I blog. I work out what is driving me nuts and it helps to gather the strength to give it just one more try.
And that last one, dear readers, is the true reason I blog.
Blogging keeps me sane.
I can just imagine what my current co-workers, were they to read this, would say: This is you, sane????
To which they would probably say: for the love of God, please, blog more often.
I’m working on it.
Yeah, I’m still here.
May 13th, 2012
Welcome to my project from hell. Let’s say you’re managing a project. It is two months behind schedule. It’s way over budget. As the deadline approaches, your team is in a visible state of panic. Instead of looking for solutions, they’re looking for reasons to delay the project. Instead of looking for ways to maintain the schedule, there are cries that “we can’t do this”. Instead of working on real problems, such as why users can’t print, there are discussions regarding colours and fonts. New problems pop up about every fifteen minutes and with each problem comes more panic. Instead of spending most of your time solving the issues that would help the project to move forward, you spend time more time dealing with the Chicken Littles that pop into your office about every two minutes.
Welcome to my project from hell.
Sometimes even good project managers go to hell. I know what you’re thinking: I must have done something wrong to deserve this. If you follow PMBOK and do all of those project-management-y things that you’re supposed to do, then the projects don’t go to hell.
Well, let’s go through that list, shall we?
Project Charter which lists deliverables, success criteria, schedule and budget, and signed off by the project sponsor? Check.
Project Schedule? Check.
Project risks managed? Well, a couple of those risks ended up playing on the wrong side which explains the budget and schedule overrun. But other than that: check.
Resources? The right people are dedicated to the project and it’s high level enough that those people have it as their top (and only) priority. Check.
Project’s business case make sense? Check.
So, what else could possibly cause a project to go to project hell?
Those unpredictable, emotional, irrational human beings. Who do not follow the logic of critical path methodology, CPI, or 1+1=2.
It’d be a great job if it weren’t for the people, wouldn’t it?
Managing projects means managing teams. By definition, a project is a unique endeavour with a defined start and finish. Given the “unique” part, chances are pretty good (like 99.9999%) that you need a team in order to execute projects. Which means that, there’s no way around it, managing projects means managing teams. And managing teams means managing people.
Teams go through four phases of team building:
- Forming: The team comes together, and the members get to know each other. There is very little conflict at this stage.
- Storming: Team members are more open with each other and confront each other’s ideas and perspectives. This stage is characterized by conflict, also known as project hell. Some teams never get past this stage. (Did you just cry as you read that? I did.)
- Norming: Team members unite around one goal. There is some give-and-take as the individual members give up their own ideas and accept the decision of the team.
- Performing: This is team nirvana and it’s where you find high-performing teams: the team functions as a whole, “they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision”. If you just read that sentence and it sounded the exact opposite of your team, well then, you’re not here.
There are two key messages that you need to understand about these four phases:
- You cannot get to nirvana without passing through hell. And hell is the Storming phase.
- The Storming phase really sucks. It makes your job suck. It makes the project suck. It sucks your energy and passion. It sucks the motivation out of your team. If the team never gets past this stage, it will fall apart. And so will your project. Which sucks even more.
Here are some signs that your team is stuck in the Storming phase:
- Team members focus on minute details in order to avoid the real issues. For example, they worry about fonts and colours instead of why all of your printers disappeared from your network.
- Team members feel overwhelmed by the work remaining on the project and panic. A task that should take 2 days will balloon out of proportion and suddenly need “two months”.
- Every five minutes, Chicken Little comes into your office to announce that “the sky is falling”.
- Working on the project is an emotional roller coaster and you feel drained of energy after a team meeting instead of energized and ready to tackle problems. During your lunch hour, you eat a sandwich in your car and cry your eyes out.
Be a Mom to get your team out of the Storming phase
How to make the storm pass. As it says here: “The maturity of some team members usually determines whether the team will ever move out of this stage.” In other words, when your team members, who are normally intelligent, competent professionals, behave like children, you’re stuck in Storming.
There is only one thing you can do.
You have to pull out all of the stops.
You have to be a Mom.
Acting like children? Treat them like children. Try these Mom tactics to get your team out of Storming:
- The answer is “No”. If you’ve debated an issue over and over, end the debate for once and for all. Make a decision, make it clear to the team and move on. Do not allow anyone on the team to put the issue back on the table. Instead, distract them with the 50,000 other action items that you have on the project action item list.
- Tough love. If someone is behaving in a way that you find unacceptable, book a one-on-one meeting with that person and make it clear what behaviours you need to see. You’d be surprised at how different people behave by themselves than when surrounded by their team mates, especially when the team stuck on Storming. And don’t forget to mention all the strengths that this person has that seem to have all of a sudden disappeared and that you’d like to see come back.
- No texting at the dinner table, a curfew and other rules. Lay out the ground rules for your team members, sternly and clearly. Meetings scheduled for 9:30 am start at 9:30 am. Confiscate Blackberries that get opened during a meeting. And zero tolerance for broken rules. You’ve got to mean it. So be prepared to follow through on enforcing your rules.
- No whining. A project has enough problems without team members adding more. Sure, list all of the problems, but make sure that more time is spent on finding solutions than whining about problems.
- Time outs. There is no tolerance for bad behaviour. Don’t be afraid to punish misbehaviour: sternly, politely, but mostly sternly.
Raising children is hard, but rewarding. When you see your 15-year-old daughter up on a stage at her high school musical belting out a tune and you’re asking yourself where on earth that came from but you’re as proud as hell, that’s when you remember how rewarding parenting is.
And when you’re sitting at the project post-mortem, reviewing the end of a successful (although difficult) project and that dark period in your team’s journey is long past, that’s when you remember how rewarding project management is.
Project management doesn’t always suck.
Happy Mother’s Day.
March 27th, 2012
Perfect composition depends on the artist, not the tool
Real photographers use real cameras. One of the first toys I bought with the income from my part-time job in high school was an SLR camera (no “D” in those days) (yeah, I’m that old). As I was 18 years old at the time, it basically means that all of my adult life (uh, a long time), I have equated “being serious about photography” with “having the right equipment”: a “real” camera with several lenses, a tripod, a polarizing filter, etc. I carried this paradigm with me when I transitioned from film to digital about 5 years ago: after my initial purchase of a DSLR, I added a better tripod, a couple of lenses, a remote cable switch and a flash. As for my camera, there was never any question of my getting a “point-and-shoot” camera: such things were for children or for people who only wanted to take snapshots at family gatherings.
You cannot possibly make art without the right, and best, tools.
Then I heard about Chase Jarvis.
The best camera is the one that’s with you. When I first stumbled upon Chase Jarvis’ website about three years ago, my jaw dropped. I dream to take pictures like these…and he was doing it with an iPhone (the first one, not the 4S). A camera phone. The loser of loser point-and-shoot cameras.
If a loser camera could produce better pictures than I could with my DSLR, then what did that make me? (Don’t answer that.)
It finally dawned on me: my pictures sucked. And they sucked not because I didn’t master focus or depth of field or exposure. I didn’t master composition.
The problem wasn’t the tool. It was me.
It’s not the tools, it’s you. There was a point in my career over ten years ago when I faced a crisis. I had just finished two projects, one after the other, which were considered failures. The indicators were awful: –50% gross margin, eight months late and a pissed-off customer. You don’t pull in numbers like that (and do it twice in a row to boot) without getting a whole lot of phone calls from a whole lot people asking a whole lot of questions that you’d rather not answer. But the one question I knew they weren’t asking out loud was: was it the Project Manager?
So, I had a little performance review with myself and asked myself the one question that no one had asked me: did I suck at this?
There were many reasons why these projects pulled in such dismal results. One of my favourite reasons, that I held onto like a crutch, was that I just didn’t have the right tools to allow me to control my projects. Getting even a simple report of budget versus actuals out of our woefully inadequate ERP system was like pulling teeth.
However it was only during that performance review with myself that I was finally able to admit the painful truth behind my failure.
It wasn’t the tools.
It was me.
I had totally and utterly failed to control my scope.
The art of project management is scope control. Controlling scope is the single most important thing that will result in project success, and it also happens to be the hardest thing to do well. All the S-curves and Gantt charts and PM Dashboards and flashing lights in the world won’t save your project unless you are in control of your scope. When project scope grows unchecked, you end up doing more than you planned, which makes it look like you took longer and spent more to do your project. But really, the only reason that the project took longer and cost more is because…well… you did more. And if you let scope increases “just happen” without telling anyone that you need more time and money (in other words, you didn’t update the project schedule and budget to take into account this additional work), you look like a really crappy Project Manager.
Like I did.
It’s really very simple: if you do more stuff, it takes longer and costs more. So, before you do more stuff, you need to make sure that everyone, especially your customer, knows that you’re doing more, is willing to pay for it and will give you more time to do it. Finding out at the end of the project that you did more is too late.
Scope control is more art than science: not only do you have to clearly identify your project scope (and look for the “gotchas” before they get you) at the beginning of the project, but you have to work daily (even hourly!) to protect your scope from changes.
Once I came to this realization, I decided to give myself one more chance before I went off and looked for another career. I decided to control the hell out of the scope of my next project.
That “next project”? It finished on-time, at double the revenue and 20% more gross margin than I started, with a happy customer. And how did I do this?
I controlled the hell out of that project scope.
I guess I didn’t suck after all.
How to control the hell out of your project scope. In six easy steps no less…
- Define the scope. You can’t control what you don’t know. So it’s crucial to spend time to understand your project before you dive in. Make sure that you can answer these questions: What does “done” look like? What are the list of things (deliverables) that the project will produce? When are they due? At what agreed cost? How do you know that the deliverables are good? (What are the success criteria?)
- Agree on the scope. The kick-off meeting is the forum to present your understanding of the scope, and to get an agreement from your customer / project sponsor as to what that scope is. Keep your representation of the scope as simple as possible without forgetting anything: use lists, tables and lots of pretty pictures to represent your scope. And don’t forget the schedule and budget: scope drives the project schedule and budget and not the other way around.
- Agree on how you will change the scope (the change process). Let’s not be naive: there is no way that your project scope will be static. Changes are inevitable. So it is best to agree at the beginning of the project (preferably at the kick-off meeting) on how you will change the scope. This change process must define: who will submit changes, what the format looks like, and who will approve them. As for the “who” on your side? You, of course. And only you.
- Publish the scope. Once you have an agreement on scope, publish it. Use whatever means are appropriate for your project (it could be as simple as an email). Just make sure that everyone who needs to know what the scope is knows it.
- Protect the scope. This is the hard part: protecting your scope. Remember how change is inevitable? This means that you have to be on the alert for clues that your scope is changing without you knowing about it. Learn to read (and listen) between the lines of any conversation you have with anyone even remotely involved in your project. Beware of sentences that start with “While you’re at it ….” or in French “Tant qu’à y être…”. And call a spade a spade: don’t be afraid to say things like “That’s a change. Let me look into it for you and I’ll let you know what the impact is on the schedule and the budget”.
- Update the scope. After you have agreed on changes (remember that change process you defined at the beginning of the project?), be sure you update and re-publish the scope. All that fun stuff you documented at the beginning of the project (the deliverables list, success criteria, schedule, budget, etc. etc) needs to be updated with your agreed changes. This way everyone knows that the “teeny tiny” whileyoureatit / tantquàyêtre will add another six months to the schedule and 50% more budget.
My super-duper scope control tools. To help me control the hell out of my project scope, I decided I would no longer hide behind a crappy ERP system. (Aren’t they all crappy?) Along with those six easy steps (that all of sudden I remembered I knew), I decided to use some magic tools of my own. Are you ready?
My attempt at scope control.
- The org chart tool in Power Point. For every element of work in the project, I drew a box. And I didn’t stop until I had drawn all of the boxes.
- A pad of lined paper and a pen. Every time anyone mentioned anything that even remotely affected one of the boxes in my drawing I wrote it down on a list, in numerical order. And I called it my “change log”.
- Excel. Ah, the duct tape that can fix any crappy ERP system. I got the costs out of the ERP system, slapped them in a worksheet, added a few columns and called it done. Every Monday, I updated it. A few hours a week was all it took to figure out if I was on budget.
As for the most important tool? Me.
Scope control is to project management what composition is to photography. No matter what expensive lens you buy, no matter what top-of-the-line DSLR camera you own, if you don’t master composition, you don’t master photography. Composition is what turns a photograph into art. And taking a photo with a camera phone forces you to block out the noise associated with tools (stuff like aperture, exposure, f-stops and filters) and focus on the art. Every time I take a picture with my iPhone (I no longer look down on camera phones), I am able to focus on that one thing that makes a photograph good: composition.
This is the same process I employed at that turning point in my career when I decided to control the hell out of my project scope. I ignored my frustration with inadequate tools, took out a pad of lined paper and focused on the one thing that makes a project good: scope control.
The best project management tool is the one that’s with you.
And that tool is…you.
July 24th, 2011
It’s the summer where I live, which means vacation. Which also means a time to read and reflect about things. If you happen to be tired of improving your Angry Birds or Sudoku scores on your favorite mobile or tablet device, here are 3 YouTube videos that changed my life.
You’re welcome to let them change yours.
The 22 minute meeting. If the chatter on the internet is any indication, we are all obsessed with the inefficiency of meetings in the workplace. With good reason. Because most meetings suck so badly, it’s painful. This amusing video is only 5 minutes long and, after listening to it several times last year, I actually considered replacing that poster in our washrooms on “How to Wash Your Hands” with Nicole’s handy-dandy poster. In fact, I just might still do that.
As for the “changing your life” part, I was so intrigued by the challenge of giving a 5-minute presentation that I promised myself that I would try it. Which I did, earlier this year.
The Impossible Hamster. After watching this short video, I lost 3 hours surfing the nef website, which lead to more thinking that the 2008 / 2009 financial crisis is a sign that maybe our system is seriously flawed.
I’m still thinking.
At the very least, take a lesson from this video on the power of a simple story or metaphor to communicate your ideas. It sure beats a bunch of bullets on a Powerpoint slide, don’t you think?
RSA Animate: Crises of Capitalism. I picked up an RSA Animate video from my Facebook NewsFeed and I enjoyed the experience so much that it has quickly become my favourite YouTube channel. Again, take a lesson from watching any of these videos to notice the power of pictures and key words to communicate an idea or message, no matter how complicated.
Scrolling through the videos in the series, I tripped over this one by David Harvey. After I picked up the bits of my exploded head from off the dining room floor, I have since discovered his website, his free video podcasts in iTunes U, and a book coming out on the Kindle this summer.
And yes, that’s Marxism he’s talking about on his website.
Did you just squirm? So did I, self-styled fan of neoliberalism, when I typed it. Challenging your paradigms hurts, doesn’t it?
Caution, shifting paradigms ahead. As for all those silly CIOs and CEOs that ban YouTube from the workplace, you can use this blog post as proof that there’s some pretty useful stuff on that there internet thingy. It’s more than just about the top song playing in Italy this summer.
Happy watching and try not to get hurt from those shifting paradigms!
June 13th, 2011
The way we were. Throughout my career, I always seem to find myself in business process review and implementation. As I am very comfortable questioning…well…everything, I end up …er…helping people let go of the “way we used to do things”.
It’s hard work. Mainly because people really love their paradigms. Here are some of the business process paradigms that I have come up against:
|What they say to me…
||What I wish I could say back…
|The only way to tell if a document is controlled is if it’s signed. In ink.
||Document control can be done by software. Which runs on a computer. Welcome to the 90s.
|I need to approve this form so that I can know what is going on.
||You can subscribe to the RSS feed so that you’ll be informed each time the form is generated. Welcome to the 90s.
|It only takes me 15 minutes so why worry about that step?
||It happens 300 times a year, which is 4500 minutes or 75 hours. That’s the equivalent of a 2 week vacation that’s wasted on…nothing. Don’t you keep saying you’re too busy to (fill in the blank)?
|Transferring costs from one budget code to another takes no time. Why worry about it?
||But there are 100 of you generating requests for transfer which keeps an entire team busy for one week. That’s about $100K a year spent on…nothing. There, now we can afford that new expert I keep telling you we need to hire.
I, of course, have no paradigms. None whatsoever. Because I am perfectly open-minded and never resist change.
Except when it comes to turkey.
Welcome to my paradigm. During our planning meeting for our Christmas 2010 Turkey dinner, my Dear Husband (DH) brought up some process improvement ideas. During our post-mortem of last year’s dinner (what? you don’t do a post-mortem on all of your projects?), we noticed that we were still spending too much time in the kitchen in that crazy period when the turkey comes out of the oven and it is time to get everything on the table. In an effort to improve on this madness, DH suggested that we do as much cooking as possible either the day before or even the morning of the dinner: the gravy, the cranberry sauce, the tourtière and even the mashed potatoes. Our resulting schedule was a complete re-engineering of the Christmas turkey dinner and I was onboard for every single change that he suggested and even came up with some myself. Because, as I mentioned, I am completely open-minded to change.
But towards the end of our planning session, DH made one more suggestion. He kept it to the end for a very good reason. Because he knows me.
“We could also make the turkey one day ahead.”
“I was talking to this woman at work, she loves cooking just like you do, and she makes the turkey in advance, then cuts it up, puts it in a shallow roasting pan, pours homemade chicken stock over it, covers it with aluminum foil, pokes some holes in it, then just heats it up in the oven. This way when the guests arrive, they smell the turkey but you get none of the hassle of carving it to serve it…”
I looked at him, absolutely horrified. Cut up the turkey? When you take it out of the oven, it’s in pieces? Chicken broth?
It has taken me this long just to be able to write about such a travesty.
Welcome to my turkey paradigm.
Shifting paradigms and other MBA crimes. Before we get into my turkey paradigm, or any of the paradigms that I encounter in my business life, we need a common understanding of what exactly is a paradigm. In simple terms, a paradigm is a thought pattern or a framework of ideas, a set of rules if you will, that is accepted to be true. The term was originally coined to describe a set of practices that define a scientific discipline at any particular period of time, but it has now suffered such abuse at the hands of MBA-wielding professionals that it has almost lost its meaning. (Ooops.) But for the sake of this discussion, let’s consider it as “the box”, as in, when you think “outside of the box”, you move outside of your paradigm or what you accept to be true. Because we haven’t killed that analogy enough either.
These days, paradigms are shifting all around us. (Double oops.) Here are examples of paradigms that I see everywhere, as well as the challenges to those paradigms which will cause them to shift. (See? I can’t stop.) I plan to write a blog post on each one of these subjects…eventually.
|A book is something that you hold in your hands with real pages that you turn. I will NEVER read books on an e-book reader.
||I named my new Kindle “Never say never”.
|There is no place for democracy in a company functioning in a capitalist framework.
||Yes, there is.
|We need Wall Street and Bay Street for our economies to function or else the universe will explode. That’s the reason for the 2008/2009 bailouts.
||No, we don’t.
|We need to pay CEOs $50 million / year so that they’ll continue to do a great job.
||CEOs have become the new monarchs. They earn their salaries no more than Kings and Queens do.
|Performance reviews help employees to improve themselves.
||Performance reviews don’t work.
|If we give access to all employees to the wiki, they’re going to delete important information.
||Right. Because Wikipedia doesn’t work.
It’s my paradigm and I’ll cry if I want to. So as you can see from the above table, I am not afraid to challenge any paradigms. This is because I am a very open-minded person who embraces change.
Except when those ideas are totally ridiculous and silly. Like cooking a turkey one day before, cutting it up, putting it in a shallow roast pan, and pouring chicken broth all over it.
Because everyone knows that there is only one way to prepare a Christmas or Thanksgiving turkey: you brine it the day before, you stuff it, you roast it in the oven until it reaches an internal temperature of 160 degrees F, you take it out of the oven, you put it on the table so your guests can “ooh” and “aah” how perfect it looks, then you carve it and serve it.
Which brings me back to my Turkey Paradigm.
We all resist change. Every single one of us clings to set of ideas and principles that we just can’t let go.
I’ve always done it this way but for a good reason. According to John Fisher’s transition’s curve, which describes the process for personal transition, I ran off the curve at Disillusionment in my Turkey Paradigm when I decided that “this wasn’t for me” after surfing the web for about 15 minutes and (thankfully) finding nothing about advance cooking and cutting up of turkey. According to Kotter’s 8-step model for organizational change, I certainly saw no urgency in trading off the beauty of presenting a roast turkey against the questionable convenience of this cook-cut-reheat approach. And, sure, when it comes to roast turkey, I’ve “always done it this way”, but I have a much better reason than, say, the reason for the “0” on this form.
Not the greatest picture but I was a little busy
Never say never. Our re-engineered Christmas Turkey Dinner 2010 was a huge success. We were able to enjoy time with our guests and still pull off a full-course turkey dinner, complete with homemade tourtière, made-from-scratch Christmas Log cake and cookies, cranberry sauce, gravy, mashed potatoes and green vegetables.
As for that turkey?
It tasted as delicious as it looked when it came out of the oven in its glorious roasted splendour.
Whole. In one piece.
Will I ever cut up a turkey to save time and hassle?
But then, I also said I’d never read books on an ebook reader, didn’t I?