Category Archives: Project Management

The “Save” Icon

Category : Project Management

The "Save" Icon

The other day, after speaking on a panel for Chick-Tech, I realized that I was, by at least a decade, the oldest person in the room.  That meant it was also highly likely that I was also the only person in the room who had actively used a tool that every single person in that room sees every day.

A 3.5 inch floppy – or, as many will more likely recognize in graphic form, the ‘Save’ icon.

It reminded me of a time when my step-daughter asked me “what exactly does ‘cc’ mean?”

When I replied that it stood for “carbon copy”, she said that she had always wondered, did we really make carbon copies of things? How, exactly did that work?

That conversation happened years ago – possibly even decades ago.

And remembering that, coupled with the flash of realization the other night, caused me to ask myself an important question – one that we don’t always think to ask ourselves (me included!):

”Are you sure that everyone you are working with understands the same way that you do and why?”


“Why are you sure?”


“Why do you think they see the situation/issue/question the same way that you do?”

Which engenders the question,

“How did you confirm that understanding?”

The odd thing about a meritocracy: building one doesn’t guarantee that the team – or the company – will succeed.  The people who have the maddest technical skills may not be the best at working in a team environment.  The person with the best interpersonal skills may not be able to bridge the gap in a spot crisis when solid (possibly even amazing!) technical skills are needed.

We are not suggesting that implementing Clear Definition, combined with Ownership and Collaborative Spirit, will remove these problems.

We are suggesting  that these three Key Success Parameters will give you a stronger shot at addressing these problems with less stress on the leadership team, the project team, and lastly – but not least – you.

KSP Tip for High Performance: Model the behavior that shows that you do not take common context for granted.  Ask for paraphrased loop-back periodically during discussions with your team members. Encourage and support when they do the same. If you‘re asked, feel free to blame it on me (‘that darned consultant wants us to try this!’). Or, alternatively, you can tell them the story of the ‘Save’ icon and ask:

“How many of you have actually used one of these ‘floppy’ disks?”



Papyrus, White Boards, Glibness, and Cerebral Knowledge

Category : Project Management

Glibness (n): fluent but insincere or shallow.

I once consulted to a high-tech engineering company outside of Pittsburgh. The engineers had attended one of my project management seminars a short time prior, and asked that I come in and do a bit of coaching.

One of the best students in the class asked for some help with his project. He was about half-way through the project and looking for some guidance to help him finish. We met, exchanged pleasantries, and got to work. I went through my usual checklist and inevitably came to the precedence diagram (a diagram showing the sequence and flow of the project work). “Of course I have one”, he responded (as I had stressed this topic in the class).

“Excellent, let’s pull it out so I can see it”, I replied.

“Well… it’s in my head”, he responded.

It took a half-second for me to recover (I didn’t expect that response), put a smile back on my face, cleaned off his white-board and said, “Okay, let’s go through it.”

The next few minutes went exactly as I expected. He started confidently, telling me what activities were currently active and what followed them. It didn’t take long before the confusion started. “Oh, wait, I forgot about (some task)”. “Oh, yes, then there’s (some other task)”. This went on for a short while.

Tasks were missing in his head. He had thought about them at one time, but his mind relegated them to the background. He hadn’t thought through the sequence (we changed many sequences during the exercise, and had to add a few new tasks). But after we were done on the white board, we had a solid plan to finish his project. The entire exercise only took about 20 minutes.

We’ve become a cerebral society. If we need information, we just GTS (Google the S[tuff]) and move on. We tend not to study it, we don’t analyze it, we frequently don’t even challenge it (after all, it must be true… it’s on the internet). We get fast answers to quick questions and move on.

It’s a form of glibness, a shallow understanding of the topic. He is a bright engineer, caring, hard-working, and wants to do things right. He just kept everything in his head, never put it on paper or a white board, or even in electronic format. He never spent the time to really look at the sequence, challenge assumptions, and get it right.

The problem is the mind forgets, it automatically re-prioritizes what’s in short-term memory. Things go missing, they go to the background, and of course, the mind doesn’t bother telling us when it does this, it just does it.

Examples of this are so numerous I dare not mention them all. One of the techniques Kimi and I started doing some time ago in our speeches is asking senior managers if they ever laid out all their projects in front of them to see how resources were allocated. Their usual response… deer in headlights! That tells me that if they actually did that, they’d realize the difficulties they were placing on their staff.

I still love paper. I frequently sketch things out on white-boards, go over it many times (and usually with a second pair of eyes); then, once I truly understand it, it will end up in electronic format somewhere so I can pull it up any time. I write down my assumptions, decisions, and rationales. I can’t tell you how much time this saves me.

While I believe mankind is getting smarter, we still can’t just run things from our heads. We can’t run projects from our heads, we can’t manage strategic plans, business processes, or research cerebrally.

