Project Management

Three Ways of Setting Simple Rules

A global expert on strategy and execution in turbulent markets, Dr. Donald Sull  is a Senior Lecturer in the Technological Innovation, Entrepreneurship, and Strategic Management group at the MIT Sloan School of Management, where he teaches courses on Competitive Strategy and Strategy Execution in Volatile Markets. His recent book, Simple Rules: How to Thrive in a Complex World is a great summer read. Don will be in an upcoming Business901 podcast. Below is an excerpt from the podcast.

Joe: What I took from the book is that you actually group rules. Was that done on purpose? Is there some truth to that?

Don: I think there’s some truth to it. On purpose, I mean when we started this project 15 years ago, you know, we didn’t have a strong sense of, you know, we didn’t have a strong theory or strong biases to how the rules would sort out. One of the things that was interesting is we studied rules and creative domains like Elmore Leonard’s rules for writing a book and Tina Fey’s rules for producing 30 Rock and then social biology, how bees find a new nest and how ants coordinate their activities and, you know, monetary policy, how the Federal Reserve uses simple rules to set policy.

What was interesting is we’ve studied the rules, simple rules across these different domains is that these 6 categories of rules emerged. What we learned are that basically 3 types of rules that are around decision-making. The first one is boundary rules, what’s in and out. Examples of this would be the rules that doctors use to diagnose the celiac disease for instance. They use a set of simple rules, you’re either diagnosed with the disease or without it. The second set of rules is prioritizing rules. These would rules like the rules that Darfus uses to decide how much money to give to specific projects. The third set of decision rules is around stopping rules when you decide to stop doing things.

It turns out, we’ve had this, Mt. Everest has been in the news with this tragedy over the past couple of days. Up to today, one of the most fatal days for climbers on Mt. Everest was caused because the climbers, a group of 16 climbers ascended the summit and they ignored what was called the 2 O’clock rule which basically said if you’re not at the peak by 2 o’clock you turn down no matter what because it’s very dangerous to descend as the weather turns and as it gets dark. A group of climbers, about 2 o’clock, they’re a couple of hundred yards away from the summit. They started arguing with the guide. The guide ignored his own rule. They climbed, hit the summit about 345 and it turns out that the delay of an hour and 45 minutes was fatal for five of the climbers. That 2 o’clock rule is an example of stop and will help to remind us when to stop doing something.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Stick to the Plan

You have not been around Project Management long if you have not uttered those words before. I may show my age a little here, but I started with Microsoft Project when it came on (2) 5¼-inch floppy disk. I have used more software packages than most are familiar with. This is a person that was weaned and very successful in developing and carrying out waterfall based plans usually displayed on some type of Gantt Chart.

How many of us has used these words Stick to the Plan? In retrospect, how many of us felt like we were following the path of the cartoon below?

Project Planning

As I go back and review some of my past project management notes and books, it is interesting to note that they really said the same thing just wrapped in a different wrapper. I will borrow a simple outline that I have referenced for years and what Ken Blanchard called the book, The One Minute Manager for project planning. The book, Getting the Job Done!, was co-authored by Barry Posner (if you have been around project management a while, I am sure the name will ring a bell).

In the book, Posner lays out a acronym

  1. Set a clear Goal.
  2. Determine the Objectives.
  3. Establish Checkpoints, Activities, Relationships, and
    Time estimates.
  4. Create a Picture of the Schedule.
  5. Develop people individually and as a team.
  6. Reinforce the commitment and excitement of people.
  7. Inform everyone connected with the project.
  8. Vitalize people by building agreements.
  9. Empower yourself and others.
  10. Risk approaching problems creatively.

The acronym ends up being GO-CARTS, and every GO-CART needs a DRIVER. What I find that this fit waterfall projects as well as it fits most agile projects. What I guess I get frustrated with is the constant selling of unique processes and systems that are the answer. Even in the most complicates and complex environments will still need to adhere to a set of rules or agreements that these 10 steps suggest.

