This post is an excerpt from a whitepaper, authored by Nicus Chief Product Officer Amit Kumar, titled “IT Financials in an Agile and Product-centric World.”
According to a 2018 Gartner Survey, 85% of respondents’ IT organizations have either adopted, or plan to adopt, a product-centric approach – with the majority expecting to have more than 80% of work under a product-centric model by 2022.
Traditionally, an IT organization’s primary purpose was to “keep the lights on” for the business: keep the systems running, and make sure the service-level agreements (SLAs) are met, the downtime is minimized, and support is available when needed and when promised. The focus was very much on being a behind-the-scenes enabler. IT was not a core part of driving business outcomes – in other words, a cost center.
In the last decade or so, there have been some fundamental shifts in the technology environment and how companies go to market as well as what they consider drivers and differentiators in the market.
Imagine this – an elevator company, Kone, considers itself a data company first and an elevator manufacturer next; a paper products company, Georgia Pacific, considers itself a technology company first, with a focus on IoT and edge-enabled devices ultimately driving its paper product business. It’s not an exaggeration to say that almost all business organizations are technology-driven organizations now. Technology drives differentiation and new business models. Organizations that do not embrace it will not survive the next decade.
A few key trends have fundamentally changed the equation for most organizations:
• Advancement of Cloud and SaaS
• Digital innovation/transformation
• Customer and user preference changes
These trends have driven how businesses view their own technology orientation and the IT organization’s role in helping drive these changes. IT has shifted/is shifting from being a cost center to a value driver. CIOs are no longer focused on keeping the lights on. CIOs, and by extension their IT departments, are key partners and drivers of this transformation.
This change has led to a shift toward a product-centric IT organization. Historically, this was the domain of software companies that were bringing a software product to the market. Now, IT needs to drive business outcomes, and it’s not enough to just keep the lights on. The technology and software systems being managed and built by IT must meet and exceed the typical standards that were traditionally reserved only for market-facing products. Elements like user satisfaction, continuous iteration and improvement, performance, and privacy considerations are core to this exercise.
1. IT is a close partner to the rest of the business. The focus is on driving business outcomes, and all developmental activities are directed toward driving business outcomes for products or business value streams.
2. The budgeting and investment approach required is different from a project-centric organization.
a. IT organizations need to be prepared to invest for the “longer” haul. The first one to two years for a product usually require investments until the returns become apparent.
b. The approach also needs to be a milestone-based, iterative approach assuming a much longer product lifecycle versus a finite short-term, project-based investment. Evaluate the performance and goals at each milestone and guide efforts toward the right business outcome.
3. Finally, as we discussed earlier, the development approach is a very iterative Agile approach. Feedback is taken constantly, and direction and plans are tweaked to achieve the right product/business outcomes.
Making the shift from project to product is comparable to creating a product-centric technology organization, like becoming a software or digital business.
The biggest consideration here is that the development approaches have shifted from a Waterfall to an Agile approach. In a Waterfall approach, there is a distinction between Development and Pre- and Post-Development periods.
As Figure 1 illustrates, with a clear distinction between these periods and the associated activities, the accounting and financial exercise of identifying expensed versus capitalized items is much easier.
In an Agile world, this distinction is not as clear since a lot of the design, planning, testing, and
implementation activities are an ongoing and integral part of the Agile sprints.
Furthermore, Agile is characterized by a 1:1 team – product/value stream relationship. In other words, it is encouraged to have a team (and all its members) own and manage all aspects related to one product (or pieces of a larger product). The team continues to not only build out the product but also have responsibility to support it over time. While this is very beneficial for the quality and sustenance of the product, this creates some challenges for the appropriate financial alignment of the effort.
There are some changes to accounting that need to be considered in an Agile development approach; however, the core fundamentals are really not that different from Waterfall:
• The link between a development activity and the primary outcome still needs to be understood.
• The contribution of an activity/person/team to the outcome needs to be understood.
Obviously from a pure finance and accounting perspective, it will always be better to have a very granular and time-based recording of all Agile and sprint activities, for each person at all times. If this level of detail exists, then it’s immaterial if the process is Waterfall or Agile or some other approach to development. With this approach, the detailed analysis of which tasks, and how many hours (and dollars), can ultimately be aligned to the type of expense for a day, week, sprint, release or any other increment desired.
While this method is ideal for finance/accounting, it is not recommended for an Agile approach for a few reasons.
Download the full whitepaper to continue reading…