Governance in an Agile Environment
It’s common for project management to assume that Agile environments aren’t suited to traditional project governance. At its core, Agile environments are self-organising and flexible, and aren’t suited to traditional gate-stage approvals. But is this perception valid? We believe project governance still has a place in Agile environments, but in a slightly different form to how it usually presents.
Defining good governance
The core of this issue lies with one misunderstanding: what governance actually is. Even recently, literature on project governance has been presented from the perspective of traditional linear-based industries and project frameworks.
For many, governance has become synonymous with stage-gate processes and bureaucratic rules that flourish in traditional Waterfall settings. However, they mistake the mechanics of project governance with its function. Whilst building structure and accountability is a critical part of project governance, it is not all that it is employed for.
Project governance is viewed as “the system by which a project is directed and controlled and held to account” (McGrath & Whitty 2015: 781). Therefore, why wouldn’t Agile projects still need and use project governance?
Six Dimensions of Good Governance
Kujala and others (2016) explore six dimensions of project governance:
- Goal setting: ensuring business and other requirements and technical and organisational capabilities are consolidated within the project’s frame and objectives.
- Incentives: aligning project team and stakeholders’ reward and risk-sharing schemas with project targets
- Monitoring: applying practical tools and mechanisms to measure project performance.
- Coordinating: arranging project elements that guide future project actions and communicating those decisions to relevant parties
- Decision-making: ensuring the right people have the right roles with the right responsibilities to make sure project objectives are met.
- Capability building: to build mechanisms that identify the competencies required for projects, and opportunities based on ongoing or past project experiences.
Project governance is thus primarily focused on providing frameworks that help organisations make ethical, effective, and strategically aligned decisions. Project governance is not about excessive controls and bureaucratic processes. Rules for rule’s sake have no purpose.
No matter what type of project you are running, be it Agile or Waterfall, or anything in between, your team needs assistance to build better environments and ensure efficient project delivery.
The Agile Environment and Project Governance: Are they incompatible?
What makes an Agile environment different from any other project government framework? Well, it is primarily their focus on value, flexible requirements, iterative structures, and self-governing qualities.
Unlike traditional ‘top down’ project governance which often focuses on controlling time, scope, and cost, Agile governance is more decentralised. Thus, the emphasis is on empowering teams with the freedom, authority, and capabilities to produce value for the customer.
Good governance in an Agile environment is predominantly focused on the decision-making and capability-building dimensions of project governance. By focusing on how decisions are made, teams commit to the direction of the project regardless of whether they agree. This empowers people to communicate openly and have healthy debates that concentrate on resolving issues and generating solutions.
Building a Bridge
However, just because an Agile environment uses a different approach does not mean it is an entirely different process. Assuming traditional project governance is irrelevant in an Agile-focused project shows a misunderstanding of Agile and traditional project governance.
Once again, the main goal of project governance, irrespective of methodology, is to fulfill the six dimensions cited above. Successful Agile governance requires adapting these dimensions to suit an Agile environment.
Adapting Governance to an Agile Environment
There are a few critical guiding principles for successful Agile project governance. These reflect the Agile manifesto values. Agile favours people over process, value over documentation, collaboration over contract, and responsiveness over sticking to a plan.
Lappi and others have done extensive research on the shifts that needs to be made to the six dimensions of project governance:
Goal-setting
While traditional linear project governance has a front-end focus when setting goals, the Agile environment is much more visionary. However, many Agile teams often use these looser requirements as an excuse not to plan or define goals. Rather than the SMART Goals commonly championed in traditional spaces, Agile teams could benefit from applying CLEAR Goals.
CLEAR goals, which stand for Collaborative, Limited, Emotional, Appreciable, and Refinable, were created by Olympic medalist and entrepreneur Adam Kreek. They are a set of flexible goal-setting approaches that align better with the fast-paced environment of Agile delivery.
Agile goal-setting must also be in line with its emphasis on customer value. The Agile environment’s project goals will not be accurately defined if it cannot measure customer value. This is an important aspect that’s often left unaddressed in traditional project governance.
Incentives
In traditional project governance, success is measured in relation to outcomes linked to time, cost, and scope. Traditional project teams, with their stage-gate processes, are often motivated by the completion of their own individual tasks and responsibilities. However, these outcome-based incentives do not align with the iterative and collaborative structures used in Agile projects.
Success Agile project governance must emphasise the motivation of teams through their shared commitment and performance. Agile projects can be influenced by peer recognition, so rewards should relate to team performance over the individual. Research has shown that developers are much more motivated by empowering, flexible and trust-based approaches than individual recognition and rewards.
Monitoring
Monitoring is all about tracking progress, but if the measure of success is inherently different, so will their measurements. In traditional project governance, monitoring is conducted periodically and is measured against pre-defined benchmarks. These are often confined to the traditional project controls of time, cost and scope. Also, they are usually set out in a top-down fashion during the early stages of project planning.
In an Agile environment, the most common monitoring practices are sprint reviews, testing, and customer validation. Empirical performance metrics are decided by the delivery teams themselves. As mentioned above, the emphasis on customer value throughout the monitoring process is critical to successful Agile project governance. Instead of the traditional periodic monitoring practices, Agile projects emphasise real-time monitoring. Team progress is displayed visually and transparently, allowing full direct visibility to senior management if necessary.
Coordinating
Project governance coordination does not simply mean the coordination of project elements. It also involves setting out the frameworks for collaboration and formalising relationships to enable projects to achieve their required outcomes. A critical part of coordination is making sure team values, objectives, and beliefs are aligned.
In the Agile environment, setting the right culture is one of the most critical factors for successful projects. In fact, the State of Agile report shows that conflicting culture is one of the biggest reasons why projects fail. Agile is all about collaboration and, by extension, good agile project governance needs to facilitate knowledge sharing.
Effective Agile project coordination is dependent on having the right tools. These are tools to visualise performance so they can be prompted to do the right things and collaborate effectively.
Decision-making
Project decision-making is a combination of decision-making priorities and authority, a process project governance is all about. In traditional project governance, decisions are made primarily in accordance with formal and rigid project plans and pre-defined requirements, while Agile projects prefer using the product vision and backlogs to prioritise activities and make decisions.
Additionally, the power and authority to make decisions are also different. In traditional project governance, project managers call the shots throughout the project and escalate decisions if the decision is beyond their level of authority. In Agile settings, decisions are often made with the team, though the prioritisation of activities is dependent on the product backlog and continual engagement with the customer. This fosters open communication and discussion with a clear focus on what is most important – customer value.
While traditional project governance may have a clear chain of command in decision-making, Agile teams allocate responsibilities individually and have a more adaptive leadership approach depending on the task at hand. Leadership can sometimes become blurred in Agile teams and must be established clearly at each stage to minimise time wasted during discussions. These leaders often maintain and manage relationships between the customer and the team to make sure all the relevant requirements are being prioritised.
Capability building
The typical principles of assurance in Agile and traditional projects remain largely similar, however, their means of assessment vary. Agile projects focus on adapting their governance, assurance, and approval processes to their indicators of success that are mainly tied to customer value and team-based processes.
Instead of simply reporting and providing purely data-based reviews, Agile projects rely on observation and engagement with the delivery team to assess opportunities for improvement. Reviews also focus more on team behavior and practices over processes and documentation, aligning with the Agile value of people over process
One of the challenges of Agile projects is its dependence on highly skilled, highly collaborative, self-managing, and self-motivating team members. Agile team members are often allocated to a single product to limit any hand-over complications and to keep teams focused and centralised.
Agile project governance is necessary, just different
Every project team wants to make better decisions and achieve their objective, no matter the methodology. Ultimately, Agile governance is not about adding more rules to a flexible framework, but about establishing the fastest route that creates the most value. Our article hopefully showed you the ways that Agile project governance is still very much relevant, just that they might look a bit different from their traditional counterparts.
pmo365 is all about transforming your project governance with real-time and instantaneous data updates across the organisation. Our PPM experts build integrated solutions that adapt to your organisation’s unique needs, regardless of the project methodologies you employ. If you want to find out more chat directly with our PPM experts to see pmo365 project governance tools in action!
IIR: Introduce, Integrate, Replace
Step 01
Introduce
You cannot run a portfolio on Excel and PowerPoint alone.
Project portfolio management is the discipline of seeing every project in one place, prioritising the work that matters, allocating people against demand, and governing delivery with real numbers. It is not optional at any serious scale. The moment you have more projects than one person can hold in their head, you need a single, current view of status, schedule, cost, resource and risk.
Excel and PowerPoint feel free because there is no licence conversation. The real cost is elsewhere. It is the hours spent maintaining workbooks, the version confusion, and the numbers that go stale the moment they are pasted.
A spreadsheet cannot tell you, on demand, which projects are at risk, where your people are over-committed next quarter, or how much of the portfolio budget is actually spent.
Introducing a proper PPM platform is the first step. Not to add another tool for its own sake, but to give the portfolio one place where the data lives together and stays live.
Step 02
Integrate
The instinct after buying a PPM platform is to make everyone move into it. That is the fastest way to fail. Project managers already have tools they trust, and finance already has systems of record. Force a migration on day one and you get resistance, shadow spreadsheets, and a dataset nobody believes.
Integrate first. Meet the data where it already is. Two directions matter.
Direction 01
Enterprise systems
Connect to the finance or ERP layer so actuals, commitments and budgets flow in automatically. Reporting stops being a monthly reconciliation and becomes a live view. Nobody rekeys a spend figure again.
Direction 02
The tools PMs already use
The direction most platforms neglect, and arguably the more important. The portfolio should read from the PM's own tools, not force people to abandon them.
The reason this matters is simple. That data is already there, and it is kept current by the person closest to it. When the portfolio reads directly from these sources, the status report updates itself. No chasing, no copy and paste, no reporting lag. The PM keeps working the way they always have, and the board gets a live picture as a side effect.
Step 03
Replace
Integration buys you two things: trust, and live data. Once both are in place, you look at what can go.
Every organisation carries tools and spreadsheets that either do not do the job well or carry a heavy maintenance overhead. The classic example is the resource spreadsheet. It is a workbook someone maintains by hand to track who is on what. It is always slightly out of date, owned by one person, and impossible to reconcile against real demand.
Replace it with the equivalent function in your PPM.
A proper demand management capability does what the spreadsheet was reaching for, with none of the overhead. It models demand against capacity across the whole portfolio, updates as projects shift, and needs no manual upkeep.
Replace deliberately, one function at a time, and only after the platform has earned it. The test is simple: if a spreadsheet is high overhead or low quality, and the platform does the same job natively, retire the spreadsheet.
The payoff
You stop producing reports and start reading them
Follow IIR and the nature of reporting changes. The status view is current because it is fed by the tools people already use and the systems that already hold the money. The overhead that used to consume the last week of every month disappears, because there is nothing to assemble.
That is the whole point of real-time reporting. Not a prettier deck, but a portfolio you can look at any day of the month and trust, at a fraction of the effort it takes today.
Built on Microsoft 365. Native ground for IIR.
pmo365 integrates with the tools your teams already run in, so the path from Introduce to Integrate to Replace is a natural progression rather than a rip and replace.