Those PMI PDUs

OK, so you got your certification or accreditation through the Project Management Institute (PMI).  Now you need to plan on getting 60 PDUs over the next 3 years.  Is this too much to ask?  I don't think so.  How would you feel if your doctor never learned anything new, upon graduating from medical school?  Stakeholders should feel that same about people managing or leading projects. Over the course of the last few years, I've witnessed quite a few people who don't actually work as project managers get their PMP.  I know, you've heard me rant about this before.  But, since these people were able to navigate the system, what can the system do?  Well, I see the PDU as a mechanism that can continually attempt to separate the wheat from the chaff.   For some who really aren't contributing to the profession, and were just looking for three initials for a resume, the added cost and effort might not be worth it.  To be fair, I also know people who are very experienced and knowledgeable in the area of project management.  Requiring them to seek out and log PDUs is just an added deterrent to getting the PMP.

Back on topic, I break down the people getting PDUs into 2 groups.  Those who earn their PDUs over the course of 3 years and those who buy theirs.   Since I watch at least 1 free project management related webinar every other week, I ask myself why anyone would ever pay for them.  But, I digress.  Upon hearing the PMI was introducing a new PDU category structure as of 1 March 2011, I figured I would take a look.  What was once 15 categories will now be 7.  Without going into grotesque detail, I'm going to give you the 50,000 foot review.  In plain English, I like it.

Not only did the PMI modernize the language to include blog, webinar, and podcast, but they also grouped the PDU categories into 2 divisions.

1. (Receiving) Education

2. Giving Back to the Profession

I particularly like the language of "giving back".  When I think of the PMI, being charitable or giving back isn't really one of the first things that comes to mind.  I see this category naming as a step in the right direction.  I noted my disappointment in the lack of giving back in October (2010), when I was comparing the AgileDC conference and the PMI North American Congress.

I only have 2 recommended changes, if PMI would consider making a modification to the PDU requirements of the future.  First, I would ask PMPs to get PDUs in all 5 process groups.  I think people tend to get PDUs in process group or knowledge areas they are already proficient.  Second, now that the PMI has identified giving back to the profession, perhaps in a few years they'll add giving back to the community?

Like the image?  Find it at Pictofigo

The Stormy Present

The dogmas of the quiet past, are inadequate to the stormy present. The occasion is piled high with difficulty, and we must rise -- with the occasion. As our case is new, so we must think anew, and act anew. We must disenthrall ourselves, and then we shall save our country. That passage was read by Abraham Lincoln in 1862.  As I read it today, I couldn't help but think of a parallel.  I hear of projects struggling and hear people complain that this is just how we've always done it...and that this is good enough.  Why don't you stop and ask yourself why?  At a time when the country and the world struggle financially, shouldn't you consider just for a moment, that the ways we used to do things may no longer be good enough?  I think if you let go of the past and keep an open mind, there is time to save your project.

The Agile Introduction

When you meet someone new and they ask you what you do, what do you say to them?  Do you have a prepared introduction?  Have you prepared an explanation of your unique qualities?  If you think that is hard enough to communicate to the layman, try explaining Agile. If someone says "Hi, I'm Bob. I'm a Project Manager", most people get it.  We've all had a generation to get it.  Oh ya, so you manager some one or some thing.  I get it.  Now, when explaining Agile and how it relates to what we do, there is an extra layer of complexity.

For those in the Agile community, you'd be willing to take 10 minutes trying to explain Agile, rather than to be associated with the status quo.

But here is our problem as Agile proponents.  We don't all agree as to what Agile means.  There's a bit of a disconnect there.  I've heard people basically recite the Agile Manifesto when asked what Agile was.  The Manifesto (for Agile Software Development) hasn't been around long, being written and signed in February of 2001.  Though the authors signed it, I doubt they would all agree specifically what Agile is.

I've heard people describe Agile as "caring, loving, respectful"...  Though I don't discount you may see people exhibit this behavior, I don't go that far.  I'm talking Agile here, not my wife!  You see, to some, Agile is a living breathing thing.  But, I'm much more pragmatic.  I'm still passionate about Agile.  But, I'm not going to hold some dudes hand and sing Kumbayah by a campfire.

