Certain facts tend to get hidden when you deal with computers. Other professions have detailed lists of what they have to tell you in order to be ethical. Although the CIPS ethics statement says an IT professional must be honest, we do not have a list of topics that must be explained honestly and clearly. We need to work towards transparent IT.
I retired a couple years ago. As part of that process there were a few chats with financial folks that I really found hard to follow and didn’t want to sit through. Normally, sales folks pick up on these things and get on to the good part. But in finance they are required to make sure I’ve heard and understood certain things that might make my money disappear. It occurs to me that the computer industry should have similar lists.
I went to the CFA website to find that list, and found that disclosure is part of their ethics requirements. When you buy a new house there is a disclosure statement, and it turns out when you buy a new franchise there is a disclosure guide too. But these are just one-time statements. Companies are required to do continuous disclosures. It is not just a one-time thing. The continuous idea takes it one step further and uses the term “evergreen” meaning the information should not get out of date. The wording for pension information also includes the word transparent. It says:
“Communicate with participants, beneficiaries, and supervisory authorities in a timely, accurate, and transparent manner”.
Transparent does not always mean ethical. We can be told about things that are not fair or right and then be given no choices. But transparency is definitely a good step toward enabling ethics.
So what should members of the IT department be transparent about? Here are some of my ideas:
– How good is this estimate? How much risk is there that the project will overrun? What are the open questions that will make this estimate change the most?
– How good is this design? Is it “future-proof” or will new technologies soon require an upgrade or rewrite or leave holes for hackers? Will it work well with other software in your architecture, now or in the future?
– How well was this tested? We know there will be bugs. How can they check for them? How major can a failure be? What plans do they need if this does not work?
– Where did this data come from? How was it calculated? How accurate is it?
– Who can see this data? Are there any back doors or defaults that may cause security problems? How much does security / privacy depend on the people running the processes?
– What business rules are now mechanized? How can they be more visible?
So far, the main mantra for information technology folk is “talk to your clients”, and sometimes “make sure you understand their requirements”. We need to extend that to detailed lists of “make sure they understand….”.
What would you add to my list?