Making Fostering Connection A Primary Project Goal

Fostering good water may be just as, or more important than, swimming in the same direction towards a goal

“Fish discover water last…In a similar way, we… discover trust last.”

Steven Covey, the Speed of Trust

My church is starting an effort to improve the way we use technology to communicate our story. I volunteered as the PM for the effort and we had our first meeting last week. Now, typically in a project visioning session, the idea is to gather as much information as you can from the project sponsor, and then plan out how to analyze the current state, molding the future work towards the sponsors vision. So that was my expectation going into the meeting.

I started it off by asking the Pastor to give his vision, and then, as I am used to, we started working through ideas to bring that vision to reality. One team member suggested a brainstorming session to gather more data about what church go-ers wanted, which I thought was the right and proper next step.

“Great idea!” I said. “I wonder what we should do to make that…”

“Well,” my Pastor interrupted. “An effort like that may be a bit of a ways off, you may want to hold on for a few months to allow the team to gel before you take on such an endeavor.”

My head cocked to one side, like Data from Next Generation, pondering new information that I hadn’t considered before.

Interesting, I thought to myself. Usually, and you the PM reader will appreciate this, we want to show progress on a project pretty much as soon as possible. So here was a project sponsor elevating a previously unstated goal – good team dynamics – higher than progress on project deliverables.

Then I realized that for him, and for churches in general, fostering connection is the goal. Creating connection that lasts so people feel part of a healthy, enjoyable group is primary, the problem to which we apply that connected team focus, is secondary.

This is a major mind shift for me.

In the business world, the project goal is always primary, and good team dynamics are a method, a means to an end, not a goal.  Now here was a suggestion to flip that; the project goal is good team dynamics, and  the problem to be solved is the method.

But now that I think about it, the only thing that really lasts from job to job, are the residual good feelings and warm connection to people with whom I’ve had great team dynamics, where I’ve fostered connections that I value, and that make me feel less alone in the world.

Fun, connection..a necessary goal on any project

These are the people with whom if we teamed together again, I’m absolutely sure that anything we work on would be successful.

Conversely, with those people who I haven’t been able to foster a good connection, I can tell you that if we had to work on a team again, whatever we had to build would come out slower, and probably not be as fruitful.

So what if we made foster connection the primary goal of any project we work on?

In a project charter we would go from this kind of success statement…

This project will be a success if web visitors immediately understand the purpose and mission of the church

to this kind of statement…

This project will be a success if team members develop a great working relationship and collaboratively build a site where web visitors immediately understand the purpose and mission of the church

How would we act differently? What would we do at the beginning of projects that we wouldn’t normally do if building great working relationships was a stated goal?

And most importantly what impact would this have on our success?

So interestingly enough, the church team walked away with a group decision to analyze what currently exists, which is what I would have suggested and pushed for from the beginning of the meeting.

But because my Pastor got me thinking early in the meeting about team, I pulled back on my directiveness, and relaxed any expectation for actually walking out of the meeting with any ‘real’ work done.

The ‘real’ work, I figured, was to allow team members to build relationships through dialogue and sharing of ideas. So my facilitation focused on that.

And paradoxically enough, we wound up with the same end result that I would’ve pushed for, without it being just my idea, without me telling people what to do and with a sense that this was our decision, which has quickly moved us forward towards feeling like a cohesive unit.

For me, a PM used to pushing forward with plans, it seemed almost too easy. And as people walked away buoyed by the interactions, expressing “good meeting” to each other, I almost felt like I had done nothing but fostered connection.

And yet, everything else is getting done.



I see Forest AND Trees – ya’ll still want that?

I don’t know, maybe it’s me, but I’ve been sort of wondering where the PM fits in anymore in a self-organized team world. I’ve silently wondered if I was walking around with dinosaur skills. So who cares that I can manage stakeholders when the product owner is on the team? Yeah, I can see start to start relationships a mile away, but we don’t use Microsoft Project anymore, so who cares?

I mean, a lot of what we do as PMs is administrative.  Taking notes, setting up schedules, updating tickets, writing status reports, calculating spend. 

And a lot of it is communicating; ferrying information between groups, making sure everyone is on the same page, making sure people understand their roles.

