Project Management

I REALLY GOTTA GO!!!!!!!!!!!!

Occupied Today, my family is headed home after spending some time with my wife's parents in a cabin in Brown County State Park in southern Indiana.  It was a fun time out in nature and we enjoyed catching up with and enjoying quality time with family.

Except for one small detail: Bathrooms.

You see, our otherwise perfect cabin in the woods was equipped with only one bathroom.  I have a general rule about bathrooms, which has served me well over the years: Never share a bathroom with women, those under 10, or those over 60.

I just described every other member of my party.

(Caveat: The 10- to 60-year-old male can go for hours without needing a bathroom. Their use of a bathroom will make it look like the cross between a train wreck and a hurricane when they are done, but at least they don't need it that often.) 

You can guess what commodity became valuable during our few days together.

In projects, we have to "share a bathroom" a lot of the time.  It's called resource contention.  It's that one person (or piece of equipment or single-license computer program) everybody wants, the one who (except for the legalities of human cloning) would be dedicated 100 percent on EVERY STINKIN' PROJECT PLAN in your organization (um... no pun intended). 

It's the Web designer who cranks out perfect web pages.  It's the claims examiner who always seems to know what to do in every situation.  It's the accountant who is abreast of every financial law and policy in every state.  And we can't have them because every time we think we need them somebody runs ahead of us, gets inside, shuts and locks the door, and leaves us crossing our project plan legs in excruciating agony until the resource is available again.

But I know why I'm a project manager.  I used the same strategies for handling the bathroom constraint that I do handling resource constraints:

  • Communicate ahead - I'm a relatively strong creature of habit, so communicating that I needed the bathroom from 6 to 6:15 every morning seemed to work for basic needs.  If you know you will need a resource for your project, talk to them and to their functional manager and get it on the calendar.
  • Make alternate arrangements - we were half a mile from the lodge, so I made sure to use the ample facilities there whenever possible.  Instead of insisting on using this one available resource, can you train another person in the company or outsource to another company?
  • Change and be flexible - instead of showering in the morning, I changed my routine and showered at night.  This alleviated competition for the one available resource every morning when all of the others wanted to use it.  In the same way, find ways to use your resource at different times when they may not be as busy and are more inclined to want to help you.
  • Share - "Oooo!  Oooo!  Oooo!  Me next!" was heard a lot in the cabin.  Four adults and two children learned to wait in line and take turns.  Unless it makes your constrained resource feel like a piece of property, simply communicating your intentions and then standing in line may be the best course of action.
  • Relax - no amount of pouting, shouting, whining or breath-holding will make another person finish their "work" faster.  I've seen a lot of project managers make silly mistakes because they can't take a deep breath, relax and think.  (Project puddles are a bad, bad thing.)
  • Do you REALLY need to?  Sometimes we only think we need to go (curse the power of suggestion).  Similarly, I've challenged project managers who knew for sure they needed one specific resource... and when questioned, they backed down quickly knowing they could get by without.

Knowing what is really constraining your project is critical.  Gregg Phipps wrote an excellent piece on critical chain management and understanding how to deal with these constraints.  Resource contention can derail your project faster than you can say "toilet paper."  If you can identify and isolate these constraints on your project resources and time, you have taken a giant leap forward in solving the problem.  So what - or who - is holding your project up?  What excuses are causing the slippage?  Can you use one of the above strategies to fix it?

And once you do fix it, don't forget to flush and wash your hands.  You always want to leave the project resource in great shape for the next person.

Carpe Factum!

Preamble Your Project

Constitution_preamble Happy Independence Day from Iowabiz!

To celebrate our nation's birthday - and with help from my friend, Josh Nankivel, and his fellow authors at PMStudent - I thought it appropriate to look at our constitution as one big project charter:

We the people At their core, projects are about people.  They are of the people, by the people, and for the people. People skills are the chief component of what makes a project work.

In order to form a more perfect union Does your project support the cohesive mission of your organization?  If not, you'll have stakeholders pulling you in every direction.

Establish justice In a project setting, "fair" is a myth. There will always be somebody who perceives your project solution as unfair.  As a leader, you are shooting for an equitable solution.

Ensure domestic tranquility Keeping your stakeholders and end users at the forefront of your focus can prevent embattlement down the road.

Provide for the common defense Projects will always be embattled by office politics.  Why not keep your sense of humor and be prepared for the worst?

Promote the general welfare While you are meeting deadlines and building deliverables, why not develop your people and manage their skills and talents in the process?  It could save your project.

Secure the blessings of liberty While there are many tools and approaches in project management, the best practice is to maintain your flexibility, try new things, and ultimately just do what makes sense for your project and your team and your organization.  Rigidity kills projects.

To ourselves and our posterity What kind of legacy is your project leaving for the organization?  Will people ignore and dismantle the solution once you have moved on, or will they embrace what you have accomplished?

On behalf of my fellow Iowabiz authors, I wish you a safe and happy Independence Day holiday.

Carpe Factum!

Dude! We're Gettin' the Gang Back Together!

20th Reunion This weekend, my wife is dragging me has asked me to escort her to her 20th high school reunion.  All weekend long, I will be cursed regaled with mundane and boring exhilarating and adventuresome stories about growing up in her hometown.  At least there will be other spouses there... and maybe a cash bar.

Seriously, reunions are important elements of our socialization.  Sharing stories is a craft as old as the ages, and remembering all of the silly antics.of our youth can be an enjoyable walk down memory lane.

Even in a project setting, reunions are important.  The obvious reunion should occur before disbanding even takes place.  It is the lessons learned session.  Even if you are a project of one person, sit down and document all of those Homer Simpson D'OH moments that you wish you could do over, as well as those choirs-of-angels-singing-in-celebration-of-all-you-did-right moments.  My preferred method is the start-stop-continue approach:

  • Start:  What didn't you do that you wished you had done?

  • Stop:  What did you do that you wished you hadn't done?

  • Continue:  What did you do right that you will keep doing?

While the important benefit of a lessons learned session is external reuse, the ability to have a "reunion" and share stories is important to the internal project team as well.  Stephanie Barnes refers to these "after action" meetings, and she shares the following:

Even if no one outside of the project team uses the lessons learned it’s important for the project team to do the analysis. Sometimes things are happening so quickly on the project that team members need to take a few minutes once the project is done to tie everything together. Once all the tasks are complete they can see the big picture of what actually happened and the consequences of certain actions and decisions so they can learn and do things differently next time, make new mistakes rather than repeating the same ones time and again. I know I like to make new and improved mistakes rather than the same old ones.

I also like to keep in touch with various members of project teams long after the project has completed.  There are some teams which were together for many months, and I try to keep in touch with my teammates through various forms of networking:  lunches, coffee, LinkedIn, Facebook, or Twitter.  It's helpful for me to be reminded of the project stories (the good, the bad, and the ugly) which have made me the project manager I am.

So dust off those year books status reports and get in touch with your former teammates.  Reunions can be fun... no, really!

Carpe Factum!

Ain't No Cure for the Summertime Blues

Johnson_men My daughter winds up her third grade career today as my wife ends another year of teaching high school.  Stretched ahead of us is the vast unknown of unbounded imagination, family vacations, adventure-filled books, backyard discoveries, splash-filled swimming pool moments... and annoying mosquito bites, occasional sunburns and long-winded sibling spats (as long as we're being realistic about the next 10 weeks).

How often do we romanticize the projects ahead of us?  After all, every new project yields so much potential for fun, excitement, and positive NPV that we can hardly contain ourselves, right?  Some people look at new projects and see ponies and rainbows and butterflies and shooting stars (at least those where you let the marketing team pitch the project for you).  Ask the IT staff about the same project and they will conjure up versions of hell that would make Dante shudder in fear.  As with many projects, the truth lies somewhere in the middle.

Reconciling stakeholder expectations is a scary yet necessary undertaking.  If you asked every member of your family to give you their version of the ideal summer vacation, I would venture a guess that you would wind up with wildly different answers (at least you would in my house).  The project is the same (summer vacation) and the end expectations are the same (enjoyable relaxation and recreation).  For me, that looks like cycling and hammock time.  My wife has a strong desire to camp (yeah, outdoors... crazy, huh?) coupled with reading a mountain of books.  My older daughter envisions swim lessons and camp (with cabins, only slightly more civilized) and trips to the grandparents for unbridled spoiling.  My younger daughter is completely go-with-the-flow, as long as she is entertained.  We all have the same goal (enjoyment), but our perceptions of the deliverable (outcome) and approach (requirements and tasks) differ.

Holman_expectation_curve In The Thinking PM blog, the nail is hit on the head:  deal with the stakeholders early to define and set expectations.  If I waited until August to ask everybody if the summer were successful, I'd be a really lousy husband and father.  We're setting up the calendar of events early, so we all get a say in making summer successful.  Of course, there are boundaries.  There will be no jetting off to Europe, no horseback-riding lessons, no Harley-ridin' adrenaline-laden trips to Sturgis, and no Phineas-and-Ferb-esque antics.  In setting expectations with stakeholders, it's equally important to mention what WON'T be in scope, as mentioned in the TAPUniversity blog post about scope.

My friend, Lyle Holman, a local consultant, shares with his colleagues his "Holman Expectation Curve" (pictured above).  At the beginning of every project, fantasy is high and reality is low.  The two curves eventually converge at what is called the OMG (Oh My God) moment, followed closely by the CTJ (Come To Jesus) meeting.  The curve is inevitable; virtually every project experiences it.  The real trick is to get your project stakeholders to the OMG moment as quickly as possible.

So school's out for the summer.  Are you ready to make it an enjoyable experience for everybody?

Carpe Factum!

Does Your Project Have a Fan Club?

Fans Last month, I was in Milwaukee teaching a business analysis class for the University of Wisconsin-Milwaukee.

Of course, any self-respecting social media participant (blogger, Twitterer, et cetera) couldn't really claim a trip to Milwaukee unless he spent some time with the indomitable (in a warm teddy bear kind of way) Phil Gerbyshak.  And even better (if that's possible) is spending time with Phil AND his girlfriend, Ellen Winters.

To say that Ellen is a great singer would be like telling da Vinci that the Mona Lisa is a "cute drawing."  She is utterly amazing with the vocals in multiple genres, especially jazz.  I've already almost worn out her latest CD.  Besides performing, Ellen also teaches music in both Chicago and Milwaukee.  She shared with me that one of the things she tells her students is to appreciate those who CAN'T sing (like me), because every performer eventually will need fans.  To paraphrase her comments, "For every one of us who is able to perform well, we need the other nine to come to our concerts and buy our CD's."

So true.

And her comments apply to project management as well.  A lot of project managers just plow through the scope and schedule of their project without much regard to those who need to support it... financially, socially and psychologically.  If a project manager is supposed to spend 90 percent of his time communicating, then a substantial portion of the communication should be building the fan base.  Just because somebody isn't sharing the stage with you does not make them any less important to the success of your performance.

Ask yourself the following:

  1. Do you know who is impacted (and who just thinks they are impacted) by your project?  What is their vested interest?  Make a list of the top 20 people who need to be excited about your project.
  2. How are you answering the WIIFM (What's In It For Me) question?  Do you know the value proposition your are bringing to those not on your project team?  Check your project charter or business case; this should be addressed.  If it isn't, add it.
  3. How are you building excitement for your project?  Are you holding lunch-n-learns?  Do you have a Web site or a newsletter or a blog or a Facebook page or a Twitter account?  Have you unveiled a prototype so people can visualize what you are doing?
  4. Are you living it?  Are you spending all your time trying to get others excited, but maybe you're not feeling it yourself?  People have a strong BS-o-meter and if the person at the top isn't excited, others won't be either.
  5. Are you creating fans or evangelists?  Are the people you're trying to excite going to turn around and excite others or does the passion wane quickly?

Sure, you can ask all of the basic start up questions that are required to begin a project.  But as Ellen deftly pointed out, you can be the best performer in the world, but if nobody is there to "buy it"... does your performance really matter?

Coordination Takes More Than a Prayer

Prayer_room Our church has recently been going through a great experience in the form of a 24x7 prayer room.  The concept is really quite simple:  We've designated a couple of rooms in our ministry center that are solely dedicated to prayer, and we have people staffed in hour-long increments to do nothing more than pray while they are in there.  This is not our first time doing this, and each time it improves on many levels.

You may be thinking, "WHOA?  Why are church issues being discussed on a business site?"  Just hold your grail; I'm getting there.  Besides the observation that project management can be a religious experience, the prayer room has provided some excellent lessons on project staffing:

  1. Know the scope of staffing - our prayer room runs for just over 11 days.  Hence, we have a blocked in 270-hour period to fill with resources.  On your projects, let both the resource and their supervisor know the approximate dates they will be needed so they can manage workloads more easily.

  2. Document the need - we have a single sign-up sheet (i.e., one version of the truth) that stays right outside the prayer room and allows everybody to know when they have signed up to staff the room.  In projects, using a tool like MS Project can provide you with reports such as "Who Does What When?" to give you that needed look-ahead.  The key is communicating and setting expectations to avoid surprises.

  3. Have backup - We have one "on call" person for every 24 hours of prayer to handle no-shows and other issues.  In your projects, identify your resources who may be no-shows and develop a contingency plan in case they "sleep through" their assigned task.

  4. Handle logistics - This is our first prayer room in our new ministry center, so one logistic that needed to be addressed was building security, making sure our members could access the building and they were safe the whole time they were in the room.  Do your project resources have the right materials, supplies, equipment, hardware, software, and travel logistics to complete their assigned tasks?

  5. Match skills to tasks - While this isn't a huge issue for our church, since prayer requires a functioning mind, a willing spirit, and the ability to stay awake between 2 and 3 in the morning, it does become a larger issue for your project tasks.  Ensure you have the right people assigned to the right task at the right time.. and do this during planning rather than execution.

  6. Learn and improve - Like I said, this isn't our first time out with this exercise.  Each time, we keep track of lessons learned to make the next experience even better.  Track what went well in your projects to improve it the next time out.  With each project, the staffing challenges should diminish as you learn how to manage them better.

Follow these simple guidelines and you should have people where you want them when you want them.  If not, you may find yourself in need of a more active prayer life in order to get your projects done.

Carpe Factum!

Communication: Blanded or Branded

I just returned from Louisiana, providing back-to-back keynotes to the PMI chapters in New Orleans and Baton Rouge on project communication. It's a common understanding around project management types that 90 percent of a project manager's time should be spent communicating with project stakeholders... through meetings, status reports, issues logs, emails, et cetera.

What too few project managers think about is stamping these critical communications with their ownBlog personal brand.  They think, "As long as I get the email sent out, who cares what people really think about it?"  This can be a very dangerous attitude and approach to project management.

The more I evolve in this profession, the less I enjoy spending time with other project managers.  I don't have anything against them, mind you; I'd rather spend my time with people who are actually out there DOING projects but just not giving themselves the title of project managers.  I tend to learn a lot from those outside my industry, and their projects tend to be more interesting.

One such person is Mike Wagner from the White Rabbit Group.  He's the first one who taught me that branding should be DIRTY, and it was this principle on which I based my presentation on project communications:

DIFFERENT:  Do people see a noticeable change in your communications among the sea of emails and deliverables fighting to get through the "crap filter"?  Are you being noticed?  If you are being noticed, then you are probably either loved or hated.  Even being hated is a good thing; they'll remember you.

INVITING:  If your communications are 8-point font with no white space or bullets, you are probably not luring people into your communication.  Rather than putting up barbed wire that turns off your audience, learn the "art of seduction" to make them want to know more.

RELEVANT:  Are you giving your stakeholders the right messages with the right timing?  Even the best of news can be a disaster if it's delivered at the wrong time.  Learning how to headline and summarize makes for more relevance than dumping everything you know.  What does your audience care about?

TRUTHFUL:  I write business fiction, but there's little room for it on a status report or an issues log.  Balance tact with honesty and sensitivity to ensure the correct issues are hitting the radar screens of those who can help resolve them.  Prove you are managing your project with integrity.

YOURS:  Can people tell your style from Herb in the next cubicle?  Are you proud of your communication?  Do people see your markings all over a project archive?  If so, you are personally branding the messages and the channels to truly own what you're saying.

Yes, you can spend your 90 percent communication allotment doing everything exactly the same way as everybody else.  Or you can make your message shine through and get your project (and yourself) noticed.

Carpe Factum!

Are You Smarter Than a Third Grader?

Dictionary I have a third grader at home who is constantly curious about the English language.  (Of course, having a dad who's a writer and a mom who's an English teacher may be a contributing factor there.)  Hardly a day goes by when she's not asking about the meaning or origin of a given word.  And I usually send her to the trusty Webster's Dictionary - not because I don't know the word myself, but because I want her to get comfortable with looking up the definition for herself.

As project managers, we're charged with completing tasks according to a schedule and a budget, but do we ever back up a step and ask about the requirements that led to the tasks?  In many environments, there's a hand-off of information between those defining the project and those executing the project.  This is unfortunate as it leads to many breakdowns in communication and in performance.

Systems_model_2 I've spent the past four years researching and studying and applying a lot of systems theory in preparation of writing my next book.  (Actually, the fascination with systems theory goes back about 25 years for me, but the last four have constituted the intense scrutiny.)  As project managers, are we looking at our deliverables (outputs) as the product of the requirements that defined those same tasks (inputs)?  And are we backing up even further and looking at the previous system where the requirements are the outputs and the business problem or opportunity represent the inputs?

If you are in the initiation or planning stage of a project, start asking some hard questions:

  1. Why are we doing this task?  What is it producing?  (HINT:  if all of your tasks start with an action verb, answering this question should not be that hard)
  2. Whom is this task benefiting?  (You have to know the stakeholders who care about the task.)
  3. How will we know this task is complete?  (From an effort and a quality perspective, what does "done" look like?)
  4. What dependencies are related to this task and its outcome?  (What are the inputs you need to produce this task?  What other "things" will be produced because of this task?)

Yes, the other questions about who is working on it, when will it get done, and how much will it cost are important.  But I would contend you are selling your projects short by not going back to the dictionary and digging into the definition of your project.  And doing so might just make you smarter than a third grader.

Carpe Factum!

What If...?

Psycho-shower-scream Kids' brains are great for asking the "what if" question. And the more ridiculous the question is in our mind, the more serious the question is in theirs.  "What if we all had magic wands?" or "What if my dog were a pony?" or "What if I could have all the chocolate I wanted?" ... these are the critical questions of their age.

Sometimes we adults should ponder "what if" questions more frequently.  Sometimes we should even venture into the truly scary "what if" questions; they might make us appreciate what we have.  For example, my friend Rosa Say (whose blog is a beautiful find of wisdom) recently sent me a link to a post asking "What if... there was no project management?"  It listed the critical tasks of a project manager and then pondered an organization without their existence:

  • Project status reporting
  • Project schedule management
  • Conducting regular project status meetings
  • Project budget and resource management
  • Coordinating all project communications

A world with no project management?  Be afraid... be very afraid.  While Brad Egeland's post did an admirable job making the case for project management, it really stopped shy of what a truly exemplary project manager can do for an organization:  change the culture.  I know, I know... it sounds all soft and squishy and fluffy.  But I've seen this over and over again in many organizations.  When project managers are allowed to do their jobs well, other people stand up, take notice, and proclaim, "I gotta get me some of that!"  Okay, maybe they are not that enthusiastic; but accomplishment, results and success are their own best judge.  Having recovered an HR/Payroll software project, it didn't take long for the successful outcome of that project to reach the radar of the CEO, who then replicated its success across the other projects in the organization.  Successful project management perpetuates itself throughout a culture.

A world with no project management?  What if... just what if... that's describing YOUR organization?

Carpe Factum!

Gimme a 'P'!!!

When teaching graduate classes at Drake University, I feel it's my responsibility as a professor toBlog demonstrate to my students that passion is a key ingredient to approaching their work.  As I constantly tell them (and remind myself), "If you're not having fun, you're not doing it right."

Yes, this even applies in project management.  About ten years ago, Tom Peters released an article in Fast Company, which has become a cornerstone of the project management class I teach.  It was called "The WOW Project" and talked about how even the most seemingly mundane projects have a WOW factor to them; we just have to find it.  Recently, Fast Company republished the article on their site.

Even more recently, The Duct Tape Marketing Blog had a great post about building excitement.  The author, Don The Idea Guy, states:

First, you have to feel excited about an idea if you're going to work passionately toward making it a reality. 

But he goes on to say,

It is only through an exchange of excitement (causing others to feel the same excitement that you feel) will get others to provide the buy-in necessary to move your idea forward.

He goes on to give specific tips on maintaining excitement.  This is great stuff!  I've seen far too many "I see dead people" cubicle dwellers on projects.  Yet many project managers accept these zombies as a fact of life (no ironic pun intended) and allow them to suck any potential morale out of those who could be potentially excited.

In this tough economy, more people are worried about keeping their jobs than they are about building excitement for those same jobs.  But there is a direct correlation.  People who are excited about their work probably will have a better chance of keeping it.

Ask yourself this:

  1. As you are recruiting project resources, are you looking at passion and personality fit as much as you're looking at skill sets?  Skills can be taught; it's harder to teach passion.

  2. Do you have people who are "sucking the life" out of your project?  Can you get rid of them or try to coach them?

  3. Does your team understand why the project warrants passion?  Do you?

  4. Are there hidden gems within your project where passionate elements can be uncovered?  Are there diamonds in the rough of the seemingly mundane?

It's been fun hearing from my students about their passion for working with these small businesses around town.  One of the key elements for building passion is the feeling that they're truly making a difference.  That alone will build more passion and excitement than you as a project manager can generate.

Carpe Factum!

The Eyes Have It

Eye Recently, I took my mom in for the second of some planned outpatient surgeries on her eyes.  The first one didn't go as well, and so she was experiencing a lot of double vision.  Always the optimist, I tried to encourage her that her upcoming Hawaii trip would allow her to see twice as much tropical beauty, but she didn't buy it.  Hence, the second surgery successfully brought both eyes back into alignment so she's seeing one of everything again.  (Just don't introduce her to any identical twins in the near future... it might freak her out, okay?)

One of the reasons why many projects derail is because of the exact same issue my mom was experiencing... different vision from different stakeholders.  There was a great article recently by Satya Narayan Dash on the PM Hut blog about this very phenomenon.  Comparing three projects, Dash concluded that project success is not the same as project management success, and shared three points of consideration:

  1. Define target success for the project and the project manager
  2. Define target success for the organization considering the project involved
  3. Define failure for the project and the project manager

Recently, I facilitated a half day session where senior managers were sharing their views on integrating their business functions.  While they had fairly specific visions of what they were striving for, there were open doors for misinterpretation.  Who hasn't had a misstep in defining what "user friendly" or "open access" mean for different stakeholders?  When you define the target success, make sure you use specific criteria and are as objective as possible in the outcomes.  My preference is to list criteria as simple yes/no results (either the project solution meets the requirement or it doesn't).  Then weigh the specific criteria to score the overall project success.  To do anything less is the project management equivalent of what my mom experienced with her vision - the eyes will be shooting in different directions and you'll wind up with organizational double vision.