It goes back to the simple fact, that Getting the Job Done is not a process thing, it is a people thing. Not sure where this statement came from but it is so true. There no such thing as project management software, they are all project scheduling software. Project Management in its truest form is winning the competition for someone’s time –there are only 1440 minutes in a day.

I wonder how Moses did Project Planning?

Struggling with the Difference between a Feature and Story

One of my most listened to podcast is with a relative unknown Agile guy named Eric Landes. In the Agile world, I expect he is well-known and has spoken at a few of the conferences I have attended. I was re-reading the transcript today after seeing how highly rated the original podcast was on my iTunes list and took a few treasures from the review.

Related Podcast and Transcription: Agile Discussion with Landes

An excerpt from the podcast:

Joe:  Well a lot of my listeners are from the Lean manufacturing background so Agile may be a little foreign to them. We think of agile more what I have heard from different people that it is really from concept to consumption is a buzz word I have heard a little bit. Can you explain a feature in a story to me?

Eric:  Sure. So, I am going to a couple of differences in Kanban. You can use feature and story within Scrum, as well. Most peoples do tend to use stories in Scrum. Usually, a term used… A minimal marketable feature. It’s the smallest feature we can deliver on software that is going to be used by the customer. That makes a difference for the customers.

If you are in a software development shop and you have software or website that you are selling something digital like software. That feature is going to be something, say like a marketing person is coming up, whereas if it’s an internal software application you might actually talk directly to the customer and get that feature. The feature verses story, normally what I would say is those features normally break out into stories from the feature. You can almost think of stories that’re a smaller set of a feature if you will that probably have to be grouped together if you are actually going to sell your software.

What happens when you are moving from, say Scrum into Kanban… A lot of the Kanban teams are using their ideas of features. And then, the idea is, they want to take the feature from… As you said, from concept to cash or whatever, and bring that through their system of software development.  When I look at the differences between what we call like a Scrum or XP, and the Kanban process. The Kanban processes really are the lean process that the software development uses. We are looking at mapping your process as it stands. Seeing where the bottlenecks are, using a board to map your flow, see where the bottlenecks are, and then try and fix those bottlenecks as you’d go.

You’re going to use a lot of the Agile methods for software engineering. Some people even use iterations during their Kanban. But, for the most part, you’re looking in the flow of things. You aren’t really doing fixed link iteration, time?box iterations. You’re doing more of… I don’t want to say one piece flow because that’s wrong.

I mean, we would love to get to one piece flow. But I don’t know anybody who would claim that they’re doing one piece flow in a software Kanban. At least, I’ve not heard of anybody doing that.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)


Old Style Thinking of Plan – Do

One of my favorite authors (even though he has turned me down several times for a podcast) is Jim Highsmith. Jim has authored, several books with my favorite being Agile Project Management: Creating Innovative Products (2nd Edition) which comes as no surprise to most readers of this blog.

One of the items that Jim challenges in the book is the project management thinking of Plan-Do. In the book, he states that when considering plan-do it assumes that we already have the acquired knowledge to get the job done. He believes it should speculating not planning and exploring versus doing. In the process world and most specifically in the area of Lean, we think of PDCA and the planning portion of it as a hypothesis and the do as the experiment. Which I feel lies somewhere in between Jim’s explanation of the two. If I use the three components of how I visualize my Lean thoughts, Standard (SDCA), Incremental (PDCA), and Exploration (EDCA), I believe I can safely say that my thinking does align itself with Jim’s.

Lean Thinking

In the before mentioned book, Highsmith discussed the “Story” aspect of iteration planning. He says in the book,

I was slow to embrace the term “Story” for iteration planning. What finally convinced me was this need to change people’s perception of planning. The traditional terms we used were “requirement” and “requirements document”— words that conjure up fixed, unvarying, cast-in-concrete outcomes. “Story” conjures up a different scenario, one that emphasizes talking over writing and evolution over a fixed specification. Using the term “speculating” rather than “planning” has a similar effect. When we speculate, we are not prescribing the future, but rather hypothesizing about it. And, to those who practice the scientific method, we hypothesize and then run experiments to test that hypothesis— exactly what happens in agile iterations. Speculating also conjures up a vision of a group musing about the future instead of one rushing to document.

