When working with stakeholders, it is important to keep them up to date. Project Governance is the procedures and processes used to keep those with an interest in the project up to date. Maintaining a defined process of communicating changes is also a requirement in some external certification agencies process. We use three main ways of communicating what is being done with stakeholders: ticketing system (Jira), Monthly reports, and Quarterly meetings. I’ll start with a brief discussion on the ticketing system, but you can find more discussion on the importance of the ticketing system in our blog How to Run a Help Desk. Then I’ll discuss the monthly reports we provide which are fairly simple. After that I’ll go into much greater detail about the Review Meetings discussing the importance of:

  • Setting Regular Review meetings. Ours are Quarterly.
  • Keeping Records of Meetings
  • Keep structure Consistent and Refer back to previous meetings.

In addition, I’ll discuss some of the standard project governance aspects that most companies use that I have found to be less than useful so I threw them out to generate cost savings for Flying Donkey and our clients.

Ticketing System

The role of the ticketing system is crucial in project governance. We use it daily so our clients can report new issues, assign employees to manage the issues and keep track of the progress. This allows us to be agile in our framework and adjust priorities based on client needs. It keeps our projects moving along and helps us manage hundreds of tasks per month across our client base. It also assists in creating the list of tasks we accomplished during the monthly reports and quarterly meetings. You can narrow the issues down to closed issues and projects they are associated with making it a breeze to summarise your project progress.

Monthly Reports

Our monthly reports are pretty simple. They consist of the identifier, the issue description, project they are associated with, hours worked, hours credited (if any), reason for hours credited (if applicable), and billable hours. They look similar to the spreadsheet below. These are quick updates that come with the monthly billing to help understand where the time and money was spent. Quarterly Meetings

The quarterly meetings are the cornerstone of our project governance. These are typically one hour calls with the client that cover the entirety of what we have done during the previous quarter, issues we encountered that need to be solved, and what we will be doing the next quarter. There are specific strategies that help make these conversations meaningful including do them routinely, keep records of the meetings, and keeping structure consistent.

Have the Meetings Routinely

Routine meetings help keep consistency and make it easy for management and staff to know what needs to be done when. We chose quarterly because we find it to be a good way to be more efficient than daily, weekly, and even monthly meetings. I’ve found that daily/weekly updates add no value. What management teams really want are high level updates. Rarely enough movement occurs in a single day or week to justify the frequency of meetings. It slows down the developers, wastes clients money, and honestly creates no value. Monthly and quarterly updates provide more meaningful business feedback and reduces administrative costs. The tech industry median SG&A is 35.5% according to SAI Books SGA Benchmarks, while we average around 25% which is a savings we can pass on to our clients.

Keep Records

We typically do video meetings so we keep records of the meetings in 2 ways: text and video. The text documents look like the item above which is an actual meeting agenda we use to cover the completed quarter’s review and discussion on the upcoming quarter. Because we are doing video conferencing we can show clients any screens or functionality they need to see for verification of any services completed at the last minute that have not already been approved for completion. We record these conversations in case developers need information from them or someone can’t be present.

Keep the Structure Consistent

Consistency in structure is important. It makes looking backwards easier. This will come in handy for companies that want annual reports as well. You will be able to combine reports where everyone can easily see the services that have been completed and the benefits they have created. In addition, it will help you see areas you can improve as an organization. For instance, we had a developer who didn’t fully understand our development process and we had to train him better on the process we use and the reasons following the process is important. Acknowledging this issue resulted in two benefits, a better trained employee and clients that trust us to own our mistakes.

Standard Project Governance Practices I Rejected

This final section is going to cover some of the project governance practices that are industry norms that I have found mostly waste time. The three main things I have rejected are:

  • issues and risk log
  • overall big project plan
  • Daily and weekly management meetings

I have good reason for rejecting these so let me explain the value of rejecting these industry norms.

Risk logs

While being prepared for risks is important, I have found that the work put into them gets ignored. Staff don’t refer to them before starting work. In addition, people rarely update the risk logs to make sure we have better solutions to solve them going forward. People learn by making mistakes and catching them. It’s how we grow. I’ve found that it helps the team become more effective by tracking retrospective issues. This provides learning opportunities for the team and takes about the same amount of time as predicting risks and planning how to mitigate them.

Everyone is familiar with Murphy’s law, but there are actually a set of laws two of which really stand out as reasons why the risk management process is rarely beneficial:

“If plan for four possibilities how something can go wrong, inevitably another possibility will present itself that you then have to solve.”

And

“If there is a possibility of several things going wrong, the one that will cause the most damage will be the first one to go wrong.”

These two “laws” show that inevitably we will have to figure something out so why spend time planning for mistakes when we can allow them to happen organically and prevent future ones through developing our problem solving skills.

The Big Plan

It’s natural to want to look at the big picture, but the software development world changes so fast that trying to have a full plan makes no sense. The idea of a big plan is based on the waterfall approach to project management. In theory it is great, but in reality it has problems. It takes a ton of time to plan, implement, and deploy. By the time it deploys, the software might not fit the current business.

Quick sprints that solve a single business problem, make more sense. They can be prioritised and implemented based on how much business value they offer. You’ll see results quicker and may find parts of “the big plan” that were thought to be important are really meaningless. So lets focus on a single feature, get it right, and move on to the next. By doing this we have software that is easier to update and maintain as well because it is built in modules that don’t require full program changes for a specific aspect of the software.

While we don’t conform to all the standard industry practices regarding project governance, we have focused on finding ways to run a leaner development team with less meeting taking up unnecessary management time. This strategy creates benefits of having structured project governance including:

  • Better documentation
  • Easier planning
  • Reinforcing a routine
  • Developing closer business relationships
  • Learning from mistakes.
  • Compliance with business governance certifications.
  • and many more.

If you have any questions about project governance, technology compliance, or anything else, please reach out to me.