Loving the Devs OR A Little Appreciation and Trust Goes a Long Way

Developers get a bad rap from us IT PMs.

We IT PMs have a sort of prevailing wisdom about dealing with the ‘devs’. We even talk about it in our job interviews as a known issue; this idea that Devs are cantankerous arrogant curmudgeons, and we need to have certain skills as PMs to navigate through Dev incurred roadblocks to timelines.

Well, I’ve worked with and been friends with Devs for a long time and I think it’s time we think a bit differently about them. From what I’ve seen, Devs have always been good to me (made deadlines, stuck to process, built incredible things) when I’ve thought of them, and given them high regard.

I think any PM will see an improvement in Dev-Pm relations if you remember and adapt to the following:

Appreciate The Knowledge

Requirements become design and merge with the human skill of the builder/artisan to become something usable and beautiful

Developers are  like skilled artisans; people who shape, and mold an idea into something concrete, movable, usable. We respect someone who, for example, builds a beautiful table, because we understand that the ability to merge art and function is unique and rare. Perhaps because there is so much work, and so many developers, we tend to down play the work they actually do.

With an artisan point of view, we should approach developers with an appreciation for their knowledge. This attitude manifests itself when we interpret questions around requirements not as stone walling, but instead, a desire to build the best thing possible.

Artisans tend to develop a sense of pride in their creation. We should recognize that when we shift gears too suddenly in requirements, that thing in which pride was taken, has to be tabled. There is some kind of human cost to this, a disappointment. Multiple disappointments can lead to bitterness. As PMs we should recognize this sensitivity. Our role in controlling the process and QAing and ensuring good requirements is key to minimizing this phenomena.

Trust the Delivery

I approach that edge of the full elaboration of requirements and the beginning of the magical transformation into something functional carefully.   As a team, we want to explain the design, but relax and step back slightly to allow the technical ability to form idea into function to show itself and flourish.

I think a lot of PMs have a hard time letting go at this point. We often want to know the exact details of how something will be built. So we have to employ trust and allow the development team to prove that they can deliver. Paradoxically employing trust, even if things arrive a little late, serves to open up the channels of communication about the details.

It’s ok…let go!

I learned this directly from a dev manager when he suggested that instead of questioning why something was done by a certain date, I instead inquire about the complexity of an item. The implication of ‘is this more complex than originally thought’ is that the developer is doing their job. The implication of ‘why isn’t this done’ is that the developer is not doing their job. Subtly of approach respects the individual and lends towards a better delivery.

Give em a say in the Process

Contrary to popular belief, I think most developers actually like process. I’ve worked with dev teams who’ve initially resisted process become dev teams who champion process. The win for the developer is when process produces good requirements, be they requirements documents, or super clear user stories with well thought out acceptance criteria. The other win for process is when the process keeps WIP at some kind of sanity level to allows the developer to do the kind of work they take pride in, and the team to trust the delivery. Monitoring both – clear requirements and scope sanity – will be an immediate win to reducing barriers to process.

Especially when it comes to code migration process, we can really engage developers. Let them create the process while providing guidance that the process should be simple, clear, clearly elaborate roles and serves to ensure traceability. PMs can help by then documenting what the developers agreed to, helping to shore up any holes in the process, and then acting as an oversight on that process. The key is it’s their process, not something that was dropped on top of them.

Course, those three things, appreciation,  trust and communication are the basis of all good human interaction.  PMs, let’s do what we can to make sure that when it comes to developers, we employ these tools to become partners, not antagonists.

 

Advertisements

I Plan to Learn From the Best – Attend the PM Telesummit March 8-10

All I’m thinking about this week is learning from the best.

And that’s what I’m gonna do March 8-11 at the PM Telesummit.

I know these speakers are going to be gooooood.  How?  I’ve been following most of them for about a year on Twitter and I also read their blogs and I know they know thier stuff.

Like Todd Williams, who just finished his book Rescue the Problem Project and will be speaking on Improving Project Inception.  Guranteed Todd’s going to provide those tips that only a thorughly seasoned PM can provide, direct from the front lines of project failure. Who better to tell ya how to get it up and running right, than the person who deals with the failings of bad starts all the time.

Like Geoff Crane, who is going to get real with all us PMs who think we’re perfect (ahem..that wouldn’t be lil old me) with his presentation on the Soft Skills Salsa: An Examinaition of Destructive Behaviors in Project Managers.

Ohh..ouch…tell it!

Here’s the full line up

Tuesday March 8, 2011


