“Project management is my favorite process, project managers are my favorite people, and there is not much I’d rather do than talk with project managers about project management!” Margo Love

Table of Contents

01:26 … Meet Margo
04:31 … The One Process Margo has Not Performed
06:45 … The Customer on Internal and External Projects
09:32 … Margo’s Pick from the PMBOK Guide’s 33 Project Documents
13:33 … Requirements Traceability Matrix
16:43 … RACI Chart
21:19 … Work Breakdown Structure
25:08 … A Project Charter
29:47 … Rolling Wave Planning
33:52 … Lessons Learned
38:10 … Final Words of Wisdom
40:52 … Closing

MARGO LOVE: The other thing is get training.  I can’t say enough how important I think it is for people who are managing projects to recognize that this is a professional undertaking.  And you would not ask a dentist to go into the dentist’s office and just look in your mouth and figure out what to do.  I’m sure you’ll be able to figure it out.  You’re smart.  You know, you brush your teeth, so go help.  But we ask our project managers to do that all the time. You know, you’re a great programmer, you’re great with people.  They’ll say, “Oh, you’re great with people.  We need you to manage this project.”  Well, fine, but being great with people doesn’t mean that you know how to manage a project.  And I think training is invaluable in that regard.

NICK WALKER:  Welcome to Manage This, the podcast by project managers for project managers.  We’re setting aside this time to talk about what’s important to you as a professional project manager.  Our guests include some of the best in the field, those who live and breathe project management and want to share their passion.

I’m your host, Nick Walker, alongside resident expert Bill Yates.  And Bill, this time around we’re talking with someone who really does epitomize that passion.

BILL YATES:  Yeah.  Margo is a delight.  She is a wonderful trainer.  She was born for facilitation and training, and so it comes from her heart and passion for project management and for people.

Meet Margo

NICK WALKER:  Well, let’s learn a little bit more about her.  Margo Love became a fellow of the Life Management Institute in 1987, achieved her PMP (Project Management Professional) certification in 2000, and earned her Six Sigma Black Belt in 2001, making her a certified project management and process improvement nerd.  She also has over 30 years’ experience managing projects and project managers in information technology for the life insurance and utility industries.  So Margo is Skyping us from a very rainy Greenville, South Carolina today.  Margo, welcome to Manage This.

MARGO LOVE:  Thank you.  I am delighted to be here.

NICK WALKER:  I love this quotation from you.  You say “Project management is my favorite process.  Project managers are my favorite people.  And there is not much I’d rather do than talk with project managers about project management.”  So can you tell us a little bit about your experience and how it’s brought about that kind of affection for the profession and the people in it?

MARGO LOVE:  I’d be glad to.  And in fact, it’s funny to hear you say – to read my words because, when I managed my first project, I hated it and I was terrible at it.  My background is in programming, software programming.  And I had been a programmer for about two years, I guess, when my company asked me to manage a project. I was so impressed with myself, and told my mother I was managing a project, and I had no clue what I was doin, I was terrible at it, I hated it.  Everybody hated me.  And so I was done with that for the rest of my life.

And about 10 years later, maybe 15, our company went through a traumatic project.  Then coming out of that, the new CIO asked me if I would head up a project management organization, which was just hilarious.  And I said, “You don’t understand that I don’t do that.”  But he talked me into it.  He said, “I think you’ll like it if you have some training and give me one year.”

And so for one year I worked with a group. We all got PMP certified, we had good training, and we also set up a good project management office with a good methodology.  And he was right.  I was hooked.  And so kind of the rest is history.  But I definitely do enjoy managing projects, and I especially enjoy talking to project managers about their project, and hearing from them, too.

NICK WALKER:  So from what I understand, you’ve done almost all your project management work in companies that took project management pretty seriously.  Good methodology.  They supported the project manager.  Now, there are 49 processes that we talk about in project management, and 33 project documents that we teach about.  So our time is going to be almost sort of a “Stump the PM” session, where we try to find out something in the framework maybe that you haven’t done.  So Bill, why don’t you get us started on our little game show here.

The One Process Margo has Not Performed

BILL YATES:  Yeah.  Margo, just for kicks, I brought the 756-page PMBOK Guide, 6th Edition with me.

MARGO LOVE:  Thank you, thank you.

BILL YATES:  I think what I’ll do is just – I’ll call out a page number and then just ask you to quote the page, just from memory.

