Excessive lead times in procurement cycles can impact company goals and slow the adoption of innovative applications that can improve customer journeys.
Customer experience continues to be at the forefront of everything that successful firms do. And more and more, banks, insurance companies, and other financial institutions are turning to software to help build, deliver, and incrementally improve that engagement while meeting the unending compliance changes by regulators. In fact, being successful could mean behaving more like a software company – one that takes an agile approach to quickly create products and services that customers want as part of their everyday life experiences – like remote deposits, business overdraft services, unsecured lending and ways to grow their savings.
See also: Agile Ways to Transform How You Work with Data
Procurement has long been an important aspect to technology adoption, helping to drive the kind of innovative investments financial firms increasingly want to make. Just like with software delivery, procurement itself needs to become more agile continually. ‘Agile procurement’ is basically a fancy way of saying that the method by which approval and acquisition of buying IT components and services need to keep pace with the ever-changing needs of the business (who, in turn, are striving to keep up with customers).
In traditional procurement processes, business and development teams typically have long and often frustrating cycles, that at times can even be combative interactions related to selecting, negotiating, contracting, and, if all goes well, procuring technology. And in organizations that are top-down heavy, this process can extend to a point where the expected benefits of the technology adoption is negatively impacted. Procurement processes are often the final stop before new technology adoption, happening after the desired technology has been vetted by the business and IT groups. However, fraught with long lead times and requirements gathering, feedback cycles, multi-tier governance, traditional approval policies, and big-budget justifications are often still the norm.
Impacting company goals, such excessive lead times in procurement cycles, can impact company goals and slow the adoption of innovative applications that can improve customer journeys. In worst-case scenarios, companies may delay technology adoption to the point that the opportunity passes by, and competitors get a first-mover advantage.
Applying IT practices to the business
Another common behavior seen in procurement activities is the purchasing of software, hardware, and services in silos or independently of each other. However, these components are highly interdependent, typically necessary to create a complete business solution and need to all be used together, simultaneously – so they should all be procured together as well. Once all the hardware, software, and associated services have been procured and signed off, the next significant issue is having the IT team implement and apply these new capabilities within their existing environments, people, processes, cultures, and policies. While new technology can provide great promise – long term success and adoption is hindered when it’s assessed independently of how it would actually work in practice, that is, within the company’s existing architecture, staff, processes, governance policies, and most importantly, cross-functional teams. This can be exacerbated with long lead times and the associated large planning and requirement cycles.
Enter the change agent – agile procurement & DevOps
To help address these problems, adopting an iterative, fast feedback, and learning-based procurement model can make improvements that increase the speed to market. Agile procurement takes its lead from the significant and dramatic improvements the DevOps movement has brought into development processes. Agile development involves:
- Minimal viable product and requirements gathering
- Shorter planning cycles
- Iterative development and continuous releases
- Deploy, test, validate, feedback, adjust or fix and release again cycles
- Ongoing learning with full transparency for fail fast or succeed earlier conclusions
In this model, business sits next to IT development and operations, to learn together and focus on business outcomes at each step of the process.
These same DevOps principles become more pertinent to streamlining procurement processes, particularly when coupled with applying cutting-edge technologies to a new initiative that impacts the firm across the full spectrum of people, business processes, technology adoption, organizational policies, and the culture of the firm.
The question then is, how? First, you need to start with a project based on a pilot or MVP – picking one that is key to the business and will prove the desired technology. Then, assign a smaller subset of a pilot budget, selecting the tools to use and that bring together the business and IT teams related to the pilot, so they collectively agree to execute on that MVP. Moving into delivery, these next steps follow in succession:
- Use agile, DevOps and open practices methodologies for the MVP
- Solicit feedback from the sponsors as progress is made, showing actual code weekly
- Assess the impact and changes needed in the behavior of staff, the policies that prevent work from being done and address these issues as they come up during the MVP process
- Work closely across teams to understand the practice of using the tool sets that work best, collectively
- And then finally measure the outcomes of behavior changes, teaming, usability of the technologies, and ways to get work done (noting practices that worked best to date)
At the end of the agile development process, the business is able to make a go /no-go decision about proceeding with further phases and has learned a significant amount about the impact the new technology can make. The organization learns what needs to change to enhance performance and answers the questions procurement has along the way. The feedback cycles in this agile procurement approach often can slash technology acquisition cycles from 12 months to 6 to 9 weeks. It provides real-time insights into performance and puts customer experience at the forefront of the business.