Time Session # Speaker Topic
08:00 AM – 09:00 AM Session 1 Rick Morris Stop Playing Games! A Project Manager’s Guide to Successfully Navigating Organizational Politics
09:00 AM – 09:15 AM Break
09:15 AM – 10:15 AM Session 2 Dana Brownlee The Secrets to Running Project Status Meetings that WORK!!
10:15 AM – 10:30 AM Break
10:30 AM – 11:30 AM Session 3 Jason Fair Agile in large Enterprise System Integration projects
11:30 AM – 11:45 AM Break
11:45 AM – 12:45 PM Session 4 Todd Williams Improving Project Inception
12:45 AM – 01:00 PM Break
01:00 PM – 02:00 PM Session 5 Traci Duez Change is Impossible Unless You Change Your Mind

Wednesday March 9, 2011


Time Session # Speaker Topic
08:00 AM – 09:00 AM Session 6 Dr. Steven Flannes Recognizing and Resolving Project Conflict
09:00 AM – 09:15 AM Break
09:15 AM – 10:15 AM Session 7 Steve Martin Consulting Secrets for Project Managers
10:15 AM – 10:30 AM Break
10:30 AM – 11:30 AM Session 8 Geoff Crane The Soft Skill Salsa: An Examination of Destructive Behaviors in Project Managers
11:30 AM – 11:45 AM Break
11:45 AM – 12:45 PM Session 9 Peter Taylor The Art of Productive Laziness
12:45 AM – 01:00 PM Break
01:00 PM – 02:00 PM Session 10 Tres Roeder A Sixth Sense for Project Management
02:00 PM – 02:15 PM Break
02:15 PM – 03:15 PM Bonus Session Dr. Ginger Levin Building and Maintaining Relationships and Making Effective Decisions

Thursday March 10, 2011


Time Session # Speaker Topic
08:00 AM – 09:00 AM Session 11 Richard B. Sheridan Agile and the Business Value of Joy
09:00 AM – 09:15 AM Break
09:15 AM – 10:15 AM Session 12 Patricia Garofano Look before you Leap: Managing the Successful Vendor Transition Project
10:15 AM – 10:30 AM Break
10:30 AM – 11:30 AM Session 13 Bernardo Tirado How Does Understanding Human Behavior Increase Your Project Success Rate?
11:30 AM – 11:45 AM Break
11:45 AM – 12:45 PM Session 14 Brian Munroe An overview of troubled projects and how we deal with them
12:45 AM – 01:00 PM Break
01:00 PM – 02:00 PM Session 15 Dr. Margery Mayer Global Communications; what does it means in today’s businesss


Don’t miss this!  You don’t have to leave the comfort of your cubicle ’cause this is 2011 and it’s streaming.  You can even catch some wisdom between your daily stand-up and updating your burndown chart.

If you haven’t registered yet…do so right here Register Now!

What Matters is What you Think and Believe OR Stay Optimistic Young Padawan

Funny how those times when I’m in a incredibly bad mood are also those times when I find the most inspirational stuff.

As you  can tell from my previous post, I’m feeling a certain sense of ennui at the difficulties I’m facing with the human mindset of the working world.    And in the Project Management we talk alot about a bunch of different ways to get people to do stuff.  Sometimes, we approach that dicey middle ground between manager and psychologist where we must deal with human pathology and cognition. Today’s blog post from Harvard Business Review blogger Dan Palotta discusses this phenom; specifically how the human element (drug addiction, infidelity, etc.) effects the business element.

I don’t have any answers except to say that,

we’ve got to be more careful with our mindset.

I’m not a religious person but I do like this quote from the Bible

“Guard your heart above all else, for it determines the course of your life.” Proverbs 4:23

I haven’t made my new years PM resolution yet.  Last year, it was to be able to lead with less fire, and more kindness.  I think I’ve made progress, but still something to work on.  This year, my resolution is thus:

Guard my Optimism at All Cost

This year I will maintain my optimism and believe fully:

Projects can be successful

People can be delightful to work with

Work can be Fruitful and Enjoyable

Cultures that suck can change

Projects that are dying can be resurrected

If we don’t believe it and we don’t imagine it, that’s why we aren’t living it.

So believe it!

Here’s what matters, and  I don’t need to describe it becuase Seth Godin et al. already has.  Highly Highly Highly recommend you read  and memorize this book What Matters Now.

My favorite is from Huge MacLeod  on Meaning.

"Meaning" from Seth Godin's What Matters Now