Try it. Spend the time and effort, lay it out, see it in the physical universe, and go over it several times. Peer review it… have another pair of eyes look at it. It’s amazing what you’ll discover and the mistakes you’ll avoid and the time you’ll save!

… not that I’m opinionated on this!


Michael B Bender

Do You Have an Emergency Contingency Plan?

I recently came across a fascinating, if frightening, story on LinkedIn that looked at the dangers of airlines running software on legacy code.
For the uninitiated, legacy code is the term given to original software code underlying a system. It’s usually of some vintage and in many cases the original coders are long gone. But it’s typically good sturdy code, revised and strengthened over time.
The problem is these systems are tied to underlying code and programming languages that are usually a relics of another era. COBOL, for example, was a common coding language in the internet’s infancy but practitioners of it are hard to find today.
It’s a great article. But what made me sit up and take notice was an example of airlines and the emergency system plans in place for an outage or emergency.
Simply put, most airline booking systems didn’t have one and in the three scenarios noted in the article all three paid the price for not having a contingency plan in place. 
In the project management field, having contingency plans in place is absolutely essential. Can a contingency plan prevent an outage? No, but it can mean the difference between a long system outage and an extremely short one. And that time can be measured in dollars, cents and customer frustration.
To talk to us at KSP Partnership about how we can improve your business processes including emergency contingencies, please get in touch.

Back to Basics

When you work with organizations to help accelerate the productivity and profitability of their project teams there are questions that keep coming up:

‘So this is project management, right? Do you teach scheduling or something?  Can you fix our project management application?’

The long answer is that we work with teams and they become more productive because of how they work together rather than the tools they use as they work together. Project management is the cloak that covers the down and dirty business of changing the behaviors and dynamics within the team.  This is because, as a seasoned project manager, there is an assumption that underlies each team.

The assumption is that they already know the basics of scheduling, estimating and risk management. Well……you know what they say about assumptions.

Regardless of whether you use Agile, eXtreme Lean, Six Sigma or Prince2 as an approach there are some things that remain true.

You need to be able to communicate to your stakeholders.

  • How long will it take?
  • What will it cost?
  • When will it be done?
  • Why might it fail and what can we do about it?
  • Are there possible opportunities to wring other benefits from this work aside even from the stated goals and objectives of this project?

Sometimes you find that even your most fundamental assumption is groundless.  Sometimes you find that, under the extreme time pressure of an ever-faster pace of business, people have lost-forgotten-abandoned some of the basic tools and approaches that would serve them well.

With that in mind, I am delighted that Michael Bender has taken on the challenge and has begun the task of creating micro-lessons – called uLessons on YouTube. These lessons will be taking you back to the basics.  No lesson is very long – you could probably take one or two in and still have time for coffee.

Teams that are on the way to becoming more productive will still actively consider the value of their tools and approaches.

And there are times when a refresher isn’t a bad idea.

Your tip for today: Having the whole team view and discuss the topics of Michael’s uLessons is also a great way to build both Clear Definition and Collaborative spirit. These are two of the four foundational Key Success Parameters. Use this discussion as a way of confirming how your team members each develop their estimates. Is there a best practice that could be standardized? Who on the team can help each other?

So the short answer is ‘No – this isn’t just project management. It’s about how to get your teams to project success.’

If you have a project that is not meeting expectations for two reporting cycles – or more – let us help with our diagnostic and discovery process.

How Much Time Does Your Team Actually Spend Working?

Category : Project Management

How much time does your team actually work during the day?

In live seminars, I run a quick survey of team productivity. I call it the “Other Stuff” list. It’s a list of all activities individuals do during the day that is not project work. I then ask students how many hours they spend on a typical week doing each of those activities. After 20 years of running this exercise, I’m still amazed at the results.

I encourage you to run this exercise with your team or colleagues. Take a white board, flip chart, or simply a piece of paper. Ask your team to list all the activities they do during the day for which they get paid. Then, ask them how much time they spend in a typical week doing each of these activities. For daily tasks, ask how much time they spend during the day and multiply by 5. For yearly tasks (vacations, holidays, etc.), divide by 50 (or 52 if you want to be more precise). Remember, it should only include activities for which they are paid. For example, if you’re paid for lunch, include it, otherwise, don’t. Here’s a sample list:

  • E-Mail, Voice-Mail
  • Meetings (non-project meetings)
  • Biological needs (coffee breaks, etc.)
  • Social needs (chit-chat)
  • Training
  • Your “real” job
  • Firefighting/Emergencies
  • Equipment problems (computer problems)
  • Mentoring, helping out your colleagues
  • Vacation, holiday, sick
  • Travel

If you’d like to see how I do it, play my short video on Estimating Basics, Micro-Lesson 1. I think the results will surprise you as well.

May all your projects be successful!


Upcoming Events

No upcoming events