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 21^st 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 includes 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.
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 peopled 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.

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.

FORWARD – How will we document this? Start with Principles.

Like you, I have read my fair share of IT books, and each author has to decide how to best present what they are trying to communicate. One way is to describe the problems/opportunities of interest to the reader, then document the new approach or method that solves the problems; the reverse is to document the new approach/method first and then describe what problems it fixes.

I would like to try a mixture of the two, in the context of a set of Principles that I think will put all the content of this book in context. This is not an original idea, I must admit, as many manifestos and proclamations have been used to introduce new ways of things; the Agile Manifesto is well known (http://agilemanifesto.org/),and I am a particular fan of the Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm). These and others like them lay out the basic reasons for their existence and the value they provide.

Principles can be very effective; the best I have ever seen were created by Mao Tse-tung for the new Chinese Red Army after his first insurrection failed. His principals for protracted/attrition warfare was summed up in “a sixteen character military guide that even an illiterate peasant could understand…

Enemy advances, we retreat.

Enemy halts, we harass.

Enemy tires, we attack.

Enemy retreats, we pursue.”^³

Effective words, against which I hope my own do not completely whither in comparison.

So what are these new IT principles I propose?

There is always more work to be done than people to do it.

Projects change the business, so know the overall business first.

Use an overall Architecture to describe the business, before and after projects.

Pick the right project(s) for the business.

Once a project is started, finish it.

Specialize – each member of a team assigned to a project should do what they do best for the length of that project.
One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

It’s the Deliverable (that matters), not the Task.

Leave a record of what you have done, so the project will not miss you if you leave.

Models are better than text.

Partition large projects into 3 month phases, which is the longest period you can plan for without the chance of significant change to priorities, resources, etc.

Purchase this book or download sample versions for your ebook reader.
(Pages 1-8 show above.)

Free EBook Samples: Free ebook sample of "CASCADE" by David Wright

INTRODUCTION

FORWARD – How will we document this? Start with Principles.