This is one area where a wise project manager will leverage the skills of a solid business analyst to help in the definition.  It will keep your project vision in alignment.

Also, make sure the discussion about success and failure criteria is held at the beginning of the project (preferably during initiation or no later than planning).  To define these criteria at the end of the project will ensure one thing:  failure.

Carpe Factum!

All That Sparkles...

Sparkles I hope you've enjoyed the recent interviews with Chad and Kristin ... I'm lining up a new set of interesting people/topics for early spring, so be on the lookout.

Right now, though, there's a more pressing issue to discuss:  laundry.  At my house, I'm "laundry boy" (sounds like a rather domesticated superhero, doesn't it?).  I have my processes and techniques an secrets.  I know how to queue the washer and dryer for maximum effectiveness.  The hampers are color coded based on type of laundry.  I research different folding techniques (although fitted sheets still get wadded into a ball and stuffed in the linen closet).  There is just something therapeutic about laundry.

Recently, my goal of efficient laundering has hit an impasse with the female offspring in the house.  You see, I like low maintenance laundry.  Sort - wash - dry - fold ... nobody gets hurt.  But my girls - 9 and 4 - like sparkely things that have to be turned inside-out for washing and cannot be dried or the sparkles fall off and attach to other things.  (Trust me, you do not want to have sparkles embedded in your Under Armour on workout day... people at the gym will talk.)  Hence, my design criteria for clothing selection is now different from my daughters... and of course, they will win.

This happens all the time on projects.  Different stakeholders have different needs and criteria.  Unless these are communicated and reconciled during scope planning, there's going to be trouble.  Somebody will be unpleasantly surprised by the time implementation hits.  Scott Berkun posted the top reasons why designs fail in his blog a few months ago... all great stuff.  It all boils down to communication, doesn't it?

The bottom line is that design and scope management are PROACTIVE activities... don't just start executing things until you've come to concensus on what you are doing, what's important to the stakeholders, and why people care about the things they do.  Even if you give every stakeholder 10 note cards, and ask them to write one critical function or feature on each card, you'll still be light years ahead of those who make assumptions and then blindly proceed.

Otherwise, you may find sparkly things on your requirements when all you really wanted was clean laundry.

Carpe Factum!

The PM Recruiter: An Interview with Kristin Solberg (Part 2)

SolbergKristin We complete our interview with Kristin Solberg today.  As I mentioned in my previous post, Kristin is a top recruiter for consulting firm Genesis 10.  In her role, she has been exposed to hundreds of project managers, and finding the correct fit among client, consultant, and project is a daunting task.  I've known Kristin for years, and her judgment and people skills are unparalleled.  In this part of the interview, we focus on some of the current business landscape challenges and how Kristin addresses them:

Kristin, what are some of your favorite interview questions when talking with a project manager?

When I’m certain they are technically qualified to be a PM, these are my top three open ended questions:

    1. How do you define a ‘successful’ project?  I’m looking for something beyond the PMI party line of finishing a project “on time, on scope, on budget.”  A good answer includes a discussion about delivering the required business value.  Bonus points if they mention an experience when they recommend a project be cancelled because it was no longer viable.

    2. What are the top three ‘value adds’ project managers should provide to a project team? Many acceptable answers, but I’m looking for 1) managing risk 2) removing obstacles for the team 3) understanding and enabling team member strengths

    3. Describe your approach to project leadership and managing teams.  Is it more important to lead or manage?  Give me an example when your approach was more effective than what the typical project manager might have done.  I ask these questions to assess the PM's fit for a specific project and/or organization.