And a lot if is solitary strategic thinking.  It’s looking at the next sprint and thinking about resources, or sitting with a project plan and figuring out what benefit will come to the stakeholders, or anticipating costs and risks before they hit. 

Communicating, Administration, Strategic thinking – these things don’t produce product; something hard and tangible, like code, or Amazon instances, or user documentation.

But here’s my a-ha moment. Seeing forest AND trees is STILL a great skill…and it’s kind of rare. And we shouldn’t downplay it.

Chances are that if you look around you, especially in IT shops, most people aren’t doing administration, coordination, strategic thinking. They’re building code, or infrastructures. They’re focused on one or two immediate deadlines, not what’s gonna happen in a month. Or two.

Somebody’s got to do that, cause if it doesn’t get done, disaster ensues.

Observing self-organizing kanban teams this past year, sort of enabled me to separate the wheat from the chaff in terms of knowing where the PM fits.  

What’s been pulled away from project management in scrum/agile worlds is task sequencing, team ‘leadership’, and the need to define roles and responsibilities. Self organizing teams manage this on their own, so in general, task scheduling and sequencing is not needed.

But understanding the whole roadmap is.  Seeing how tasks bubble up to what’s gonna happen next week and next month is. Managing pushy stakeholders around requirements changes so the dev team doesn’t all quit, is.

Somebody's got to see it all working togehter

In other words, communication, coordination, administration and strategic thinking are the skills you should start to emphasize on your resume because these are the skills that development teams aren’t thinking about when they’re building stuff.

Project Managers who have these skills fill in that necessary middle layer, greasing the skids, keeping the machine well oiled, acting as diplomatic courier – you get the idea. 

So, we aren’t dinosaurs! We just have to realize what’s needed now, and that the need to have people who see the big and the little, the short and the long term, is probably not going to go away, no matter what development methodology we use.

Removing Soft Skills stigma; a good book and a suggestion for PMI

We all know/have heard how important soft skills are to our success in Project Management.

Some of us are getting tested to see where we’re weak or strong, some of us have joined conflict management groups, or are taking self-help courses in leadership and team building.

But for me, it all still seems a little disjointed.

I mean, it’s really clear what you have to do when you need to, for example, bone up on your earned value metrics. You take an assessment to see where you are. There are seminars, online classes, workshops-at-sea, books, a nice chapter in the PMBOK etc.

Same for Risk Management or some other tangible hard skill that we need to learn.

And there’s not a lot of stigma with needing to bone up on hard skills either.

Oh God! Starfleet says I have to work on my soft skills

So I’m at a PMI conference and I turn to my neighbor and say, “Ugh, I have to take the EVM seminar. I’m soooo bad at it,” and I get a hearty warm response. “Me too!” and we go on lolly gaggin about EVM. I’ve made a friend, it’s all great.

Same scenario but instead I turn to my neighbor and say, “Ugh, I have to take the Self-Awareness seminar. I’m soooo bad it.” And I get a concerned look, “Hmmmm”, as if I’ve just admitted I drink a bottle of wine every night.

First of all, I don’t think I’d admit my soft skills ‘issues’ to a stranger and secondly, admitting it almost sounds like I need a therapy session!

So addressing soft skills is a bit harder. There is some type of stigma attached to not having certain skills – it gets more personal. Also, soft skills are really hard to pin down. For example, I may know that I’m bad at leadership from feedback I get from my team, but like, what part of leadership?!

I search online for the ‘leadership skills’ assessment. You know, like the one I took that told me I needed to learn EVM. Nothing.

I pour over my emails. Was it something I wrote?
I revisit meeting notes. Did I slam somebody?

I finally ask a colleague and they say, “It was your emotional control.” Ohhhhhh, my emotional controooolllll.

Where do I go to deal with that? Can I look up ‘controlling emotions’ in the PMBOK and read up on how to improve, or take a controlling emotions seminar-at-sea (well probably), but you get my drift. It’s harder to address soft skills.

So that’s why I was so happy to meet Deb Herting at UPenn yesterday. Deb is a PMP and CEO of The Deborah Group. She was giving a talk on her new book at the Penn Bookstore.

Her book is called The power of Interpersonal Skills in Project Management and I see it beginning to solve part of the problem of addressing soft skills.