Let's get back on point.  The Agile Manifesto originally related to software development.  Some are now applying the 12 principles of the Manifesto and items the authors came to value to areas beyond software development.  This does not make these approaches any less "Agile".

I read a very interesting comment on the Agile Scout website, where someone explained how they use Agile as a Marathon Training Approach. One of the comments was: I think we are getting a little carried away here with Agile. Some say it is a philosophy (for developing software), but people seem to want to extend it to be a religion almost. I am sure that is not what the writers of the Agile Manifesto had in mind. This is a good way to get a good idea written off as a cult.

My response to this is an analogy.  For those who celebrate Christmas or think they know what Christmas is, ask them "What is Christmas?"  I am sure that is not what the creators of Christmas had in mind.

To summarize, Agile has become something bigger than what anyone could have imagined.  The concepts, approaches, and philosophies associated with it will continue to expand to other verticals as long as the Agile community (as a whole) accepts them.  So, how do I try to explain Agile to someone I just met?  Though I reserve the right to refine my introduction, I believe

I am a Agile Proponent

Agile focuses on the frequent delivery of something that works, by using small collaborative groups of people and small units of time to make sure whatever has the highest value get done first.  As each unit of time progresses, more gets done and more information becomes available to which future work can be done.

Like the image? Find it at Pictofigo

Take the Oath

Over the last few years, I've seen more and more people get certifications (or accreditations) from PMI, Scrum Alliance, APMG, and now SAFe.  Some will demonize the organizations for offering certifications and accreditations without actually proposing anything to deal with what they perceive as a problem. I believe certifications and accreditations are only as good as the people who get them.  One component I see missing is an oath of honor.  Yes, like Kingon honor or knights of the round table honor. (oh ya, I'm a geek)

When I wanted to be a Boy Scout, I met the qualifications.  But I then took an oath.

When I wanted to be a U.S. Marine, I met the qualifications.  But I then took an oath.

