The Road to Digital – Part III (Execution)

Background

In earlier articles in this series, we explored these aspects from Digital Transformation

  • Digitalization and the beneficial outcomes that one can expect by undertaking a journey in digital transformation.
  • The catalysts in terms of advances in technology that enable digital transformation and a more concrete example of how such a journey would look in a typical enterprise.

In this final article in the series, we will explore how this impacts the people who participate in the journey; how employees need to reinvent themselves so that they continue to be valued; and how enterprises adjust their operating models to take advantage of these trends.

The KYC example in the previous post illustrates how agile methods are used in the software development process. However, agile is not just a software development methodology but applies as much or more to other aspects of the business. Let us stay with the KYC example in the previous to explore this further. The Product Owner for the program was not from the IT department, rather she was selected from the operations group responsible for performing KYC. She had a vision for the end product informed by an understanding of the goals of the program. She directs the communication efforts, alerting the team to significant events that impact the program such as a new regulation that requires capturing added information. She is also responsible for any course-correction that is inevitable in large engagements as we learn to use the feedback from earlier iterations. She does this by managing the backlog and prioritizing features as necessary. The prioritizing activity is a judgment made by her based on the following estimates.

  • Value: Which feature when implemented has the greatest impact on the program. Being part of the business/operations group, she is better equipped to make these decisions rather than someone internal to IT.
  • Development effort: The dev team provides her with an estimate of how easy/difficult it is to develop the capability for a feature.
  • Other operational factors: These could include the effort to train staff if it entails a significant change from current procedures and communications that need to be sent out.
This shift in focus to a value-based operating model has implications for financial models for budgeting and accounting, organization culture, and talent management.

Organizational impacts

Financial Models: Budgeting vs Funding

Most enterprises have an annual budget cycle that looks something like this

  • Somewhere around August, this exercise is kicked off. As the owner of your “cost center”, the manager is required to provide his “ask” in terms of the budget for the next year
  • If lucky, he is notified in November/December, that the ask was granted with an x% reduction. The not so lucky ones get notified in January.
  • In February, he finds out that he is “over budget”. The expenses from December were not properly accrued and the “Carry Over” projects have to be closed.
  • In October, he is informed that he “under budget” and will scramble to use it lest he loses it

The manager’s performance is rated against his ability to stay within budget instead of the value delivered. This inhibits his ability to respond to changes in the operating environment. This misalignment has at least one of two consequences. Technology initiatives tend to deliver lower value or there is opaqueness around work performed.

Here is an alternative approach leveraging agile practices to make a distinction between granting money, viz., budgeting and managing money, viz., funding. Some elements of how such a mechanism might work.

  • Budgets are allocated for specific themes in the annual budget under a broader, (say) three-year program.
  • Product Owners map their themes or epics under the broad budget items.
  • As the user stories within the product backlog are elaborated, the various components of cost are estimated by development and operational teams.
  • Similarly, the expected value of implementing the story will be provided by the product owner. To do this, the product owner works with the user community for a feature enhancement/new capability. If it is to pay off technical debt, the decision will be made based on input from the technical team.
  • As described before, the grooming and prioritization of the product backlog are informed by an assessment of both the cost and associated value.
  • Post-deployment, the value redeemed within the budget cycle is captured.
  • Additional funding is granted based on the value redeemed.
  • Tools used to manage the product backlog are integrated with the financial tools and processes so that the requisite monitoring and alerting happens.
  • Tool integrations also promote transparency in reporting as the underlying data from financial tools and product backlog are synchronized
  • Quarterly/bi-annual reviews could be more productive. Decisions on whether to provide/deny additional funding are informed based on accurate information from the reporting tools.

Cultural

It is well understood that there is a strong correlation between the success of transformation initiatives, organizational culture, and ease of acquiring mindshare with the stakeholders. Let’s explore some strategies to overcome resistance and promoting the status quo. Many of us have encountered/experienced sentiments like this is the way things have always been done or why fix what’s not broke. Here’s a great experiment that illustrates this point. Let us take the same KYC example from the previous article. It is quite possible that employees in different geographies have allegiance to a process followed locally and so resist changes to standardize. Many of these employees may be “traveling in time” on a daily basis. At home, they and their family members frequently interact in social media; they use the latest smartphone; use apps for checklists, calendar, monitoring investments and interacting with various service providers. The same employees when they show up at work may get transported backward in time. They open 15 windows for emails, its attachments, multiple spreadsheets, and proprietary applications often copying data from one window to another. Influencing the employees who do not find this time travel all that appealing by showcasing how the same workflow can be reimagined using a prototype may be helpful.

