Cascade The Book

This book is written for people who work at companies that have an IT department to support their non-IT business. In comparison, this book 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, 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%u2026 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.
In 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 have written this book for you.

The premise of this book is that the situation described above can change, but it is usually slow-going; or worse, there can be an immediate change when your department is outsourced. In the meantime, what can be done to be "successful" in your average IT department in your average company?

What has to be done is to deliver on all those change requests, and finish those current projects so you can start new ones (there will always be new ones). At risk of sounding like a psychedelic poster, this means accepting the things you can't change and changing the things you can.

What can't you change right now?
-The installed base of legacy systems.
- The backlog of change requests and bugs (even if you do manage to deal with a lot of these things, there will be new ones come along to take their place; that is job security).
- Senior management's' conflicting priorities for IT.

All of this is pent-up like rising waters behind a dam ready to burst. Something has to change, but you can't just blow a hole in the dam, the result would be chaos.

So, what can you change (or at least start to change?)
- The structuring and management of the IT projects.
- Overall management of staff by skills/specialties.
- Allocation of staff to the projects.

What follows in the rest of this book is my prescription for this change, supported by some war stories, lessons learned, and lots of ideas to try. Even an 'average' company has some unique aspects, so maybe not everything in this book will work for everyone, but I hope to give you enough ideas that some will work. My own fervent belief is that visible success with IT projects may lead to softening/improvement of the things you can't change right now.

And why should you believe me?

--> "David Wright is a veteran of over 25 years in the IT trenches. He started as a programmer in the mainframe-dominated 80's, followed by 20 years as a Business Analyst and Architect, supplemented with stints in project management and testing when limited resources required it.
Mr. Wright has spent time both in operational areas delivering enhanced and new business systems, and in research and development focusing on information system methodologies and tools. The companies he has served in these capacities have ranged from life insurance to express delivery to equipment leasing & financing. In those companies, he has supported both the operational business and supporting functions like Finance, Human Resources, and even IT administration systems."

Sound good enough? If so, let's get started.