MARGO LOVE:  So you are a [crosstalk].

BILL YATES:  Yeah.  When Nick’s talking about the 49 processes, that’s in that framework, and you mentioned that you’ve probably performed all of them, almost all of them, probably 48 of the 49.  So I’ve got to ask you, what’s the one process that you don’t think you’ve really performed?

MARGO LOVE:  Well, I was going to make you guess, but I will confess that I have never performed “Perform Quantitative Risk Analysis.”

BILL YATES:  Ah, okay.

MARGO LOVE:  And so I used to feel guilty about that.  But this version of the PMBOK Guide actually says this is an optional process and not appropriate for every project.

NICK WALKER:  Oh, you’ve got an out.

BILL YATES:  Yeah, yeah, you’re right.

MARGO LOVE:  Yes.  And I’m like, yes, so I knew that all along, and the reason I’ve never performed it is twofold.  For one thing, a project manager can’t do it by yourself.  It requires a lot of assistance from the performing organization; some experts that can help you with the numbers.  And also one project performing that is not as meaningful as if it is an organizational strategy, that all of their projects perform it.  And so I have not worked on a project where any of the organizations I’ve managed for would have known what to do with the output.

BILL YATES:  Got it.  Yeah.

MARGO LOVE:  So, and neither would I.  I mean, that…

BILL YATES:  There you go, yeah.  You’re right.  PMI did in the – I think going from the 5th to the 6th edition they made that change where they said – they finally said, okay, look, there’s “Perform Qualitative Risk Analysis,” which is most of the toolsets that we’re accustomed to.  And then “Perform a Quantitative,” they finally put a big old asterisk on it and said “Only if needed.”  So you do, Nick’s right, you’ve got a legitimate out, Margo.  You’ve really – you’ve done them all.

MARGO LOVE:  Great.  I can stop feeling guilty.

The Customer on Internal and External Projects

BILL YATES:  Yes, you should, absolutely.  So one thing I wanted to step back on and ask you about is describe to us your customer.  I think you’ve done both internal and external projects.

MARGO LOVE:  Yes.

BILL YATES:  So talk about that for a second.

MARGO LOVE:  I’m glad you ask because project management changes a little bit, I think, depending on who your customer is. So my first projects were all internal, meaning I was charged by the organization I worked for to manage a project that benefited the organization I worked for, and managed several projects like that where essentially your sponsor and your customer are the same person.  Then I went to work for a consulting organization that provides project management and similar services for large-scale software integration projects. And so for those customers I was always working under contract.  The customer was an external contract who was clearly paying me to be a project manager, and so in that sense of the word it was a bit different than an internal project.

There’s another type of external project that I have not managed, and that is when the customer has paid your company for goods or services, and your company assigns you to be the project manager on the company’s behalf.  And so in that regard, the customer may not even know there is a project manager, may not care.  But your company knows and cares because they want to deliver successfully.  So they’ve charged you to be the project manager.  I’ve not been in that situation.

And then the fourth type really, I would say, is still a very important type of project.  And so that’s a volunteer project where there’s no one really paying, and maybe not even a sponsor.  But an organization I’ve been a part of has undertaken one project or another, and I have either volunteered or been asked to lead the project.  And I think project management concepts are still extremely important, but are delivered a little bit differently in a volunteer situation.

BILL YATES:  I agree with that.  It’s funny, Margo, I mean, you and I have to get pretty nerdy with this PMI stuff, the jargon and all.  And they talk about enterprise environmental factors, and, so you know, it’s a fancy way of saying there are a lot of things that can influence your role as a project manager.  And I think you’ve hit on the big ones there.  It’s like, what kind of company am I working for?  And is this an internal engagement or an external engagement?  Do I have a customer?  What is their expectation about project management?  And those influence our job in a big way, for sure.

MARGO LOVE:  It does.

Margo’s Pick from the PMBOK Guide’s 33 Project Documents

BILL YATES:  So one of the things that I wanted to get into with you, Nick mentioned 33 project documents.  He’s actually got a tattoo on his left forearm representing all 33.  It’s just something he did when he went deep with Manage This.  I really appreciated his commitment.

NICK WALKER:  Some of them are fuzzier than others here.  So I’m wondering if I’ve got all the important ones tattooed there.  Are they all created equal?