First, its an easy read, not intimidating, less than 90 pages book. That’s something you could give to your boss with a subtle wink, and they might actually read it.

Second, and most importantly, Deb has provided a framework for soft skills that helps identify and organize skills into a manageable lists.

Something about the framework and the organization makes the soft skill more tangible for me. Maybe it’s the fact that PMI’s list of ‘interpersonal’ skills is long and vague. (see the appendix of PMBOK 4th ed.)

But her list has only three interpersonal skills, those she considers to be the most important from PMI’s list; Team Building, Leadership, Communication – with a handy acronym; TLC.

And within each, there are abilities and competencies that are easy to grasp.

So instead of pouring through emails to figure out where I suck at leadership, I can do this.

Really? I don't set Clear Goals and Objectives? But what do I do? Where do I go? (wahhhhhhhh)

My co-worker says, “Michiko, you suck at leadership”.

After I go to the bathroom and cry, I come back to my desk with a mascara streaked face, and pick up ‘The Power of Interpersonal Skills in Project Management’.

‘Hmmmm’, I wonder, ‘Where am I bad at leadership?’.

And I can ponder from a whole list of leadership skills Deb has provided in her framework such as:

  • Be Passionate
  • Be Self-Aware
  • Control Emotions
  • Manage Expectations
  • and many more….

So the nebulous (‘I suck at leadership’) has become the concrete (‘I don’t think i’m controlling my emotions’.)

We all need this – this next step to understanding how to improve our soft skills. We need a breakdown, we need a way to make it tangible, and manageable.  Currently, soft skills guidance is nebulous and scary, PMI should work on making it concrete and universal, thereby removing any associated stigmas.

Deb’s book begins to do that.

I think next steps are for PMI to do the same, to incorporate a whole chapter on soft skills, not just an appendix. Give concrete, tangible areas to improve. So instead of a paragraph called ‘Communication’, give a breakdown of skills under communication and describe what they are, just like Deb has done.

And then start to encourage providers to test PMs on those skill sets and  PMPs to receive training on areas to improve.  You can look at The Deborah Groups one day seminar “The Socially Emerging  Manager – Interpersonal  Skills for the 21st Century Manager” as a great of example of how to do just that.

So then, the next time I’m at the PMI conference I turn to my neighbor and say, “Hey, I’m taking the ‘Controlling Emotions’ seminar”.

My neighbor says, “Oh yeah, I took that online test too, and I really have to work on ‘setting clearing goals and objectives” and we start lolly gaggin and having a great time.

There’s not so much stigma because PMI would’ve have openly identified skill sets where people need to improve and everybody will have something to improve on that list (not just old mascara face over here).

Hiding Behind the System is Bad Form

Hiding Behind the System

Just a quick note to say, buyer beware.

Collaborative communication tools are meant to supplement communication not replace it.

Many software teams are now using software packages that encourage a disciplined written approach to workflow. The need is to enable teams to move faster by reducing the amount of fluff communication, and to also share work across globally distributed teams. It’s helped us all become much more productive. That’s a good thing.

Really? Come on...

You’ve seen and worked with these packages. They handle your software repositories, or your issue tracking, or your document approval workflow, or your project reporting.

The problem is that people who don’t like to communicate are hiding-behind-the-system when it comes to real problem solving. That’s a bad thing.

The danger in these packages is that they can become an excuse to not communicate.

We all need to be cognizant of our time so that we can be productive, but if you start to see the following, you know that it’s time for a good sit down; it’s time to get out from behind the system.

  • A discussion/dispute about the meaning of what someone wrote in a system, without that person there, that turns into an email war
  • Someone mutters to themselves and/or yells at the screen in response to what someone wrote in a system
  • The thread on an item in a system becomes pages and pages long, characterized by terse one-liners

This kind of behavior is a complete waste of valuable time. If the goal of the system is to decrease time wasted in communication, then if you get sucked into a system/comment/email war, you’re increasing time wasted in communication. Especially if you can solve the problem with a simple voice to voice chat or video conference.

Project Leads need to watch out for hiding-behind-the-system behavior and encourage parties to talk face to face.

Process and Method pale in comparison to Plain Old Face to Face (even via Skype)

Remember that for any of us it can be scary to sit in a room and work it out with someone we’ve just flamed in a system.

