Analytics Sausage Factory - stay lean and mean

I recently got asked by Head of Business Services concerned about the backlog of report requests for the BI team. The BI infrastructure and BI team had been in place for a year and have decided on an Agile approach, but were not able to keep up with the demand. Thus, this article is about how to produce more sausages (reports) from the sausage factory (BI team).

I think the keys to success in such a situation are:

• Stakeholder management
• Lean principles
• Avoid Agile methodology pitfalls

Stakeholder Management

First, this is a good position to be in where business is become fact focused and have the desire to make more informed decisions. The team should understand who are the data consumers, power users and champions in the organisation, as the amount of time required for each individual is quite different.

Second, establish service interface:

• Set expectations. Publish how requests should be made and how they will be processed
• Ticket system to track requests status
• Template for report requests e.g. title, purpose, owner, risks, data quality issues, etc.

Third, have regular ticket review process with the team. The key questions are:

• Is the report request template correctly filled out? If not, send back to requester
• What is the priority? Appropriately triage requests
• Are there already similar reports that can be modified and reused?
• Is this a Project request? e.g. extra resources and time will be needed to address reports of a similar nature together

Tips:

• Explain what Bimodal IT is and what you offer to the customer. Mode 1 is like a marathon runner, while Mode 2 is like a sprinter. They differ in terms of goals, value, approach, governance, sourcing, talent, culture and cycle times. These make very different promises of experience to the end-user.
• Put a lot of thought into the report template. This template should be a live wiki document that is worked on by report owner, developer, tester and users. There needs to be a named business owner for each report who is responsible for its accuracy. It should also contain business rules, data quality issues and potential enhancement plans. It should be the one place to go to for any questions related to the report.
• Published registers will reduce the communication overhead. BI team should maintain these registers:
• Publish production report registry (i.e. completed report template) so that business is aware of what reports that they already have
• Publish report progress registry so that business can review ensure BI team stays focused on things that matter
• Publish data quality issue registry ordered by source system
• Publish master data sets and have assigned owners
• Secondment of subject matter experts (e.g. finance, HR, operations, etc.) on a part-time to be part of the BI team allows important knowledge sharing and upskilling. This will also educate source system owners on enhancing / correcting the data for reporting purposes. Also, secondment of a BI team member into the Finance department can mean faster production of finance reports.

Lean Principle

The key principles behind lean is:

• Eliminate waste i.e. non-value adding activities e.g. transportation (e.g. hand-over), waiting (e.g. clarification in requirements), overproduction (e.g. too many similar reports), defects (e.g. error in data entry), inventory (e.g. reports that are not even used), movement (e.g. report ownership changing), extra processing (e.g. data cleansing).
• Reduce rework - some rework is unavoidable in Agile (see next section for more detail)
• Even out the pipeline - a machine has an optimal performance range e.g. faster speed consumes too much fuel and causes excessive fatigue, while too slow is unproductive
• Enhance entire value flow - the horizontal flow of products / services that interact with multiple technologies, assets and departments

The cost to fix things increase as things progress down the line. E.g. changing the business rules for a report at the development phase is much easier than in the productionisation phase. Therefore, the more effort put up-front will save you more work later. Systematically addressing root cause rather than dealing with signs and symptoms is critical.

Practical tips:

• Simplify and standardise processes with templates. If there is a need to clarify requirements (e.g. requester did not think things through enough, new stakeholders that were not identified at the start), the art of the gentle push back is essential here!
• Empower and cross-train BI team members so that each individual can complete a report end-to-end. Break-down silo thinking and encouraging departments to become cross-functional. Secondments is a great way.
• Wikis are great places for knowledge capture and management. Explanation of report figures always happen (e.g. report owner changes, others want to use the report). That is why a report registry is critical.
• Build data quality checks - lack of quality in data entry results in the need for data cleansing and manual adjustments later. Have a live data master data register that alerts the relevant owners automatically.
• Consolidate operational systems and processes. E.g. post-merger of company, is two Financial and HR systems necessary? Use the data warehouse to help you migrate

Avoid Agile Methodology Pitfalls

The business demand that information be at their fingertips immediately can create a lot of wastage. Agile’s benefits can be higher productivity, better quality, less user resistance and greater customer satisfaction. IT needs to balance this with the need to building infrastructure that is understandable, sustainable and expandable.

The current Agile methodology advocated by Tableau is called Drive. It has four phases:

1. Discovery
2. Prototype
3. Foundation Building
4. Scale Out

From the steps, you can see Agile is geared towards getting business buy-in and short-cutting issues of uncertainty. With this methodology, business also needs to be heavily committed from the start and throughout the process.

Pitfalls of Agile Methodology are:

• Over-promising buy the BI team leads to post sprint demos are smoke and mirrors. You may get away with it the first few times, but the effort to keep this up eventually takes more time than getting real work done. I believe transparency and realistic targets is the best policy.
• Product owner not prepared for the time taken for specification clarification and testing all the time. Product owners need to understand they need to provide clear business cases and stories, and cannot let things slide and expect to pick up the pieces during productionisation testing. Agile means requirements just in-time for developers i.e. greater collaboration between product owners and developers. I have seen many projects mis-managed because the business questions were not comprehensively collected or questions not understood and answered by business. Because testing is happening every cycle, and automated regression testing process is mandatory. 
• Product owner not focused on MVP (minimum viable product). If you are building a car, focus on building that gets you from A to B. If you are building a report, focus on ensuring that the numbers are correct and everyone understand what they mean.  
• Product backlog is organised by the development team. Business representative, ideally part of the team, should drive the product prioritisation. Vice versa, the business should not be deciding on the technical solution for the development team.
• Creating your own bottle necks outside the team i.e. just because you implement Agile in one department, does not mean other departments will or can react as quickly. I have seen a few occasions in the BI setting where the ETL developers are following a waterfall process, while the front-end report developers are following an Agile process, because each team had a different manager and different priorities. Creating cross-functional teams via cross-training or secondments is one of the ways to address this.
• BI team and product owners not properly educated on learning from failure each cycle. The basis of Agile is that you are actually learning the most from failure and further requirements and specifications come out with each cycle. Be prepared to change your thinking and direction as new information is learned.
• Setting, measuring and rewarding milestones. I recommend at least three environment: development, test and production. Plan your stable releases into production.
• Taking short-cuts that bite you later, or scaling out to quickly based on a successful prototype. See underneath.

I think Agile BI is useful for businesses in the very early stages of BI maturity, but can prevent efficiency at larger scales i.e. cranking up the sausage factory. Foundational pieces for successful Agile BI are:

• Executive support - continual input to make timely strategic decisions
• Answers to complex business questions - Agile do not make these questions go away, but allows these questions to be answered later where more information is available
• Collaboration and trust - Agile is about “failing” quickly and cheaply in order to gradually to get to an end goal. The organisational culture must be supportive of continual learning and change.
• Architecture - e.g. Data warehouse, Master Data, Star Schemas. I believe that you can only be Agile if you have strong foundations. Building quickly on sand means that the reports will become outdated and inflexible very quickly.
• Reconciliation database (to ensure data quality)
• Documentation (solution design, user guides, etc.)

Tools like Tableau are very good at bypassing the above, but these foundational pieces are still important to ensure consistency and efficiency in reporting. Agile does not necessarily mean that that you reach the end point-faster, but does ensure constant successes along the way to ensure you are heading in the right direction.

Thanks for reading. I would appreciate any feedback or lessons learnt from other project managers.

Kind Regards,

Gary