I'm glad you mentioned adding value, because it is certainly on everybody's mind these days.  In our lean economic market right now, how have your job responsibilities evolved to continue to add value?


The individuals that you present to the client have to be a perfect fit.  They have to have the right balance of technical fit as well as cultural.  With the competition that is out on the market it is not enough to have similar experience, they are looking for an individual that have the precise background for their project. The project manager that will secure the position is the individual that can sell themselves

What “after the sale” activities do you do for the project manager and for the client to ensure continued success?

Our goal is to follow-up with both parties within a two week window of starting a project and to have continued contact.  If a client or project manager is having difficulties we want to be able to recover the situation sooner than later.  We have a large network of contacts that we can reach out to for support. As in most situations, communication is key.

Well put, Kristin.  Thank you again for taking the time to talk to me.  For those of you out there looking to hire or contract with a talented project manager, Kristin and the folks at Genesis 10 would be a great first stop.

The PM Recruiter: An Interview with Kristin Solberg (Part 1)

SolbergKristin Continuing with my highlights of local project practitioners of excellent caliber, Kristin Solberg of Genesis 10 is the focus of this post.  Genesis 10 is a national consulting practice with offices in many cities across the U.S.  They offer a wide array of consulting services, including project management and business analysis.  Kristin is the recruiter for the Des Moines branch.  I've known Kristin for a number of years, and she exemplifies the qualities of a great HR recruiter.  In the current economy, finding the right project manager for the job is critical.  My interview with Kristin focuses on her skills in matching the right client with the right candidate.

Thank you, Kristin, for taking the time to talk to me.  Where do you find qualified project management candidates?

I have been in the IT recruiting industry for close to thirteen years. The last six of those years at Genesis10 has been specifically recruiting within the Project Management space.  At this point in my career the majority of candidates that I work with come from my own network as well as from referrals of individuals that we currently work with or have worked with in the past.  If you want to find a great project manager ask for referrals from those individuals whose work you have a great deal of respect for.  Their referrals are always a reflection of who they are.

How do you match your clients’ needs with available talent?

When working with a client we try to gather as much information about the opportunity as possible. That includes why is the position open, what are the individuals missing that you have currently spoken with and what type of person will succeed in the position.  It comes down to both a skill fit as well as personality fit.  The majority of opportunities that we work on we already have a understanding of what the client looks for.  That is the great thing about working in a small market such as Des Moines.  You get to know your clients not only on a professional level but also a personal one.

How do you balance technical fit with cultural (i.e., human/organizational) fit?

A number of individuals have the same skill set so ultimately it does come down to personality/culture fit.  When we present candidates they will have the core skill set that the client is looking for but different styles on how to complete the task.  The client then has to decide what style would work best for the project at hand.

How do you measure your success?

When both parties (client/project manager)come back during the project or completion of the project and tell us it was a "perfect match."  I also get great satisfaction when a candidate or client contacts Genesis10 due to our reputation in the market place.

Thank you again, Kristin, for your time and insight.  Look for the rest of the interview with Kristin on my January 19th post.

The Project Office: An Interview with Chad Feeney (Part 2)

Continuing from the conversation we started the last time, I'm interviewing Chad Feeney, who is leading the Project Office at Farm Bureau in West Des Moines.  The first part of our conversation occurredBlog earlier in the month.

What do you look for in a skilled and talented project manager?

 

