Feed on
Posts
Comments

Update from an article originally published by me in 2007

Alignment is everything

For many years, managers in the software industry submitted budgets that were unrealistic to Business Unit managers that had no clue as to what to question, what to approve or where to cut. As business has grown up and increased its expectations of IT departments, Development and Infrastructure has also been forced to mature and face the fact that they aren’t an “overhead” cost. This is especially true in eCommerce.

The Best is the enemy of the Good

I’ve never met an Engineer or Manager of Engineers that didn’t see an infrastructure project as vital to the organization’s ongoing health and stability. I’ve seen (and been) that Manager before. They’ve actually been wrong more than they’ve been right. The reason for this is the lack of a complete picture of the goals of the organization as a whole, the priorities for various Development/Infrastructure (DEV-INF) projects, and the fact that budgeting exists because resources are finite. Sometimes an eCommerce site can limp along for years on a code base that is far from the ideal architecturally, but it may cost far less to maintain and extend it than to upgrade it to the “Next Great Killer Platform” at the cost of revenue-driven projects.

The Holistic view of a Budget

While all projects will have some value, it’s important to prioritize projects in alignment with the overall organization’s strategy and objectives. There is no use in a complete re-architecture of the site when current demands of Marketing, Consumer Experience and other various Business Units cannot be met. The goal in eCommerce is simple. Keep the business growing, keep the site in “five nines”, and refine the user experience to increase conversion. DEV-INF budgets must play in this ballpark or, as a development leader, all credibility with Business Units will be lost; ultimately will leding to a breakdown in communications between Engineering and Business, which is a crisis in an eCommerce workplace.

Metrics are the key

Once projects are aligned with Corporate Objectives, it’s vital to show all cost drivers for these expenses. Many times the cost of ongoing maintenance is not factored in, but can be as much as 65% of an overall budget. This is also true for time budgeted for QE/QA. While the individual Engineer writing code may only write 250 lines that finally make it into production in a three-month long project, how many times he/she had to write it, how much time was eaten up managing and checking this code, and finally what documentation, knowledge transfer and future extendibility these 250 lines will have also affect costs. All these things must be taken into consideration.

Budgeting isn’t just all planning. Once the planning is complete, the spending begins. Vital in this aspect is accountability and assessment of performance. Hard, industry-standard metrics exist to gauge the performance of DEV-INF budget items. In eCommerce I’ve found many easily measured values:

  1. Actual vs. Proposed Development times.
  2. Actual vs. Proposed Resources.
  3. Pre-release bugs.
  4. Post-release bugs.
  5. Effects upon site stability and performance.
  6. Did the Project “Do” what the owners said it would do?
  7. Were the expectations of Business Units met, and are these stakeholders satisfied with the results?
  8. Did any problems that come up get handled in appropriate manners?
  9. Were in-place processes broken?

Approaches

Approaches to DEV-INF budgeting should be aligned with the current culture and expectations of the Business. They must have significant buy-in by various business stakeholders. If business drivers have “skin in the game” as to line-items in a DEV-INF budget, this automatically give credibility to it and also act as a check to make sure that I’ve done my homework. Many successful organizations use the Consolidated Projects Approach to budgeting and allocation for DEV-INF projects with outstanding success. In a nutshell:

Consolidated Projects List basic points:

  • IT budget planning process starts before the organization’s process.
  • IT managers submit summary project data for consolidation into a single spreadsheet
  • These projects are then sorted and prioritized by DEV-INF managers before submission to the overall business Prioritization Committee.
  • The Prioritization Committee decides how these projects are to be aligned, budgeted and implemented within the entire Organization’s overall Business needs and strategies.

This approach provides Senior Executives with a complete picture of all proposed projects, their costs, and priority ranking; these units will have a “30,000 foot” picture to make a more informed decision. Total project requirements may now be viewed as a single picture to senior management; priorities become a decision factor. No single group can drive pet projects or non-revenue generating development without prioritization or fully understanding what the business impact or opportunity costs involved are.

This process may be extended with Gate Checks to assure relevance to the goals of the company as time changes. This is especially true with larger organizations that may be widely distributed. Projects can often times have huge scope (ah — to de-scope, another topic!) and can take months of development time.? The needs of a business can change over this period, and any project that is underway should have enough flexibility to move with the times or the business stakeholders or group as a whole should have the gumption to kill or suspend development indefinitely or until such time as solid metrics warrant completion.

PDF Printer    Send article as PDF   

Leave a Reply

Bad Behavior has blocked 47 access attempts in the last 7 days.