Many of the companies I’ve worked with have invested significant effort in developing and implementing consistent project intake processes, often supported by fairly costly project portfolio management systems.
While these changes can reduce the occurrence of pet projects, they still won’t make a meaningful difference in portfolio value realization. Yes, increased effort may be spent in creating business cases than before and those business cases may get challenged by different levels of governance committees, but that doesn’t mean benefits will be realized as expected. Unless the requested funding is tremendous, the level of scrutiny the business case will experience is likely to be restricted to a quick review of assumptions, validation of SWOT analysis and other such sanity checks. To really validate the realism of the benefits model would require an investment of a similar (if not greater) level of effort which was spent on creating the original business case.
Most sponsors tend to display a strong optimism bias – if they didn’t, they’d be unlikely to sponsor transformational projects. However, this optimism bias can result in inflated expected benefits and the underestimation of the one-time or ongoing costs or the impact of external factors which could reduce benefits.
Without some sort of benefits management framework that insists on objective representation of expected benefits when baselines are committed and then regularly re-checks the likelihood of realizing those benefits, risky project investment decisions could still be made. And once a project is over, even if no benefits were realized, few organizations will hold the sponsor accountable for poor outcomes. While chronic offenders likely deserve some punitive action, I’m not a fan of tying compensation to benefits realization – while that creates “skin in the game”, it also might generate an overly conservative culture which could result in competitive disadvantage for a company.
This made me think about credit ratings – independently established metrics providing an objective method of evaluating the credit risk of an individual, organization or country. Could this approach not be adapted for assessing the benefits realization reliability of a given sponsor?
Similar to a credit rating, new sponsors would start out with a modest reliability rating. As they request project investment decisions and the benefits are realized (or not), their rating would increase or decrease. These ratings could then be used as an input into project intake reviews. Sponsors with good reliability ratings would be subjected to less scrutiny and have access to higher levels of project funding. Those with lower reliability ratings would have their business cases challenged more rigorously and could have more funding disbursement gates.
So who would calculate and publish such reliability ratings? This could be a job for your friendly, neighborhood PMO.
(Note: I checked the credit rating of this article when it was originally published in March 2015 on my personal blog, kbondale.wordpress.com)
We all recognize the criticality of effective project sponsorship. The selection of the right individual for the role and an onboarding process to help them properly fulfill their responsibilities can increase the odds of project success. Sponsorship is a key component of project governance.
Project governance does not end there.
There are always going to be project decisions which a sponsor won’t be able to make on their own. A common example of this is a funding request which exceeds the financial authority of the sponsor. Sponsors may also be unable to unilaterally make decisions or remove hurdles which impact functional areas outside of their jurisdiction.
What does overall governance effectiveness & efficiency even mean?
A well designed, properly implemented governance framework ensures that project decisions are made in accordance with organizational policy and that they fit within the organization’s risk appetite. It ensures that these decisions are made with minimal wasted time and effort such that project flow is not impeded. Good governance is also there to act as a safety net for issue resolution such that hurdles which impede a project and which can’t be resolved at the team level are dealt with in a timely fashion such that project impacts are minimized.
So how can you assess if your project’s overall governance process is both effective and efficient? How do you know that you’ve found the sweet spot between too much process and anarchy?
Here are some symptoms of governance gangrene which could help you make some immediate improvements or could at least help you to identify lessons which could be applied to future projects.
Frequent reversal of decisions. While this is sometimes caused by excessive multitasking or making decisions prematurely, analysis of reversed decisions may reveal insufficient engagement of the right stakeholders when decisions are first made. Thorough stakeholder analysis and consideration of broadening the governance safety net may be one way to reduce the likelihood of this.
Excessive effort spent on administration or documentation supporting decision making. If more effort is spent on supporting the decision making process than coming up with the decision recommendation itself, that’s often a sign of a bloated, wasteful governance process. Process analysis to determine non-value add steps could help to lean governance out.
Decisions or issue resolutions are chronically late with measurable impacts to the project. If death-by-committee is causing decisions to be made long after the time when they should have been made, an assessment should be conducted to determine if the processes are too complex and can be shortened and if not, is there a way to move up the timing for when decision requests are submitted.
Governance committees never evolve beyond the storming phase. It’s a good practice to establish a steering committee or advisory group on large, complex, cross-functional projects, but if there is no one supporting them through Tuckman’s stage of team development, your project could end up falling victim to long standing executive personality clashes or organizational turf wars. A strong sponsor can help in such cases by acting as an informal coach to the committee.
Blessed with a good sponsor but cursed with ineffective or inefficient project governance?
Diagnose it, or you might be humming “One is the loneliest number that you’ll ever do.”
(Note: this article was approved through lean governance and published in January 2015 on my personal blog, kbondale.wordpress.com)
In one of my previous articles I'd written about the need for change across multiple areas of an organization when undertaking an agile transformation. A key enterprise partner is the Finance department and the organization's model for project funding will have significant influence over successful agile delivery.
Traditional project funding models are anchored to periodic (annual, semi-annual or quarterly) portfolio re-planning exercises which ingest updated forecasts for active investments and funding requests for new ones. The funding approach for an investment might be one time lump sum, split into two pieces (e.g. seed and remaining), or progressive through the use of funding tranches.
The challenge with all of these funding approaches is that they are based on an estimated cost of a project rather than the funding we wish to allocate to a product, capability or service.
So what challenges arise from a project-centric funding model?
It can result in higher risk, premature financial commitments.
Even in those cases where a funding tranche approach is used, the expectation is that the estimate for the current funding request will be at a high level of confidence. Now nothing prevents project teams from requesting a minimal amount of funding (e.g. one sprint's worth), but in most cases, project funding approval processes are not lean enough to encourage such behavior. Given this, teams choose to make a funding commitment tied to a major milestone such as a release which might span multiple sprints worth of work. The danger in this is that unless we have a long lived team with predictable velocity working on a well understood product, the level of confidence in the work to be done and how complex that work is will drop the further out we go resulting in a team being at risk of a cost overrun.
Now you might say that agile delivery approaches can work when we fix cost and time and let scope or requirements be the variable. This is true, but how do we know how much to budget up-front to be confident in meeting business needs?
It can also encourage sloppy product management.
When product owners receive funding for a single project and don't have any guarantees that they will receive funding for follow-on work, it is tempting to throw everything and the kitchen sink into the project backlog and to procrastinate on making tough prioritization decisions. With product-centric funding, the product owner can effectively prioritize the product backlog with confidence that there is available funding for incremental evolution of the product's capabilities.
Moving from a project-based to a product-based funding model is a challenging people, process & technology change, but will be a powerful accelerator for your agile transformation.
A stealth project is an initiative that was never formally sanctioned or approved. This is not a value judgment - many stealth projects are able to deliver worthwhile business outcomes, but at what cost?
Stealth projects have been portrayed as being one of the Four Horseman of the Project Portfolio Management Apocalypse. So why do they survive (and even thrive!) in many organizations?
A stealth project usually emerges when a customer knows that their request will not be addressed in a timely fashion and leverages their position, influence or relationships within the organization to get the work done.
Likely causes for this perception are:
Another possibility is that the customer may simply not know any better. They may have been used to going to their "favorite" resource in the past to get things done, and even if a work intake process has been implemented they may be unaware of it or be purposely ignoring it. We tend to repeat past behaviors that resulted in desired results where there were no negative consequences. If there were no repercussions in the past for not following proper work intake practices, this behavior will persist.
So why should we care about stealth projects?
How can we identify stealth projects?
Organizations that have successfully implemented time capture systems have an advantage, but it could also be as simple as managers knowing what their teams are working on, and for the management team as a whole to be committed to identifying and exposing stealth projects.
The outcome should not solely be punishment of the originators of these projects. In many cases, the customer may be unaware of the proper work intake process or may be highlighting a scalability or flexibility issue with the process.
To weed out stealth projects, a well communicated, flexible and scalable work intake process coupled with management commitment to the process is essential. However, this needs to be balanced against fostering a culture that encourages the brainstorming and submission of creative, innovative ideas.
(Note: this article was originally written and published by me in November 2009 on ProjectTimes.com)
We might assume that organizations have well defined criteria that are used to decide which projects should be terminated. Unfortunately, most organizations are haunted by the un-dead corpses of those projects that have survived long past their useful life. A contributing factor to the proliferation of these zombies is the lack of objective criteria as well as inconsistent decision-making regarding project termination.
In this economic climate, the inability to consistently terminate projects is competitive disadvantage as it robs organizations of the ability to focus on high value projects that will help them survive a downturn and come out much stronger on the other side than their competitors.
To improve the consistency of project termination decisions, introduce an impartial project delivery assurance process that gets executed on all active projects (over a certain size) on a quarterly basis. This delivery assurance process could look for the following tell-tale signs of project "rigor mortis":
Do you see a trend?
None of the questions I've asked are using traditional ways of evaluating project health - this does not mean that we are ignoring earned value management, the triple constraint and your issue logs, but we simply can't afford to have successful operations, but dead (or un-dead) patients!
(Note: this article was originally written and published by me in July 2009 on Projecttimes.com)