Category Archives: Communications
“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.
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 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.
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.
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.
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.
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
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.
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.
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.”
“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 http://bit.ly/g9MN7c which is a good idea so you can keep getting emails about their white papers.