When looking for a PM there are a couple of key items we look for:

  • Experience. Its very important for us to find a candidate that has had favorable and challenging experiences. We look for someone who's weathered some storms.
  • Communication. Like our discipline indicates and experiences validate, we communicate 90% of the time. So, someone whom can demonstrate notable skills within written and oral communication.
  • Leadership. A candidate must demonstrate to us that they don't just have one leadership style. They must be adaptable to the situations and Interpersonal styles of our customers and executives. We like to understand from a candidate they know when to swim with or against the current.

 

What has been your biggest challenge in managing a project office? What is the most rewarding aspect?

Our biggest challenge in managing a PMO varies from day to day, but a common theme is expectation management. A majority of the time, we provide a service that meets expectations and has a rewarding benefit to the company and the PMO. Occasionally, we're asked to provide services that is dependent upon our partners capabilities. I like to remind myself your service is only as good as individuals whom are performing it. Consequently, that is the most rewarding aspect...coaching and partnering with fellow PMs in providing the best service possible.

 

How would you sum up your philosophy of project management?

Triple Constraint. The concept is easy to understand but the application and communication of this philosophy within a corporate environment is probably the most challenging for any project manager or PMO leadership. During our early stages of a project, the concept and feasibility stage, it's important to establish the ground rules of the triple constraint. But it's in the planning stage where our services as project managers must prove back to the executives that their expectations can be met using the triple constraint as the dialogue tool. It's our obligation to listen to the voice of the customer and partner with them on the options since never is anything cut and dry with a project. I've always kept this simple premise as much in front of our customers as possible.

Look for more interviews with other local excellent project practitioners in the future.  Thanks again, Chad.

The Project Office: An Interview with Chad Feeney (Part 1)

Recently, I've been thinking about ways to "shake up" this column.  I've spent the better part of the past 18 months sharing my philosophy of project management; however, there are many talented project practitioners throughout Greater Des Moines.  Recently, I've been reaching out to some of the ones whom I've come to respect greatly over the course of my career to allow them to share their stories.Project

This month, I'm starting with a great project leader.  Chad Feeney heads up the project office for Farm Bureau in West Des Moines.  I've worked with Chad in the past, and we've known each other for over a decade.  He's a highly skilled project leader, who now leads other project managers.  This is the first of a two-part series.  The remaining questions will appear on my Dec. 19 post.

Chad, thanks for agreeing to share your thoughts with my readers.  How large is your project office?  What services do you provide?

To help put this question into context, the PMO is a shared service department within FBL Financial Group Inc. We have a mix of entry, mid-level, senior project managers and project portfolio managers. With occasional staff augmentation with project management consulting, we're 15 individuals strong. Our services range from project management to strategy facilitation.

 

How did your career path arrive at managing a project office?

My personal career path started within IT as a systems analyst and an occasional DBA wit Principal Financial Group Inc. It was during my tenure with Principal that I was introduced to project pathways and actually started managing a project for the residential mortgage division. After the project completed, I was very interested in the project management discipline and processes, of which, I decided to make a career choice of pursuing full time. I continued to build experiences as a PM and fulfilled roles as a program manager and project portfolio manager at Wells Fargo and ING. I started with FBL in 2000, and helped initiate the Project Portfolio Management discipline which subsequently gave me the opportunity to lead the PMO department.

 

How does your project office continue to demonstrate value in the financial services industry, given the recent economic events?

Our value to our users and customers has evolved over time as we have matured our project management practices. We matured from a Ad Hoc project management function where status reports and issue logs were the common deliverables and discussions with executives to a practice where the PMO facilitates/coordinates strategy development, partners with business leaders to determine fit and goals of a project to an overall business plan, providing hard factual numbers with financial management and bringing insight of resource demands for IT - where did IT spend its time and where will the demand be from future projects via resource management. Overall, we're trying to give our executives/customers more transparency to make much more informed, cost-saving or cost-avoiding decisions.


Another value add we provide to our customers is within a forgotten practice of lessons learned. The pace for delivery and service is so intense that we often forget to look back and determine if we actually achieved the objectives and benefits of a project or program. Our PMO has been looking very hard at what we can provide our executives and customers in this space. In 2008, we've had some success with providing some of the easier lessons learned for a give project. For instance:

       How many of the objectives were met - Scope Achievement

       Did we stay within budget - Financial Management

       Was our schedule within an acceptable tolerance - Schedule Management

       Where did we spend our time throughout the project - Time Entry Transparency


Are any of the above questions familiar? Does the triple constraint come to mind? Acknowledging these kinds of questions is really not the most attractive, as compared to benefits realization, but keep in mind these questions by themselves still tell a story. For example, if we find that we spent more time in development than estimated why is this? Did we estimate poorly, was our requirements sound and complete, or was the solution more complex than expected? If we can help IT answer these questions and partner to make improvements with these core skills, I believe we're bringing value in the near timer while focusing upon the benefit realization conversation and service for the long term.

Great insights, Chad!  I'm looking forward to sharing the rest of our interview with my readers on the 19th.

Thanks To You Meddling Kids!

Recently, my daughters and I have been enjoying some vintage Scooby Doo episodes.  AtBlog the end of each episode, in a typically formulaic approach, the bad guy (after being unmasked) would utter something like, "Yeah, and I would've gotten away with it, too, if it weren't for you meddling kids!"

It would appear as though Fred, Daphne, Velma, Shaggy and Scooby stuck their noses where they didn't belong... and turned it into a career which spans generations.

What about your projects?  Do you have a few of "those meddling kids" among your project team?  Are you asking the right questions about your projects:

  • Why are we doing this project?
  • What are we trying to improve?
  • What's wrong with the status quo?
  • What will it do for our company?
  • Who cares about this project?
  • What can go wrong if we proceed?

Make sure you have somebody documenting these questions (and their answers) as you will invariably having people asking these same questions throughout the life cycle of your project, and it will help to have this information readily available so everyone gets the same answers.  Let "those meddling kids" ask any questions they want... the only bad question is the one not asked.  I was reading a post by Stephane Bourbonniere about e-Discovery projects.  In this post, he talks about some of the right questions to ask... BEFORE he even launches into the project management issues.  Yes, snooping around for clues is encouraged.

If you don't have any meddling kids on your project, if there are no people asking questions, if there are no hungry dogs sniffing around your project, I can only say one thing:

Jinkies, Shaggy!

Dear Mr. President

SealpresidentialcolorAs of writing this, I do not know if I'm addressing Sen. McCain or Sen. Obama.  My message is the same, regardless of which one of you wins.

First of all, congratulations on winning one of the most epic and historic elections ever.  As one who loves the art and science of office politics, I've been riveted to the dramatic twists and turns the past 10 months have provided.

Now, however, it's time to get down to business.  And I have but one request for your performance as "Leader of the Free World":  it's time to quit acting like a politician and start acting like a project manager.  Since you're a Washington Insider, I'll explain in simple terms and try to use small words:

  1. Prioritize - As a project manager, it's impossible to do everything to make everybody happy.  Our profession is blocked in by the triple constraint.  You'd better learn this principle quickly.  You have a few things that are the top of everybody's minds:  Economy, environment, education and enforcement being among them.  Special interests and party politics will need to take a back seat.
  2. Define - once you've established your priorities, you will need to figure out what your project solution will look like.  You're going to get battered around quite a bit, but you're the leader we elected, so we'll expect you to have the diplomatic backbone to sell your solutions across party lines and also make all of the Joe-The-Plumbers and Joe-Six-Packs content.  Along with this, don't forget to create some metrics so you can prove to your nay-sayers you were successful.
  3. Plan - create a timeline for the tasks needed to make your solution.  Get the right resources in place to make them a reality.  Make a budget.  Identify and strategize your risks.  Set the expectations of your stakeholders.  Don't get distracted by all of the special interests who will want to add to your plans.  It's called "pork" and we're sick of it.  (In project terms, we call it "scope creep."  Either way, it's bad.)
  4. Lead - protect the project priorities, stay focused on the key things, execute your plans, remove obstacles for your project resources and keep us informed.  Work with us... ALL of us... Democrats, Republicans, Independents, Federal employees, State employees, Local employees and regular citizens who know how to think and solve and articulate and get things done.

Regardless of which of you wins the election, my wish, my hope and my prayers are the same, Mr. President: Act more like a project manager than a politician and figure out how to Carpe Factum.

Let's Give 'Em Something to Talk About

Dangle_carrotAs a project management consultant, one question I receive very regularly is how to motivate the project team, especially if the project is long.

My philosophy on motivation is to get people who really want to be on my project in the first place... in other words, to generate my own passion and energy.  If they don't want to be on my project, I like to give them a reason to want to be on my project.  I mention this article when I teach classes, but Tom Peter's Wow Project article is timeless.  Talk about building passion into ANY project.

The most exciting project I was ever on was a HIPAA (Health Insurance Portability and Accountability Act) compliance implementation.  Why was it fun?  We made a conscious decision to make it fun.  We built relationships within the core team.  We did goofy things for the training video.

There are some projects where the scope is so boring that you really just need to trudge through it.  However, what really makes or breaks the motivation factor is how much people know you care about them.

Here are a few things you can do to make your project more enjoyable and keep people motivated:

  • Food - There's a reason Jesus held the Last Supper instead of the last board meeting.  Have a food day.  Take your team out for lunch.  Cater lunch in.  There's just something about the tantalizing aroma of chow that gets people up and going.
  • Certificates and Recognition - Criticize in private; praise in public.  Make a big deal when an individual (or even better, a team) has a big win.
  • Play - not only will it get people away from their work for a while, it's been shown that play time actually improves people's creativity and analytical thinking skills.  Building some play time into the day may make your team more productive.
  • Brand yourself - give your project its own brand (T-shirts are a fun way to advertise your brand identity), but give your style of management and leadership its own brand as well.  Create a brand story that says, "Hey, I'm both fun and productive" and you'll have people beating down the doors to work on your project.
  • Budget for it - stick in an extra few bucks (the amount will depend on the size of the team and the length of the project) to do a few really special things for people throughout the project life cycle.

These are just a few things you can do to help people trudge through the sometimes less-than-pleasant activity of project management.

Carpe Factum!

Vanilla, Please

