PMI Global Insights

I saw this potshots comic today and liked it, so I'm sharing it.

Why do many people (myself included) find it so hard to communicate?  I actually find it pretty easy to broadcast (as you can see from my posts), but true interactive communication is difficult.  I'm not sure if it's the risk of exposing my feelings, if its a disconnect of values with the person I'm communicating with, if it's my attitude, or if I just don't add anything of value to the person I'm communicating with.  Or is could be I'm just overthinking everything :)

Regardless, I frequently challenge my own ability to communicate.  Granted, I thought I was a good communicator until I had children, but I found that what I thought I communicated clearly, was not received clearly.

My path to green for this is to keep on trying,  Use active listening and watch for body language signs, paraphrasing back what the person said, and accept that I don't have to respond to everything said to me.  I can acknowledge with a smile or the nodding of my head.

Anybody else find communication more difficult that it should be?

Get your most burning project management questions answered in “Ask the Experts” at PMI Global Conference.  Sign up for a specific time at: http://www.signupgenius.com/go/4090c44a9ad23a7fb6-askthe5 or just stop by.

Times Dave is scheduled for:

Saturday October 28:  3:00PM -  4:30 PM

Sunday October 29: 10:00  11:50 AM, 3:00 5:00 PM

Monday October 30:  1:00 – 2:30 PM

David L. Davis PMP, PgMP, PBA

Senior Project Manager OhioHealth

[email protected]

I thought I would add to David's post "I've Learned..." because I feel it's always nice to have some key takeaways from peoples' experiences to, shall we say, leap-frog past those things ourselves? We don't want to learn EVERYTHING from our own mis-steps along the way...

So what can I share that might help a few souls out?

I've learned...

- that you can ALWAYS learn something new from another person, no matter their age, education, background, or experiences.

- that diversity matters - diversity in all ways - when it comes to assessing challenges and finding their solutions.

- that in times of change and uncertainty, the best thing you can do for the people around you is to be open, honest, and to help them see why and how they still matter - how they've contributed to what once was, how they can help shift through the change, and how they will continue to provide value moving forward.

- that if you trust and give people the opportunity to step up to higher expectations, and provide them the necessary support they need (tools, training, moral support, backing, or other), they will rise to the challenge.

- that it's okay to be wrong, and

- that it's better to say no when your plate is full, than to think you can do it all, AND that people will understand, especially if you open up and choose to tell them why.

For this last point, I find it can be one of the most difficult ones to stick with. 

I am passionate about so many things, and I love to see positive change, in our working environments, and in the world too. So, when people ask me if I can volunteer to help them do something, my heart and mind are often quick to say "YES"...

Not only is this not healthy, it is not a reality when we have family, when we would like to care for ourselves, and when we still need to pay the bills. So, be careful with what you say yes to, and balance that volunteer time with everything in your life. 

I've deliberately said no to many things of late, and a few more where I said, maybe - in a few months...when (and if) the waters calm!

I'll be sharing other lessons around engaging your teams, collaboration and lean processes that will increase the performance within your organization, when I present on Sunday, Oct. 29, 4:45...you can find more details about my session here.

What have you learned that you might share?

...

If you'd like to discuss anything in particular with me, please book an appointment with me at the Ask the Expert booth during the following times. (And if you miss this chance, or won't be there? Book a time with me anyways...)

Saturday, Oct 28th: 3:00 to 4:30

Sunday, Oct 29th: 10:00 to 12:00

Monday, Oct 30th: 9:00 to 12:00

Looking forward to meeting you there!

Hi Mr. Davis!

First, you’ve asked an excellent question.   I think there’s really two parts to it.   Some of the ones you list could affect the project only (resignation) but some of them are corporate level risks (cyber-attack). 

There should be good risk-stewards at the corporate level, working with the accounting and general management folks to forecast and protect against hurricane, tornados, zombies, whatever.   These risks are out of the project manager’s hands and are part of the overall business risk assessment.  You *could* say these are “organizationally accepted risks.” 

That’s all “C-Suite” stuff.   Sure, your project may get washed away in a hurricane, but the PM isn’t really held responsible for insurance, or claims, or set-asides for that.  Perhaps, a PM may get involved in planning for data safe-backups (offsite) but even that is not common.

But!  As a top-notch Project Manager, when you think of these ORGANIZATIONAL types of things, I believe it’s your duty to ensure that the general business folks have considered them.   So, for instance, I had the sprinkler system come on over a weekend (no fire) and it stayed on until Monday.  I never imagined that would happen.  If I was just a bit smarter I would have, and would have politely asked the folks upstairs in the corner office if they had set aside funding to take care 2 feet of water from sprinklers.   I don’t consider this to be a project risk, but an Organizational level risk

