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)
Organizations that are in the midst of an agile transformation will often track how many projects within their portfolios are being delivered following an agile lifecycle. Obsessing over this number or using it as a basis of comparison, or worse, competition between departments will make it a vanity metric. However, used appropriately, it can be a useful data point for assessing the progress of the transformation.
Knowing how many concurrent projects can be delivered using agile approaches is important because if the organization attempts to execute more than its capacity to deliver, a slew of issues will emerge.
Mandating that core team members will be dedicated to a project or product is important so that many of the beneficial outcomes of agile approaches such as predictable velocity, reduced context switching and increased team cohesion can be achieved. Dedicated product ownership is also needed to ensure that stakeholders needs and wants are being actively solicited and the team is not delayed waiting on decisions or requirement clarification.
But is that enough?
Having sufficient agile leads (e.g. Scrum Masters, XP Coaches) and coaches is also critical to meet increased delivery expectations from business sponsors.
Agile leads need to be focused on a single project. Within that project, they can be supporting more than one team, but to have them juggle different projects will impede their ability to remove blockers, increase alignment and build high-performing teams.
Coaching is needed at the delivery team level but it is equally important to have key stakeholders such as functional managers coached to achieve the necessary mindset and behaviors shifts required for successful adoption. Without this, teams are likely to stall in their agile evolution.
Procuring and retaining competent agile leads and coaches is not easy. They are in high demand due to accelerating demand for agile delivery and finding qualified candidates who have both the experience and cultural fit with your organization is challenging. Like any other hot skill, there will be a limited supply of full-time talent in a geographic area given the number of companies simultaneously conducting agile transformations.
You should certainly have plans being executed to build these skills internally, but this won't happen overnight and if your company has compensation or cultural shortfalls relative to others in the local market, it will be very difficult to build sustained bench strength. You could use contingent staffing to address peaks in demand this is not a long-term, financially viable strategy if increasing organizational agility is truly a strategic objective and not just the "fad du jour".
But not tackling this will just prove Peter Drucker right "In most organizations, the bottleneck is at the top of the bottle."