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.