BILL YATES:  So if you had 33 project documents – and again, this is a reference to the 33 that are in the PMBOK Guide.  For those who care, it’s on page 559.  But if you had to pick one of those, what would be the one that probably meant the most to you or changed your life the most as a project manager?

MARGO LOVE:  I could probably make a list of five or six that really did change my life as a project manager and have made it easier.  I will say the one I have used consistently from the earliest days of my project management to this very week, no matter what type of project I’m managing, is the issue log.

BILL YATES:  Yeah.

MARGO LOVE:  There are some volunteer projects where I spend more time and effort managing issues than I do managing schedule, budget, people, all those other things.  Project managers are largely called on to solve problems.  And problems go in your issue log, along with questions, decisions, things you need to research, things that you need to ask somebody else to do.  All of those kind of things go in my issue log.  And it is the first thing on my desk that I open in the morning and usually the last thing I close at night.

BILL YATES:  And Margo, when you talk about an issue log, are you talking about something that every stakeholder on your project can see?  Or is this kind of team eyes only, or Margo eyes only?  Or do you have different issue logs?

MARGO LOVE:  That’s a great question.  And as a matter of fact, for most of those 33 documents – not all, but most – I would say I have multiple versions of them.  I will have multiple versions of the schedule, and certainly multiple versions of the issue log. So I do keep a stakeholder issue log with my external stakeholders outside of the team, and sometimes I will have an issue log for a particular stakeholder. These are the questions and things you have asked me to follow up on.  Sometimes I’ll combine them with others, and then on some projects I may combine them all into one.

But it is not unusual for me to have my own personal issue log that I’m keeping up with that no one else sees.  And then I may have one that the team members contribute to.  Not because I’m hiding anything.  Not because it’s secret.  But first of all, all the stakeholders don’t need to know what’s keeping me up at night and what’s bothering me.  They pay me to solve those things without letting them know about it, so I am very comfortable keeping separate issue logs for the situations as they’re needed.

BILL YATES:  Yeah, yeah.  I’ve found that to be true, as well, especially when it comes to tricky stuff like, you know, you’re assessing stakeholders and trying to determine if they’re for you or against you, and how can I influence them? You know, so what’s our strategy for getting somebody who’s got a lot of influence to actually be in a supportive role?  And it may be more than I want to keep in my head, so I document it, and it’s a type of issue log or a strategy.  But I don’t want everybody reading that one. 

MARGO LOVE:  Right, exactly, exactly.  So if I have an issue that someone is not performing well, I certainly wouldn’t want to make that information available to the rest of the team.  So I would keep that separate.

BILL YATES:  Yeah.

MARGO LOVE:  Or maybe I have an issue that I think I’m not performing well.

BILL YATES:  Right, right.

MARGO LOVE:  I don’t want that in there, either.

BILL YATES:  Yeah, that’s true.  Yeah, it could be a personal thing, okay, so I need training in this area.

MARGO LOVE:  Exactly.

BILL YATES:  Or here’s something I’ve got to pick up on, or find a book on a topic.  That’s a great point.

Requirements Traceability Matrix

BILL YATES: All right.  I want to pivot with you, what about, before you started going deep into PMBOK and PMI, had you ever come across a Requirements Traceability Matrix?

NICK WALKER:  What?  A what?

BILL YATES:  Yeah, you just are – so Nick’s thinking of movies, he’s thinking of all kind of different things here for the matrix.

NICK WALKER:  Requirements Traceability Matrix,so is that just a fancy way of saying what have people asked for, and who asked for it?

BILL YATES:  Yeah.  Wow.

NICK WALKER:  Oh, okay.

BILL YATES:  I think we’ve got a budding project manager on our hands here.

MARGO LOVE:  Well, actually, yes, and we use ours for more than just keeping a source of who asks for what. As I said, the company that I have consulted with, so in that company I am paid to be – they are paying our company for project management services.

BILL YATES:  Right.

MARGO LOVE:  So I must manage as a professional project manager.  So I must know how to use all of the tools and the inputs and outputs.  And what we do with the Requirements Traceability Matrix – which, by the way, is another one of the 33 that changed my life because this is one reason our projects are successful.  They’re delivered on time, on budget, and meeting the requirements to the satisfaction of the stakeholders because of our Requirements Traceability Matrix.

