A few passing observations from the last few months; contrary to what many (IT/business) folks believe, they are just as good or just as bad in managing processes and projects as their counterparts in (business/IT).
Problem Resolution is Everybody’s Problem
A few weeks ago I was discussing issues that came up with one of our systems, and the team was a bit dismayed that the user community was still finding errors (we should be trapping for that stuff!) I pointed out that it’s illogical to worry about stuff like this. We’ve implemented fault-tolerant systems that predict as many problem situations as we can think of, with lots of alerts and doublechecking built-in. If we can think of a problem, we will build a trap for it. It stands to reason, therefore, that the only bugs to appear are the ones that we couldn’t anticipate – so the only people that will experience the bugs will be the people using the system.
It’s inevitable that end users will find your problems, and that’s nothing to be concerned about – we’re all testers, and testing never really ends (in a continuous improvement environment). What you should be concerned about – how quickly we can turn around a fix for the problem? What is our total uptime? Do we see decreasing numbers of new problems, and zero recurrence of previously reported problems?
Truth be told, the onus of root cause is just as much on the business. Was this a scenario that could have been predicted? Were the requirements and/or testing scenarios complete? (… apparently not …) When projects are well run, and it’s a true partnership between IT and the business, misses like these are everyone’s problem.
Nature Abhors a Vacuum
Business managers may not understand the details of the technology they work with, but they certainly understand good management techniques. Try working with any manufacturing operations group and not going to them with metrics or KPIs (Key Performance Indicators). This is their bread and butter; they cannot understand how anyone could manage without some form of metrics. And if they see none, they will not only notice the problems, but will proactively look for issues, assuming things aren’t under control.
On the other hand, if you have a reasonable set of metrics and are managing to them, they certainly can’t accuse you of not following sound management principles. They may provide feedback that the quality of their experience is still not the greatest – but a structured, metrics-driven approach shifts the conversation to towards a discussion about best metrics to manage to, and not whether or not IT knows what they are doing.
In the End, We’re All [Bad] Programmers
- Poor Segregation of Data: Mixing critical values with complicated algorithms (business rules) makes for a delicate and hard-to-maintain spreadsheet (application).
- Poor Documentation of Assumptions: when revisiting (cloning/debugging) this report, if you can’t remember the original assumptions (design), you may need to rework (refactor) the entire thing
- Poor Documentation of Constraints: complex worksheets with many simultaneous calculations would benefit from interim formulas in key cells (asserts) to test reasonable boundary conditions
- Difficulties in Making Changes: spreadsheets and formulas can and should be structured to allow for foreseeable extensions and modifications (subroutines)
- “Now It’s Here; Now It’s Not”: at times it’s too easy to change values in the worksheet to test different assumptions. And then lose track of all the changes made over time (version control)
- The Presentation Readiness Problem: when creating spreadsheets, analysts (programmers) should anticipate their use in final presentations (user interface)
In summary, the author provides this sage admonition …
- Treat the development of a spreadsheet – any spreadsheet – more like writing a term paper with footnotes and a bibliography.
See that? Accountants and programmers should aspire to be … students?