Vanilla_ice_cream_coneI'm currently in New Orleans speaking at the local PMI chapter event:  Project Management All Jazzed Up. It's been a wonderful visit, and I've enjoyed sharing with fellow practitioners how to become more creative and how to build "office politics proofing" into their project plans.

One workshop I attended yesterday was entitled "Fight for the cause" by Lisa DiTullio. Wow! She was an amazing speaker who exuded credibility, having pulled off an incredible multi-million dollar project recovery for a major health-care insurance institution in Boston.

What impressed me about her presentation was not a lot of flash or theory, however. Lisa and I are actually kindred spirits:  we like simplicity. She told a story of being a young girl in south suburban Boston and going with her large Italian family for ice cream every Sunday afternoon. Given all of the flavors to choose from, she always selected vanilla.

Why? Well, the flavor of vanilla is basic. It maintains its integrity. It's simple, without pretense. And it's very easy to accessorize. You can add just about any ice cream condiment to vanilla ice cream and it improves both. Having watched my daughter request sour gummi worms with her bubble gum ice cream, I know there are combinations which no rationally thinking person should attempt.

How vanilla are your project management processes? Are you easily wowed by the chocolaty richness of Lean Manufacturing? What about the fruitiness of Six Sigma? The big problem with these is that they leave little room for flexibility. Is there a nutty consultant who has sold you their "flavor of the month"? The templates for these methodologies work well if you stay strictly within their confines. Lisa and I talked for a long time yesterday after our respective workshops were finished, and we realized that while we're both pro-process, we're anti-methodology. We like to keep things simple in our project processes and then accessorize to fit the situation. We may pull in a tool from Lean or Six Sigma, or we may just make up a new "flavor" depending on the need. But by going vanilla, we keep our flexibility intact.

Are you afraid of project management because of the complexity of some of the methodologies out there? Are you overwhelmed by the sheer volume? I have a book on my shelf at home of project templates - it's over two inches THICK. I rarely reference it. It's easy to become spooked by project management. Hence, I choose to manage my projects with a foundation of only four documents:

Then you can accessorize this "vanilla" project management with additional tools and templates... AS THEY ARE NEEDED.  How can you make your project management more vanilla to maximize both flavor and flexibility?

Carpe Factum!

How Much Is That Doggy In The Window?

Nyse_wall_street_2I was planning on writing about risk analysis and quantification for this post, and I was wracking my brain to figure out a good segue into the topic. So I must remember to send a nice hand-written note to the executives at AIG, Morgan Stanley, Freddie and Fanny and Lehman Brothers.

In my last post, we covered ways to identify risks in your projects.  Now we need to quantify those risks... in other words, figure out how potentially bad they can be.  Our goal here is not to have exact numbers, but to be able to make intelligent decisions about whether to spend money and energy to avoid or mitigate the risk.

The calculation to figure out the "cost" of the risk (otherwise known as Expected Monetary Value, or EMV), is pretty simple.  First, you should determine the probability that the risk event will occur (e.g., there's a 20 percent chance Sally will quit unexpectedly). Then calculate the impact of the risk event should it occur (e.g., if Sally quits, it will cost us $40,000 to backfill her position).  EMV is simply the product of the two numbers.  So the "Sally Risk" is worth 20 percent x $40,000 = $8,000.

What? You say you don't have time to put an exact probability or dollar figure to each risk?  I don't either. In one of my most successful risk management projects (a highly complex program involving hundreds of resources and a detailed process/system overhaul), we created a very simple 5x5 grid to calculate risk:

Risk_quantification

The program executive, the technical lead, and I sat down over a long meeting and threw out the first number that came into our head for each risk.  (Surprisingly, we agreed the first time about 90 percent of the time; for those where we disagreed, we had some great dialogue.) We then multiplied the two numbers together to come up with a composite risk score. If the risk score was higher than eight (8), we paid attention to it. For those which scored less than 8, we revisited them about once a month.  So it's not necessary to do complicated Monte Carlo calculations, difficult computer-generated models, or expensive and time-consuming in-depth research.  Risk analysis and quantification can occur very quickly, yet still provide you with the ability to make quick decisions about the important project risks on which you should focus.

Like the $85 billion ones.

Carpe Factum.

What? Me? Worry?

WhatmeworryHaving a pre-schooler in the house is a continual lesson in risk management.  Try as I might to keep her from harm, the prevailing question in our house is not WHETHER we will go to the emergency room, but WHEN we will be heading there.  I'm not sure what her guardian angel did to honk off the Almighty and wind up with my daughter as his responsibility, but I'll be sure to thank him some day.  A typical soundtrack for any given day in our house sounds something like:

Me: "Abby, stop that/slow down/be careful.  You're going to get hurt."
Abby: "No I won't!" (Insert sound of running or continued activity, followed by a THUD and the sound of crying.)
Me: "Honey, what happened?"
Abby: "I fell down and got hurt."
Me:  "Hmmmm"

As a project manager, you may not like to think anything bad could possibly happen.  The internal voice which just keeps prompting you to "think happy thoughts" also prevents you from seeing what might possibly go wrong.  Franke James, a good friend and a stunning visual essayist, recently created a very telling blog post on a series of explosions which recently rocked her world.  A propane depot less than five miles away blew up, causing 12,000 people to evacuate in the middle of the night.  Her husband dismissed it as an unpredictable event, but Franke had other thoughts:

Yes, it had a massive impact.  But it was NOT unpredictable.  It was entirely foreseeable.  The residents complained to the city about safety violations.  Twenty-one years ago the city planning commissioner warned of this, except he predicted even greater loss of life.  It was just luck that the explosion occurred at 4 a.m. on a Sunday night.  If it had been a weekday, the loss of life could have been catastrophic.  As it was, two people died.

Franke goes on to do a brilliant risk analysis.  She provides a model for every project manager.  Too often, egos, ignorance and schedules get in the way of really diving down into the details of what can go wrong.

Before running headlong into a project, spend time brainstorming with as many people as you can get to participate to identify all of the possible things that can go wrong.  Make sure you write them down (if they're not documented, they don't exist).  To help get you started, here are some of my favorite categories of risk management brainstorming, just to prime the mental pump:

  • Hardware issues (including sourcing and supplying)
  • Software issues (version control and compatibility)
  • Vendor issues (delivery and solvency)
  • People issues (performance capabilities, availability, office politics)
  • Budget issues (economy, competing projects)
  • Managerial issues (weak sponsorship, lack of consistent project processes)
  • Manufacturing issues (supply chain, machinery, or infrastructure)

In my next blog post, I'll share with you how to analyze those risks.  But for now... start looking at what can go wrong.

Carpe Factum!

The Summer Games: 14X40 Vacation Relay

OlympicringsI love the Olympics (summer or winter games).  Regardless of my schedule, I take time to watch and cheer as the world comes together.  The variety of games and the diversity of skill to excel amazes me as I watch the peak of athletic prowess in action.  (By the way, a gigantic Iowabiz CONGRATS to Shawn Johnson - you've made your state proud of you, both by your performance and by your gracious integrity.)

Vacation_calendar In our offices, there is a different kind of summer game, and it seems to bring most projects to an excruciating halt in the 14 weeks between Memorial Day and Labor Day.  I refer to it as the 14X40 Vacation Relay.  The 40 hours a week you get are about as productive as a sloth at a relaxation clinic.  You can't see it directly, but some of the color commentary sound like the following:

  • "Sorry, but we can't sign off on the deliverable.  The executives on the Steering Committee won't all be back in the office at one time until September."
  • "What do you mean Fred is unavailable?  A three week fishing trip?!  He's supposed to be working on this critical path task due this week!"
  • "I can appreciate the fact that Andrea's kids are home on summer vacation, but we need her subject matter expertise, or we can't move forward."
  • "I know you're waiting on a hiring decision from us, but we can't sync up all of interviewers calendars for a couple of months."

How do you combat this phenomenon, short of shutting down every project in your organization for three months each year?  Keep everyone from taking a vacation?  Hmmm, that seems a little intense (as well as counter-productive, according to Andrew Trent).  There are a few simple strategies to help you mitigate this problem:

  1. Revisit your project plan at the beginning of summer - what major deliverables are due in June, July and August?  Who is assigned to them?  What are the risks associated with getting them done on time?  Do they really need to be completed during these months or can they be delayed.
  2. Block off "high volume vacation weeks" on your plan - I generally will block off the entire weeks of Memorial Day, Independence Day, and Labor Day so in my plan, no work is scheduled.  But I don't tell my team this (so don't let my secret out, OK?).  During these weeks, where so many are gone anyway, it allows those still in the office to play catch-up on behind tasks.
  3. Have critical resources assign proxies - if there is a resource on your project who might be unavailable when critical deliverable or hiring decisions need to be made, ask them to assign a back-up who will be there when they aren't.  Allow them to negotiate what level of authority the proxy has, but allow enough leeway to keep the project moving forward.
  4. Touch base proactively - I provide my teams with a 3-week look-ahead report (generated directly from the project plan) so everybody knows what is due in the immediate future.  We talk about these upcoming tasks weekly, so I know early if there are resource availability issues and can mitigate schedule risks.
  5. Compare your end-of-summer plan with your start-of-summer plan - use variances as a "lesson learned" along with explanations of what caused the variance.

Again, the 14X40 vacation relay does not need to be a "summer game event" which shuts down the entire organization.  With some project planning and a lot of proactive communication, you can make summer as productive as the other nine months of the year.

Carpe Factum!

It's Decision-Making - Don't Blow It

Native_american_fluteThis summer, I've sought a few relaxation techniques to add balance and equilibrium to the life of this dad/husband/project manager/writer/speaker/college professor/other duties as assigned.  One such pursuit has been the Native American flute.  Keep in mind, I'm not very musically inclined.  With the Native American flute, I don't really have to be.  It works on a pentatonic scale (i.e., 5 notes) as opposed to the 7-note scale of other traditional instruments (not to mention all the requisite sharps and flats which add complexity).  Five notes.  That's it.  Hit any one of the five, and it sounds hauntingly beautiful.  The concert tour will be scheduled any day now.  OK, maybe not.

The Native American flute can teach us some lessons about decision-making when selecting a solution for our project.  Often, we encourage our teams to brainstorm and believe the sky is the limit.  However, when it comes to presenting solutions to the decision-makers, one is never enough, but it is also possible to have too many solutions.  Why not use the approach of the Native Americans?  A maximum of five alternatives.  Any one (or any combination) of those five will sound good.  Providing only one alternative gives decision-makers (usually attention-deprived executives) the chance to dislike it and send you back to the drawing board (and who would want to listen to only one note?).  Provide them with too many alternatives and their eyes glaze over (along with more chances to get it wrong).

I found a blog post with some good pointers on brainstorming and problem-solving techniques.  Their eight steps are in about every management 101 textbook you'll find:

  1. Look for the reason. Specify the problem and identify the reason, why it must be solved.
  2. Look for all available information relating to the problem and list them.
  3. Define the judgment criteria. What principles or standards should be met for one of the alternative solutions to emerge as the best solution?
  4. List as many possible choices as possible through discussions and brainstorming sessions. The more ideas you generate, the closer you move to the optimal solution.
  5. Examine each choice on the yardstick of standards and judgment criteria that you have defined. Determine the pros and cons of each alternative.
  6. Identify the best alternative. This is relatively an easy step, once you have sequentially followed the above steps.
  7. Initiate the plan of action. The decision you have just taken must be transformed into action. In absence of the execution of plan, the very reason for making decision will be nullified.
  8. Finally the consequences of your decision and the steps leading to it must be examined and evaluated so as to learn the valuable lessons. This hones up your decision making skills further.

However, there are probably a couple of steps missing in the 5-6 range.  My additions would be as follows:

  • (5.1) Narrow down the alternatives to no more than five possible ones.  Just like the notes at either end of the scale are the hardes to hit, put the least favorable alternatives at the start and finish.  (Working from the middle is a great rhetoric technique.)
  • (5.2) Present to the decision-makers and get their commitment to your solution, securing you resources and support as you prepare for steps 6 and 7.

Any project solution you present should then be a lot easier if you just ensure your project is solving the right problem.  Then you'll be making beautiful music for your organization!

Carpe Factum!

The Patient Is Recovering Nicely, Thank You

Heart_rateYes, it's true.  Iowabiz.com is back up and running, thanks to new sponsorship of The Business Record.  I'm excited to be back in the saddle (although having a couple of months off with one less blog was a nice reprieve).

I've written in the past about effective project recovery and rescue techniques, and I've learned a thing or two about getting a flailing project back on its feet.  It's been interesting watching Drew McLellan and the Business Record folks as they breathe life back into Iowabiz, and it brings to light an interesting aspect of project recovery:  PUBLICITY.

Yes, every project manager knows (or should know) that 90% of effective project management is communication.  Stakeholder communication becomes even more critical when dealing with a project recovery.  Merely having a recovery plan isn't good enough; it has to be communicated and sold to those who endured the originally failed project.  So communication in and of itself isn't enough.  You now have to SELL, SELL, SELL your project as never before.  As Amy Alberg of the Making Things Happen blog states:

The next stage is to develop your project recovery plan and sell it to the team, stakeholders, customers, suppliers etc that may be part of project. Begin your planning and communication with a healthy dose of reality. If something should have worked based on X assumption and it wasn’t, don’t continue to assume it will and determine a viable alternative. The recovery plan itself will vary widely based on the size, scope and type of project you are working on. Basic elements are issue statement, root cause, impact, resources required, short term actions, long term actions, date fix will be in place, who the accountable person will be. If there are multiple options, than lay those out without playing the blame game so decision can be made. This will take strong communication and salesmanship to convince all parties that this project will be successful and ensure strong support needed. At this point, you may be communicated with a frustrated team, angry customers, internal political battles, competing agendas, etc so be deliberate in crafting your message.

One of the big lessons I've observed watching the Business Record that every project manager could learn is that one communication channel/medium isn't enough.  It's a publicity full-court press.  Don't assume that a blanket email will cover everybody's communication needs.  Hold a "town hall" meeting.  Schedule one-on-one's with key decision-makers.  Set up an internal website or blog or Facebook group to carry on an ongoing dialogue with stakeholders.  Heck, perform an interpretive dance in the company lobby if it will get people's attention (just don't put your CFO in a tutu - I hear he doesn't have the legs for it).

Remember, you want people to be well informed that 1) the project is being recovered, and 2) you have things well under control.

