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!