OnPoint, LLC

The Annual Budgeting Process – It Can Use Some Improvement

Over the years, I’ve had the opportunity to work with a wide range of managers and executives. Some had a very IT-centric education and background while others were decidedly non-technical. Most were command-and-control types while others viewed themselves as servant-leaders long before that description was popularized. The majority were calm and reasonable while blessedly few were screamers. If I were to assemble all of these people in a single location and ask their opinions they would not agree on much. Except for one thing – their dislike of the annual budgeting process. Since most 12-month budget cycles are started 3-4 months before the cycle begins, managers are asked to accurately predict what will happen in their organizations 14-16 months thereafter. They are asked to describe funding requirements for projects that have not yet been conceived and their performance will be judged by their adherence to a budget which is merely a wild guess. As organizations have attempted to apply agile principles at scale, managers have discovered that the annual budgeting process is not only disliked, it impedes organizational performance because:

      1. The extensive up-front effort to define and analyze project business cases yields little useful decision-making data and results in green-lighting projects with limited business value

        2. Project cost-overruns result in shifting funds from valuable early-stage projects in order to complete an over-budget project for which the business case is no longer valid

          3. It is difficult to reduce resources on approved projects to work on newly-identified opportunities with greater business value

So, how do we fix this dreadful process? Following are some sources of ideas for applying lean | agile principles to budgeting:

The Scaled Agile Framework (SAFe) proposes that, in lieu of project-based allocations, budgets should be based on funding long-standing teams organized around business value.

The Lean Startup book recommends Innovation Accounting for new products

The Lean Enterprise book advises the reader to eliminate project-based funding processes and separating funding decisions from the annual fiscal cycle

Beware of Assumptions – They May Bite

Those of us who work with projects are always making assumptions.  We think about them briefly when writing the project charter, and they seem so reasonable at the time.  Certainly the customers will use the new product and will tell all their friends about it.  And there is no question that we will get our product to market faster than our competitors – even those competitors that are not currently on our radar.  So, we spend the next 3 months, 6 months or more working on the release only to find that our assumptions have bitten us in the … leg and make us look foolish. 

The agile frame work, with the reliance on the judgment of product owners, may help prove or disprove the assumptions before we launch the new product.  But product owners are proxies for the real customers in the market and may make incorrect assumptions about priorities and product features.   The customers are the ones who are most able to either prove or disprove our assumptions, but how do we engage them?

Eric Ries, who wrote the book, The Lean Start Up, proposes a systematic management process that calls for validating product strategy assumptions via the development of a “minimum viable product (MVP)” that can be used by potential customers very early in the product development process.  The metrics resulting from the use of the MVP provides input into decisions to either “pivot or persevere” with the original product strategy.  Here is a link to a website that discusses the book, the process, and the movement in support of lean product development http://theleanstartup.com.

If you are contemplating a new product or service and would prefer not to be bitten in your assumptions, it would be worthwhile to investigate the lean start up process.

Product Development – “Are we there yet?”

Those who sponsor software product development are frustrated by the time it takes to go from a great idea to the first trickle of revenue.  The months slowly pass and the sponsors adopt the refrain of children during a long road trip, asking “are we there yet?”  The product development team provides the parental response, “we’re almost there” and continues the usual product development practices.

The book, “The principles of Product Development Flow” by Donald G. Reinertsen, proposes that the sponsors are justified in their complaints that teams are taking a long and tortuous path to market.  Specifically, he points out that product developers focus too much on capacity utilization and not enough on cycle times.  As a result, the developers create large batches of work that result in large queues of work that are invisible to the product developer’s dashboards.

Reinertsen proposes a new flow-based product development framework, adapted from lean manufacturing, that seeks to measure and reduce the size of queues by reducing batch sizes and applying WIP limits. He proposes a prioritization method that takes into account cost of delay and the size of the job being scheduled.  Underlying this framework are some 175 principles that complement those of agile software development.  The book is quite deep and may require a couple of re-reads before the concepts settle in fully.

Per Reinertsen, this framework results in product development process improvements of 5 – 10 times, thus allowing product development teams to honestly tell their sponsors that, “we’re almost there.”

Life in the fast lane

You see them on the freeway, driving in the left lane, 5 feet behind the next car, staring at their cell phones and eating breakfast.  Their driving style limits their ability respond to changes in road conditions or to react to the actions of other drivers. They take an excessive amount of risk in order to save a couple of minutes. There is a good chance that, if they make it to the office safely, their driving style will carry over into their work.

Excessive speed is standard operating procedure in business today.  Staff levels have been cut but workloads have not, leaving no resources to maneuver around obstacles and pursue new opportunities.  There is an excess of activity and a shortage of results. As the Eagles (the band, not the football team) would say, life in the fast last will “surely make you lose your mind.”  Is it time to back off the throttle? Following are a few thoughts how to slow down and still improve performance.

  • Challenge the thinking behind deadlines. Is there a business need for to hit this particular date? Or is the date merely a means to create a sense of urgency?
  • Adjust your project portfolio to make sure it is complete and matches your capacity. It is common for people to work on projects that have not yet been identified, approved and prioritized. Even if they are working on approved projects, the sequence of those projects may result in bottlenecks while awaiting the availability of key subject matter experts. Try to stagger project start dates to minimize the risk of colliding priorities.
  • End a project and declare victory. When employing an agile project approach, business value is delivered incrementally according to priorities set by the business owner. After a point, the incremental business value for a given project may be lower than that of a competing project. You do not need to complete every deliverable on the backlog list. Take a look at the entire portfolio of projects and identify those that can be considered complete, then close them out and free up the resources for other work.

Values – Aspiration vs. Reality

The Values section of business plans commonly mention customer focus and respect for others.  Unfortunately, it is a bit less common to see these values at work in the organizations.  Why is there such a difference between the plan and reality?  All too often, the values statements in the business plan are not consulted when making day-to-day staffing decisions.  Who is promoted, who is hired, and who is terminated?  The result of these decisions is commonly a management team that falls considerably short of the aspirations stated in the business plan.

Reflect on the attitudes and aptitudes of the key members of your management team, and consider the following:

  • Are they noted for their technical expertise rather than their understanding of the business or customers?
  • Do they employ distrustful or contemptuous language when describing their interactions with customers or colleagues?
  • Do they complain when customers change plans or priorities?
  • Do they excessively control the flow of information between their team members and the customer?
  • Would you characterize their personality as fault-finding rather than problem- solving?
  • Are they verbally abusive to those who report to them?

Decisions made in promoting people to leadership positions should be consistent with the strategic plans.  Otherwise, the entire organization will conclude that the plans are “merely words” and not to be taken seriously.

OnPoint, LLC