When I wanted to be a Freemason, I met the qualifications. But I then took an oath (which I can't repeat)

Not to compare project managers and leaders to doctors, but they take the Hippocratic Oath!  From that, I took inspiration.  Instead of trying to save lives, we're trying to save projects.

So, here is my first shot at it.  I call it the Metis Oath.  Metis was the Titan goddess of good counsel, advise, planning, cunning, craftiness and wisdom. Let me know what you think.

Metis Oath

I swear to fulfill, to the best of my ability and judgment, this covenant:

I will respect the hard-won gains of those practitioners in whose steps I walk, and gladly share such knowledge as is mine with those who are to follow.

I will apply, for the benefit of the stakeholders, all measures [that] are required, avoiding those twin traps of overtreatment and therapeutic nihilism.

I will remember that there is art to project management and leadership as well as science, and that empathy and understanding may outweigh all other things.

I will not be ashamed to say "I know not," nor will I fail to call in my colleagues when the skills of another are needed for a project's recovery.

I will respect the privacy of my stakeholders, for their problems are not disclosed to me that the world may know. Most especially must I tread with care in matters of project success or failure. If it is given to me to save a project, all thanks. But it may also be within my power to fail a project; this awesome responsibility must be faced with great humbleness and awareness of my own frailty.

I will remember that I do not serve a budget, or a schedule, but a human being, whose success may affect the person's project and economic stability. My responsibility includes these related problems, if I am to care adequately for the project.

I will prevent waste whenever I can, for prevention is preferable to cure.

I will remember that I remain a member of society, with special obligations to all my fellow human beings, those sound of mind and body as well as the infirm.

If I do not violate this oath, may I enjoy life and art, respected while I live and remembered with affection thereafter. May I always act so as to preserve the finest traditions of my calling and may I long experience the joy of managing and leading those who seek my help.

Pomodora Relationship

I have a dirty little secret.  I have an on-again off-again love affair with the Pomodoro technique.  Though I deal with a wicked case of ADD, I seem to keep it in check, thanks in part to my Personal Kanban.  The other method I use, though I admit not as commonly, is a pomodoro timer.  When things get really bad, I break out the timer.  And ya know, things get back on track!  You'd think I would learn. If you find yourself reading this blog, you'll find that I'm a proponent of  using simple techniques to get things done.  If you're looking for me to do a deep dive on policy, process, and procedure, you're in the wrong place.

So, how do I get some of my work done?  [1] I limit my work in progress (WIP) and [2] I limit my time (timebox). When I do both, I tend to stay focused and deliver more. The pomodoro technique, like other techniques I like, is pretty darned simple.

So, let's talk about my Piggy Pomodoro!

1. Choose a task to be accomplished
2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3. Work on the task until the Pomodoro rings, annotate the task you were working on
4. Take a short break (I take 5 minutes)
5. Every 4 Pomodoros take a longer break (I take 10 minutes)

As part of this process, I'm moving tasks on my Kanban from Backlog to Work in Progress.  If I take a break, I move it to Blocked.  When I return, I move it back to Work in Progress.  This allows me to visualize what I'm working on and know what I was working on before my break.

Have a Kanban or Pomodoro story?  I would love to hear it.

Why do I use a Piggy, you ask?  Because tomatoes give me gas and Chickens would just be wrong.

Image:  Amazon

The Cave of Zombies

The “Allegory of the Cave” by Plato represents an extended metaphor that is to contrast the way in which we perceive and believe is reality. Plato said what we see are actually imperfect “reflections” of the ultimate Forms, which represent reality and truth.  In his story, there is a cave in which prisoners are chained down and forced to look at the front wall of the cave.  Behind the prisoners is a fire and puppeteers, casting shadows on the wall in which the prisoners perceive as reality.  Being you and I know there are puppeteers, we know the shadows the prisoners are seeing are not reality.  But, it's their reality, none the less. Once a prisoner is released, he is forced to look at the fire and objects that once provided his perception of reality.  Only then does he realize these new images in front of him are now the accepted forms of reality. Plato described the vision of the real truth to be “aching” to the eyes of the prisoners. He added they would naturally want to go back to the cave and look at what they had always seen as a pleasant and painless acceptance of truth.

Once a prisoner climbs out of the cave and is fully immersed in the rays of the sun, the prisoner would suffer bewilderment, fear, and blindness to the objects he was now being told were real. The natural reaction of the prisoner would be to recognize shadows and reflections. After his eyes adjust to the sunlight, he begins to see things as they really are.

Plato's allegory made me think about zombies. Oh hell, what doesn't!?

We're not just prisoners in a cave, we're zombies.  Those who have left the cave come to visit once in a while.  They may complain that the food outside isn't as good.  But, they've taken the uncomfortable step of leaving the cave and merely want you to eat something other than brains.  If you are a zombie still in the cave, the other zombies are going to tell you to just eat more brains.

It doesn't matter what kind of zombie you are.  If someone offers to expand your reality with ideas foreign to your own, don't be so negative.  Don't just dismiss them. Don't eat more brains.

Like the image?  Find them at Pictofigo

Know Your Customer

Communications with your customer(s) and team(s) is key to your success.  Knowing what they want is just as important as what you plan to deliver.  I laughed out loud (uncomfortably) when I saw the graphic to the left.  Though I'm not Jewish, I've worked with a lot of people from around the world.  I've grown to appreciate the things that make us all unique.  Trying to sell some Jews a ham on Chanukah is almost as bad as offering an all-you-can-eat meat buffet to a vegetarian.  It doesn't matter how good of a deal you can offer, the product itself must meet the needs (and wants) of the customer.  Perhaps if the vendor of the boneless smoked ham had the list below, they could have avoided this embarrassing (and potentially costly) situation. Problem Statement

Describe the business reason(s) for initiating the project or building a product, specifically stating the business problem.  Identify the high level goal it relates to.

Description

Describe the approach the project or product will use to address the business problem.

Goals and Objectives

Describe the business goals and objectives of the project or product. (I like user stories)

Scope

Describe the project or product scope. The scope defines limits and identifies what is delivered (inclusive). The scope establishes boundaries and should describe products and/or services that are outside of the scope (exclusive).

Critical Success Factors (Acceptance Criteria)

Describe the factors or characteristics that are deemed critical to the success of a project or product, such that, in their absence the it will fail.

Assumptions

Describe any assumptions related to business, technology, resources, scope, expectations, or schedules.

Constraints

Describe any constraints being imposed in areas such as schedule, budget, resources, products to be reused, technology to be employed, products to be acquired, and interfaces to other products. List the constraints based on the current knowledge today.

I want to thank my wife for sending me the image.

Agile Traffic Analogy

The post today was brought to you by... my hellish commute and those in the Washington DC metropolitan area who help create it.  Thanks! Today, I'm going describe Agile concepts by using my commute as the analogy.

Goal

During any given day, spend as much time working or at home and as little time commuting as possible.

I'll write a User Story because I'm weird like that

As a project management advisor to a government PMO, I want to travel 55 miles in the shortest period of time so I can spend more of my life delivering value than wasting time sitting in traffic.

Predictive Approach

How long will it take to drive 55 miles to the office in the morning and 55 miles to my home in the evening?  We've all had to estimate our commute time.  Sucks, doesn't it!?  We're all terrible at estimating.  Why?  Things change...constantly!  You can spend as much time and energy as you want, trying to think of all of the possible scenarios.  You can break your commute into "chunks" and estimate those.  That could give you a better estimate, taking into account variances in each leg of the commute.  But, until you get on the road and actually start your commute, you just don't know.  We've got weather we need to deal with.  We've got that knucklehead in the far left lane, driving 10MPH under the posted speed limit (with his blinker on).  We have to deal with the occasional traffic accident.  Work on a project is no different.  You can try to estimate your time, up front, but when something happens (notice I wrote WHEN not IF) your original estimate is going to be wrong.  What are you going to do?  Are you going to try to make up the lost time later in your commute?  Is something else going to be sacrificed like hours of work or hours at home?

Do I personally think there is a more accurate way to estimate a commute, as the commute happens?  Yes.

Adaptive Approach

This was my Adaptive commute this morning.  My wife told me that the traffic report on the radio stated there was an accident 40 miles into my commute.   Good to know, I thought.  Information is good.  Communications is good.  So, did I change my estimate at that time.  Nope!  Why, you ask?  I was armed with my handy Droid X.  My Droid X has GPS and Google Maps with a traffic overlay.  Now, I still broke my commute down into chunks.  I still had the basis of estimate there.  But, the magic happened after the commute began.  I did see the traffic slow down (on the map) that my wife referred to.  But, the radio was still reporting that the lanes were blocked.  The map indicated that traffic was getting by slowly.  Good to know I thought.  Information is good.  Communications is good.  But now, I saw (on the map) that traffic was stopped much earlier and they were not saying anything on the radio traffic report.  By the way, the radio station only reports the traffic every 10 minutes.  By getting realtime feedback from the Droid, I was able to know when I was going to have take a different route, to bypass the delay. I took the next exit and my commute route and the map refreshed.  I could see, by the map, where I could get back onto my original route.  I actually arrived to the office, 20 minutes from my optimum commute time.  If I had not had the Droid and the constant feedback about the traffic conditions, it would have added a hour.

I still lost 20 minutes.  But that was unavoidable.  But I think I minimized my delays by getting real-time feedback.  I had opportunities to adjust my course based on information.  I was able to adjust my commute estimate every minute, not every 10 or 20 minutes.  If someone from the PMO had called me to ask when I was going to get to the office, at any time along my commute, I could have given them a pretty good estimate.  But that telephone call isn't necessary.  Here comes the kicker.  I share my location with Google Latitude.  They can see where I am at any time.

Here are some things to think about for your next commute

• Know where you are and where you want to go
• Break your commute into chucks
• Get traffic conditions as often as possible
• Be prepared to change direction
• Be prepared to reestimate your time of arrival, the closer you get to your destination
• Give people a way to know your location so they don't have to ask you every 5 minutes
• Feedback is good
• Information is good
• Communications is good

Like the image? Find them at Pictofigo