The business cycle of most firms is cash-driven: work is performed, invoiced at completion, and collected on negotiated payment terms. Obviously, cash flow is important to the business as it affects our ability to do the things to run the business, like meet payroll and pay expenses. Cash flow isn’t revenue, however. To recognize work delivered as revenue, client work must be delivered and unambiguously accepted by the client.
This is a priority, particularly for publicly traded firms. As the stock price usually trades at a multiplier to income (or in the case of many Nasdaq companies, a multiplier to revenue in lieu of earnings), revenue recognition is critical to Wall Street. For engagements that span many months, this can mean that revenue recognition is deferred for many reporting quarters. We can end up in a situation where cash flow is consistent and healthy, but net income is variable and frequently weak.
Amongst other things, Sarbanes-Oxley (a.k.a. Sarbox, or SOX) establishes compliance guidelines for publicly traded companies so that revenue isn’t gamed. The intent is to define clear guidelines accounting the facts of what operations have delivered or not delivered. As simple as that may seem, the pressure in the executive offices to recognize revenue is quite real, and the software industry in particular is rife with examples of companies gaming revenue numbers with incomplete deliveries.
The rules under Sarbox governing revenue recognition are explicitly defined. The governance mechanism for this under Sarbox is a “proof of completion” certificate. This is a simple document that serves as the client’s acknowledgement that specific functionality was delivered to satisfaction by the supplying vendor. This document must be received in the reporting period in which the revenue is to be recognized; e.g., if we’re going to recognize revenue in Q3, the proof of completion must be received by the supplier in Q3.
The capability for operations to deliver what they forecast will go a long way to letting the air out of the results bag. Of course, it’s not so easy. The ability for ops to deliver isn’t purely an internal function. Factors outside the control of a company’s internal ops, such as customer staff turnover or change in a customer’s business direction, can impair execution of even the best laid plans. Thus no matter how strong the internal operational performance, external factors will significantly affect results. Still, the ability to forecast and respond to this change in a timely fashion will go a long way to meeting revenue targets and goals, and reduce the risk of change in the business environment.
Our traditional ways of working in these environments are often based in hope and unnecessarily produce a lot of uncertainty and inconsistency of our own making. We set our forecasts based on individual “quarterly completion commitments” and “business feel” based on what we see in the sales pipeline. As we approach quarter-end, we swarm disproportionate numbers of people on specific projects to drive to what amounts to an internal definition of “complete,” only to then plead with the customer to accept. The pursuit of a mythical number given at the beginning of a quarter in the vain hope of making it a reality through the fortunate combination of contracts, capacity and capability coming into alignment is a primitive practice. This ultimately results in a mad scramble at quarter-end to complete deliveries, introducing operational risk. For example, if a delivery proves to be more complex than originally thought, or if people are not available, or if some customer deliveries are prioritsed at the cost of others, quarterly ops revenue contribution is at the mercy of things substantially out of our control. Without mitigating this risk – or indeed providing visibility into it in the first place – we increase the probability of a disappointing quarter.
In fact, these practices stifle operational maturity. In this model, operations are at best a hero-based delivery group that relies on a few talented individuals making Herculean effort 4 times a year (that is, at quarter end. At worst, they’re an under-achieving function that requires a high degree of tactical supervision. In either scenario, operations are reactive, forever executing to a mythical, primitive tactical model, never rising to become strategic contributors to the business.
Because they bring operations into alignment with regulatory requirements in a non-burdensome manner, Agile management practices are especially valuable in Sarbox or similarly regulated business environments. There are several Agile practices we can bring to bear in this environment:
- Instead of defining large, monolithic packages of delivery, we can decompose client deliverables into independent, uniform statements of business functionality or Agile Stories. Each of these Stories will have an associated revenue amount, specifically the cost of delivering each to the customer. This gives us a granular unit of work with economic properties.
- Each of these requirements can have an associated Proof of Completion document. This provides tangible affirmation that client acceptance criteria have been met.
- We can define the fiscal quarter as an Agile “release” divided into 13 iterations of 1 week each. This gives us time-boxes around which we can construct a release plan.
- We can forward plan our capacity by taking a survey of known downtime (vacations, holidays, etc.).
By executing to these, we yield significant financial and operational benefits.
- We accelerate revenue recognition. Granular, federated expressions of business requirement can be developed, delivered and accepted incrementally by the customer. This will yield faster revenue recognition than highly-coupled requirements made in one delivery.
- We reduce the risk of not being able to recognize revenue. Incremental customer acceptance reduces the risk to revenue recognition inherent in a single large delivery. For example, suppose a sea change within a customer threatens revenue from projects. If we have granular delivery and acceptance we can recognize the revenue for deliveries made to date. If we don’t, we lose revenue from the entire project, making both the revenue and the efforts to-date are a business write-off.
- We have more accurate forecasts of revenue capacity and utilization. By planning capacity, and taking into account our load factor, we can assess with greater accuracy what our remaining quarterly capacity looks like. Expressing this in revenue terms gives us a realistic assessment of our maximum revenue capacity. From this we can take investment decisions – such as increasing capacity through hiring – with greater confidence.
- We have more accurate revenue reporting. Each POC received creates a revenue recognition event in that specific iteration. This gives us a “revenue burn-up chart” for the quarter. In tracking actuals, we can show our revenue recognition actual versus our burn-up. This means revenue forecasting and reporting is based more in fact than in hope.
- We have more accurate revenue forecasting. By forming a release plan that includes the complete cycle of fulfillment stages for each customer requirement – analysis, development, testing, delivery and POC/acceptance – we have a clear picture of when we expect revenue to be realized. As things change over the course of the quarter – as stories are added or removed, or as capacity changes – the release plan is modified, and with it the impact on our revenue projection is immediately reflected.
- We have transparency of operations that enables better operational decisions. Following these practices we have a clear picture of completed, scheduled, open and delayed tasks, an assessment of remaining capacity, and visibility into a uniform expression of our backlog (i.e., a collection of requirements expressed as stories). With this we have visibility into delayed or unactioned tasks. We can also take better scheduling and operating decisions that maximize revenue contribution for the quarter.
- We have transparency of operations that reduces surprises. The release plan tells us and our customers when we expect specific events to take place, allowing us to schedule around events that might disrupt delivery and acceptance. For example, we may expect to make a delivery in the last week of the quarter, but if the person with signature authority on the POC is unavailable, we’ll not recognize the revenue. Foreknowledge of this allows us to plan and adjust accordingly.
- Acceptance Criteria are part of everything we do. The Proof of Completion document builds acceptance criteria into everything that we do. We think of completion in terms of delivery, not development. This makes everybody a driver of revenue.
In sum, Agile practices professionalize operations management. By being complete in definition, being fact-based, providing operational transparency and exposing and mitigating risk consistently throughout a reporting period, they align execution with governance. This results in non-burdensome compliance that actually improves the discipline – and therefore the results – of business operations.
