By Nichole Gable, Principal
Do you work in the Federal Government? Is your office doing analytics? Have you decided to set up an Analytics Organization? Or maybe reinventing your current shop? If you are, you have a lot of decisions to make. How many people do you need? What is the blend of talent? Who are the Federal customers? What analytics will you build? And, most importantly, what is success?
One way to determine success is to measure yourself against a pre-existing maturity curve. Most curves examine the process of how an analytics shop grows from creating small, simple models to large, detailed ones. The ability to deliver large, broad, and complex analytical models is the definition of a mature analytics practice.
But does that work? In practice, delivering these large models into production can take months, if not a year or more. Delivering an analytic should not be like putting up a series of skyscrapers, which can take months to years, but more like building one room and making sure the occupant likes it, before building the next one.
Building an analytic for a Federal mission team should be tackled in an Agile fashion. The first principle in the Agile Manifesto states that “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.* ”. Analytics, like software, strives to solve problems, relying on the same principle. Leverage your Agile mindset: focus on shorter sprints, employ re-usable code, and keep a continuous feedback loop to deliver value at every stage.
We propose that Federal Analytics Organizations should be measured by Frequency of Value Delivery.
Two keys here. First, measure value in terms of Return on Investment (ROI). Second, reduce design complexity in order to increase frequency of delivery. “The art of maximizing the amount of work not done” is critical to Agile execution. Manifesto principle #10. It is our attraction to big, involved models (i.e., complexity bias) that increases our initial design complexity, leftover from our habit of “trying to do too much at one time.” At high levels of complexity, an Analytics Organization cannot deliver frequently enough at a high enough ROI to succeed.
In September 2016, the International Organization of Scientific Research (IOSR) conducted a study on the performance of Agile Scrum projects in an organization, identifying direct relationships between process metrics and quality objectives. One notable observation was that as design complexity increased, so did defects in the final products.**
Continuous, high-value delivery of analytics is the goal. At low maturity or Ad Hoc, frequency is two to four times a year. At a high maturity or Adaptive, frequency can be daily or even every second (think Amazon). What is the difference? Adaptive Organizations have constant interaction with their Federal customer groups, clear definitions of “Done”, high levels of self-assessment, low-to-zero levels of downtime during deployments, high levels of reusable and modular code, high usage of iterative and incremental coding best practices, low levels of unsynchronized data silos, and, of course, high levels of automated testing and deployment protocols.
Analytics Organizations should focus on becoming Adaptive Organizations that can leverage Agile to increase productivity, focus on the Federal customer, shorten time-to-value delivery, and thereby increase value in Federal mission operations over time.
How can we help? Kearney’s Emerging Technology Practice works directly with Federal Analytics Organizations to measure and enhance their maturity. We understand Federal mission-centric organizations and how to apply Agile practices and maturity self-assessments, where required, to enable desired outcomes. Our multi-disciplinary approach incorporates analytics, cost reduction, business model transformation, change management, communications, and process analysis to move the mission forward. If you are interested, reach out to us at 703-931-5600, www.kearneyco.com, we would love to hear from you.
* www.agilemanifesto.org/principles.html
** Srijith Sreenivasan Manimaran Sundaram, “Process performance model for predicting Delivered Defect
Density in a software scrum project,” IOSR Journal of Computer Engineering (IOSR-JCE)
e-ISSN: 2278-0661,p-ISSN: 2278-8727, Volume 18, Issue 5, Ver. IV (Sep. – Oct. 2016), PP 60-73
https://pdfs.semanticscholar.org/fcf6/ed3d5654529eb589ab19888c7319e710853a.pdf