Ok – NOW I’m ready to say HAPPY NEW YEAR and wishing you Happy Projects, Successful Outcomes, and Joyful Teams!

It's an Identity Thing – Losing Power in the new Agile Regime

My first scrum experience was terrifying.

Fresh from passing my PMP and ready for full application of the method, I decided to tackle my problem project by properly notifying the Director of Projects that the Project Sponsor was not involved, and the team could not do their work, and we needed him to come down hard on the sponsor.

Lord Dashing, Earl of Project Management

Lord Dashing and Handsome, Earl of Project Management

His response was to flip the whole project into Agile-Scrum. And I transitioned immediately from a Project Manager to a Scrum Master.

Models and methods aside, what really freaked me out, was that I had, overnight, lost power. I was no longer the final decision maker, the hub of communications, the control point for requirements flow, the master of my own domain.

I hated it.

For a while at least…but I couldn’t deny that the project sponsor was more involved, the BA started to shine in her own right, and the guy who never got anything done, was suddenly held accountable.

So…it worked. And the project moved forward.

Here’s the thing. I think there’s a lot of PMs out there who’ve been raised in the traditional Aristocratic leadership model of Project Management and are deathly afraid, as I was, of losing power to the Consensus Democracy that is Agile.

Just looking at the visual of a traditional project team, It’s apparent that the PM is pretty important. They get paid more, they have decision making authority, they can make the lives of the project team miserable and it takes and act of congress to move em out if they’re bad (especially in the government).

TPM2

Agile teams, however, form as needed, and generally pick the leader for that particular project by consensus. And when a new project starts, a new leader is chosen, and the old leader steps down.

Agile can even be an identity challenge for project sponsors. In traditional Project Management, the Project Sponsor is like Sauron, the All Seeing Eye, the Finance and Banking Committee, the School Principal – you get me. The one you’re scared of/have to please.

In Agile, the Project Sponsor is a) an equal and b) a obstacle breaking resource for the team. They’re more like Consigilare’s, or Ambassadors. Honored for their ability to break through impasses and communicate information that protects the team.

And then there’s Control. Control’s a big piece in traditional Project Management – as in IPECC (initiation, planning, execution, control, and closing). Controlled change is the key, and a change management process is set up to minimize chaos, which is a really really bad thing. The PM gains power by managing changes, deciding which changes to communicate to the team, and having some decision making authority on those changes.

But in Agile, change is welcomed and chaos is expected. Change is discussed in every meeting and the team together decides how to handle it. The PM is no longer sitting on a change board, deciding where to fit changes into schedule and then telling the team. No, the scrum master is now simply facilitating a team conversation as soon as the change comes up. There’s no waiting, there’s no control of the change flow, there’s no independent decisioning of who will implement the change. Again, the PM loses power.

Assuming form is function, look at the difference between the two structures. The form of traditional PM project teams is segregated and hierarchical with clearly defined channels of communication. The Agile team form looks more like a cell. Remember the cellular structures from high school bio? The form of the cell is for the facilitation of processes in an independent organism. Each cellular sub process is just as important to the function of the cell as the other. The project sponsor becomes the cellular receptor for communication with other cells and the larger body as a whole.

Typical Agile Project Team Structure

Since this is a highly politicized year, let’s put on our government comparison hats from Political Science 101.

Comparison Between Agile and Traditional Project Management

To me, the Agile side looks like Consensus Democracy while the Traditional Project Management side looks like Aristocracy.

Traditional PMs (me included) have got to adjust. We collectively can’t stand that the new generation doesn’t have a deep respect for our gazillion years of experience and know how. We don’t like that they think they are equal to us. And this is because we’ve been operating under an Aristocratic model. We think of young bucks and does as the uninitiated, forever ‘in waiting’ until we deem them acceptable. How dare they think they can even talk to us like that!

But those young bucks and does are under a different paradigm. They’ve seen the fallacies and glorious fall of the Business Aristocratic model in their parents jobs, and they know that the world needs them and is their equal. Guess what, they don’t have a big problem with Agile. Their companies are doing really really well (ie Google, Facebook) and they get things done…fast.

Here’s the deal. Us elders have got to adjust (by ‘elder‘ I mean 35+). This is part of PM evolution. Or maybe PM Revolution. As the Aristocracy is booted from power, and Consensus Democracy shows itself to be way more effective, we are going to lose our edge if we don’t surrender our identity as the big boss.

Fed Gov to get tough on Project Management Practices on Key Projects