So the best thing is to encourage a wipeboard about facts. Software engineers in particular work better with facts, and when you can get a wipeboard between two contentious engineers, the wipeboard becomes the silent mediator.

I encourage you to read Alistair Cockburn’s article Humans and Technology where he concludes “People are Communicating Beings”.

It’s not process/process technology that gets you winning, he suggests, it’s communication. Low process and high process teams fail, low process and high process teams win. Therefore, process is not the key indicator for success.

Remember that Cockburn is one of the founders of Agile Methodology; he is a well-established, noted authority on software engineering and he (not some do-gooder with a masters in Conflict Resolution) says:

The most significant single factor is “communication”…The most effective communication is person-to-person, face-to-face, as with two people at the whiteboard.

“As we remove the characteristics of two people at the whiteboard, we see a drop in communication effectiveness.

The characteristics that get lost are:

* Physical proximity. I am at a loss to explain why, but being physically close to the other person affects the communication. Whether it is three-dimensionality, timing, smell, or small visual cues, physical proximity matters.

* Multiple modalities. People communicate through gestures as well as words, often making a point by gesturing, raising an eyebrow or pointing while speaking.
Vocal inflection and timing. By speeding up, slowing down, pausing, or changing tones, the speaker emphasizes the importance of a sentence, or perhaps its surprise value.

* Real-time question-and-answer. Questions reveal the ambiguity in the speaker’s explanation, or the way in which the explanation misses the listener’s background. The timing of the questions sets up a pattern of communication between the parties.”

I would venture to say that up to 90% of meaning is lost in written comments in systems.

So hey, even the Mark Zuckerburg endorsed Daft Punk has this to say about the matter:

I turned away because I thought you were the problem
Tried to forget until I hit the bottom
But when I faced you in my blank confusion
I realized you weren’t wrong, it was a mere illusion

It really didn’t make sense
Just to leave this unresolved
It’s not hard to go the distance
when you finally get involved face to face

Here’s the whole song:

So pick up the phone! Hit up Skype! Hangout in Google+! Get out there, get visible, get talking – solve the problem! Don’t let yourself or your team hide behind the system.

The Next Generation PM – Ready Made Guidelines

Be a Next Generation PM

This report from Forrester reads like the new PM Manifesto.

So much good stuff in here, it almost feels seminal – like the new foundation for thinking about where we begin, where we start as Project managers.   I can see organizations using this as the basis for hiring new PMs, and I can see PMs using this as a way to figure out where we need to shore up and sharpen our skill set.

Easy to read, and grasp, this report includes findings like this:

Organizations really want to know that projects deliver business value and satisfy the customer.

Stakeholders develop a business case before a project begins, but traditionally organizations haven’t circled back after project completion to make sure that project outcomes deliver the value laid out in that initial justification. They are, however, starting to place a priority on measuring benefits realization as a component of project success by implementing post-project measurements of actual project benefits.”


(my fav)

A need to become leaner means that organizations are stripping away unnecessary processes.

As organizations realize that traditional software delivery methods are bloated with processes and artifacts that add little or no value, they are trending toward Lean Software — and this transition will significantly change how they deliver projects. Project management offices (PMOs) are looking for ways to streamline their processes to focus on value and eliminate unnecessary effort and documentation; project managers must adapt to communicating more while documenting less. They must understand how to be just as effective as — but more efficient than — before.“*

*emphasis is mine

To read the full report, sign into ZDnet which is a good idea so you can keep getting emails about their white papers.

Stanford’s 10 Good Ways to Change Behavior

This one really got me thinking.

I follow the US Army Comprehensive Solider Fitness program on Facebook.  They’re all about positive response to traumatic occurrences, where trauma leads to strength and resiliency rather than continued pain and failure.  You can read more about CSF here.

Today they posted the following presentation from Stanford University’s Persuasive Tech Lab: The Top 10 Mistakes in Behavior Change.  For those of us working change management as Project Managers (which is most of us) I found these ideas to be a bit challenging, but in a good maybe-I-should-adjust way.

View more presentations from Persuasive Technology Lab at Stanford.

Here they are:

The Top 10 Mistakes in Behavior Change

1. Relying on willpower for long-term change. Instead,imagine willpower doesn’t exist. That’s step 1 to a better future.