So, if you can imagine a business risk and it has some likelihood of occurring you have an honor-bound duty to inform the business risk people about it.    If they don’t take care of it, then you must handle it on the project. 

If it’s a commonly accepted risk taken at the project level (a late deliverable) then it should be in your project’s risk register and you’ll be the grass and the executives will be the lawnmower.

-- Dave

ATA (Ask to Answer) for the Risk expert Mr. Maynard.

I wonder if there is a formal explanation for something I call “Organizational Accepted Risk”.  There are many risk items that I personally don’t call out in my risk mitigation strategy because the Organization automatically accepts the Risk and will deal with it when it occurs.  I mention it in my governance document, but not in my Risk Plan. Some examples of these risks are listed below:

1. A team member leaves the organization (whatever the reason: resignation, layoffs, death, etc.)  It definitely can impact my deliverables, but.
2. A cyber attack.  I do a lot of network projects and there is always the risk of a cyber attack taking resources (wanacry is one example).  We deal with it, but it can cause a jeopardy.
3. Funding cut.  I treat this as an issue when and if it occurs and requires the project plan to be reviewed.
4. Act of God – there are lots of things that can happen to disrupt the project.  Fire, hurricane, tornado, zombie apocalypse.  I don’t call these out as specific Risk items as we just accept them.  The probability is low for some areas (not too many hurricanes in Ft Wayne) 

My question: “is there an accepted best-practice for handling Organization Accepted Risk” and could you direct me to it?

Develop a document that will help you manage your BPI project!

Creating a project charter for your business process improvement (BPI) projects are a best practice for a number of reasons:

• Enables you to get your “head” around the scope of the BPI project
• Enables for clarification of BPI project needs/expectations
• Ensures a link between the BPI project and strategic objectives

While we all know that, in theory, the project charter is handed to the project manager from the project sponsor, in reality this never happens! The project manager develops the project charter based on information from the sponsor and other key stakeholders. Too often project managers skip developing a project charter and focus purely on the project scope statement. I prefer to use both documents. I use the charter to develop a list of questions that provide me further information about the BPI project, why it is being undertaken, its link to the organizational strategic goals and the overall objectives for the project.

Once finalized and approved by the sponsor, the charter is then used to develop the project scope statement. This charter, as well as the scope statement, enables me to better manage my stakeholders as the project work takes place. I frequently refer back to that charter to ensure we stay on track with the project, pushing back as necessary when the project is taking the wrong direction or is at risk of doing so. It enables me to have better conversations regarding changes to the BPI project.

BPI Project Charter Components

Components of BPI project charters are described in the table below:

BPI Project Charter Best Practices

Here are the best practice steps I take to create a BPI project charter:

• Compile all of the information I already have for the project based on emails I have received from the sponsor and others, memos I have received and conversations I have had. I add that information to the project charter – filling in whatever blanks I can based on my knowledge of the business and what the business is trying to accomplish.
• Review the charter with the project sponsor and any other key stakeholders to validate the information I have and fill in the blanks. I have found that by going in to this meeting with a charter that includes not just the information they have provided but also information that I assume to be valid based on my knowledge of the business, I’m able to have better, more productive and efficient conversations about the purpose of the BPI project. The more I know about the project the better I can manage it and share that information with the project team to get them engaged, committed and excited about the initiative.
• Revise the project charter with the additional information based on my conversation with the project sponsor and other key stakeholders. Incorporate any new information and identify any new questions or concerns for another conversation with the sponsor.
• Review the charter one more time with the sponsor and any other key stakeholders. Get any additional questions or concerns addressed.
• Finalize the charter and get sign off from the sponsor.

While this may seem initially like a large effort, it really is not. Spending this time up front to get the charter accurate enables for me to develop strong relationships with the project sponsor and any other key stakeholders. It also ensures that I understand what we are doing with this project and why – which enables me to have better conversations with team members and other stakeholders. You can’t effectively manage a BPI project – and get others committed to it – if you don’t know the business reason behind the BPI project. You notice that in each conversation with the sponsor I have advanced progress on the charter. Additionally, I have taken some steps in filling in the blanks myself based on knowledge I already have. It may not be completely accurate, but enables for far more productive conversations with the sponsor and other key stakeholders.

In summary, create a project charter for all of your BPI projects, to enable for getting your “head” around the project and developing key questions to ask sponsors to ensure you have what you need for project success.