by Procedra Team | May 28, 2020 | Insights
My first thoughts about IT Modernization usually focus on the intersection between the technology and the customer experience: is the element that is being “modernized” resulting in a positive impact on the customer experience? Not just externally, but internally. Has the human experience been taken into consideration during the decision to modernize?
More often than not, it isn’t. Decision makers spend wildly, chasing buzzwords like speed, scalability, agility, transformation, reduction in costs, automation, security. Those are great things to aspire to accomplish. How is that being accomplished through spending exorbitant amounts of money with no end goal in mind?
Earlier this spring in a Nextgov article explored what federal agencies do best when it comes to IT Modernization. They noticed what I’ve often noticed in decision makers in this example: “They’ve heard about artificial intelligence and so they chase implementations without taking into account the larger context, the overall business needs and mission imperative.” In short, they’ve gone right past the human element and chased all the promises that will happen after this conversion. Updated systems and tools without understanding on how, who, and where customers are using those tools leads to a failing strategy.
The customer experience for government agencies has to be part of the IT modernization strategy. Over the last two months, we’ve seen why the customer experience has to be tantamount: how many over 35 million Americans have been able to file for unemployment? How many have received their initial stimulus payments? A brand new website doesn’t address the 40-year old COBOL processing system and how it isn’t compatible with the user interface.
IT modernization efforts need to be more than just an enhancement of what is already in place. It has to be more than just improving cybersecurity, or upgrading an existing platform. Yes, sometimes it is a matter of replacing a legacy system, but is what you are replacing the antiquated system compatible with other systems? Is your team able to adapt quickly and efficiently?
We now have the ability to analyze massive amounts of data to create predictive models to seal the gap between developing and implementing new products. Agile and customer-focused product development have shortened the time to adapt to new technologies. Our behavior has fostered a quicker adaptation, too. Before, technology was forced up on us and we just had to adapt. Now, technology is seen as an enhancement to the experience, not the fix. And that is due to importance being placed on CX strategies.
IT modernization should be aligned with that change to continue to seal the gap and provide easy experiences to customers. The need for a continuous process governed and executed by an overarching CX strategy will help keep costs down and focus efforts on selecting and implementing the best option for both a better internal and external customer experience.
by Procedra Team | Sep 10, 2019 | Insights
Lately, I’ve had a lot of conversations about the main drivers within an organization to be more efficient and bring value to customers: it’s a mindset for a culture to become agile and customer centric.
As a product expert, I have worked in different environments, industries and companies of all sizes, from startups to enterprises to government. I think it is fair to say that no matter the industry or environment, we’ve all shared the same experience: there’s no systematic process or solution to define and solve problems, a “one size fits all.” What may work for one organization may not work for another.
Organizations are complex people and systems, and change is never easy. I have seen how becoming agile – not being, not implementing the change quickly, but becoming agile – has enabled us to make sense of what we are trying to achieve. It’s not just team structures, or agile process applications, or using the latest agile tools, rushing to modernize systems and processes without clear definition of ‘modernization’. Becoming agile is a culture change.
I’ve led organizations and teams on the path to becoming agile and changing to a more product- and user-centric mindset instead of being a process or project driven. I’ve heard and experienced some resistance while trying to eliminate the mentality of “We’ve been doing this for years and it’s working, it’s successful, why do we need to change the way we’ve been doing it now?” Many find it difficult to incorporate the human element into the process and asking your the whole of your team to operate transparently and collectively.
As humans, we tend to adapt certain habits, get anchored to them. We avoid change, even though we know things aren’t working, or they aren’t efficient. Oddly enough, this is the core of agile: the flexibility, the incremental delivery for discovery and feedback, to abandon something when it isn’t working and collaborate with everyone to find a new path to progress.
The first step is to be open to embrace change. I have had to be agile in how I work with organizations: not every approach I used to help teams become agile. It may not work the same or has the same impact at each place: it is a mindset, a culture change. As leaders, we should push towards creating an uncomfortable situation for adapting new habits, help teams to become critical thinkers, problem-solver, and finder of opportunities, among other attractive qualities.
It is breaking down siloed thinking shaped by your role defined on paper and tapping into everyone’s skills. I believe it’s important to get uncomfortable until you get comfortable. an environment of vulnerability that many people haven’t worked in before and will feel uncomfortable, even threatened at times. Leaders need to be part of change and encourage a culture of collaboration, transparency and innovation. They need to reflect that transparency, that vulnerability too.
Secondly, recognize that resilience is key, because you are taking an iterative approach to building products. Becoming more resilient as iterations go by involves dealing with uncertainty and complexity. You are constantly “back at the drawing board” – adapting a certain pace to quickly ship product while you are collecting feedback and improving – simultaneously. As leaders, we must help implement agile gradually. We must check on collected concerns of our team as they move along with agile to eliminate uncertainties and risks.
Agile provides the ability to adapt to changes quickly and easily with a sense of purpose, specially when it comes to building MVP’s and responding to the users needs. You reduce risks and eliminate uncertainties. You are facilitating the road to innovation, which requires patience, perseverance, and again, resilience.
Third, acknowledge small wins start by clearly articulate the mission and how the product brings value to people’s life. Speaking in one voice, to encourage collaboration and eliminate the mentality of “it’s not my job” or “it’s outside my area.” These small wins include sharing customers’ feedback across teams so that everyone can realign with the mission.
I’ve seen and lived those experiences, similar to the above scenarios. I have worked where business takes the “waterfall” approach with their decision-making process and getting approvals, but developing the product is “agile” meaning they had scrum teams. That doesn’t work: business must embrace and adapt to all of agile, which I have seen positively impact product quality and timeline or speed to market – the human value and user-centric mentality was missing from the core of product development. Being agile means to produce a product for specific needs, not strictly the bottom line.
You are not striving to be efficient in focus on your customers and product if:
· you are an organization who doesn’t embrace or foster a culture of collaboration and innovation
· you are an organization who build your product based on business assumptions and preferences in the absence of a user research and feedback or engagement early in the process
· you have a lengthy approval process that affects sprints and teams velocity
· you are an organization who doesn’t listen to employees and collect feedback and concerns
· your DevOps is not integrated in the agile development process to improve operation, development, monitoring and performance in nowadays IT complex structure
- You have ‘ego’ implemented in the process
- Your org structure is not aligned with your vision and goals, when you have so many management layers and titles that don’t make sense
I would love to hear about your experiences changing or influencing your organization’s culture to become more efficient and product centric. What challenges have you faced? How has your team adapted.