So we will list all of our requirements, and we will have thousands.  We’re not talking a list of 15 things, so we’re talking thousands of requirements. And so ours is it can be in an Excel spreadsheet, in my head that’s what it looks like.  And the first column will have what is the source of the requirements.  So you’re correct, Nick, we do trace it back to the person that came up with the requirement. Or if it’s a government regulation, then what governmental body is going to have that requirement.  Then each column traces the requirement through the project.

So these are software projects, and by that I mean the second column may have the name of the design session where we will design a solution for that requirement. And so the third column may have the name of the software module that meets the requirement, and the fourth column may have the name of the test case that will test the requirement. Then as it goes through the entire project, we check off that we have accomplished seeing the requirement traced through every step in the software development process.  And the last column is actually a signature by the owner of the requirement that they have seen it work in the test system.  And before we can make the test system live, we have to have signatures on all of those requirements.

BILL YATES:  Wow.

MARGO LOVE:  And we’re heavily audited on that, the auditors go back and double check that every requirement went through the process and was signed off before we went live.

BILL YATES:  That’s really robust.

NICK WALKER:  I can picture that.

BILL YATES:  Yeah, you can see it in your head.

MARGO LOVE:  It keeps, well, it is.  It keeps things from falling through the cracks, and again, like I say, our software  works when we go into production because of that.

RACI Chart

BILL YATES:  Right.  Okay.  You just made me think of something else.  So we’re still playing Stump the PM, and you made me think of a very practical tool that maybe some project managers are not using today that I think changed your life.  You and I, when we were talking earlier, I think you mentioned that.  So what is RACI?  What does that stand for?  What is RACI?

MARGO LOVE:  A RACI chart is a type of another fancy name which is Responsibility Assignment Matrix.  But I find that there are many project managers using RACI charts.  And, yes, that was another thing that I used early, that has really helped me in the beginning of a project, very early on.

A RACI chart is another Excel spreadsheet, and the columns across the top will represent different participants or stakeholders in the project by role.  Typically I don’t put names on it.  But I’ll have programmers, testers, business analyst, data architect, roles across the top, and then work packages for my work breakdown structure along the left, the rows on the left.  And at the intersection I will say whether the role is Responsible, Accountable, Consulted, or Informed for the work package.

Now, that’s where it gets its name, RACI, from those letters. So I have found it to be very helpful.  However, I confess that also at the beginning of many of my projects we spent way too much time arguing about what’s the difference in “responsible” and “accountable.”

BILL YATES:  And accountable, yeah.

MARGO LOVE:  And so, finally, I threw out the letters RACI and developed our own system that works on our projects of letters that represent people’s responsibility to the deliverables.  So, for example, on our projects we say, “This person is responsible.”  That means they’re doing the work.  “This person is contributing.  So this person is informed of the results, and this person reviews the results.”

BILL YATES:  Okay.

MARGO LOVE:  And so that way, very early in the project, everyone knows what’s expected of them throughout the project.  And so as I am developing the project schedule and the resource assignments, I know what type of work to assign to which type of people based on their role.

BILL YATES:  Yeah.  You just hit such a key point, Margo, from my experience.  So one of the keys is to make sure that the team members are all on the same page as to these abbreviations or this tool or this technique we’re going to use. And even, you know, you and I are in the classroom a lot, and so I’ve experienced the same confusion over RACI, you know, who’s responsible?  Who’s accountable?  And so everybody’s, like, going to Wikipedia or going online to look into different opinions on it.

So to me that just points out, okay, this is something you need to have a conversation with your team about, and you don’t have to use RACI.  You can use something different, but use something that makes sense to your team.  The importance is to have the roles across the top and the responsibilities across the rows so that we can have a good conversation about who’s going to do what.

MARGO LOVE:  Absolutely.  And I’ll share a funny story.  So I had one sponsor who was sitting in on the process of completing the RACI chart.  And he said, “We pay you to be accountable for everything, so you must have the ‘A’ for everything in this project.”

BILL YATES:  Okay.

NICK WALKER:  Agh.

MARGO LOVE:  Which technically, yes, I get it.  I’m paid to be accountable for the success of the project, but the RACI chart would be meaningless to me, personally, if every row had an “A” on it.  I needed to know who is the go-to person that I could go to as the project manager.  So it was in that conversation when I decided “A” was not going to work for us.

BILL YATES:  Yeah, yeah.

