Day 1:
I have recently made a major career change, moving from what I would now call a client company to a consulting company. It's an exciting change, but I don't expect to write about my new experiences at this time.
However, I had also been spending some time writing an extended piece about my experiences over the years working in several IT departments, especially to define a set of "better practices" for succeeding in a multi-project environment. (I read another blogger's
point that claiming you have a "best" practice is the height of egotism, and it rang true to me, so I will stick with "better".)
This material appeared on a more general blog of mine, and out of it evolved "Cascade". It is not strictly about Business Analysis, but we do not work in a BA vacuum, we are always part of a team to deliver a product or service, and I can think of no better analogy than fast flowing water that swirls around rocks and other obstacles and emerages to fill a large body of water, a Cascade of information system deliverables that add to the overall portfolio of a company.
You can see the resulting book at http://www.lulu.com/content/2088656 , and read the first few pages. What I plan to do in this blog is feature the material from the forward/introduction (hopefully to pique your interest in reading the rest!).
First up: Does this sound like where you work?
The book was written for people who work at companies that have an IT department to support their non-IT business. In comparison, this blog is not written for people who work at IT companies; from Google on down to someone selling excel macros. The main reason is that I have not worked for an IT company and, although I have worked with many in customer-vendor relationships, I do not feel qualified to write about something I do not have experience with. However, even companies selling IT need some other IT to help run their business, so perhaps some of my experiences may overlap with theirs.
Given that, let us consider the vast majority of companies that are making automobiles or serving hamburgers or providing investment advice or any and everything else. In those companies you will find a department/division filled with IT ‘professionals’: Programmers, Project Managers, Analysts, Testers, Implementers, Operators, and loads of other specialists like Database Administrators and Network Engineers. (I use professional in quotes because long-standing professions like lawyers and engineers like to protect the use of the word.)
The name of this group has evolved generally to the ‘Information Technology Department’, or IT for short (no ‘D’ at the end); such past names as “Data Processing” or “Management Information Systems” seem to have faded away . As an acronym, “IT” is used interchangeably to name the department and describe the functional scope addressed by that department.
So, as we speed through the first decade of the 21st century and on into the next, what is the common situation that these IT departments face?
It probably includes an installed set of information systems that are used by the business to control and report on its operations. There is always more than just one system, and possibly hundreds(thousands?), many doing the same work as many others. Some may be decades-old, a few may be recent and using fairly new technologies, with the implementations of the rest spread-out over the history of the department since that first ‘computing machine’ was purchased, with the wide range of development and operating technologies which that implies. (How along ago did you read that your mainframe computer was dead? Did it die? Not likely.) The still favourite term for describing this installed base is legacy systems.
It probably includes a large back-log of requested changes to that installed base of systems, overlaid with a long list of problems/bugs in the systems that the business is currently ‘working around’ until they ever get fixed.
It probably has an “IT Strategy” that describes in glowing terms how the above two cases will be remedied by moving to some new method or tool or one enterprise system… if the budget and resources can ever be freed up from fixing and changing the current systems.
It is probably overseen by a senior management group (or steering committee or review board) that is charged with deciding what IT work is approved and carried out. This group may be formal or informal, and may only be one person in the end, the CEO or someone he/she has delegated it to; since IT costs money, the CFO is a common choice.
I n this structure, the head of the IT department (CIO is the hot title, of course) plays a committee secretary and/or facilitator role, who is supposed to assist the rest of management in making their IT choices. This is a difficult role, as the rest of management has a split-view of IT, that most of it is a waste of time and money, except for the work each one wants for their own department/division.
There are probably a large number of current projects being carried out, that no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon.
It is staffed by a group of IT staff that has remained the same size in numbers, or has been reduced, while being charged with doing more work than ever: “Work Smart, Not Hard”., “Do More With Less”. Each person is probably assigned to many of those current projects, juggling the work and trying to determine what they should really be working on.
The overall morale and effectiveness of this staff depends greatly on the skills of their immediate management and more senior managers who provide some level of inspiration; if not, morale plunges and turnover increases.
Sound familiar? Then you have the same experiences as me, and I will be writing more entries for you.
Next time: what you can't change but, more importantly, what you can change...