July 28 2010: OMB Director Peter Orszag issues this memorandum with key points as follows:

OMB is “…launching an IT Project Management Reform”  by

OMB Cracks the Whip

OMB Cracks the Whip

  1. Halting the issuance of new task order for all financial system projects
  2. Setting forth new guidelines for project management for financial systems

These new principals will include:

“Splitting projects into smaller, simpler segments with clear deliverables”,  focusing on  “critical business needs first”, and conducting  “Ongoing transparent project oversight”

Amen.

And starting now, “Agencies that have previously completed modernization projects must refrain from moving into additional rounds of planning and development until OMB has approved a revised implementation plan for those projects consistent with this guidance.”  And “..projects have to submit a self-evaluation and deliverables will be revised down to 90-120 days.”

Wow. 

The top 30 problem child projects will undergo rigorous review as part of a three step process described onOrszag’s blog:

First, New task order issuance is halted and new project plans must be submitted that adhere to the new principals.  Ie – Make em smaller, leaner, deliverable based.

Second, Fed CIO Vivek Kundra will evaluate the plans, and decide who will be part of the new budget. Ie – Some programs will get cut.

Third, OMB’s Jeff Zeints will present recommendations for new IT procurement and management processes. Ie – Failing programs will have new process/procedures to follow.

And let’s get clear with the problem children projects.  They are:

Department of Agriculture Web-based Supply Chain Management (WBSCM) $278.0 M
Department of Commerce BIS ECASS2000+ $64.5 M
Department of Commerce USPTO Patent File Wrapper (PFW) Program $276.5 M
Department of Defense Expeditionary Combat Support System (ECSS) $2.0 B
Department of Defense* Future Pay and Personnel System (FPPS) – U.S. Navy *
Department of Defense* Integrated Pay and Personnel System – Army (IPPS-A) – U.S. Army *
Department of Defense* Air Force Integrated Pay and Personnel System (AF-IPPS) – U.S. Air Force *
Department of Health and Human Services FDA MedWatch Plus $78.0 M
Department of Homeland Security NFIP Technology Systems & Services (2011) $101.2 M
Department of Homeland Security Homeland Security Information Network (HSIN) $473.4 M
Department of Homeland Security Automated Commercial Environment / International Trade Data System (ACE / ITDS) $4.5 B
Department of Housing and Urban Development HUD Transformation Initiatives $312.2 M
Department of the Interior Consolidated Infrastructure Automation Telecomm $7.6 B
Department of the Interior Incident Management Analysis and Reporting System (IMARS) $122.8 M
Department of Justice FBI Next Generation Identification (NGI) $3.4 B
Department of Justice FBI SENTINEL $556.9 M
Department of Justice JMD Litigation Case Management System (LCMS) $128.3 M
Department of Transportation En Route Automation Modernization (ERAM) $3.7 B
Department of the Treasury Consolidated Enterprise Identity Management (EIdM) $432.5 M
Department of the Treasury IT Infrastructure Telecommunications ITT TSS $2.8 B
Department of Veterans Affairs Benefits 21st Century Paperless Delivery of Veterans Benefits $579.2 M
Department of Veterans Affairs Medical 21st Century HealtheVet Pharmacy $163.9 M
General Services Administration Federal Supply Service 19 $376.2 M
National Archives and Records Administration Electronic Records Archives (ERA) Program $994.9 M
Office of Personnel Management Retirement Systems Modernization $136.0 M
Social Security Administration Citizen Access Routing Enterprise 2020 (CARE 2020) $599.3 M

 

First thoughts:

1. Hope it works.

2. Think that the new guidelines Jeff Zeints is prepping should incorporate lessons from the UK National Audit Office’s six reasons for project failure.  Specifically, separate intent from scope, emphasize communication over deliverables that represent communication, allow flexibility in contract scoping by describing the ‘what’ and not the ‘how’ in the contract.  Finally, remove the IMS as a contract deliverable.  Describe deliverables in terms of business capabilities, not project management deliverables.  A fancy schedule does not a project make.

Thoughts?

The Seasoned PM OR Why Failure is Your Friend

The worst thing any executive can do is put an un-seasoned Project Manager at the helm of a large, complex project.   “Seasoned” is a funny word in that everyone uses it, but its definition is varied and broad.  We’ve all met and suffered under un-seasoned PMs, and there’s lots of literature about poor performers who kill projects. But what about those great PM heros, the legend we all want to work for, or under whom you finally were able to shine, or who took a failing team and turned them around?

