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.