MARGO LOVE:  And so I made myself “A.”  I was accountable for everything, and then I added an “O” for Owner.

NICK WALKER:  Ah, good.

BILL YATES:  That’s good, yeah.

MARGO LOVE:  The person on the team who was owning making sure that this got done. So that was the beginning of my downfall in the RACI letters, and from there I just went crazy.

BILL YATES:  You just went crazy with it.

MARGO LOVE:  And then just made up whatever I wanted.

NICK WALKER:  It sounds like it worked, though.

BILL YATES:  Exactly.  As long as it gets the job done, right?

NICK WALKER:  Yeah, yeah.

Work Breakdown Structure

BILL YATES:  Margo, speaking of getting the job done, so I have to confess to you, I have been able to successfully manage projects where we did not have work breakdown structure.  And I know that is just scandalous, I know it’s breaking your heart to even hear that. It is a best practice, and it’s, you know, so I’m sure that you could argue, well, just think how much better or smoother or more effective or even further under budget you would have been had only you used one.  Because, you know, you mentioned that this is one of those 33 documents that changed your life.  So talk to me about your first encounter with your work breakdown structure, how you two fell in love, and how your marriage has worked out.

MARGO LOVE:  Well, I did start off managing without work breakdown structures because the company I worked in never did that.  I learned about them when I got my PMP certification and during that training that I had.  And all of a sudden it made sense to me because a work breakdown structure is a very deliberate look at the components of the thing you are creating.  So it keeps everybody very focused, not on the tasks that we’re doing, but on the thing that we’re building, and it gives you flexibility in those tasks.

And so one of the downfalls of not using a work breakdown structure is that the tasks in the schedule become the law.  And we have to do these tasks because the schedule said we had to do these tasks.  If you can back that up to a work breakdown structure, then people have a little more flexibility.  Okay, so I don’t need to do this task and that task, I have a different idea, great.  Go do it however you think it needs to be done, as long as we get it done correctly.

BILL YATES:  Yeah, just create the work package, yeah.

MARGO LOVE:  It really frees everybody up a little bit, I think.  Do you have time for another story?

BILL YATES:  Oh, I’d love to hear a story.

NICK WALKER:  Always time for stories, yeah.

MARGO LOVE:  Once I learned the benefit of a work breakdown structure. Now, and so by the way, let me say I do not create a beautiful hierarchical tree that we print and publish.  Usually I scratch it out on a whiteboard. So I may scratch it out on a piece of paper, we look at it, we refer to it briefly.  I live and breathe by it. So the team really doesn’t spend as much time with it as I do.

BILL YATES:  Yeah.

MARGO LOVE:  But that said, once I learned about work breakdown structures, I cannot manage any project without one.  And when my daughter decided to marry the love of her life, and we sat down to plan that wedding, of course we had a target date and a budget. And so I said, “The first thing we’re going to do is create a work breakdown structure.”  And so, bless her heart, I taught her all about work breakdown structures.  But it made so much sense to her, and it worked so well for us, to always not let any component fall through the cracks.  Every component got a schedule with tasks.  Every component got a budget with money.  And in the end her project was delivered on time, almost on budget – well, it was actually on budget because we had an Approved Change Request.

BILL YATES:  There you go.

MARGO LOVE:  Which brought the baseline up so that it was in the budget.

BILL YATES:  I’m with you.

MARGO LOVE:  And certainly met all the requirements to the satisfaction of the stakeholders.

BILL YATES:  Well, as long as Mama was happy.  I mean, so that’s the key stakeholder.

MARGO LOVE:  And Mama was happy, too, yeah.

BILL YATES:  Yeah, that’s the key.  That’s the key.

NICK WALKER:  I fully expect to see a work breakdown structure being used on “Say Yes to the Dress,” you know, from now on.

MARGO LOVE:  So if I were managing that show, there would be a work breakdown structure.

A Project Charter

BILL YATES:  Completely, yeah.  Margo, while we’re on the topic of things that – I guess it’s Bill’s confessions from past projects.  I did not make use of a project charter, either.  I did in some cases, and in other cases I got so much backlash from my customers – again, the projects that I worked on were kind of type three that you were describing.  They were, you know, so I was the project manager for our company, we were installing software, implementing for clients.