Solid and Seasoned

“Seasoned” implies time.  And that’s because time implies experience but more so, time implies great changes and hardship.  A tree that’s only withstood spring-like weather is not “seasoned”.  A great oak that has withstood winter after winter, sudden changes, harsh winds, intense heat, and deadly parasites is “seasoned”.   We also use “seasoned” when referring to pots that have been used so much that cooking in them imparts a certain flavor or ‘seasoning’ to the food.  In effect, all the food that’s ever been cooked in that pot, even dishes that have burned,  have left a mark that adds tremendous value in subtle ways to any future dish.

I can’t speak for every trait of the seasonsed PM, but I can say that I’ve noticed, unilaterally, that the great PMs I’ve worked for have all possessed the following four character traits.

Seasoned PMs have encyclopedic knowledge of the project  The seasoned PM knows that the devil is in the details.   She understands that knowledge is like a sword that cuts through obfuscation and clarifies mistakes to right the ship.  Handling this sword of knowledge like a master fencer, the seasoned PM can recite the risk register by memory, has delved deep into all the issues, reads all the documentation, grasps predecessor and successor relationships faster than anyone else,  and makes the connections others don’t see.  In fact, she understands that she is the ‘connection maker’ for the project.  Someone has be able to take both the ground level assessment and them zoom out to get the birds-eye view, and keenly spot trouble areas before molehills become mountains.  A seasoned PM sees this important task as her innate duty to the project.

Seasoned PMs are patient with the faults of others The seasoned PM understands the rule of try and try again.   The rule is that no one, and no team,  ever really gets it right the first time.  And the corollary is that sometimes people will get things really really wrong.   The seasoned PM doesn’t harp on failure.    He’s interested in why something didn’t work only to fold that understanding back into future project assumptions.    In team meetings, he won’t point fingers and blame team members for failure, rather, he’ll encourage a healthy second attempt.  He realizes that the deep dive into a problem is not about discovering and unearthing the personal failings of the people, but about the causal analysis of facts, that leads to discovery of the nuggets of learning inherent in the failing.

Seasoned PMs hear the facts despite the delivery Seasoned PMs don’t get caught in how people say things.  In fact, the seasoned PM can sometimes appear to be completely unphased by vehement emotions.   She knows that when people are highly emotionally charged, focusing on their delivery only makes them more strident.   So she never tells people to ‘calm down’ or ‘watch your tone’.   She knows that if someone is so stressed that they’ve lost their professionalism in emotion, that there is indeed a systematic problem somewhere in the project that has to be addressed, and she focuses on finding that issue.  Her self-confidence is intact, forged over time, and that enables her to exhibit a calmness even in the face of strident emotion.

Seasoned PMs have been broken in by failure In mythology, the hero must overcome some major setback.  This is because the setback serves two purposes.  First, it inculcates humility.  Failure proves to the hero that despite his many talents, he is, in fact, as capable as failing as anyone else.   No one person can control everything and failure moves the hero from the one person savior who takes all the glory to the leader behind the scenes who works in concert and harmony with others.  Second, it sharpens the hero’s key skill.  Every hero has a unique talent.  When you’ve been humiliated by defeat, you tend to be stripped of all the things that were inconsequential, burned by fire, if you will, to that which is your true essence.    That unique skill will survive the struggle and is strengthened by failure, so when the hero emerges, he is quite certain of what he carry with him everywhere.

When I was in my early 30’s I used to be so proud of the fact that I had been so successful.  But now, if you ask me what my best projects were, I’ll tell you about my flops, or the people who drove me nuts, or the team that was a full of misfits.  I’ve reduced a measure of pride, gained a measure of humility, learned a measure of respect for others…and that’s what makes me successful now. All this to say that if you have experienced a set-back, or a project failure, use it to develop your flavor of who you are.    These are your golden opportunities to grow into a great, seasoned PM and Lord knows we need em!

Project Management is Stressful

Sometimes, life is pretty darn stressful.

I think that as Project Managers we don’t really take into account just how much is really on our shoulders, and how being a PM creeps into our everyday life, maybe to an extent only experienced by senior executives in organizations (but without the executive pay).

On Time and On Schedule!

On Time and On Schedule!

Does this sound familiar?

1.You wake up in the middle of the night and the first thing on your mind is an issue with the project schedule.

2. Your workday starts with a plan that dissolves within the first five minutes due to project issues.

3. You wind up doing what you were going to do during the day, at night and on weekends.

