We’ve established the importance of targeted reading and writing for the senior information technology executive. I’d like to turn my attention now to the third R, ‘Rithmetic. Even though the “soft skills” of management are probably most crucial to a successful executive, IT is one area where quantitative skills are a regular (and, sadly, often ignored) part of the job.
I’ll have a lot more to say on each of these subjects in future posts, but for now, let’s outline the seven major arenas in IT where quantitative measurements and analysis need to be part of your arsenal. Some or even all of these will seem obvious and maybe even unavoidable; yet, some, astonishingly, have rarely (or even never!) been touched or attempted in more than one company I’ve seen. In fact, sometimes it seems that even established companies go out of their way not to be quantitative in several of these areas, running instead by “seat of the pants” and gut feel.
- Budget
Getting budget forecasts right is 90% of the battle here, and the only way to do that is through unswerving attention to detail, making sure, for example, that you don’t miss whole categories of expense (remember that system you purchased just before end of year? It’s going to cost you maintenance in the following years). Budgeting systems can help, if you’re lucky enough to be in a company that uses something more sophisticated than spreadsheets and elbow grease for its budgeting process. A great percentage of non-labor corporate expenses tends to flow through the IT function, so shepherding these expenses carefully is a key role of any CTO.
- Return-on-Investment (ROI) analyses
Are all the projects you do (development and infrastructure-related alike) based on a solid, quantitative, brutally honest assessment of whether there’s a financial return to the company on the necessary investment? Yes, some projects are indeed simply “strategic” or dictated by regulatory constraints, but I’ve seen the ROI analysis skipped more often than not, with executives somehow preferring instead to let emotion and gut feel dictate the decision. And, in your ROI analyses, are all the likely costs taken into account? A well-scrutinized and fair-minded ROI analysis process will expose any tendency that you or others may have towards “wishful thinking”, which leads to bad investments. Lots more to follow on this topic, including covering negotiation with providers.
- Project estimation
“Oh, that’ll take about two months”: the toss-off estimate that too often rules the day (and then sinks the ship). Instead, do you have a process and a model for breaking down a project and coming up with more than a seat-of-the-pants estimate? Are you constantly honing that model and evaluating how well it’s performed for you? There’s lots more involved in this category, extending to your overall project methodology and development process, but the estimation aspect (breakdown of tasks, amount of time, level of resources) is the one where ‘rithmetic comes most into play.
- Resource allocation
Cousin of the area above, resource allocation is, as I’ve discussed, one of the main functions of management. Again: is yours seat of the pants, or based on quantitative factors? What’s the capacity/throughput potential of your “factory” (development and infrastructure-related alike, once again)? Are you filling, underfilling, or overstuffing that capacity with the projects currently on the docket? Do you have a repeatable allocation process that is subjected to regular examination and scrutiny as you strive for continuous improvement? Some IT departments swear by specific project management tools to do this; others have developed spreadsheet allocation techniques for a “squint across your thumb” way of making sure you know where the large chunks of resource are needed and being allocated. Again, lots more to follow on this topic.
- Capacity forecasting
Servers, system memory requirements, disk space, network, database: all of these are finite resources, and all of them tend to get filled up over time, by the nature of our business. Are you awake at the wheel on how full (or empty) the tank is on each of these? Are your plans to upgrade them based on quantitative and demonstrable growth curves and system installation/upgrade assumptions? I stepped into one company where the operations director had simply decided to purchase major server CPU boards twice a year, with no quantitative studies supporting that need.
- Performance metrics, operations
In a nutshell: what metrics are you tracking (and how are you summarizing and publishing those metrics for your own use and for scrutiny up the management chain) to let you know how your systems are performing (e.g., response time, stability, throughput)? A distressingly large percentage of internet companies, in particular, that I’ve gone into as an employee or consultant have been unable to show me any methodical tracking and publishing of IT operational metrics beyond the merely financial.
- Performance metrics, development
Aside from just meeting the targeted delivery schedules and milestones (a feat that by no means should be undervalued), how are you measuring development and QA? Is your factory functioning as well, better, worse than it was last year? Examples here of possible mechanisms include velocity charts, function point counts, test case management, bug counts over time.
‘Rithmetic. It’s your friend. It definitely beats mere “table thumping” when you need to explain just what your department is up to and how well it’s doing.
Lagniappe:
- Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))
, by Steve McConnell
- Testing Computer Software, 2nd Edition
, by Cem Kaner et al.
- VersionOne, “Velocity“.
- “FAQ – IT Investments – What is ROI and How is It Used“.
Speak Your Mind