Welcome back, Iowabiz!

Carpe Factum!

In Case of Emergency, Break Glass

Fire_extinguisher A picture is worth a thousand words.  Do you have an action plan in place just in case things get really wild and crazy on your project?  Do you know what you need to do first?  Second?  Whom should you call?  What is the first meeting you should hold?  What messages should you relay?

We spend a lot of time and energy on business resumption and disaster recovery plans for our organizations.  Do we know how to apply these concepts for our projects?

In your next risk management plan, put in a scenario for "everything bad happens at once" and see how well you can prepare for it

Carpe Factum!

It's A Date

Dsc_0067I had to chuckle when I drove past a local arena and saw the sign advertising the Cinco de Mayo concert... on May 3rd.  Evidently, somebody neglected to tell the planners that "cinco de Mayo" is Spanish for the 5th of May.  Oh well.  I'm sure the concert content is great, regardless of which day it occurs.

In project management, we talk a lot about late tasks and how these impact the project and the organization.  Sometimes, we neglect the impact of tasks that come in too early.  An older post at the Ever Changing Crusades blog yields a valid issue on completing projects too early:

Since I mentioned Dead Lines.......back at my previous job,  I had absolute dead lines.  Everybody did.  What was the point in getting a project finished too early and then something, at the last minute, changes the outcome and have to redo the work?  My view was/is to just wait until all the facts were in, and then do the job.

So assess your tasks.  Think about the predecessor and successor relationships.  Look at impacts and resources.  If your task needs to finish on a specific date, then don't try to overachieve.  (Mind you, don't procrastinate either.)  Just get it done... right... and on time.

Carpe Factum

The Holy Trinity of Project Management

Cooking_holy_trinityIf you have ever been in a New Orleans kitchen, then you know that many a good Cajun dish starts with the "holy trinity":  celery, onions, and peppers.  Saute them until they are just right, and they become the cornerstone of many excellent meals. 

But you need all three to achieve just the right flavor balance.

As I learned from one of my early mentors, project management starts with its own "holy trinity":  Communication, visibility, and accountability.  All three of these together serve as the starter recipe for any successful project.

Communication is key.  As any certified project manager will tell you, a good PM will spend upwards of 90% of his or her time communicating with the team, the stakeholders, the users, and the executives.  As Emily Foshee notes,

A good project management system will provide a valuable mechanism to streamline communications with your customers and between your employees. It will help your employees complete each project phase on time and on budget, which will increase customer confidence and ultimately increase your company’s revenues.

Visibility is a forgotten element of project success.  If your project isn't hitting the right radar screens, then there will be nobody there to protect it when it hits road blocks.  Having (and using) a project dashboard report to demonstrate what projects are being tracked means that the focus will be on the right projects.  Chris Spagnuolo's dilemma on Agile/Scrum projects drives home the importance of visibility:

...Because the metrics are based on actuals being provided in near-real time by project team members, executives and customers can "peek" into the project at any given moment and know exactly what the situation is.  They don't need to wait for the weekly or monthly status reports.

Accountability is becoming a rare commodity in the workplace today.  It seems there are more and more excuses, acting in inverse proportion to results.  Creating a culture of holding people accountable for results (both in a positive and negative sense) is critical to getting things done.  As Bob Mitera comments:

As a former business owner and project manager...what if I was tired when I was supposed to be approving your pay check? Yeah...I thought so. Get to work.  If (your people) are accountable to themselves or their family...they will take action with or without you. Don't mistake passion for a job as loyalty.

Again, just as a Cajun cook needs all three elements of the holy trinity to make a successful meal, the project manager needs to channel all three elements of this holy trinity to make a successful project.  Missing any one of the three leads to something less flavorful.

Carpe Factum!

Spring Cleaning Your Project Archives

Spring_cleaningThe requirements and specifications drafted for your project solution.

The minutes from all of those project meetings.

The status reports, drafted weekly.

The change requests, approved or denied.

The project plan.

The business case... or project charter... or statement of work... whatever you use to define the project up front.

What happens to all of these things when you are done with your project?  Well, there are a couple of different approaches. 

Ending a project is like spring cleaning.  Things either get thrown away, go in the garage sale pile, or go into seasonal storage (to be brought out later when needed).  Unfortunately, many project managers treat all of the project documentation like one of the first two categories (dispose or never access again) instead of the third.

Saving your project files in an easily accessible location allows reuse for other project managers to learn from you and your project - the good and the bad.  It also diminishes rework on future projects.  ("Remember that great test plan that Fred wrote last year?  Yeah, use that as a template.")  You no longer have to reinvent the wheel.

So don't toss that documentation into the spring cleaning bin too quickly.  It may be useful after all.  Just find a way to store it effectively so others can access it.

Carpe Factum!

Bustin' My Buttons

Button_brokenI like to have my shirts professionally laundered.  For a couple of bucks, my dress shirts are washed, ironed, starched, and placed in neat little plastic wrapping (which is recycled as packing cushion when I need to mail my books someplace). 

There's nothing like the feeling of contentment when I put on a crisp clean shirt in the morning...

Except...

My one big pet peeve about dry cleaners and professional launderers is when they break a button and don't stop to replace it. 

My last dry cleaner, Reeds, did that religiously.  In the four years I used them as a laundry service, I maybe had one or two button issues.  The prior cleaner, whom I unceremoniously fired, was notorious for breaking or losing buttons from my shirts.  Worse, they were unapologetic about it.  So I switched to Reeds.  But now Reeds has closed their doors, and I'm forced to find a new dry cleaner. 

And with my first trip to the new cleaner, what am I finding on my shirts?  Broken buttons.  I think I'd rank "button condition" above starch level on my satisfaction scale for professionally laundered shirts.  You could say it's a "hot button" of mine (OK, bad pun, sorry).  I'll give the new cleaner a shot at fixing the issue by communicating to them how important this one criterion is to me.  If they don't fix it, I'll be shopping for another dry cleaner.