In the past several months, I have really started to embrace this “Story” type of thinking. I have started to create more narratives in the planning phases and even in my proposals.

  • In project scoping there are fewer tasks being assign in the earlier phases but it also seems to drive more conversation in beginning of the project or an iteration such as SDCA, PDCA, and EDCA. I think it is a good thing.
  • On the proposal side, I have found many people uncomfortable with this process. They are looking for what you are going to do. I equate that to starting with the answers. Which I typically think in the sales and marketing world is a disaster waiting to happen.

What are your thoughts, is more narrative/speculation a good thing or a bad thing?

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Coaching An Agile Team Virtually

I have coached a variety of teams virtually and wondered how someone else did it. So I asked a could of questions.

An excerpt from last week’s podcast, Managing Product Development .

Joe: Much of a consultant’s role is relationship and trust building; when we do it virtually, that’s sometimes very difficult to do. How does working internationally as a consultant different for you than let’s say working with a client in Columbus?

Gabi VanderMarkGabi Vandermark:  Yes. There is nothing like a face to face interaction, a handshake, or a hug, or whatever the culture accepts and requires, that face to face interaction is absolutely important, but you also can’t afford to travel every day to another country to see your client or see your customer. What I typically do is I combine the two. You have to find ways to build a relationship up front with some face to face interactions and then maintain it throughout with whatever online tools we can find. Video chat, I spend most of my day on video chat. When conversations need to happen, that if I was around somebody, I would maybe call them into my office, shut the door, a one on one conversation. I typically choose to do a video call. There is that face to face. It’s not as warm as being in there with someone, but you can still see their facial expressions, and it gives you a little bit more of a sense of being close to that person.

But upfront, it’s important to be together and especially when you’re going through sessions where you’re designing something or you’re starting a process. A lot of times in Lean Product Development, I would always suggest to a client to start with a vision. The vision not only for the product, especially for the product but also for the team that’s going to be building that product. In those sessions where you’re defining a vision and maybe defining an identity for that team, it definitely needs to be face to face.

Joe:  In developing a team, you’re just not ending up with an existing team, let’s say in Brazil that you have to work with and then six months into the project, you meet them most of the time, you’re at the very beginning. You’re trying to meet that team in some capacity as visually or face to face if possible.

Gabi:  Absolutely, yes. Typically what we do is we identify who the team is, who are the members of that team, and plan a first meet and greet in person to validate that that team makeup makes sense. A team is one of the most important things for Product Development or any sort of project. You want people that are dedicated and you also want to explain to them the ‘why.’ Why are we doing this? Why are we putting in a brand new URP system that’s going to change your entire life? There have to be ways to you connecting with that team to explain the why. They may not like the why but understanding the why will at least help them deal with that change and be focused on the project. Definitely upfront, a face to face interaction as quick as possible with enough information on my back pocket about what we’re about to execute. Because also meeting the teams without having enough information, just to sit in front of them and say I don’t know, I don’t know, I don’t know – that’s not worth it. When I do meet the teams, I need to be prepared to answer a lot of their questions about what we’re about to do.

Joe:  Do you find that limiting the size of teams is important, even more internationally?

Gabi:  I think the makeup of the team is more important than the size. Having the right people doing the job that one, they’re good at, and two, they like to do, is more important than the size. I do tend to try to build smaller pockets of teams, if I have a large number of people, so that they become self-organized in their little groups and it’s easier to spread that knowledge and reuse knowledge. But when I do break into smaller groups, I have to find a way to bring collaboration amongst them. When I was at Nationwide for example, I had three different teams. Two in the US, one offshore, and collaboration communication was a constant job for me or a constant task for me to bring those three teams together to make sure that they were talking amongst themselves, because all three of them were touching the same product. That becomes kind of my role, as the quarterback of bringing everybody together and making sure that collaboration exists.

About Gabi Vandermark: Founder of Rottie Consulting LLC, Gabriela (Gabi) Vandermark, discussies Lean Product Development with an emphasis on Product Owners.  Rottie provides consulting services to a variety of industries specializing in IT Project Management & Delivery, Technology Leadership, Organizational Change Management, Leadership Coaching, and International (South American) Relations.

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Software and Product Development Leads into HR?

