Who should attend Steering Committees?
As a Stakeholder or Product Owner
I want to understand who should attend the steering committee
So that I know I have the best representation
So the first thing to note is that if you are operating under a construct that has a Steering Committee, you are probably not operating as an Agile organisation and your delivery team will struggle to “be” Agile. However “doing” an Agile approach is still better than a waterfall approach when delivering Data, Analytics or Visualisations.
A Steering Committee’s role is to govern a project and be accountable for making sure the project delivers it’s agreed outcomes to the stakeholders.
In AgileBI approach:
- The Agile Team govern themselves, with the help of the Scrum Master to assist them to improve. They are accountable for delivering what they promise to deliver.
- The Product Owner governs the prioritisation of what is done, and will typically have a group of stakeholders who assist them with the prioritisation. The Product Owner is accountable to make sure the top priorities are delivered first.
- The financials are simple in an AgileBI approach, you take the cost of the Agile Team per day and multiply it by 15 working days for each delivery sprint. You add on the cost of the infrastructure, which is hopefully cloud-based and therefore has a known cost per day.
- The proof of success is shown each ‘Prove it’ day and measured based on the acceptance criteria being met.
So the role typically is undertaken by the Steering Committee, of being accountable for delivery and making sure the project is on budget and is taken care of, without the need to write endless monthly status reports to the Steering Committee or discussing in detail who is doing what with them.
As I have mentioned a Product Owner will often have a group of people that will assist with prioritisation and this will often be done via a prioritisation ceremony. In fact, one of the most effective ways I have seen this happen is for stakeholders to “horsetrade” their deliverables to see who will define the vision statements for the next sprints. This ceremony is not a Steering Committee or a Steering Committee meeting!
If you are stuck in an organisation that is still undergoing the transition to becoming an Agile organisation, and you are forced to operate under a Steering Committee construct, then it is crucial that the Product Owner attends and is the “voice” of the Agile delivery outcomes.
No doubt if you are forced to have a Steering Committee you will also have one (or more) Project Managers. Their role should be to organise the Steering Committee meetings and produce the minutes (think Project Administration) not to be the voice of the delivery team.
And if you are operating under that model you probably also have a formal Project Management Office (PMO) in place as well, so the Project Manager can also add value by completing the myriad of reporting that the PMO will require. Leave them to manage the dross of low-value traditional reporting that waterfall requires.
Leave the Agile Team to deliver and the Product Owner to manage expectations. That, after all, is their role in an AgileBI Approach.

Other Blogs from this category
ODE & 3CPO – Talking multiple languages
When we decided to start building ODE we knew a few things already. One of those things was that most of our customers already had data warehousing technology.
They had already invested in Microsoft, Oracle, IBM, SAS, Teradata, Informatica or any of the other raft of data warehouse repositories and ELT technologies that are abound in the market place.
We also knew that it would be a big decision on their part to throw out this technology and implement the technology we decided to pick to be able to use ODE and gain the AgileBI benefits that it provides.
ODE – The start of a journey
About two years ago we started a journey into the world of AgileBI. It all started out of frustration (as most journeys do), frustration about the magic sauce.
The magic sauce was the reason why one data warehouse project would be a raving success and the next a ‘meh’. It was often the reason that after delivering a raving success and then returning 12 months later I would find the data warehouse had become a ‘meh’. By that I mean not updated, not well managed and not delivering to the stakeholders expectations.
The little things I love about YellowfinBI #5
User Guide Videos! Typically I dislike youtube videos and prefer to follow the tutorials to get something done. But when I was using the Yellowfin Append Sub Query functionality in anger the other day I just couldn't get it to do what I wanted, even as I followed the...
The little things I love about YellowfinBI #4
Subqueries! Often you want to manipulate the data you are using to get a report just the way the user wants. And often this requires you to do sub queries on the data you are using (for me it was creating columns for my measures based on offset periods, so I could...
The little things I love about YellowfinBI #3
Up to date and easy to find documentation! One of the coolest things about Yellowfin is that they do releases every month which includes squashed bugs and a raft of smaller new features, as well as point releases every six months or so, that typically introduce major...
Introduction
As a Reader of this site
I want to understand what it is about
So that I know whether I should keep reading
The little things I love about YellowfinBI #2
Making the impact of editing the semantic layers visible. When you edit a semantic layer that is being used by users, there is a high chance that you are going to effect the Dashboards and Reports they are using. Why? Because you are changing the underlying layer that...
The little things I love about YellowfinBI #1
Additive and Semi Additive Measures! When creating measures in your semantic layer (called Views in Yellowfin, Universes in BO, Information Maps in SAS, RPD in OBIEE etc) its important to be able to define your measures as additive or semi additive to ensure they...
Yellowfin makes changing view names seamless
One of the frustrations I have with many BI products I have used is that they often state all their components are fully integrated. But when you go to use it in anger you find gaps that increase the effort required to do simple things. Often its around metadata...