Culture of Success and Stakeholder Management Part 2: Relationships & Trust (Post #4)

Identifying who your stakeholders are is just the first step in managing stakeholders.  Once you have them identified, it’s time to get to know them and ultimately, build a trusting relationship.  There are three key areas I focus on when building relationships.

Relationships are Evergreen.  Building relationships is something that is ongoing and never ends.  Think of it in terms of the evergreen tree; once it starts growing, it’s one of two colors.  It’s either green and healthy, or brown and dead.  Relationships are the same way.

Every person you interact with is different.  Each comes with a variety of backgrounds and experiences.  No two are the same.  My best recommendation is to engage your key stakeholders 1-on-1 and truly try to understand their world.  It’s not about the quantity of time you spend with them, but the quality.  Start with “small talk” and get to know their personality, what their likes/dislikes are, and their jobs.  Seek to understand their daily routine and how your project will impact them.  Also, find out if they’ve ever been burned on a project in the past.

An example is stakeholder I was warned about who was called “grumpy.”  I took this person out for coffee and found out our kids were about the same age and into similar sports.  We eventually started talking about the project.  I soon found out the last couple projects her team was never consulted on and left in the dark.  During requirements gathering, I made sure her team had input and gave her regular status reports.

Build Relationship Capital; Spend it Wisely.  I’ve seen dozens of definitions for relationship capital and summed up, it’s the influence a PM builds and wields with people, built through trust and open communication.  This can be done with anyone, but we’ll focus on stakeholders as they hold power with your project.

I work hard to build trust with stakeholders.  I listen intently when they talk, take action when they ask, and provide information before they’re surprised.  I keep my EQ in check when dealing with them and tougher issues.  This all leads to trust and open communication.  When that happens, I know I can go to them and ask for help when I need it.

An example is I built a good relationship with a marketing person, which was also the department that provided most of the funds for our project.  We needed to make a procurement, but finance said no since it couldn’t be capitalized and we needed for figure out a Plan B.  After review, Plan B would add a month of time.  So, I went to the marketing person and asked for additional funds to be approved directly from her department.  Since she trusted me and knew I wouldn’t ask unless there was a need, approved.

Build Relationships WITH Stakeholders and AMONG Stakeholders.  This goes back to building capital.  Once you’ve built relationships with your stakeholders, it’s time to build it among them.  Stakeholders with a relationship and shared vision can do more than just one alone.  They can hold each other more accountable than just the PM.  This relationship can also be beneficial when conflicts and/or issues arise.

I once managed a large-scale program with 11 projects and six project managers.  We setup a steering committee that met weekly to provide status, highlight what’s to come, discuss issues and gain commitment on next steps.  One key stakeholder, who was also the director of a technical area, committed to getting resources on the projects but never followed through.  After I talked to him a few times, I finally asked three other stakeholders to assist, which they did the same day.  Within 48 hours, we had the resources we needed.

Now that you know who your stakeholders are and built a relationship with them, it’s time to ensure they’re kept informed throughout the project.  Join me for the Part 3 of Stakeholder Management, ongoing communication.

Culture of Success and Stakeholder Management Part 1 (Post #3)

Let me preface this by saying I spend a lot of time on stakeholder engagement and management.  Most of what I’ll write about can be applied not only to stakeholders, but team members, management, spouses, or anyone else you come in contact with.  The reason I talk about it here is stakeholders can kill your project, make your life hell, and/or set you back in your project management career.

I learned stakeholder management the hard way.  My first, and largest, project failure was just shy of $2M.  In a company of 17,000 people, I didn’t identify a team of 4 who had overall responsibility for new product development.  Once they discovered my project, they swooped in and ended it.  My lesson learned here; even if you think you know who your stakeholders are, dig deeper.

First, let’s define a stakeholder.  PMBOK has its definition and if you’d like to read it, Google “PMI Definition of Stakeholder”.  Though it’s accurate, there are a few other points to consider.  They are:

  • Fully Engaged – they pay attention to project progress, iterative outcomes, assist with issues, and are active listeners/ask good questions during meetings
  • Supportive – this does not always mean they want the project to move forward, but they understand WHY it’s needed and won’t go out of their way to sabotage it (yes, I’ve had stakeholders try to kill a project mid-stream because they wanted to funding to go to their area)
  • Accountable – follow through on their commitments
  • NOT Indifferent & Apathetic – reference back to fully engaged

But who is a Stakeholder?  They’re not always easy to spot and sometimes, they don’t want to be known.  There are two areas I look at when identifying stakeholders:

  • Follow the $$Money$$ – if they, or their department, are paying for any part of the project, they’re a stakeholder.  Some companies have departmental budgets where a portion is taken to support ongoing projects.  Be aware of this and ensure there’s representation, even if the department manager doesn’t feel it’s necessary.
  • Are they impacted? – I have an 80/20 rule here; 80% are easy to see, the 20% are not and it’s up to you to dig to find them.  These people can be internal and/or external to an organization.  Don’t be afraid to ask, a lot, until you’re satisfied.

The “other” stakeholder assessment.  Again, I won’t talk about the PMBOK stakeholder assessment.  I’m talking about the other assessment.  The personal assessment.  The one you, as the PM, creates and never lets others see it.  I know how to get on the CIO’s calendar for a bag of Reese’s.  Need a key stakeholder who hates meetings to show up at one?  Bring yellow Peep’s.  Find people’s likes and dislikes, as well as other tid-bits of information and keep it somewhere.  You never know when you’ll need it!

Identifying who stakeholders are and their characteristics is tricky.  My lesson learned was expensive and one I share frequently to show how critical it is.  Once you have stakeholders ID’d, it’s time to build relationships.  Join me for Part 2 of Stakeholder Management, coming soon!!

Culture of Success and “Governance”: the 10 Letter – 4 Letter Word (Post #2)

In this episode of Culture of Success, we’ll talk about Governance.  The focus will be on project and program selection. 

If you’ve been in project management for any length of time, you’ve experienced what I like to refer to as the “drive by project.”  This is where someone, usually in management, says they need a project spun up ASAP.  They’ll give you an idea of what’s needed and by when.  You’ll probably ask a few clarifying questions to make sure you know what’s in scope and what’s out.  Then, you put a document together, have this person review and okay what’s being requested.  At this point, they may ask when you can get started.  In an organization with any level of maturity, the answer is “When governance approves it.”

What I’ve found from experience is when I say the 10 letter word “Governance” to a project requester, a 4 letter word is what I get in response.  But the role of governance is to provide a decision making framework that is logical and repeatable.  In this way, an organization can govern their capital investments as well as balance daily operations with project initiatives.

Every company will setup governance differently based on the way they do business as well as their maturity.  Some will have detailed metrics that stack-ranks requests.  Others will select projects based on talking about what governance members feel is most important.  But in any case, some projects are selected, others aren’t.  If the wrong projects ultimately get selected and have to be killed mid-stream or go to completion and never used, team morale will suffer.

So what does the Governance committee need to make their decisions?  Again, it depends on maturity, but it’s usually in the form of a business case with some of the following info:

Organizational Alignment & Criticality.  Every company has a mission and vision.  To obtain those, it needs a strategy.  To meet strategic goals, it takes projects.  But does every request support organizational strategy?

When a new project is requested, it needs to be bumped up against organizational strategy.  Does it align with strategy?  Will it help accomplish our goals?  Does this make sense to do it now and if so, what other projects may be impacted?  Do we have what we need to be successful?  Do we HAVE to do this for compliance reasons?  And the list goes on and on.  Ultimately, the project needs to achieve organizational goals.

A Vision of What “Done” Looks Like.  Tell me what “done” looks like?  Sometimes it’s easy.  But more often than not, you’ll hear “Well, let me see…”  It can take time and a few conversations to uncover what “done” will look like.  For example, I once had a senior manager ask that a project be spun up to create a website.  Then he walked away.  Sure, I could’ve had a really nice website built, but probably wouldn’t meet his goal.

Project frameworks aside, some projects are approved with a fuzzy definition of done because stakeholders may not know yet.  In these instances, the scope is continually iterated.  At some point, preferably sooner than later, done can be clearly defined.

ROI, Risks, Issues, and that Other Stuff.  If you Google “Business Case Template”, you’ll get over 13M results (at least that’s what I got).  Each will be different in format, but content is close to the same.  Things like ROI, financial information, risks, issues, competition, and a host of other areas will be included.  All are important, though not all are necessary.  Build it out so it makes sense to those reviewing it.

Once governance approves a project, their work doesn’t end.  There is still decisions to be made as it relates to resource allocations, escalations, and provides guidance when necessary.  Without governance, the shot-gun effect of project selection creates chaos with what’s a priority and has a negative impact on employees.

Culture of Success: It Started with a Stress Ball (Post #1)

The first time I heard the term “culture of success,” I was looking at a consultant who was presenting our new project management process.  In our company, each group within our  division had a different process for managing projects.  Though similar, there were enough differences where management thought it vital to have a consulting firm interview each group and create one process to rule them all!  The best thing; they gave us stress balls that said “Culture of Success,” which we really enjoyed throwing at each other for months after.

The first thing that struck me about the process was how much paperwork there was.  Every little step required a signature.  All communication was to be tracked.  There was full traceability of emails and they were to be saved.  Their definition of culture of success was all process and very little human interaction.

Fast-forward 10 years (or so) and I heard the phrase again.  This time culture of success focused primarily on team dynamics and communication, leaving process mostly out of the equation.  There was also an emphasis on stakeholder engagement making them an integral part of the team instead of phase/gate approvers.  It was a complete 180 from the previous definition.

Since that time I’ve come to create my own definition of “Culture of Success,” which moves a project or program  from chaos to clarity through accountability and relationships.  Let me break it down a little more:

  • Chaos: a state of disorder that is always there at the start of a project, but then moves to…
  • Clarity: a clear, concise definition of “done” and any objectives for success, as well as adherence to processes to complete the work, which leads to…
  • Accountability: this is the RACI and beyond, which each person understanding & maintaining their role and committing to project success; this happens through…
  • Relationships: this is the pillar of getting things done

So to go in reverse; without Relationships there will be no trust and Accountability, which leads to a lack of Clarity and puts the project into Chaos.

From there I looked at different areas of a project where if not done correctly, doesn’t move you from chaos into clarity.  They are:

  • Begin with the end in mind
  • Stakeholder management
  • Team Dynamics
  • People vs. Process paradigm

Each of these areas will be detailed out further in future posts.

And like that, my concept of Culture of Success was born!  Oh, and the stress balls; they lasted longer than the process.  Six months after go-live the consultant-driven process was put on hold because all the approvals required overwhelmed stakeholders.  Management caved to complaints and like that, back to the norm!

“If you Project Managers are so damn good, why do projects keep failing!?” and a Commitment to Help

“If you project managers are so damn good, why do projects keep failing?”

I was added at the 11th hour to this webinar panel when someone else couldn’t attend.  The premise was simple; these are small to mid-sized business owners who want to know more about real-world project management practices, and would ask questions to a panel hoping for helpful information.  Piece of cake, right!?  What became immediately clear was most of the attendees had either failed or currently extremely challenged projects.  They were frustrated and didn’t know what steps to take to get their efforts back on track.  One person in particular was extremely frustrated and didn’t hide it.  Since no one else spoke, I asked him politely to repeat his question.

“Yeah, if you project managers are so damn good, why do projects keep failing?  It’s like $100M worth of failed projects for every $1B spent!  If project managers are worth it, shouldn’t that stat be lower?”

“Well sir, if you’re looking at PMI’s Pulse of the Profession, yes, that’s essentially the stat they published (it was actually $97M, but who’s counting).  Though it’s lower than last year, I agree it’s still alarming.”  I went on to explain project failure can come from anywhere including a definition of done not being clearly defined, incomplete requirements, no sponsorship, scope creep, team that’s off doing their “day job” and make project work second, or a project manager who was picked from the operation pool because you thought they’d be good.  The list can go on, but it’s the project manager’s job, along with the sponsor & key stakeholders, to try to tie up all those loose ends.

Our conversation went on for another 5 minutes until it was uncovered he had lost a large sum of money to a failed IT deployment and was really upset.  I talked about creating a “Culture of Success” for the project and gave some key points.  These are the same points I’ve presented at PMI events.  Though they’re relatively simple in theory, they can be difficult in practice.

In the end both the attendee and I made a commitment; I will blog about “Creating a Culture of Success” with stakeholders, project teams and processes, and he will implement the concepts that make sense for his company.  So to that end, I look forward to publishing what I’ve presented at PMI events.  I hope you find them informative and entertaining!