The founder of OdBox, Matt Barcomb, partners with organizations to help leadership teams develop and deploy strategy, optimize product management and development, and evolve traditional HR functions into modern talent development practices. Matt can be found on LinkedIn or on Twitter.

Related podcast and transcription: Matt Barcomb’s Journey into Lean Software

An excerpt from the podcast:

Joe:   One of the things that I associate you with, of course, is software and product development, but it seems that umbrella has started to incorporate more parts in the company, and it’s affecting and becoming an integral part of other parts of the company. How is that affecting your work because you talk about a lot more type of organizational work, a lot more type of work with HR – is software the push into it or is it just your growth in trying to make people work together?

Matt: That’s a good question. I would probably say it’s a nice little cocktail of both. One of the reasons I got into human resources, talent development is again through client work. I would go into a place, and they were having problems hiring people that could fit for the skills and we started talking to them and then they’re kind of following a very traditional or recruiting through Monster or whatever, and they ask for help, like how do you find talent, and so we can talk about that. We wound up kind of rejiggering how they do recruiting, we kind of talked a little bit about how should they do promoting, what are their current performance plans and structure, what do those things look like, do they make sense. It’s just sort of pluck a little thing here, and you try a lot of things; a lot of companies are willing to try some things. Not every company has been willing to try all my crazy ideas, but some of them are just things that make sense. I mean I can’t remember ever being at a company ever who thought that how they did ratings, and rankings, and performance, and tying it to compensation was a wonderful, fair and equitable system that everybody enjoyed. So given that that’s never happened, one of my first principles is like well what happens if we get rid of it? Instead of trying to figure out a way to make it better or improve it or add something to the system, what if we try to simplify it first? Not that that will solve the problem, it will very likely cost other problems. But let’s take the thing away first, so when we do try to inject something, we’re injecting something into a simpler ecosystem.

Like HR is one area where we try to grow it more towards talent development, where to find people, how to promote people, how to make that a collaborative thing and I’m kind of a proponent of setting up structures such that transparent salaries could be possible. I want to be clear that I don’t necessarily advocate for going all the way towards actually making salaries transparent; it just really depends on the context. Working with sales organizations was sort of the same way. I started working more with product management as part of product development, this idea that you’ve got a group or an organization that’s sort of incented or they’re going like this to help create a product or sweeter products that has a strategic fit for a market and that they’re sort of always butting heads with this other department in the organization who’s incented to hit quarterly revenue targets at almost whatever sales price, that incented to drive some crazy behavior. I’ve seen product development departments get thrown under the bus because they couldn’t make the features fast enough, and they could have made their numbers if product had just delivered faster. I’ve seen sales departments reel because the BP of product are really hard-lined pricing strategy, and that was not allowing them to make their numbers. So trying to encourage them instead of trying to just throw sales under the bus and say, “Oh sales guys are coin-operated, evil, moron people. They should just go all be car salesman…” Let’s figure out what we’re really trying to achieve through sales.

I mean that’s a pretty obvious problem, we need the company to make money. So how we change sales and how do we change software and how do we change the product to all work together? I mean again this just taking a page out of the systems thinking kind of playbook of how are we not aligned? We have these different functions, we need a strategic fit to a market, we need to make sales, we need a revenue, we need to develop product – how do we get these three things to swim together instead of feeling like they’re often tearing the company apart?

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)

Taking Ownership of the IT Project

Founder of Rottie Consulting LLC, Gabriela (Gabi) Vandermark, discussies Lean Product Development with an emphasis on Product Owners.  Rottie provides consulting services to a variety of industries specializing in IT Project Management & Delivery, Technology Leadership, Organizational Change Management, Leadership Coaching, and International (South American) Relations.

This is the slide deck of the presentation we reference several times in the podcast.


Download MP3

Business901 iTunes Store

Mobile Version

Android APP

Lean Sales and Marketing: Learn about using CAP-Do

Lean Engagement Team (More Info)