So the customers sometimes would push back, I can remember one time being in a conference room in a customer site. We were doing a new project for an existing customer, and so it was like a big enough new effort that they said we need to really create a separate project for this.  So we were sitting around the conference room, trying to hammer out a project charter. And I remember the customer, Rick, finally pushing back from the table and saying, when are we going to finish doing this so we can start the real work? And so it was kind of that thought of, okay, maybe we need to put a bow on this charter and move on.

MARGO LOVE:  And move on.

BILL YATES:  So what’s your perspective on the project charter?

MARGO LOVE:  The primary purpose of the project charter is to transfer authority from the senior management of the organization to the project manager so that you have the authority to spend the money and assign people to do work.  And so if I found myself in a situation where that was inappropriate or not appreciated, I probably would not do it.  However, I say that.  Let me give you a few reasons that I think a charter is important, even if you do have a contract.

So typically, the details of the contract are not something you would want to share, or it could be that they’re not something you want to share with all of your team members.  I have worked on contracts before where there were financial penalties or financial terms of the contract that were not appropriate to share with every team member on the team.  So a charter is a summary document that summarizes those details in a more public viewing way. Your charter should be brief, so if you’re spending a long time arguing about it, you are probably putting too much into it.

BILL YATES:  Exactly.

MARGO LOVE:  Because the charter should be brief, ours are one-pagers, and it’s almost just the first page of information I’m going to share with any stakeholder about this project.  It’s public, it says here’s the overall target date.  Here’s the overall financial funding, here is the overall other constraints I’m working under, and Margo Love is the project manager.

BILL YATES:  Yeah.

MARGO LOVE:  Now, I try not to wave it around in people’s faces, so I don’t put it on my wall in the office.  But I do hold on to the fact that I am named as the project manager in the project  charter because, frankly, in many of the projects I manage there is more than one person who thinks they’re the project manager.  And so if you start with the charter, with the entire team and all of your senior management stakeholders, it is very clear who’s the project manager, and you don’t have to fight for that throughout the project.  So I would insist on one in any project that I was being paid to manage.

I typically don’t do it for volunteer projects because we don’t spend as much time arguing about who’s in charge.  People just want to do it, and so I’m like, okay, we can just get together and do it, and I don’t have to have any kind of authority handed to me. So if I had a customer balking at the idea of writing a project charter, that tells me something, and it tells me of some sensitivities that that customer has. And then I would want to think about why is this such a hot button, do they feel like I’m wasting their time?  Do I feel like I’m dragging things out?  Are they really concerned about me being the project manager?

So I would think through what some of those issues – there you go again – what some of those issues might be, and really try to address those underlying issues.  Whether or not I’ve got a signed charter is almost beside the point in that case, I don’t think any of these deliverables is meaningful on its own without a reason to be.  I would not create it just because somebody said I had to create it, so I would look for a reason for it to be valuable to us as a project team.

Rolling Wave Planning

BILL YATES:  Yeah, that’s good.  We’re playing Stump the PM with Margo Love, and I have another question for you.  What is rolling wave planning, and how could it possibly be meaningful?

MARGO LOVE:  Oh, my goodness, so rolling wave planning has changed my life, as well, I love it.  Now, bear in mind that I manage projects that last anywhere from two to three years. So we’re talking long projects, it would not be appropriate probably on a four- to six-month project as much as it is on a long project.  It’s a type of progressive elaboration, another $50 term from our friends at the Project Management Institute and our peers who write the content.  But rolling wave planning is used as you’re developing your project schedule. And so the concept is you only develop the details of the schedule for the foreseeable future, and you leave the distant future high level.

So on our projects, if that were in early October, and I were developing a schedule for a project we were going to start November 1st, I would probably develop the details for November, December, and January.  And then, as we got into November and December, I would develop the details for February.  And then by January I would be developing the details for March. So you are planning in rolling waves, it makes people uncomfortable, it made me uncomfortable at first.  It makes your customers uncomfortable because people want to know the details.

BILL YATES:  Right, so I was going to ask about how do you manage that, Margo? The same kind of thing, I’d get pushback from the customer going, hey, so I’m paying you to manage this thing, you guys don’t have your act together.  You don’t know what’s happening when I can’t look into the schedule.  What’s up?

