Historical and Future Costs

Since late 2017 we have been working on sharpening the saw when it comes to governance of historical and future costs related to software development and delivery.

We were in need of better control of historical cost, both capital expenditures (capex) and operational expenditures (opex). Simply seen; new value creating projects/application functionality are seen as capex, and application maintenance/systems operation as opex.

The teams are responsible for maintaining a set of applications in our business capability map, and they deliver new software features to different business projects. The business project can involve value chains that consumes features of many applications.

Application work might include work such as requirements, design, implementation, testing, devops. Project work might include project management, quality assurance, roll-out.

So, we had a need of "wiring" up all these elements to get answers such as: 

• In total; what are our Capex/Opex for a given period?
• What are top 5 Capex for a given period, amongst all applications?
• What are top 5 Opex for a given period, amongst all applications?
• How is team A when it comes to Opex/Capex, what is the application distribution?
• What applications have the lowest Opex?
• For a given project, what features are linked to it?
• What is the total project cost, including application work across teams?
• Which developers are mainly doing maintenance work etc?

We have of course different developers and others at different hourly rates. 

We decided to model this picture in Genus Apps (www.genus.no), a fast and reliable model based application development, a no code choice that also runs in the cloud. After a couple of weeks the application was ready and put in production early january 2018. We executed training on a team-by-team basis, and had an internal expert and a Genus modeler following the teams during the initial period. 

Everyone logs their working hours in the Genus system, the hours are logged on the correct application feature (capex) or application (opex) for the eventually wired project for the given feature. A timestamp is provided, and the person logging the time is already wired to a team. Hourly rates are stored in Genus.

With this system in place we had a fairly good control of historical cost, the system creates inputs for SAP accounting.

We also needed better control of future estimated costs. For this we are using Jira, and we estimate product feature / project costs in Jira. We have integrated Jira and Genus, so that:

• Features can be automatically created from Jira to Genus
• Hours spent on a feature are "transferred" back to Jira
• Estimates for a feature is "transferred" to Genus
• We can see what features are linked to different business projects

Basically a bi-directional synchronization of data. One gets control of consumed number of hours, vs estimate per feature (the same for project activities).

We can generate future estimated capex and opex load per team and application. Information that are used in the rolling budgeting process.

Today we have better control of historical and future costs. Key success factors include; business support, knowing what information you need, user support during implementation, instant answer on daily questions, clear definitions of work (what is capex/opex), great partnership, internal cooperation with accounting.

There are of course many other resolutions to this common type of problems, and we have our challenges. But, all in all; we have better control of capex and opex than before. We have automated routines for business reporting to top level management, at all time updated numbers at a good enough level. That of doing the right things is absolutely identified during the estimation effort. The business in involved and get an early indication of estimated cost. The balance of the historical cost distribution can also provide an indication if "one are doing things right". E.g. within software development, if time spent on requirements management are very low, it's probably worthwhile to investigate it.

If you are interested in more information, please send me a message.