Delivery Excellance : Governance — Improvements on catalogue services Billing /Invoicing in Agile Delivery
Background:
While I was working as Delivery Manager for one of my banking customer, there were lot of discussions or negotiations happening while a monthly invoice is submitted for catalogue services under Time and Material delivery. The projects followed agile methodologies with regular release cycle with 4 weeks sprint.
We followed an estimation template, which splits the billing percentage across phases (Analysis, Architecture , Design , Build , and Management efforts separately), used to attach to every user story which is prioritised for specific release. This estimation chart categorise the efforts based on the service impacted for code change /deployment and given boundaries like less than 6 services impacted categorised as small, greater than 6 and less than 16 services as medium , greater than 16 services large and so on.
When the monthly billing cycle approaches, the phases completed for the user stories are billed. There was a practice asked to follow to list down on the stories, which phase is completed and can be invoiced for the approval from Product Owner before it goes for invoice generation. This creates often multiple stakeholders reviews for optimizing the invoice. During those reviews the story categorisation (medium/large) are the candidates for revisiting and downgrading the category for invoice optimization.
How to ensure/improve the consistency and integrity on catalog-based billing:
In JIRA or whatever agile tool your project is setup for product backlog and delivery, the user story must have an initial estimate (zero level) with an estimation chart approved by the product owner before initiating the work. In exception scenarios, where the developer assigned started the work , the change or code promotion should not happen if the estimates are not approved. There are scenarios where initial estimates gets approved but scope revision results in enhanced revised estimates. This second revisions and approvals were at times not factored and creates lot of confusions during billing phase.
Being flexible in this area, creates lot of financial voids for the service providers at the last moment, to get the invoices approved and actual deliveries compromised. Compromises done on efforts, changing medium efforts to small by reducing the services impacted etc can be mitigated by this critical measure.
I had seen places where Product Owner directly influence developers to reduce the service impacted, when the invoice get submitted. The early baseline before starting the work will ensure that, the estimated Vs actual does not have many changes in terms of scope (service impacted), complexity , dependency etc.
Project change request: For any scope change, a change request associated with user story with revised estimations with approvals needs to be in place. There should be a remark by Product Owner/Scrum Master /PM on estimates revision made and approved to proceed further. These notes are critical during invoice cycle for appropriate categorisation.
This also gives an insight to the Product Owner that if the estimates are not approved, the work cannot be delivered and the resource focus will be prioritised for the approved stories.
Tooling: Revenue leaks can be mitigated, if the estimations were captured digitally than excel charts to avoid manual errors on versioning as well as workflow management(approval/revision tracking/report generation etc).