But let's tie this issue back to our projects.  What are the success criteria that define the quality of project completion?  We use terms like "user friendly" without giving specific criteria for meaning.  We talk about wanting things "as soon as possible" but don't tell people how we're defining the "possible" part. 

On some of my projects, the team will do a short exercise before we begin defining requirements.  I ask everyone on the team to define two terms:  "Cold weather" and "Small town."  The definitions come back all over the board, both in quantitative (below 32 degrees, under 5000 people) and qualitative (hat and glove weather, only has a Casey's) terms.  We then use this exercise to talk about being specific on defining our project solutions.

The blog, Neeru's Corner, agrees with the approach.  Guest blogger Jim Swanson nails the ambiguous language problem very well

The truth is, one of the surest ways to fail in requirements is to say to your users, "Give me your requirements," then stand back and "catch" them. Why doesn't this work? The stakeholders are experts in their domains. While the analyst probably has more expertise in the IT domain, the two speak different languages. The stakeholders truly do not understand exactly what IT needs to be able to develop an effective system for them.So the only way for a project to obtain comprehensive, correct, and complete requirements from all stakeholders is to truly elicit them. Elicit means to probe and understand the requirements, not just capture or gather them.The reality is that the quality of the requirements depends on the quality of the solicitation of them by the analysts.

So as you are defining your next project, take some time to work with all of the key stakeholders to better communicate and document your expectations.  And if you can recommend a great dry cleaner in the Urbandale vicinity, please let me know.

Carpe Factum!

Implied Complexity

RussspacepenI've always loved the story about the NASA pursuit to find the perfect pen for astronauts.  Independent businessman Paul Fisher spent one million dollars of his own money to develop a writing utensil that could be effectively used in space.  Wow!  What an impressive project!  Fisher must have felt so proud to have accomplished such a feat that would move the space program forward exponentially.  That is, of course, until it was publicized that the Russians had beaten them to it.  The Russians used pencils.

How about your project scope?  Are you making your project scope way too complex?  James P. MacLennan wrote a post advising project managers to keep things simple to avoid scope creep.  His comments made me smile:

Keep It Simple, Sir! Feature creep is the greatest enemy of the short-term project. Some features (like quality / testing) are not what you'd want to negotiate out of the project. Thinking about cutting short on documentation? You naughty, normal person ...

But how do you keep it simple?  How do you avoid complexity in your project scope?  How do you avoid adding too much too soon?  I like Rosa Say's approach.  Ask "why"... A LOT.  Asking the right question can lead to a much simpler project scope than asking a lot more of the wrong questions.  If NASA had just asked for a writing utensil that can work in space, they may have come up with the pencil solution.  Instead, they added a constraint (pen) which added complexity to the scope.

What questions do you need to ask about your projects to keep the complexity in check and prevent scope from getting out of hand?

Carpe Factum!

Does Your Project Get To Go On Spring Break?

Spring_break_guysIt's spring break!  Yea!  Get out the swim wear!  The suntan lotion!  The beverage of choice!  The warm breezes!  The beach!

What?

You say you can't?

You have to stay put and work on your project?  Worse yet, you have to work harder because everybody else is gone.  Bummer, dude.

Holidays can be the kiss of death to a project schedule.  I was reading the Manic Monkey blog the other day, and had to chuckle about this line:

Unfortunately with a very busy Christmas holiday all group members are slightly behind on the completion of their gremlin. This has therefore put us behind. We are now ensuring all modeling, texturing and rigging is completed by 1st February.

Here's a little trick I've used while planning some projects where there will be a holiday or a series of days (like spring break) where people will probably be gone.  You can do this on any project management software (my preference is MS Project).  Find the weeks where a substantial number of the project staff probably will be gone and block those days off as "non-working time."  I don't do this all the time.  For example, when every second counts, and the executives have passed down a "no vacation" rule for the staff, then I wouldn't recommend trying this.  However, if the project will be going for several months, it's important to remember that people have lives.

Project_plan_working_timeHere are some common dates/events I will consider blocking off:

  • Thanksgiving
  • Christmas and New Year's (last two weeks of the year)
  • Spring Break
  • Memorial Day Week
  • Independence Day Week
  • Labor Day Week

The benefits to the project can be phenomenal:

  • Allows the team to have a balanced life
  • Builds in contingency time without being obvious to anybody on the project (I don't tell people I'm doing this when I do - otherwise it can be perceived as an invitation to procrastinate)
  • Allows other team members/tasks to play catch up during these weeks when other project staff is gone
  • Takes reality into account.  People will be gone at certain times of the year.  Get over it.

Do you have other recommendations for introducting reality into your project planning?

Carpe Factum!

High Pressure Front

BlizzardAs I'm writing this, I'm thinking about the weather. 

Yesterday, it was 63 degrees and sunny and beautiful.  This morning, I woke up to four inches of snow and temperatures in the teens. 

It makes you wonder if Mother Nature is letting her geeky nephew, Clarence, intern in the weather department without adult supervision.  But we're Iowans.  We're hardy and resilient to change when it comes to climate.

Are your projects as resilient as Iowans are to changes in the environment? 

As we know, in business, things can change on a dime.  And while we joke about the weather ("wait five minutes; it'll change"), we have less of a sense of humor when it comes to our projects.  As Jim Garr writes in his Technology Services blog:

The real value here I think is to anticipate that change and then position yourself (in this case IT staff and technology inside MDC) to respond. Put the right people in the right places as much in advance of the "need" as you can...and the resulting impact will be a much smoother transition for ...almost everyone.

That's a challenge for many of us in the technology world...while many will profess that they embrace change and welcome it....I can tell you first hand that sometimes those words are nothing more that lip service. IT staffers as much as anyone else can be less than enthusiastic about being resilient in the face of change.

Jim has a point.  When I'm working with clients who are a little further along with their process maturity (i.e., they don't cry foul at the slightest hint of project rigor), I suggest setting up a "change triage process" in tandem with handling regular change control procedures. 

Do this during the planning phase, so you are not reacting to change while it is happening.  For those changes which come up suddenly, completely blindside you, and need immediate attention, try the following:

  • Establish your triage decision-makers.  Who are the people who can and should make quick decisions, and have the ability to read the signs to make the best decision for the project and its stakeholders?
  • Determine whether the change is controllable (can you avert or delay the change).  If you can buy yourself more time, then do it.  Move more controllable changes to your normal change control procedures.  Only critical environmental changes should move onto your triage team.
  • Determine how the change affects the scope and the schedule (note, I did not say cost).  Then think about the dollar value of the additional effort to make it happen, or the lost dollar value of a delay (i.e., opportunity cost of being late to market).  This is your triple constraint discussion.
  • Write up the tasks that need to happen in the first day and the first week.  Make assignments and set people loose to make them happen.  Then use this time to build out your other tasks to handle the change.  It may be that a revised project plan must be one of your first deliverables; however, on some changes, you will know what must be done before formal planning can occur.  Don't hold up a critical change because of the planning.
  • Keep the decision-making centralized to as few people as possible, but pull in subject matter experts to give you the information you need.  If you are under the gun, the last thing you need is decision-making by committee.  Bring in your experts, but make the final call.
  • Communicate to your stakeholders what is happening and why.  Don't leave your team or your customers in the dark.  Most people are understanding of changes that are outside your control.  What they want to know is that you are still in charge.

Doing these proactive steps can help you adapt quickly when the environment doesn't play nice.  Now I need to go shovel snow.

Carpe Factum!

Eat Your Veggies; Enforce Your Tasks

Eat_your_veggiesOne of the most valuable lessons of project management came as a child at the dinner table. 

Let's face it:  very few children like to eat their vegetables in this McDrive-Up world of fast food.  Until I was married, I honestly thought the four food groups were grease, fat, sodium, and cholesterol.  But all too often, because she knew it was good for us, my mom would serve us vegetables.

Mind you, to the typical eight-year-old, vegetables of any variety in any quality are often perceived as ... well... gross, at best.  But I learned to eat them quickly and get them out of the way.  Why?  Because as unpleasant as they were piled piping hot on my plate, they were absolutely unbearable if they were allowed to grow cold.  There was truly nothing worse on this planet.

On projects, we all have tasks that are unpleasant.  Nobody wants to get them done.  They may involve filing government paperwork or filling out permit applications or sorting through historic data to find one minuscule fact.  Tedium!  But... if left unchecked, that same task could end up taking twice as long and costing four times as much due to penalties, estimate overruns, fines and interest, or lost opportunities.

