In this article we will look at project governance. It's a key element of successful delivery, and stakeholder communication is critical regardless of methodology.

Stakeholder communication is critical regardless of the methodology. A few thoughts from different projects:

• On Agile projects it is easy to focus on the business stakeholders you are working with and assume they are updating the wider stakeholder community. On small projects this may not be an issue, but it could become a serious one on a large or business-critical programme.

To add more detail to this, let’s look at two projects. The first one is a development project for a single department. The application is going to be used only by the department, and the manager of the department is working on the project. Also, the application is going to be deployed to existing infrastructure. In this scenario stakeholder management should be covered.

The second project is a major transformation involving multiple business and IT departments. PRINCE2 Agile is being used to manage this activity. Assume that people in the business and IT departments are part of the project team. You will communicate with them in the daily standups, but don’t forget the requirement to update senior stakeholders on a regular basis. 

• Include good and bad news in the updates. 
• Be completely transparent about the issues and challenges the project is facing. Stakeholders appreciate transparency and hate surprises. 
• Always include the steps you are taking to resolve the issues in the communication.

Project Board

There is an ongoing debate that formal project governance and Agile can’t coexist, but let’s think about this. If you are running a project with five developers, then you won’t need a project board. Or will you?

• If you are using Agile (or elements of Agile) for a major programme that will impact the whole organisation, the stakeholders will probably want to have a project board. I would argue that you, as the project manager or Scrum Master, would want it even if the stakeholders do not request it.

• If the project involves a small development team and only one department will use the application (and the manager is part of the team), then you won’t need a Project Board. This project can be managed under Agile and not a hybrid methodology.

• The key point is to think about the criticality of the application. In some circumstances the development team may be small, but the project is critical and affects the whole organisation.

Many projects in the real world are not pure Agile or Waterfall. They are a combination of the best parts of the methodologies based on the organisation’s maturity with Agile and the size, complexity and risk of the project.

If you are working on a business-critical project with hundreds of IT staff that will impact virtually everyone in the organisation, the senior managers will need to be involved in the governance. This isn’t incompatible with Agile; think of it as a useful addition. The project board is responsible for supporting you and removing blockers. On a large, complex project they will be able to do this far more efficiently than a project manager could. 

We’ll look at traditional programme boards using Waterfall methodology next, and then we’ll move on to Agile governance.

Waterfall Programme Boards

Role of the Programme Board

• The programme board consists of senior stakeholders with overall responsibility for delivery of the project.
• The programme board is there to support the project and to ensure the correct governance is being followed.
• If there is an issue that cannot be resolved by the project team, it should be escalated to the programme board.

Waterfall Programme Board Responsibilities

Typical key responsibilities of the programme board are:

• Agree on the objectives and deliverables of the programme.
• Review the programme team’s work to ensure that the expected benefits will be realised. 
• Approve initiation and the programme stages.
• Review requests to change the programme’s scope, budget, timeline, benefits or critical success factors.
• Appoint a programme manager. 
• Sign off on the Project Initiation document.
• Approve the project plan.
• Agree on tolerances for quality, timescales and budget.
• Approve of the project phases. (Including approval to proceed to the next phase.)
• Manage resolution of variances from the agreed plan.
• The programme’s strategic direction.

Agile Project Governance

The governance procedures on Agile projects take a different approach compared to Waterfall projects. 

The main differences are:

• The authority to make decisions is delegated to the Agile teams. The main benefits of the Agile governance model are:
• It enhances an organisation’s overall Agile processes.
• It increases the efficiency of making decisions when there is a requirement to escalate an issue.
• Collaborative decision-making is encouraged.
• Everyone responsible for delivery is involved in project governance. Planning meetings, standups and retrospectives are all used as part of the governance process.
• Delivery managers, service owners, support team managers, technical architects, security managers, change managers, data architects and chief information officers may also support the delivery teams. It may be appropriate for these roles to be involved in project governance.

The Agile governance model is based on the core principles as outlined in the Agile Manifesto. This results in teams being supported, but not managed, by the governance process. The role of the stakeholders is to support the team.