A consequence of changes in how work gets done is refactoring of the workforce. Many of the advancements in technology also enable operations and other non-IT personnel to self-service themselves instead of relying on IT. With some training on tools like rules engine and tools to author process models, many of the SMEs can work on product/platform teams that manage the workflows. Conway’s law is a significant impediment. Here is one article that discusses strategies to overcome this.

Another consequence of the financial model suggested earlier is that there is more process, but less bureaucracy. Teams that focus on due diligence, governance, and administrative matters can be leaner, but also more effective.

In his book, Dealing with Darwin, Geoffrey Moore describes the idea of core vs context to describe how organizations evolve. A company’s core is what differentiates it from its competition. It is something that gives the company a unique advantage because of an IP or a secret sauce it holds and through which it generates higher revenue or can operate with a higher margin. Context is what the company does that is necessary for it to function, but not a differentiator in the marketplace. In this interview, Moore offers some suggestions for companies to discover their core. Data Science can also help. This is important for digital transformation initiatives when it comes to setting the agenda and prioritization. While determining ROI and where investments need to be made, organizations would prefer to invest in its core.

For example, in financial services, company A may have an established presence and a very high market share but be constrained in its ability to innovate quickly. Company B, a new fintech, on the other hand, could be very agile, quick to market new capabilities. They would likely have greater success in attracting new customers by highlighting a great user experience and less friction during the onboarding process. Company A, on the other hand, may choose to focus on customer retention strategies while it figures out how to disrupt from within in the background – like in the KYC example earlier. As an example, because company A has been around for longer and since it enjoys, greater market share, its ROI when it comes to investing in technologies like AI that leverage data science. As time progresses, company B may be acquired by company A – or company B may choose to reinvent itself. It may be able to offer the algorithms it developed using the large amount of data as a service to other FinTechs.

Another example would be a company that is expanding through mergers and acquisitions. An important goal might be to integrate the various systems in order to provide a unified experience to all parties. Such companies may choose to adopt an API first strategy to further these goals.

Impacts on people and their roles

The KYC illustration in the previous article highlighted the changes in how services are developed, delivered and consumed. For this to be successful, the individuals who develop and deliver these services need to not only develop different/additional skills but also undergo a change in mindset. Let us explore some these in this section.

Developer: In a traditional setting, there were distinct roles associated with requirements gathering, design, coding, testing, deployment, and support. Each of the roles became more important in the corresponding phase of the project. In a typical agile sprint, all these activities are performed within the sprint cycle. The shift toward making more frequent, but smaller releases means there is less opportunity for handoffs across teams. The same team code, test and deploy the software. In addition, they participate in backlog grooming sessions in lieu of traditional activities like requirements gathering, design, and estimation. With the advent of frameworks to support automated testing, the act of testing also involves coding and so the a full stack developer is expected to perform all these activities.

In terms of skill, this means s/he should know her way not just around the traditional development tools like an IDE, but also work with the product backlog and tools used in continuous integration and continuous delivery. Examples of these are Jira, Rally, Confluence, Jenkins, TeamCity, Upsource, git.

Further, it is not just knowledge of these tools, but also the mindset of not being more accountable for what you produce as opposed to throwing stuff “over the wall” to the testing team/documentation team. Working with an agile team can also be different. The team is the unit for which many of the performance metrics around productivity and quality are captured. So the dynamics within the team are different. There is an expectation to share all artifacts/work products even while they are still work in progress.

Project Managers: A project manager typically morphs into a scrum master role. Instead of managing, this person becomes more of a facilitator ensuring that the team follows a routine within each sprint and that removes any impediments that the team may face.

In a traditional project, a major activity for a PM would maintain checklists, add entries as new tasks are discovered and check them off when done by following up with the individuals. In an agile team, there is greater accountability with each developer and s/he is expected to update status directly in the backlog. The scrum master’s role is now elevated to that a process QA - Ensuring that team members feel empowered to perform their activities and removing any friction in the process.

A project manager who understands the business processes; amassed significant subject matter expertise and has nurtured relationships within a user community may also be effective as a product owner in that domain.

Product Owners: We have discussed this role at length. Someone who has the vision and maintains a roadmap for the product; understands the value proposition and makes informed choices on prioritization by weighing expected value against cost estimates. The typical roles and responsibilities of a product owner are well documented. Instead, we focus here on the aspects of this role that are critical from a digital transformation perspective.

The PO is responsible for marketing the product within its user community and other stakeholders and secures funding as necessary. They are in many ways change agents. Creating value also means driving value and promoting adoption. The PO has a good understanding of the organizational dynamics and navigates her way to driving value.

Similar changes should be expected within the support functions that are contextual to the enterprise.

Summary

We saw how organization can use digital trends to transform to reach their growth target and be more efficient. We reviewed some of the catalysts and inhibitors for enterprises starting on this journey. Finally, we also reviewed execution strategies that organizations may consider to implement such a program along the dimensions of people, process and technology.