How much of a stickler do you need to be at enforcing deadlines?  Well, it depends on whether you actually like cold and slimy asparagus, whether you want your eggplant looking like over-exposed road-kill.  (Sorry, but the imagery was too good to pass up... I hope you weren't reading this around dinner time.)  Really, it depends on your consequence-tolerance level should you let deadline after deadline pass without penalty.

People are people, regardless of age.  I found a great new blog post by a teacher where she talks about her mentor telling her that assignment due dates should never be enforced: 

Students are faced with deadlines all the time. "You can not play with your friends until you put on a coat." "You have to earn your allowance money before you can go shopping." They watch their heat being turned off in their apartment because mom or dad couldn't pay the gas bill by the 15th. Coach makes them run an extra lap because they were the last one to practice. Auntie burned the pie again because she didn't take it out when the timer beeped.  We are a culture of deadlines; when time lapses past the deadline and the task is not completed direct and indirect consequences happen. Middle school students understand this, perhaps what they have a harder time understanding is how to function without the deadline.

And so it goes with project teams and tasks.  There is one tool that I use consistently on projects that keeps the number of late tasks to a relative minimum:  The Late Task Report.  I create a report that shows which tasks are late, when they were due, and who is responsible for completing them.  Then I distribute the report far and wide:  the entire project team, project management team, company executives, CNN, Fox News, Wall Street Journal, The Weather Channel.  The result?  The team members HATE having it published to executives that they are behind on tasks.  They complete the task as quickly and accurately as they can, without much additional prompting from me.  The report itself works as a kind of "bad cop" to motivate behavior.

So... how are you doing at eating your veggies in a timely fashion?  Is it a project that you can stomach?

Carpe Factum!

The Project Status Meeting

Project_meetingFor some reason, this recurring event seems to strike fear into the hearts of project managers everywhere.  What should be a relatively simple and straightforward activity becomes a fingernails-on-chalkboard, grind-to-a-screeching-halt, black-hole-of-time schedule vacuum.

Outside of the basic meeting management principles (communicating a firm agenda, holding dominating personalities at bay, or recording meaningful minutes), many project managers forget the basic purpose of the project status meeting:  to communicate project status.

But what does that mean, exactly?  I'm currently on a project, consulting with the project manager to keep things moving forward.  Our status meetings are a weekly 90-minute conference call (with a web-interface). 

We review two reports:  recently accomplished tasks (i.e., those done since the last status meeting) and the look-ahead report (those tasks slated to be started in the next three weeks).  We go through each report (which is sorted by work functions) line by line. 

The team manager gives a brief, non-redundant recap of the task, if necessary, updates any changes in date or status, and provides any additional issues.  Notes are captured and added back to the project plan for later reference.

In short, your status meeting should do three things:

  • Look back - what did we just do?
  • Look ahead - what are we about to do?
  • Look sideways - what can derail us?

Quick, simple, nobody gets hurt.  Are you running your project status meetings effectively?

Carpe Factum!

Flickr Photo credited to Tech2morrow

Your Wild Card Winners

Giants_patriots_2Go, New York Giants!  (I'm not a Patriots fan, as you may have read.)

Super Bowl XLII is now one for the history books.  The Manning Boys are both happy campers.

The question for you as a project manager is what to do with your unexpected wildcard projects.  Can they be turned into winners?  The answer, quite simply, is yes.  But it's a qualified yes.

As Harley Lovegrove writes in the Interim Manager's Forum Blog,

A well defined project that has its roots in good business sense, and that has only one objective to deliver: ‘real value to the client’, is the only project worth making space for. Cut back all the rest that pose the risk of getting in the way or interfering and give the good one all the attention and nourishment you can.

When it comes down to it, only the projects that were rigorously challenged before they were started, and where everyone gave 100% commitment to ensure their success, and were lead by a steering group that were resolute to sticking to the original objectives – are the only projects that turn out to be successful in the long term.

Easier said than done, right?  Not necessarily, it just means that (like the Giants' receivers) you as a leader have to keep your eye on the ball at all times. 

No absentee management.  No hit-and-run directions.  Those unexpected wildcard projects can be the sweetest wins of all for organizations.  I know that for me, the unexpected projects that come along that meet Harley's criteria above.  Focus.  Dedication.  Perseverence.  Winning.

It's a pretty cool formula for project (and football) victory.

Carpe Factum!

Office Politics And The Project Manager

Officepolitics You are a small business owner/manager.

You have a project you want done.

You've made assignments and set the vision.

So why isn't anything happening?  It might be that your organization is a victim of office politics, a case of passive-aggression in your company.  I've written numerous articles on my blog about office politics, and many people have used GUST in their career planning strategies.  Want to read more on the subject?  Check out www.office-politics.com.

The one constant problem with office politics is that 1) most people start the conflict themselves without realizing it and 2) most people don't realize that they are involved in a game until it is too late.  Celine over at the Pimp Your Work blog shared a great post about what to do when your team loses.  Office politics can cost your company thousands of dollars, and when it rears its ugly head on your projects, Celine shares some things to do to help your team cope:

  • Keep your spirits up
  • Find out what you could've done better
  • Show appreciation for everyone's efforts
  • Focus on how well the team worked
  • Look forward to the next challenge

As the business owner, if you have control over the circumstances that caused the loss, there are some additional things I'd like to suggest for you to do to mitigate the issue:

  • Determine the motives of the perpetrators - it may be that the office politics prevented you from doing something really stupid.
  • Figure out what can be salvaged - did office politics completely undermine your project?  Can anything be saved?
  • Establish safeguards for the future - determine how to leverage accountability to ensure that accomplishment can still occur.  Remove those who prevented your success earlier.

Carpe Factum!

Are They Shooting At Me Yet?

Swat_mirror_training_2One of the areas where I volunteer my time is as a photographer for the local police SWAT team. 

It's a win-win relationship. 

I take pictures of them while they are in training scenarios and drills that their team leaders can use later for development purposes.  They are providing me with endless subject matter for my next book.  And, as volunteer opportunities go, I don't think I'll ever be too old to hang out with a bunch of guys in camo sporting heavy fire power.

Last week, I was observing the SWAT drill training on room entries.  One tool that the SWAT operators need is the mirror extension.  This allows them to see into a room before they enter (and if the mirror gets shot by the bad guy, at least it is replaceable).

Project management is a lot like that.  We're entering unknown territory, and we don't know what the consequences will be if we go through the door (i.e., complete the project). 

But we do have a mirror extension.  It's called "requirements and scope planning."  Just like my SWAT buddies have to measure and interpret what is going on around the corner, you have to measure and interpret what's going on at the end of your project.  But you have to be able to do it while you are still at the beginning.  And you have to be careful to aim your mirror correctly to ensure you are measuring the right things.  It takes a lot of foresight, as Rich Maltzman from the Scope Crepe blog states:

What I am saying is that it makes sense to be extremely thoughtful and careful when establishing the measurements and very important to consider the intangibles. I know that "you cannot fix what you don't measure", but you also must be aware of what you cannot measure and account for it in the mix.

In defining your requirements, you have to mentally go forward, then look in your rear view mirror and mentally drive backward through your project, define your route (plan your scope), and then actually drive forward.  Confusing?  You bet.  However, a lot of project managers and teams just rush forward through the door and that is where the "bad guys of project management" start shooting at them:  Scope Creep, Poor Leadership, Competing Resources, Unclear Objectives.

Think about what you want to accomplish, then stick your extension mirror out to see if it is a safe route to pursue.

Carpe Factum!

Caucus or Carcass

DefeatThe Iowa Caucuses of 2008 are now history.  Congratulations to Barack Obama and Mike Huckabee on their wins.

Chris Dodd and Joe Biden have already "left the building."  One can expect others to start dropping like flies, too, since there were quite a few "single digit" vote garnerers out there.  It will be interesting to see the "candidacy projects" begin to get cancelled as funds and support run out.

A lot of people don't understand how and when to cancel a project.  Some projects continue on for years and years without accountability or deterimination.  There are some projects in Iowa's largest employers that have gone on for years without ever producing a major deliverable.

A lot of the problem with this decision process is having the right information early enough in the project.  As Peter Stevens said in his blog:

You can react. You can identify the problem and make adjustments. Why is the development proceeding so slowly? Are there enough people? Are they the right people? Maybe you can reduce the scope and still achieve your business goals. Maybe your developers are being distracted by other tasks.

He continues by adding:

Once management has learned that they have control, can react and can prevent disaster long before it occurs, they will no longer be tempted to kill the messenger. In fact, they will welcome the messenger and appreciate the methodology, because early warnings will ensure that management looks good when the project comes to a successful and timely conclusion.

So cancelling a project is about having the right information at the right time to react appropriately... to determine whether corrective action can be taken.  Sort of like being the campaign manager for Duncan Hunter.  Using the information available to make intelligent decisions is critical.  Part of the problem is that the decision-makers have never been availed of the accurate information about the project.  That leads to a lack of accountability within the project.

So ask yourself if you have the following information available:

  • A list of key deliverables associated with the project
  • The target dates of major milestones
  • The budget (actual and planned) associated with the milestones and deliverables
  • The resources accountable for completing each deliverable.
  • The risks associated with each deliverable as well as the project as a whole.

If you can track this information, you will know whether your project is worth continuing.  It will keep you out of the "loser" category and help ensure your project is on the winning campaign trail.

Carpe Factum!

Are Your Projects Ready For Year-End?

HNew_years_toastave you returned all of your gifts?  Has your indigestion from over-eating cleared up yet?  Are your Christmas Decorations stored away for another year?  Have you made your New Year's Eve plans?  Are your projects ready?

Projects?  Year-end?

Yes, especially at year-end.  This is a great time to assess the health and status of your organization's projects.  It's an opportunity to set New Year's resolutions for the sake of your company's accomplishments.

Chrissy over at the Executive Assistant's Toolbox posted a great article about preparing for your annual review.  There are some useful year-end checklist points which can be extrapolated to doing an annual review on your projects as well.

At the Project Level:

  1. For completed projects, did they end on time, within budget, and with a significant number of the promised features?  (If not, find out WHY.  See if there are repeating trends across projects.)
  2. For current projects, is it on track (same criteria as above)?  Again, dig a little deeper if the answer is no.  Take corrective action on the problems that are preventing your projects from being successful (and it may mean removing people, as unpleasant as that may sound).
  3. For current projects, is regular communication occurring?  If 70-90% of a project manager's job is communication, are you as the business owner receiving meaningful status reports?  Is the team playing nice in the sandbox?  Do your clients and suppliers know what is going on?
  4. For current projects, is there a baselined and actively updated PROJECT PLAN?  If not, stop work until there is one.
  5. For pending projects, is there a BUSINESS CASE (or project charter or statement of work or whatever you want to call it)?  Bottom line, is some document being created which outlines why this idea should be a project?

At the Portfolio Level

  1. Are all of the projects being tracked collectively as well as individually?  Do you know how much of your annual budget is going toward project activity?
  2. Do you have a dashboard in place which gives you a quick-at-a-glance visual of the project activity and performance?
  3. Are your resources aligned to the right projects at the right times?  How many stops-and-starts are occurring across your project portfolio?
  4. Are you tracking cancelled and rejected projects, and the reasons for them?
  5. Are you identifying and tracking trends in project success and rewarding those responsible?

As you approach 2008, assess your project activity regularly to avoid surprises when it's time to look at 2009.

Carpe Factum!

This site is intended for informational and conversational purposes, not to provide specific legal, investment, or tax advice.  Articles and opinions posted here are those of the author(s). Links to and from other sites are for informational purposes and are not an endorsement by this site’s sponsor.