MARGO LOVE:  Well, so the easy answer, which is not going to work for everyone, is that we write it into our contracts.  So we say our projects will be managed using rolling wave planning.  And then we have to talk about what that is.  But that doesn’t work for everyone.  So here are some of the things I would share with the customer who was not liking that approach. First of all then, in the schedule I add tasks that say, on this date, detail out the next month’s tasks.  Or begin detailing them, so I can tell them very comfortably before we get to January 15th, you will know what we’re going to be doing in March.  And before we get to February 15th, it’s in the schedule that we’re going to do this.

And I will encourage them early in the project, when you’re gathering requirements, and you’re doing design, it’s easy to talk about it then. Because you can say, well, we’re not real sure what all your requirements are, so I want to be sure they’re all in the schedule.  So I’m going to add the next set of tasks once we have clarified your requirements, or once we’ve developed your design.  So it is a benefit to the customer, they can’t tell you exactly what their requirements are the day you’re developing the schedule.  Well, therefore I can’t tell you exactly what task I’m going to carry out to meet your requirement.

BILL YATES:  That just makes too much sense, yeah.

MARGO LOVE:  Yeah.  So together we’re going to figure all that out, and when we know, then I will add the next set of tasks to the schedule.  Now, one thing that you have to do very carefully to make it work is your high-level estimates have to be good.  You can’t start a project with high-level estimates that you know are unrealistic.  So if you’ve started off by saying, well, we can build this in two months in the schedule, but in your heart you know you can’t build it in two months, you’re going to run into a real issue when you start trying to detail that two months of work.  So your high-level estimate has to be a valid, realistic estimate.  And then your details just fit right up under that beautifully.

Lessons Learned

NICK WALKER:  Margo, so there’s something I want to ask you about.  We often ask our guests about lessons learned in projects that they’ve worked on, and oftentimes, you know, people sort of keep these lessons to themselves unless really asked about them and have them drawn out of them.  But it’s my understanding that you actually have sort of an organized way of documenting your lessons learned.

MARGO LOVE:  Well, Nick, I wish that were more true than it is.  This is one area where you can easily stump the PM because lessons learned is probably an area of weakness for me.  I will say my last few projects I got a little bit better on this.  But I think in general I’m going to blame it on the industry as a whole, it’s not just me. So I think we have a misunderstanding about what lessons learned really are.

Most of us think of lessons learned as the meeting you have at the end of the project, when you invite the team to a meeting, and you start with a blank whiteboard, and you say, okay, what did we do well on this project?  And so you write some notes down.  What did we do poorly?  I dread that question because, in my personal opinion, a lessons-learned meeting like that is just one final opportunity for everybody to gripe about whatever they’ve griped about all project long anyway.

BILL YATES:  Yeah.

MARGO LOVE:  You know what I mean?  It’s like do I really want to go into this room and have everybody fuss at me one more time because we had too many meetings or whatever it was?  But really the value of lessons learned is not people’s opinions. Now, I do think that meeting’s important, it’s part of close-down, so it’s a type of team-building at the end of the project.  It’s part of customer satisfaction, but I don’t think the information gleaned from that meeting is nearly as important as fact-based lessons learned.

And so by that I mean, on this project, how much did we spend for these things?  How much did a hotel room cost?  So how much did we pay for bricks?  How much was the paint?  Whatever it was you were spending money on, how much was it, and were you able to get a discount?  If so, how did you get a discount? Who did you talk to?  What codes did you use?  That’s a fact-based lesson learned, another one is how long did things take.

BILL YATES:  Yes.

MARGO LOVE:  How long did it take to write a test case?  How long did it take to execute a test case? So how many defects were found on this project?  How many risks in your risk log became reality?  And why didn’t your risk strategy work better? So to me, those are the fact-based kinds of lessons learned that are better to capture.

BILL YATES:  And those are best captured all along, you know, throughout the entire project.

MARGO LOVE:  Absolutely.

BILL YATES:  To your point, Margo, it’s like, okay, so if you’re doing things the right way, and you’re capturing those lessons learned all along, then there may not be a need for that final meeting other than to maybe recap, make sure that everything’s been documented that you had intended.

MARGO LOVE:  Well, again, I think it can change the flavor of the final meeting because it is more of a customer satisfaction, adjourning properly.  We get together for one last time to put a bow on it.  In fact, I would probably review at that meeting some of those key fact lessons learned for the group. So one of the things we are to do, and we do during the project close-down process, is write a final project report, which summarizes a lot of the things on the project like we’re talking about.