I don’t know about you, but I find that I have to turn off “Michiko as Project Manager” consciously, as soon as I walk in the house.   This week my task junkyness has run amok with a wake up at 3am scenario just to finish up a WBS and Schedule for a proposal that cropped up suddenly. This lead me to post to my facebook status “I am not my career” in subconscious revolt.

Somehow, there’s got to be balance.

So I started reading and found a good book on the PMI 24X7 book site (if you’re up to date with your PMI membership dues, you get this site for free – lots of good stuff). “Essential People Skills for Project Managers” by Steven Flannes and Ginger Levin. This is an easy read with lots of honest good info, but in particular their Chapter on Stress Management for the Project Manager is filled with solid recommendations for dealing with stress.   They’ve diveyed up sources of stress which makes it a bit easier to understand.

Essential People Skills for Project Managers

Essential People Skills for Project Managers

Stress From the Position These are stressors inherent to being a project manager, meaning before you’ve even lifted a finger you’re first day on the job – you can count these things to stress you out. Things like ultimate responsibility, dealing with people issues, finding resources, leading without driving everybody crazy. It’s not like you get to sit around and wait for stuff to happen, or someone to tell you what to do. You’d better drive the train or you’re out of a job. Even if the world was perfect and people ran around singing like Disney characters, the job itself would still be stressful.

Stress from the Organization
But the world is not perfect…
Organizations have their own dysfunctions; leaders who don’t like each other, entrenched silos, values that may be a little askew or even unhealthy. As the PM, you don’t get to watch peacefully, grab some popcorn and enjoy the reality show. No, somehow you’ve got to dive right in and pull out whatever good you can from the muck. No armchair quarterback for you, buddy.

Stress from People
And people are not perfect…..
Sounds like a truism, but you will face toxic people that you have to lead, that you have to report to, that you have get resources from. There will be bullies, and narcissists, and wimps, and perfectionists. And guess what? Whatever traits that you have (because you have some things that get activated too), will interact with traits of others for quite interesting and colorful combinations.

Bottom Line: Project Management is stressful

Over the years I’ve found that we all have expectations in these three areas; job expectations, organizational expectations and people expectations. Usually, we carry more unrealistic expectations in one area than another.

For example, I always have unrealistic people expectations. For some reasons, maybe because I watched a lot of musicals as a kid, I think that the world is Kumbaya and why can’t we all get along. Then when someone shows their colors I’m like so shocked!!

I’ve never had a problem with job expectations – in fact, I sort of relish the responsibilities and stress of the job itself. Organizational dynamics don’t faze me either. But I’ve had friends who really have a hard time dealing with the responsibility of project management (“God, I hate having to always tell people over and over again why we are doing this project.”) or with the organization (“I cannot believe all these people care about around here is making money, that sickens me!”).

What to do about stress?

Level Set I would say, first thing, get real about the job. Make sure your expectations align with reality. Then you can go in with an appropriate level set in your mind and not be shocked when crazy things happen.

Explore why things bug you If you get bugged out about something, ask yourself why. Do a little introspection. How do you view yourself? What happens to you when your view of yourself gets messed with?

Develop a well rounded life I think this is the most important piece. We are not our careers. Martin Seligman and the Positive Psychology folks at UPENN suggest developing “holistic fitness”, that is not just physical fitness, but fitness in our emotional, social, spiritual lives. The Army has picked up on this and created a whole program around it called Comprehensive Soldier Fitness (CSF).

CSF Poster

CSF Poster

The idea is that when you develop ‘holistic fitness’, you are more resilient and can transform bad happenings into positive outcomes. There’s lots of good material on this like ‘The Resiliency Factor: Seven Essential Skills fo Overcoming Life’s Inevitable Obstacles’ by Karen Reivich and Andrew Shatte. Or check out the CSF page on Facebook for more available tips like these 10 Ways to Build Resilience:

1. Make connections.
2. Help yourself by helping others.
3. Maintain a daily routine.
4. Take care of yourself.
5. Give yourself a “news” break.
6. Have a plan.
7. Prepare a security kit
8. Nurture a positive view of yourself.
9. Keep things in perspective.
10. Maintain a hopeful outlook.

I used to thing these kind of things were kind of corny – like I had more important things to do, like updating my change control lists, and preparing executive briefs.  But hey, if soldiers are doing this, then maybe its not such a hokey thing after all.  I’m starting to learn the value of a day at the museums with the family.  And ironically, I’m learning that it’s this well rounded life that helps us to be great project managers.