2. Attempting big leaps  instead of baby steps. Instead, seek tiny successes –one after another.

3. Ignoring how environment shapes behaviors. Instead, change your context and you change your life.

4. Trying to stop old behaviors instead of creating new ones.  Instead, focus on action, not avoidance.

5. Blaming Failures on lack of motivation.  Instead, make the behavior easier to do.

6. Underestimating the power of triggers.  Instead, [understand that] no behavior happens without a trigger.

7. Believing that information leads to action. Instead, [understand that] we humans aren’t so rational.

8. Focusing on abstract goals more than concrete behaviors.  Abstract: Get in Shape. Concrete: Walk 15 min. today.

9. Seeking to change a behavior forever, not for a short time. Instead [understand that] a fixed period works better than ‘forever’.

10. Assuming that behavior change is difficult.  Instead, [understand that] Behavior change is not so hard when you have the right process

I always get caught on number 7 Believing that information leads to action.  I tend to think that if people know about consequences of their actions, they’ll make adjustments.  One would think that, for example, if you’re the belly button to the health of the US economy, and you know that you don’t know the credit profile of your billion dollar book of business, you’d stop and re-assess and maybe add more credit enhancement.  But, that’s not what Fannie Mae did.  The rest is history and it’s definitely not rational.

And how many times have we blamed a failed process on people not performing needed steps in that process.  Our Risk Management process doesn’t get off the Risk Management Plan paper because everyone skirts around it; and nobody likes the idea of a risk owner.  Maybe this is what number 5 Blaming failures on lack of motivation is about. Maybe the process is too hard and we’ve got to ‘make the behavior easier to do‘ if we really want to implement our process.

Stanford’s got some pretty cool stuff. Here’s a new field – Captology  – Computers As Persuasive Technologies ‘capt’ and ‘ology’.  I’m sure it’s a play on words with ‘captivate’.  I can honestly say that if I use a website that captivates me, keeps my attention and engenders wonder, I’m really open to whatever is being sold.  Check it out – more on Human Computer Interaction (HCI) and using programming to persuade on Stanford’s Captology Website.

Lines and Points: A Different Way to Think about Your Relationship to Everyone Else

I’ve been reading Carolyn Myss’ Defy Gravity, which is a fantastic read about healing. One of her ideas is that people are never what they appear to be when you meet them. Rather then are the sum total of every experience that ever happened to them.

Her point was that if you’ve been hurt by someone, the way to forgiveness is to understand that the person who hurt you has probably also suffered a mish-mash of hurts, aggressions, sadness, and pain which has spilled onto you. This thinking is sort of a first step in understanding that often times, the pain that you experienced from that person is not really personal.

This got me thinking about geometry of all things. Remember the idea that a point is really not a point on its own but on point on a line. So if you meet me at a certain ‘point’ of my life, you may interpret me as that ‘point’ at which you found me. But in actuality, this ‘point’ is really just a part of a line, a trajectory of my life that intersected with yours.

Your Team is a Little Blue Dot

Your Team is a Little Blue Dot

And that line originated from the intersections of my mum and pa (ie my starting point) and has continued since; and that continuation has included financial difficulties through grad school, raising two kids as a single parent, maybe being ostracized for being too smart by bosses who were threatened by me….a WHOLE lot of stuff.

We all have that WHOLE lot of stuff – or said differently, the line of points that is our life is full and complex and long.

What happens when your line intersects with another’s line in the work place?. You probably know that it’s never simple, it’s the cumulation of myriad points over time and BOOM you intersect and bring all those points to bear on that one moment in time.

Now imagine multiple points coming together at say…the beginning of a project.

Complicated, eh?  No wonder you head into storming right away – it’s not just the one person, it’s not just that singular moment where you meet everyone for the first time at a project’s rather the sum total of their lives and yours to that point.

The point is (I really need another word don’t I?)..The IDEA is that as Project Managers, we have to understand the complicated nature of human beings. Most of the time bad behavior, be it from a boss who is threatened by you, or a developer who only wants to do what they want to do, has nothing to do with you…it has to do with an accumulation of a life time of points on a line.

Maybe just that understanding can enable one to develop the compassion that Derek Heuther and Samad Aidane are referring to in Compassion is the Killer App.