And so I will present that final report at the last meeting.  And of course you want it to end very positively, here’s the good work we did on this project.  Then you go over a lot of the good benefits that have been received because of it. Certainly we’ve enjoyed working together, you recognize the participants.  And you gather their feedback on what they enjoyed about the project and what you think went well, and it’s just a good way for everybody to really have one last celebration together.  You’re not so much collecting lessons learned as you are affirming what we’ve learned over the course of the project.

Final Words of Wisdom

BILL YATES:  Margo, as we are thinking of different ways to stump you as a project manager, so I actually want to turn it for a minute and give you the opportunity to speak some words of wisdom or advice to those that are earlier in their career of project management.  Is there a particular piece of advice that you would give someone new to the field?

MARGO LOVE:  Well, one of the things that I did wrong on almost every project, and if I were starting a new project today I expect I’d do it wrong again, and that is on almost every project I hung on too long to someone who was in the wrong job.  So if you have a person who is underperforming, I think you should work very hard to figure out how you can help them perform better.  But when you get to the point where their underperformance is impacting the rest of the project, you’ve got to let them go.

And so that has always been a hard lesson for me, and it is very difficult. By “let them go” I don’t necessarily mean fire them, but help them find a position in the company that is more suited to the strengths that they have. It’s better for them, and it’s better for you, and I can tell you that all day long, but doing it is oh so painful.

But I tend to let things go, and it’s not just in my project life.  I do it all over the place.  I’ll let the car make a funny sound for too long before I take it to the car shop. So my dishwasher hasn’t worked in two years.  You know?  So I’m hoping it’ll come back and join us.  I’ve counseled it, and so far it’s not doing any better.  So, you know, really I should have let it go. It’s a lesson I’ve learned in my life over and over again and have yet to fully apply as I should. So that would probably be one of my pieces of advice.

The other thing is get training.  So I can’t say enough how important I think it is for people who are managing projects to recognize that this is a professional undertaking. And so you would not ask a dentist to go into the dentist’s office and just look in your mouth and figure out what to do.  I’m sure you’ll be able to figure it out.  You’re smart.  You know, you brush your teeth, so go help.  But we ask our project managers to do that all the time. You know, you’re a great programmer, you’re great with people.  They’ll also say, “Oh, you’re great with people, we need you to manage this project.”  Well, fine.  But being great with people doesn’t mean that you know how to manage a project, and I think training is invaluable in that regard.

Stump the PM Closing

NICK WALKER:  Well, Margo and Bill, I have learned a lot from this edition of Stump the PM.  And so I guess the one big takeaway that I have that probably far surpasses all of the others would be this.  And that is, when it comes to Margo Love, it’s impossible to stump the PM.

MARGO LOVE:  Oh.

BILL YATES:  Agreed, agreed.

NICK WALKER:  So we have a grand prize selected especially just for you.

MARGO LOVE:  Oh, boy.

NICK WALKER: So this is the Manage This coffee mug that we’re going to send you with our compliments.

MARGO LOVE:  Oh, that’s so great, thank you, I will really appreciate that.

NICK WALKER:  Margo, before we go, is there a way folks can get in touch with you for more information that you might have to offer?

MARGO LOVE:  Oh, yes, I would be so glad for them to.  My easiest email to reach me is actually through Velociteach at margaretl@velociteach.com.

NICK WALKER:  Margo Love, thanks again for your time.  We appreciate your sharing all this.  And Bill, again, thanks, as always, for your expertise and passion, too.

MARGO LOVE:  Thank you.  It’s been fun.

BILL YATES:  Thanks, Margo.

NICK WALKER:  Let’s take a moment to once again say thanks to our listeners for your feedback about the Manage This podcast. So keep them coming, leave a comment on Google, Apple Podcasts, Spotify, Stitcher, or whichever podcast listening app you use.  You can also leave one on the Velociteach.com website or on our social media pages.  It’s your feedback that helps us create the kind of discussions that you most want to hear.

Also, please take a moment to claim your free PDUs, Professional Development Units, for listening to this podcast.  To get your PDUs toward your recertifications, go to Velociteach.com and choose Manage This Podcast from the top of the page.  Click the button that says Claim PDUs and then click right through the steps.

That’s it for this episode of Manage This.  We hope you’ll tune back in on January 21st for our next edition.  So until next time, keep calm and Manage This.