Lead By Example

I usually roll my eyes when I see those bumper stickers "My child is an Honor Student at BlaBla School".  I get it.  This parent is proud of the academic achievements of their child.  So, forgive me as I'm going to jump on the bandwagon. I'm not excited that my son got an award at school, stating he passed an academic test that his teacher gave him.  I'm excited because I know he passed (what I believe is) a more important test.  My son got an award because he was an example of outstanding character and displayed the trait of kindness.

I sometimes think we as individuals and organizations have our visions and our missions missaligned.  Strategically (our vision) we have a long term goal.  Tactically (our mission) we have a short term plan.  One of my goals in life is to not screw up my son and help him become a good person.  I hope I can help ensure that by leading by example.

If he chooses to lead others someday, will those who follow him think he's really smart or are they going to say he inspires them; that he's empathetic and kind?

Regardless if you see yourself as project manager or a project leader, think about your core values.  Think about how your actions will impact those around you.  Lead by example and see just how contagious it can be.

Measuring (Project) Health

You'd think I would follow my own advice when it comes to my own health.  When dealing with project deliverables or tasks, I like to get feedback from the team as often as I can.  Ideally, I recommend daily feedback.  Realistically, there are extended team members who you don't deal with on a daily basis.  Due to their expertise, you may need to share this person with others on the program.  Notice I didn't call him or her a "resource".  Anyway, you need to make sure you do a few things, when interacting with these team members.  One, identify the maximum amount of time that will elapse between interactions.  Two, identify some threshold criteria.  Exceed the threshold and you should be interacting with this team member. Now, I've followed this prescription in the past, when dealing with experts like Software Architects.  Seriously, it doesn't matter the title of the person we're talking about.  What's important is you know you have maybe one or two of these types on your program.  The other important thing to note is if you don't do either of these things, you run the risk of this coming back and biting you.

3 indicators you've gone too far

  1. You have not interacted with your expert within the predefined timeframe
  2. You have not interacted with your expert after a threashold has been exceeded
  3. Your expert has prescribed Levofloxacin to you

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