You might know that I started my banking career at Alexandria National Bank. It was there that I met the very best operations person I have ever known, Michael Umlauf. He was not a programmer or an “IT” person; he was just a very good manager. The best advice I ever got from him was to “know what your input would be (i.e., form, raw data, etc.) and know what you want out (i.e., reports).” When we merged three bank operations into one to form First American Bank in 1978, that was his mantra, and it resulted in the smoothest conversion of systems I have ever experienced (and I have gone through a lot of bank mergers!).
Right now, as I am working on several operational projects, trying to design systems and procedures, Umlauf’s advice frequently comes to mind. Often I collaborate with folks who have never considered the basic “input/output” issues of effective organization. My opinion is that processes must have rules. Unlike dealing with nature, where the rules are already defined, managers should step through what the rules should be before processes are designed.
Last summer Dick Davies wrote a blog titled Value Centric Work Analysis. It talks about defining the work process and how that makes work more efficient. This is a good time to review this information and apply it to what you are working on.
As part of your thinking about processes and rules, I think you should first consider what your customers think is important about the system you are defining. How easy is it to use, what kind of instruction and feedback do they need to use it effectively, and how much of their time will it take to complete it?
Next, I think you should consider how efficient your requirements would be for your staff to interface with. Is there a lot of additional data entry required? From the questions you are asking, is customer input going to be clear? How much time is going to be required to “manipulate” the data?
Finally, I think you need to evaluate what you are going to do with the data you receive. What is the purpose of the process? What reports are you going to produce and whom are you going to show these reports to?
A final opinion: don’t go out and engage an IT person to design the technical parts of your system until you have stepped through your work process and know exactly what you want.
This doesn’t sound much like gardening, does it?
3 comments:
Good thought. Although I have in-laws who grow beautiful gardens from very deliberate architecture.
I was most struck by your prescription of when to turn it over to the IT professionals. With the tools we have now, I seldom turn it over before evaluating the first prototype. I find that is quicker getting to what I want.
A sage point (not from the herb garden) to know what you want out and know what you put in. If a successful project is a 1 effort, a rework during the design stage is at least a 10 effort, and rework after launch is at least a 100 effort.
The worse words I can think of after a project goes live is "Darn! I really need to have ___________."
Dick's point about using the tools available to do a rough cut is on target. Always better to have something to look at to get a better result, than a concept that the coder may know nothing about.
Great post, Joe
Post a Comment