See communications and delivery as separate but a part of the same customer-centric whole

It's all part of the same thing,
we just don't know the difference sometimes
but we have to create and define it.

Most projects are tough because there are two main and competing parts to them: doing the work (adding value) and communicating about the work (selling).  I wrote about these two things yesterday.  When we're in roles like project manager or business analyst, we have to do both and can't focus on just one or we'll fail. 

One time at Microsoft I focused exclusively on delivering the value and failed because I didn't spend enough time on communications and change aspects with the customer (I had no time or willingness to, either, so serves her right...). 

On the flip side, dealing exclusively on with the selling aspects is the same as analysis paralysis and we shouldn't just want to sit there and talk about it all day: that's not the goal either.  So there must be some kind of balance between these two things.

I think we're lucky: Scrum makes communications a daily occurrence through standups and has a standard process and roles for communications.  Scrum fixes the time of communications and gives most of  the time to the development team to do their work.  In the meanwhile, management and planning activities happen in parallel. 

In Scrum there's a clear and defined way of communicating and this is necessary.  Many new projects don't have this structure and need to get it as soon as they can.  So, in summary, we need to have the role of delivery, the role of sales, and then a defined and clear relationship between them.  Get it!!

How much power we actually have as project managers

Being on top of the mountain feels good, but
there's still sky and heavens above and plenty
of places to fall and hurt yourself below.
Don't forget your true, humble place.

Being the boss is fun.  But its rare.  Sometimes we might think we're the boss but very frequently we are not.  Being a customer is probably the closest we can come to being a boss: "the customer is always right".  I would really like to achieve this level of control on my projects where the buck stops at my desk and what I say goes. But this rarely works.

We should shrink our organizations.  We should centralize more decision-making authority and shrink our work cycles.  But this doesn't often work because sometimes we really do require input and authorization on projects from a very large collection of stakeholders.

So it might be true that "my requirements are what I say they are" but at the aggregate and at the project manager's level, they are rolling up and what the project manager says or thinks really doesn't fly.  The project manager really is just a facilitator and adviser to a larger, far more political, process.

So be careful project managers, although you may feel like you may have god-like powers and feel in control, you're still reporting to your board and you're still accountable to your customers, stakeholders, and stockholders.  Tread lightly and don't abuse the power.

Listening and advising as the key skills of consulting

Things will go in your ear that you don't want to hear sometimes.
But you will hear them.  You don't have to listen to them,
you just have to figure out how to react to what you hear: be calm.

There are three main skills in consulting: listening, giving and taking advice.

Listening is hard sometimes when there's so many things going on in your head.  Combine that with stupid or annoying speakers and it's hard to keep your mouth shut sometimes!

Try to quiet yourself and let yourself listen to what is being said: drink it all in and relax; breathe, contemplate responses but do not engage.  Let others finish their thoughts and points before you offer anything more, if you offer anything more; sometimes silence is far more powerful than words.

Accepting advice also requires that you listen and it also requires a great deal of patience and trust.  It is impossible to take advice if you can't listen.

Giving advice is easy.  Anyone can give advice.  But not everyone can give good advice.  There are a lot of people out there seeking advice.  Some of us are even paying great sums for advice and help from others.

Being a leader requires that we listen, give and take advice.  Balance these skills and be excellent.

In organizations, mimicry is the highest form of flattery

As the reflection is to the mountain, the repeated message is to the speaker.

I take a lot of notes in meetings.  I write things down and frequently write up my notes and send them back to the attendees for their information and consideration.

Some people might find this behavior annoying or overboard but I don't care.  I feel like I get a ton of value out of writing things down and sending them back to people.  In fact as a project manager doing so is critical to success and managing risk.

A lot of times people really don't know what they think or what they're saying and having someone write down and repeat back to them what they heard, they are given the chance to correct or expand upon what they have said.  A relationship can form and a deeper discourse is possible.

The same is true for the spoken word.  In conversations with people, repeating back to them what you heard is a key and important part of effective communications.

People need to feel like there is very high clarity between what they're saying and putting out there.  Some people say, "Do you know what I mean?" or other phrases in order to verify that they're not crazy or way off base.

So next time you're in an important conversation, please play back what you have heard to the speaker to the best of your ability either using the spoken or written word; or both.  Build a community.

Basic schema for tracking a project

I’m managing a project/program right now and am using the following basic structure for communications to the team:

• Deliverable Name.  What’s the body of work/thing.
• Sub-Team members.  Who all is working on it.  Be semi-descriptive, “Jim and Mary with Joe”
• Status color.  Red, yellow, green, N/A.
• Status notes.  Be clear about the current status of the thing.
• Active assignments.  The things that people need to do with respect to this item in the near-term.  This should include risk mitigations, escalations and everything.  Everything needs to be work / an action.

In the meeting, we review last week’s list, and update it for this week.  It’s a simple process that seems pretty effective.  As new Deliverables appear, I add them.