Memories of IT - mid-80's - Analysis and CASE Tools

So now I move on to the next project, replacing yet another batch system with something newer and shinier, and I am doing the Analysis phase. In a timely fashion, a few things arrive that will help me greatly...

• a fast, collating, stapling photocopier, which I would need for distributing the requirements documents
  
• an IBM PC AT, with a hard drive, a mouse, and a graphics card. The drive storage was tiny by today's standards, 10 meg. The monitor was still monochrome, an annoying orange-yellow.
  
• and the reason for the AT, a copy of Excelerator 1.0

Excelerator was my first CASE tool. I think the vendor sales guy drove up from Boston to Toronto and gave us a copy out of his trunk. I entered my level 0 DFDs in it, and then I could easily change it as needed. When it was stable, I would generate a print file on to a diskette, and then go to a PC attached to a plotter to print the diagram. (No LAN yet.)

Next, I could select a level 0 function, and then draw a new diagram , exploding that function to level 1, keeping a link to level 0. This was like gold for me, so pencil and erasers were now history.

Excelerator did not support Data Models in 1.0, but I used a general diagram to at least draw the diagram and kept definitions and such in a text document.

Looking back, I would have to say that the quality of what I produced was probably low, but I was young, all was new, and there weren't many examples to compare to. I am fortunate to have had the time to learn and improve since then, and it hasn't stopped; there is always room for improvement, and new things to learn.

Memories of IT - still in the 80's - They didn't call it downsizing yet...

Ok, now I am trained up to be a Business Analyst, and an opportunity to be one was about to present itself. But first, a little about changing environments.

When I joined and for the first few years I was there, Crown was PL/1-IMS mainframe shop with all systems developed in-house. I don't know how this came about, as so many companies used COBOL and VSAM files. The fact that Crown Life did not use COBOL was one of the reasons I accepted their job offer in 1979. The only old war story I heard from some company veterans was when the first computer was installed at the company in the mid-60's. It was a big deal, all about "turning the big switch" to move the company on to using a computer.

Development of new systems moved in cycles, of course, depending on what needed built/replaced, allocation of budgets, etc. After the development of the new Stocks/Bonds Admin system was done, the focus moved to the Group Insurance business. Crown Life did a lot of business in the United States, like most Canadian insurance companies of any real size, and it was still possible to make money in group health business as well as life, before health costs sky-rocketed and HMOs took over.

So, the company had a number of group sales offices around the United States doing business, and they needed a new system. Something about the cost of using billable mainframe cycles probably played a role in the decisions to create a system based on a mini-computer located in each sales office, which employees would use all day, and each mini would then feed the days transactions to a master system on the mainframe in Toronto for consolidated processing; sounded reasonable, I guess. Adding minis to our mainframe environment was new, and probably should have been treated as a risk, but I was 26 years old and not on that project, so can't say I worried about it much myself.

The team for this project was located next to the department I was in. I recall that I did not know many of these people directly, but they seemed like a good enough bunch. Reporting about project status to people outside the project always presented things in a good light, but that kind of reporting usually does, no matter what is actually happening.

Because something bad was happening on that project; I found out about it like most of the rest of the company when I came to work one day and the area with that project team was empty, and stayed empty. The mini-mainframe mix had not worked out (more on that later), so the project was cancelled and the whole team up to director level was let go, fired. I don't believe the 'down-sizing' euphemism had been invented yet, but this was the first one I ever saw like this, quick and brutal. I think this was the cause of me realizing what a lot of other people were realizing as the 80's progressed: companies could just not afford to be completely loyal to their employees, so it was time to start managing your career yourself, start looking out for #1. Obviously this is when employee loyalty to their employers started to disappear too, and management magazines over the next 10 years or so had to gall to print articles asking "why?".

Anyway, the Group Business division still needed a system, so senior management brought in a new team that went right out and bought a Group Insurance COTS package. It was totally mainframe, so whoever wanted to avoid mainframe costs was ignored (or had been one of those who was fired), and it was COBOL-CICS-VSAM.

This was the first package I had seen purchased at Crown Life, so the developing of all systems in-house could not be assumed anymore; and the pure PL/1-IMS environment was no more. Business realities would now drive what systems and technologies would be used.

PS: About the reason why the mini-mainframe mix failed... about 5 years later, I was on a training course near Washington DC, and the direct flight for myself and a co-worker also attending back to Toronto was canceled. So, we ended up on a travel nightmare, taking a flight that stopped 3 times and we had to change planes once. A couple of other travelers were doing the same thing, so we got to talking (especially in the bar between planes) and turned out they were AT&T techies. When I said we were from Crown Life, they rolled their eyes and said that we may not want to hang out for the rest of the trip.

Why? It turns out that for the minis in those Group offices to communicate each night with the mainframe, they would need special or dedicated lines (any network techies reading this will probably know why). In those days, those lines were not easy to get, and Crown Life ended up on a waiting list measured in years. When that situation became apparent to all, it wasn't too long after that I came into work and found that project team gone.

PPS: Crown Life apparently sued AT&T over this. They had a contract, of course, and they claimed the delays breached the contract or something like that. As a Crown Life employee, I never heard about this lawsuit, but the AT&T guys we were traveling with sure had; I don't know how the suit ended up, but Crown Life was not a favorite of AT&T for a long time; but us foot soldiers who had met at random decided we would have a few more beers and not let company issues bother; we just wanted to get home that night.

So, when I started on the next big project, all assumptions had changed.

Memories of IT - 1984 - Structured Techniques

So, this many posts in and I am still less than 5 years into my career... but an important shift in the story is imminent.

As I came off pure programming work like the new devevelopment project I have been describing, the Analyst part of my Programmer/Analyst job title started to dominate. Some of it was the work I moved on to, but also a parallel path of training that the company paid to have me attend. Everyone has a complaint or two about anywhere they have worked, but my first employer did understand that training was vital to the development and overall happiness of their employees.

Some of the training was general skills, like public speaking and on giving presentations. On the IT side of things, structured techniques were all the rage, broken into the parts of Structured Analysis and Structured Design. As I was still primarily a programmer, I recall I attended a Structured Design course first; it was given by an external vendor. The actual diagrams and techniques have faded from memory, but I do recall it is where I first learned about"high cohesion" and "low coupling". The course also showed how it used the results of Structured Analysis as input to Structured Design.

So, I continued along, doing enhancement work on existing systems. Understanding what the business wanted out of the enhancement, and then determining the impact it would have a on a system was the majority of the work; the actual programming work needed could often be minimal. So, it seemed like maybe I was turning into an Analyst who programs a little. I think the company did have the Business Analyst job title already, so I veered my career path towards that title.

That meant I got to attend the next offering of Structured Analysis training. The course used one of the era's gurus as a basis for the course: DeMarco or Constantine or Yourdon or whomever. I should have kept my course material, it would be a classic now!

It was on this training I was first introduced to the Data Flow Diagram, orDFD. The idea of diagramming what your system should do really appealed to me, even if the diagrams were hand-drawn and hard to change. Pencils and erasers is what I remember of the course and subsequent work back at the office. That would have caused a lot of people to use it less or stop using it, but not me. My future was being defined right there in that course.

Next time - the next big project

Memories of IT - unexpected consequences of system development

(Actually, I need to wrap up a few things and start a few others before I get back to PCs...)

So, I came off of the big PL/1-IMS development project, as it wound down, 1983 or so. The system from my viewpoint was brilliant, supporting all the stock and bond investment business of the company. I worked a lot on look-up screens, starting with a definition of a security and breaking it down to all the lowest levels of investments the company had in that security. A friend of mine was quite proud of a program he wrote to allocate bond income across the company's complete portfolio after one hit of the enter key. However, it still faced two challenges:

1. the easy-to-program architecture of the online system did require more of the system to be loaded in memory at a time than an architecture based on a single screen structure. As a result, the online system always had lowest priority among all the online IMS systems, and so response to the users was always slow.

2. the actual securities traders had been doing business over the phone and writing down their trades on scrips/paper, then handing these to clerks to code up transactions to feed the existing batch systems. A major proposed benefit of going to an on-line system is that the traders would now enter their trades directly into the system, giving real-time updates and removing the clerical effort. So, our BA/PM shows a test version of the system to management and the traders, to show just how this was all going to work for them. Apparently the traders weren't aware of this benefit, and they reacted very negatively. Typing anything was for clerks and secretaries, so using a system that required typing was beneath them. So, when the system went live, traders continued to write their trades down and handed them to the clerks, whose jobs continued but as the new users of the online system.

The system did go on to have a useful life of about 10 years. I did not work on it again, so I don't know if the traders ever warmed to it. I do recall some outside consultants doing reviews of our existing systems later in the decade, and they said something stupid about this one; given its volumes compared to say, our core individual insurance systems, they wanted to know why we had not developed it on a mini-computer. I think the architect,s head probably almost exploded. I suppose not owning a mini-computer did not mean anything, nor the fact that that the company's core IT skills at the time of development were all on mainframes. By the time of this review, however, other changes had occurred; packages were being purchased, which meant COBOL and CICS were invading our previously pristine PL/1-IMS world. The architect left the company not too much later. Breck Carter, wherever you are, if you see this, drop me a line.

Memories of IT - PC enters the home, then the office

In the early 80's, I was one of the younger people in my department, even with regular new hires coming on. It would actually annoy some people...

However, we would also have co-op students, who went to university for a term, then work at a company like ours for a length of term, then go back to school. The good ones would be invited back for more work terms and often came on permanent after graduating. It was at a work-party hosted by one of these students that I saw my first personal computer. I think it had to be an early Apple, but can't be sure now. Anyway, the main thing it was running and people were trying out was one of those Alien Invasion games: bad aliens dropped from the top of the screen and you moved your weapon left and right on the bottom of the screen shooting upwards to kill the aliens before any got to the ground. Well, I thought this looks like fun, and took my turn to play, but as my previous post said, eye-hand coordination is not my strong point, and you had to use certain keys to move and shoot which I wasn't familiar with, so I lasted about 30 seconds before I lost. The surrounding young folks hooted and basically told me I sucked, so I left the game room, returned to the rest of the party and got a beer. If that was personal computing, I said to myself, then they can keep/stuff it. When the young folks weren't playing the game, they were going on about programming the thing, in Basic I guess, which I thought was mickey mouse; I mean, I programmed an IBM mainframe for a living, you could stuff your toy programming too.

So, all in all, the arrival of the PC was not something I was promoting any time soon; but one day, an IBM PC was delivered and set-up in our department. character-based screen and two floppy drives (A: and B:), and a daisy-wheel printer attached. I have to think that the amount of mainframe cycles and laser printing we were using for documents was seen to be costing too much money, so what about this PC thing for doing that?

First off, many people thought the printer was horrible, still using fold-attached paper fed through a wheel with a print quality barely above that of crayons, so people stuck to their PDS members and mainframe laser printing. The thing that got one person using the PC was Visicalc, the first PC spreadsheet. It was the BA/Manager of the big development project we were all on, and she had to do either a business case or status report with a lot of numbers to calculate and add up; well, she thought Visicalc was even better than sliced bread, and I can see why. There was nothing like it in all our mainframe programs and utilities; she might have been the first person to eventually get her own dedicated PC.

Meanwhile, the rest of us are trying out the PC as encouraged by our managers, so you sit down with at least three 5.5 inch diskettes. The first is DOS; insert it in drive A and turn the PC on. The machine would boot, and I don't recall it taking too long (long boots were still in the future). Once you get the A: prompt, take out the DOS disk and insert your Multimate disc, it being the first PC word processor of any note. So, enter MM or something at the A: prompt and it loads. It was green screen, no graphics, and so you created a document, a blank space to type in. When you wanted to save your work, insert a blank floppy disk in drive B: and save it there…as long as you had remembered to format it using DOS before hand. When you are done, take the third disk with you with your work on it, and leave the other disks for the next user.

Given all this, the PC did not really get a lot of users, but my use of a PC was about increase dramatically.

Memories of IT - could computing be fun?

The time periods covered in the previous posts overlap in some cases, so the PC did not just appear in a poof of smoke where I was working, totally unexpected. Lets pause and talk about computing for fun.

I am guessing the first CRT most people of a certain age used was on a video arcade game. Before that, there was pinball and other physical games like baseball (machine pitched a ball and you hit it with a bat in the same way as pinball flippers.) I played these games in many places as a youngster. A bowling alley on a Lake Huron beach comes to mind, and a few trips to the UK where I saw games where you dropped a coin on top of a whole lot of other coins in the hope it would be the one that tips that whole pile of coins into a slot that delivered them to you; my first exposure to gambling, I suppose; And there was skee-ball, trying to win coupons to cash in for cheap toys/trinkets. ( I mentioned earlier about playing Adventure on a teletype at university, but was really only available to students of the time.)

Then the first CRT-based game(s) appear. Was it Pong? Wikipedia would tell us, I guess. What I remember from the 80's was the arcade in the mall next to the office where I first worked, and it had about 20 machines lined up. Here is where I first learned that my eye-hand coordination skills were average or worse. All these games were based around scoring a level of points to get free games (taken from pinball I suppose) or move to the next level. I could get a free game or two, but would crash and burn not long after that point. Some of my-coworkers could play a game for hours on one quarter. They also set up tournaments for co-workers, which I did not enter.

The main game I recall of this period was the first Star Wars game. It was a first-person flyer-shooter, you were Luke in your fighter attacking the Deathstar; you started by battling Imperial fighters, then to the surface to get past tower cannons, and if you survived to that point, you flew into the trench to shoot the bomb down the hole while Darth Vader tried to shoot you down.

If you succeeded, you would start all over again at an increased difficulty level. I recall I managed to get through the first level and into the next, but never farther. Then a guy I worked with would step up and go thru 3 or 4 or 5 levels, and might just walk away before losing, because lunch hour was over. I felt SO inadequate as a game-playing male.

(This reminds me that at this point, really eccentric characters were still something you could be working with --- at the company, they were programming whizzes or knew stuff nobody else knew; so long hair or dread-locks was OK, plus guys in weird suits with fedoras, and more, and they were all great game players; but they all moved on at some point, maybe to develop games.)

Any way, the graphics on the game were neon lines on a black background., simple but effective for a game set in space. The soundtrack was the familiar movie score, with clips of things like Obi-Wan saying "Luke, use the force!". It was fun, I played it a lot, but not once did I walk away because my lunch was over...

Memories of IT - early 80's - my own terminal, plus email and laser printers

So, I and several other programmers are assigned full-time to the development project. To be productive, management figured out we needed our own dedicated terminals, so we got them, and so did everyone else in the department over time.

A major long-term impact of this was that now we could move from semi-open floor space, where terminals could be shared, to full-on cubicle farms, and that's what happened. Its funny now, because lots of offices are trying to get back to open space, and being trapped in a cubicle is treated as torture, but we were all thrilled when we each got our own 3 and half walls. I think this has carried over into my choices in housing; open-concept and high-ceilings means wasted space. I want walls, doors, and each floor of my house to cover all the available space.

What else was going on about this time? We got internal, mainframe-based email. Up till then, we were still using triplicate memo forms to hand-write messages and send them by inter-office snail mail; can't say I missed that very much, but email was charged for internally for its use of external mainframe cycles, so some departments refused to use it because of that cost, and it usually turned out to my users; but the email worked well, just still text on a green screen and only within the company.

Around this time the company bought its first laser printer for the mainframe, producing excellent quality printing on standard letter and legal paper. What you would do is insert printer commands in your code to produce reports that looked good. We also started typing memos and documents in TSO PDS members, and you would add printer codes that specified font, bold/italics, spacing and more. I think this when my typing started to get faster because of constant use, although I have still never learned how to type like a typist would. (They didn't teach typing to boys in high-school back in the 70's, that was for girls, who also learned shorthand, so they could go right out there and be a secretary! I have to think shorthand really has to be a lost skill by now.)

But even with mainframe email and laser printers to dazzle us, lurking out there was that next great paradigm-shift: the IBM PC.

Memories of IT - A New In-House Development Project

So, a couple of years into being a Programmer-Analyst... it's still the early 80's, back when jobs had numbers after them, so you would start as a PA 1, progress to PA 2, and so on. Progression also meant raises along with annual increases. I would say this was the period of my career, unique to the time, where my salary grew the fastest. No one had invented bonuses based on company success, you made what you made without concern for company profits, while realizing that low or no profit was not good for job security.

So, a couple of years in, the Corporate Systems department gets a new development project! This is full in-house development, PL/1, IMS DB/DC. The company had been using a system similar to the mortgage system I have described, but for securities: stocks, bonds, money markets, etc. I was not in on the process that led to the decision, still being a junior programmer busy on current projects, but looking back now it must have been a reaction to the realization that every-other-night batch processing was not going to be good enough for stocks and bonds trading. So, this was going to be an online system, where the trades on the markets would be captured right after they occurred. It was not a trading system itself, nor was it connected to one, so the traders were going to record what they did in this new securities administration and control system (more on how that worked out, later).

As I mentioned earlier, the core Individual Insurance Systems were already online using this technology, but it would be the first such system in a Corporate area. Our senior programmer/designer/architect took on the challenge of building a trial online system first, to show it could be done in Corporate Systems, It was an easy-to-develop structure he came up with.

Most online systems have one program for each screen used in the system that handles both out put to the screen, and receiving input from the user. I saw this structure as awkward, as it could be tough to discern which part of a program was being used at any one time. Our architect devised a master control program that would, for example, discern what screen had been just used by the user and pass its input to a program built to process input from that screen. It would do all the editing and, if there were input errors, it would pass that information to a program built to send data and messages to that screen, which would do just that. The user has the response and does what they need to do, hit enter and the whole process starts again. Once the input program is OK with the data its has received, it will then do one of many possible things defined for it; for example, the user may have indicated they want to navigate to another screen, so the input program would pass control (and any needed data) to the output program for that other screen, it does what it does and sends data out to the user, etc. etc.

Just want to remind the reader that this is still a mainframe, green screen system, so next time I will recall how we actually built it, and the good and bad things that happened.

Memories of IT - early 80's - Computing Goes Online

So, I am in a department of 25 people, all working with coding sheets, until one day, a couple of terminals appear. They are put in the middle of the department, so each person has to schedule time to use one. This is when I first used TSO seriously, using both the command line and the menu-based SPF function, I learned what Partitioned Data Sets were, and how to create files online and allocate space. The main reason to use them was that you could extract a program from the Librarian tool, edit it in TSO and then put it back in Librarian; look ma, no punch cards!. This led to the first "religious war" I saw; if you used Librarian in batch mode, it would track all the changes made to the code, providing a history of changes over time. However, if you used TSO, that updated code would be placed back in Librarian like it was a new program, no history recorded. Well, people were aghast that the history was going to be lost, how could you debug a program with knowing that history, etc. etc.

The fact that I don't remember if I cared one way or the other is the first indication that I have almost never "chosen sides" in debates like this. I might express an opinion, or actually be the analyst defining the pros and cons, but once a decision was made, I was never the person who would be whining 6 months later "we should have done it the other way..." You gotta go with what's been decided, otherwise it's time to move on.

In this case, TSO updating won out and Librarian was phased out over a couple of years. The corollary technique to change history was commenting your program code, inserting text at regular intervals to describe what the program was doing; so, it was decided that significant changes be noted as comments too.

What this led to was a need for more terminals. Over time, we got enough to have one for every two people. It sat on a swivel table between desks, so you could move it to use it when you had something to enter; the other person would do other work until their turn with the terminal came up again. This would still be in the early 80’s, just before a big new project that would change how we worked some more...

Next Time: A new development project

Memories of IT - early 1980s - Starting to work...

So what was my actual first work? Maintenance, making changes here and there in the Mortgage system. Sometimes there would be a need for a new report, so that might be written from scratch, but often it was take an existing report/program, copy it and change it. Less often, I got to create something totally new; I recall an accounting reconciliation function I developed, matching detail mortgage transactions to GL entries; it was big, intricate, and I was quite proud of it. All of this was done under the direction of an experienced programmer, a nice woman whose name I really wish I could remember, because she got me off to a good start, but left the company not too much later.

Looking back, the main maintenance work is where I first started doing more analysis than coding. Figuring out what the system was doing and how to change it to do what new thing was being asked for, that took more time and effort that the actual coding changes.

I was also lucky to start out in area that literally supported more systems than there were people in the department, so I got to work on many applications over time, from Real Estate Management to Shareholder Reporting to IT Chargeback. I contrast this with the company's main individual life insurance system, which was huge and had a whole department just for its care and feeding.

Other things to note about this period, first half of the 80s:

• All the systems in use had been developed in-house
  
  
• Batch systems were on their way out; the life system I mentioned above was on-line, using IMS DB and DC. This led to the first down/out-sizing I saw in my career; the internal keypunch group was phased out. The current staff were offered positions with an outside company that continued to do the same work for Crown while it was still needed, but with the obvious expectation that it would be needed less and less over time. At some point, the cards themselves were phased out, with the data being entered in files that mimicked the cards, and those files being used as input to batch jobs.
  
  
• The technology/tools used by programmers was also changing; more on that next time.

Next time: Development goes online...

Memories of IT - 1980 - My First System

So, about 6 weeks of PL/1 training, coding some pretty big programs (what they actually were/did, I don't remember) and I am ready for some work. The system I start on is for Mortgage administration; the company loaned money to both individuals and businesses, although the individual business was wound down by the mid-80's. This also meant staff mortgages as a benefit, which I and my wife eventually took advantage of. (oh yeah, got married in 1979 too; she was not in and never has been in IT, a good thing in the long run I think).

So, the Mortgage System, MTG for short. It was a batch system, in PL/1 but not with flat files or VSAM. Someone earlier in the decade had written a little DBMS system that this and other systems used. It was hierarchical, so each mortgage was a root record and had children records of various types, like for the payments collected; this was the Master File. Transactions for the system were written on custom input sheets that went to the keypunch group. All the transactions were gathered up and run against the Master File overnight. The input transactions would be sorted by Mortgage Number/ID, and the main batch program would process Master and transactions in Number order. It would skip past Mortgages that had no transactions, and then apply the transactions against Master records that did. It ran every other night, which gave the business time to look at output one day and then code new transactions the next day.

As I look back it now, it was a pretty good system. Since it was all batch, looking at info for a Mortgage meant printouts. To save paper, the system used microfiche. A printout for each mortgage was put on fiche to begin with, and then each time a mortgage was updated, all the updated ones would get a new-printout on a new fiche. The fiche was numbered, and there was one fiche that had an index of which number fiche to find a mortgage printout on. That index was recreated after each batch run, and would point to the new fiche as needed. Once a quarter, when a lot of new fiche had been added, the system would print a new set of fiche, and the process would start again. There were also monthly jobs for reports, and an annual run for more reports and some housekeeping, like purging paid-off mortgages from the master.

I suppose everyone has a soft spot for their first system, like their first car (mine was a 68 Ford XL) or other firsts. The system would not last forever, but that is another post...

Next time: Starting to Work

Memories of IT - 1980 - Learning to code for real

First day in a real office, wore one of my two jackets and one of my 4 ties, business casual is still decades away. I join the Corporate Systems area within IT (probably called IS at the time), and a team within that area supporting investment systems.

As mentioned before, Crown hired people of all disciplines as programmers, so it starts everyone on a programming course, overseen by one of two IS instructors. I learned that PL/1 code needs to be structured and follow some rules if other people will be able to read and maintain it, so I am quickly cured of some bad habits learned in school. Structured PL/1 means no GO-TO statements, rather one should use procedure calls to sub-routines, with parameters for passing data back and forth. DO statements are another favored construct, both DO x TO y and DO WHILE statements.

Programming technology? Coding sheets, which you gave a group of keypunch people. When ready, you put the deck in a box outside the local operations, who ran it through the reader. The reader and printers are connected by a dedicated line to Crowntec, where the mainframe(s) lived, somewhere in North York.

Given programs of any length, we did use a source management product called Librarian; your card deck would be saved as a Librarian entry/member, and after that you would used Librarian commands to add, delete or replace lines in the entry, again through running punched cards, but just the ones you needed.

Part of running all these decks were cards for JCL, mainly a JOB card with your account and ID, and all the needed PROC statements and such. I think Librarian had JCL in it, but the memory is weak. TSO and partitioned data sets were out there too, but more on that later.

Next time: My First System

Memories of IT - 1979 -Finishing University and Getting a Job

Middle of the school year, employers come on-campus to do job interviews. It is still the olden days, so you had to hand-write job applications for each company on a standard form, could have used copy-and-paste....

I recall 3 interviews; I positioned myself as being a guy who wanted to work on real business systems rather than pure techie stuff like operating systems, fairly prescient I think now, but some of the interviewers viewed themselves as techies, so it did not sell well to them. Of course, I had no idea what a "real business system" was. UofT did not have a co-op program, so I had not worked in any IT department; my summer job was not in IT, but I kept it because I could work part-time during the school year as well, and I needed the money year-round.

I think it was an interview with Bell where I hit the techie reaction most.

General Motors was hiring, but their career path for programmers was that you had to start as a computer operator doing shift work. Neither thing appealed to me, but they gave me a second interview, which meant I had to drive out to Oshawa, east of Toronto, where the interview include a tour of Operations. I remember only a whole lot of printers, so feeding them paper would be the main work. GM solved this problem for me by not offering me a job, I think they sensed my reluctance...

One of the remaining interviews was with Crown Life, a middle-size Life & Health company, located on insurance row in mid-town Toronto. The interviewer was more 'touchy-feely' than others, wanted to know more about me as a person, not just as a set of skills. Their next step was to invite you to the head office building for a tour and to write an aptitude test. There was no Operations room to see, as they had already spun off their computer operations to a separate company, and Crown Life was now one of many of its customers. They also gave the aptitude test to non-CSci majors, believing that programming was a skill people with other degrees could master as well. Anyway, I passed the test, got a job offer that actually paid more than others I had seen, although the annual amount would not buy a compact car today. I also liked that they were a PL/1 shop, as I hated COBOL. So, I accepted and started in May 1979...

Next time: Learning to code (for real)

Memories of IT - late 70's - Finishing University

Moving into the later years of university, it is true in any major that the number of people attending the the 3rd and fourth year courses reduces to a core group. So, I spent a lot of time with such a group, and now look back and wish we had Facebook or something, because I wish I had somehow maintained contact with a lot of those people.

In class, I found myself doing well in more commercial topics, like databases, and not so good in more theoretical topics, like Artificial Intelligence. So, it was clear that I was not destined to be a Computer Scientist, emphasis on the 'science'.

In the meantime, being more senior meant access to slightly better technology. One course had us using interactive terminals tied to a PDP computer, but the terminal was tele-type. It printed what you typed, then you typed "enter", off it would go to the PDP somewhere, and it would then comeback and print-out its response. I think I used this to program a B-Tree type of DBMS, which I recall I was quite proud of and got a great mark, but the details have not remained in memory, and the paper print-out disappeared at some point as well.

What this also introduced me to was the first computer game I had seen and played. It was called Adventure, and if you had a user account balance that more than met the need of your course-work, then it was time to play Adventure. It was a text version of what you would recognize as Dungeons and Dragons, or others of that ilk. It typed out that you were standing at the edge of a hole in the ground, you would type 'jump in hole', it would type what you see in the hole, like a key on the ground, you would type "pick-up key" because you would need it later on... turns out I suck at this kind of game, so no DandD play (or WoW) was to be found in my future.

There was also some TSO to be found. If you took on the job of student advisor, you got a TSO account, as long as you sat in a room near the card-reader and helped more junior students with their course-related questions. As was the nature of more senior people, we looked down on junior folks, especially those taking Programming 101 but who were not Comp Sci majors; much sneering accompanied the grudgingly provided answers. I cannot remember using TSO for anything except a text-based golf-game.

Next Time: Getting a job...

Memories of IT - 1975 - Starting at University

So, I am off to college...during the day, still living in my parents' basement off campus.

One coding course to start: I like PL/1, dislike COBOL, can't seem to fathom LISP.

Take college level Calculus and Algebra: how could something I was so good at in high-school turn into something I loathed? lucky I didn't choose to be a math major.

Other courses come and go, always looking for the easy course to fill the schedule. A course in Canadian Economics was taught by Mel Watkins, then known as a real left-winger in the NDP. His statement in the first class was that a professor could change anything about a course he wanted to, except the name... so he proceeded to teach communist economics, can't say it has come in handy since, but Mel was just fun to listen to.

Still doing coding language courses, the environment is still primarily punch cards. You create your deck, and then get in line at the back of the room to feed them to a card reader, and then move down the line to a printer which spits out the results. The paper is the old style, wide, white with green lines, holes on the side for feeding the printer. So, you only have so many runs before the assignment is due...

A separate room next door has tables to sit at and work, shoot the breeze with other students. The big issue was that most people smoked then, but a movement was started by the minority to ban smoking in the work room. Looking back, I can see why, the air in the room was blue, but as a smoker in those days, I didn't care.

Speaking of smoke... there were a couple of card-reading machine rooms on the UofT campus, one in the sciences building that I frequented, and another in the main Engineering school building. Well, the latter building suffered a major fire one night, and firemen were clearing the building when they came to card-reader room. With smoke filling the room, students told the firemen, "I just need to run my deck one more time (!)"

Memories of IT - 1975 - why would you major in Computer Science?

Last year of high-school, Toronto Canada, 1975... can I recall what was driving me?

Other than my "Fortran Programming" course, my focus is on sciences (physics and chemistry, but not biology) and maths (calculus, functions), a little English Lit, and Music, as a drummer.

I am 18 years-old, shoulder-length hair, playing drums in a garage-band, I momentarily scare my parents with the idea of skipping university and trying to be a rock-and-roll star. However, the band never gets out of the garage, I can't sing or write music, and the number of drummers in the local union is large. I was going to be(and eventually would be) the first person in my family to attend university, I had the marks for it, and my analytical bent won out, seeing a degree as something that would my life more successful.

But what would I take? Thoughts of Law were entertained, but then I looked through the course calendar for the University of Toronto, and there was a whole section/discipline on Computer Science. Well, I was the master of Fortran programming, and computers were becoming more known in general as a source of future careers. I elected for a less theoretical program, with a commerce/business minor, as the road to future employment bliss, and just like that, the next 35 years were based on that decision as a teenager. I applied to UofT and other major local schools, was accepted most everywhere, and signed up for U of T for the fall of 1975.

Next Time: Starting University.

Memories of IT - 1973 - High School Computer Science

Fall 1973, my first introduction to coding sheets and punch-card machines. The class is ostensibly about Fortran programming, but the teacher was barely there. he would write a few keywords on the board, how to define a variable, write an assignment statement, then gave us a problem to solve and program. Most of us looked at each other and said "what the..." but one brilliant guy could figure it out and could be convinced to share some of it with the rest of us.

Once I got a handle on what the teacher was really asking for, I was OK at the basic coding and debugging. We punched cards at the back of the classroom, which were put in a box and taken out of the school to the school board office, where the "mighty computer" lived. Somebody there ran the cards in a batch run, and we got the cards and a print-out back the next day.

If you got the thing working, you got a good mark, and I don't remember any exams, so it was good option course which let you focus on the core math, sciences, english and such that filled up the rest of the day. So, I took it again the next year. I can still recall the classroom and the teacher, but not much at all of what I produced over the two years. I think I learned about GO TOs and DO loops but can't be sure... but it left some kind of impression, because I took it up as my major in university ...

NEXT: Majoring in Computer Science

Memories of life in IT

I have just been doing the math, and I have been doing IT Projects for 30 years now (I started young...). It made me think that I do have my share of experiences that, if written down, some small number of people may find interesting. Seems to me a blog is great for that.

I would call this memories rather than a "memoir"; the latter would imply I have spent time researching myself and might, for example, be able to name all the people I went to school with or have worked with over the last 3 decades; not gonna happen. People who write Memoirs were also usually prescient enough to keep a diary or journal since a young age, but not I.

But, I don't think anybody will be checking my facts or lack of them; and as a blog, any reader of a certain age who wants to chime in is most welcome.

Where does it start? Spring 1972, 10th Grade ( or "Grade 10" as we called it in Canada), looking at optional courses for 11th grade in the fall, and my eyes come upon "Computer Science"; sounds interesting, what the heck...

I wrote these posts almost 10 years, and thought I would revisit them, see if remember things any better, and add on as well, so here we go...

Complex Adaptive Systems: Why most Information Systems don’t Measure Up.

Complex Adaptive Systems, or Complexity Science, is about a lot more than Information Systems, we human beings being a prime example of such complexity. Wikipedia and other sources provide all the details you want on this topic, but one view of it that has stuck with me over the years is the difference between ‘complicated’ and ‘complex’.

Roughly speaking, a complicated system is what it sounds like, a system that is not simple and not intuitively understandable; however, given time and effort, you could analyze and identify all its parts and pieces and describe the whole system. The key is that it is a fixed system.

In contrast, a complex system cannot be analyzed and described as above because it is changing over time; analyze it last week, and again next week, and you will get two different descriptions. For decades, we have been fairly good at creating complicated information systems, but complex was and is rare, if even considered. Instead, what we have in IT is the Change Request, the Backlog, the up-coming Maintenance Release.

The problem has been our creating of information systems based on the needs of an organization at the time we asked. We were guilty of hard-coding the business process and rules (while probably not recognizing them as such) and delivered that code in working order, to be told that the business wasn’t doing things that way anymore; or worse, the business would keep this to themselves and start creating the first of many ‘workarounds’ needed to get past the system limitations and get things done. In either case, the situation would deteriorate and then the change requests would start coming.

Now, hind-sight is wonderful, and decades of hard, well-intentioned IT work should not be scoffed at; this has been a difficult realization to come to, common in many disciplines where complexity science has tussled with older paradigms; and the realization did come together in pieces over time as parts of the problem were recognized and new technologies & tools were developed to help. The now ubiquitous Database Management System came from realizing that lots of flat or indexed files processed in various batch jobs resulted in lousy information, and certainly weren’t going to work in on-line transactions, and even then we had to work our way through competing designs like hierarchical systems before the relational systems we use today emerged.

However, when it comes to complexity, data needed by a business is comparatively stable; it is how the data is used that changes more. Take a typical business process of handling a loan application; today the big loans go to Fred to process, but next week they go to Anne. That is the kind of change you cannot make to a hard-coded system fast enough to support the business. Beyond that, consider the rules that drive a process, such as loans over $100,000 need to be approved by a VP; and starting next week, it is changing to loans over $75,000.

This kind of complexity has finally led to some changes and new tools to help the business. First out of the block has been Business Process Management tools (BPM), which originated when imaging systems changed offices from moving paper around to moving units of work. More recently, Business Rule Management Systems are being implemented that move the changing of rules from the realm of the programmer to that of the business expert.

Will these tools be enough to move us from complicated, maintenance-heavy systems to truly flexible complex systems? There is no denying it will help; they will certainly solve a lot of old problems, so that we can move on to solving newer, better problems and what more can you ask for.

Once a project is started, finish it.

No principle screams from the page to me than this one, yet rarely have I seen it implemented.

I have worked under various managerial styles, but it boils down to two approaches for me, integrated or divided. All enterprises of any size do need to be composed of many organizational units, but that is to divide up the people into manageable groups; it should not divide the enterprise into separate fiefdoms. Just think how many times you have seen or been part of a re-organization, and then think about how many times that has changed the actual work you or anyone else does; the latter adds up to just about nil.

Consider a complete enterprise, with all the usual line and staff functions ; ask anyone in that enterprise how it is structured to do its business and you will probably be shown an org chart. The usual hierarchy of boxes and lines, from CEO down to the base units, is the business graphic that is the oldest and most commonly used. However, why does it have to keep changing? That’s because people are not automons, they need to be grouped in ways that maximize their contribution to the enterprise, while hopefully having job satisfaction and a boss they don’t loathe; and since people come and go, and since people can change over time, any one instance of an organization (as represented by an org chart) will be become sub-optimal as time passes, so re-organization is needed, and it is a good thing if it re-energizes people and re-marshals the enterprise to be its most effective.

The problem is when management believes that the org chart at any one time also represents how the work gets done. Worse yet, they also use the org chart as the basis for changing/improving how the work gets done. This is the ‘divided’ managerial style I mentioned earlier, and it directly affects how the enterprise carries out projects.

At any one time, an enterprise has certain amount of capacity to implement change; the main numbers are how many people there are to do projects, and/or how much money is available to hire outside people to do projects. These numbers are a primary input to that common-place activity of annual budgeting/planning; these numbers are limited/finite, so managers need to decide how to best use them. In the divided managerial style, each major tree below the CEO on the org chart is allocated some portion of those numbers; if you have 10 people available for projects, the number used may be 120 person months. So, Sales is allocated 20 months, Operations gets 40, Finance gets 35, etc. Management may come up with what it believes are equitable/effective means of divvying up the number beyond just dividing it into equal units, but that is a sham; this is further reinforced by the sham idea that if each unit operates and changes successfully in of itself, then the total of all the units’ success will equal the overall success of the enterprise. Does your company have internal charges between departments, often referred to as ‘funny money’? Then your company is divided, because all that funny money means nothing to the bottom line of the enterprise.

A divided approach is a problem when projects are used to improve the business, because projects change the work, not the organization. Take an important and common business activity, order fulfillment. If you trace the work from when a customer first orders a thing or a service, to when its delivery is complete, many (many!) org units will be involved. So, if each unit independently attempts to change/improve that stream of work, they will either overlap with other units or duplicate what other units are doing without knowing it.

The main result for IT is that each org unit will want to use its allocated resources to get its own projects done. So, irrespective of their overall value to the enterprise, a number of projects will get initiated. This will result in overlap or duplication within the systems IT delivers, assuming the systems are delivered. IT management will be faced with conflicting demands on their limited resources, so only some sub-set of the projects will be proceeding while others wait for resources. This leads to projects stopping for a while when they get to a point where they need new types of resources, and then have to start up again when those resources eventually become available.

So, irrespective of the method used to divvy up project resources, the ‘divide’ approach produces an ineffective and wasteful projects environment. The solution to this problem is to move to an integrated managerial approach.

An ‘integrated approach’ recognizes that an enterprise is a team brought together to operate a business, not a collection of independent fiefdoms; a CEO that recognizes and leverages this approach also knows that projects to improve the business belong to the enterprise, and almost always impact multiple organization units. Given this recognition, how an enterprise organizes its resources to carry out projects then will (or should) be tailored to the mix of people involved, just like any other aspect of organization. This could be anything, from ad-hoc teams to a full Project Management Office. Any good structure will do, as long as the enterprise view is maintained.

And that’s all I have to say about that.

IT Project Cost-Benefit Analysis

Assuming you got through the rough stuff of defining costs and benefits, the analysis should be simple. What you want to know is if the benefits of the project will exceed the costs, and by how much. Since costs and benefits may be spread over long periods of time, Present Values of these amounts are also usually calculated to compare the amounts in “today’s” dollars.

When I did my first Cost-Benefit Analysis for a major project, I had to work with an spreadsheet expert to to do these calculations; now you can probably download something for free or a nominal fee that will do basic and advanced calculations. The key things these tools need is the two dollar values, cost and benefit, and the length of time of the analysis. The latter is usually defined by accounting standards at your company, and the most popular time periods used are three years and five years, often based around your company’s depreciation procedures/periods.

Given that, you can usually get calculations like:
• Break-Even Point, the point in time when the benefits realized exceed the project cost
• Various rate of return and yield values, like IRR.

These calculations may be used to determine if a project passes a funding hurdle; its not enough that a project makes money, but it has to make more than investing the equivalent dollars of the project cost in securities or other investments.

After all this is done, a project can now proceed into the gating process to see if it has enough expected value to warrant its being initiated and carried out. Of course, if your analysis has determined already that the project does not have positive return or does not surpass the hurdle rate, you can stop now and move onto the next project idea. Determining that a project is not good for the business is just as valuable as finding those projects that are good for the business. Resources should not be wasted.

How do you know which IT Projects to do? Benefits…

Defining the benefits of an IT project is a different issue from defining costs; the latter may not be easy to calculate, but it can usually be done. Benefits, however, are usually in the mind of the people who want the project done, and generally are not easy to get defined and get a dollar value assigned to them.

In fact, the definition of benefits for IT projects does not exist as recognizable discipline. If you go searching for it, what you will always get is the answer that business sponsor/owner has to tell IT what the benefit is. If they can’t reasonably describe and quantify a benefit, then the project will not happen.

In the early days of IT Projects, the stated benefit was usually the automation of manual effort; this was not always as simple to propose as it sounds, because automation usually was translated into reduced head count for the business. If the staff in the area affected by a project perceived this as eventually leading to lay-offs, this could kill a project because you almost always need those people as the business experts for the business scope of the project. I wrote many project proposals that had reduced manual effort as the prime benefit, but further described these savings as allowing the enterprise to take on more business without adding more people, or freeing up people to do new more valuable work for the enterprise; reduction in headcount was never mentioned.

However, automation of manual work as a benefit could usually be quantified in dollars in potential saved salary costs. The problem today, however, is that all the obvious automation projects have probably already been carried out at your company. This leaves smaller or less obvious cost-cutting projects, or projects that are expected to increase revenue/income.

The question becomes: how much will this project contribute to increased sales of products and/or services. This is difficult to predict, and most business people are leery of attempting to do so. Just like IT Project teams are held to a project estimate or be considered late/costly, business people who estimate revenue increases can be held to task if it is perceived that the expected increase did not materialize. An interesting corollary development is the increase in the number of companies that are evaluating projects some time after they complete (six months or so) to see if the promised benefits have been realized. This can make business people even more wary of putting their names to what is and should be treated as an estimate.

In the end, however, some dollar value of benefits needs to be proposed and agreed to, if a cost-benefit analysis is to be performed. All I can say here is that, like all estimates, stating your assumptions and having them agreed to as the basis of your estimate is crucial. If reality proves that one or more assumptions turn out to false, then everyone involved in the project shares responsibility.

How do you know which IT Projects to do? Project Costs

A typical IT project will involve IT people resources, of course; analysts, designers, programmers, testers, trainers, etc… The titles may be different at your company, but the people will be performing these roles. The question, of course, is how much of the valuable time of these people will be needed, and how much that does that time cost? This is when the estimating begins.

Estimating the cost of IT projects is a whole discipline in of itself. I highly recommend the writings of Vitalie Temnenco on this topic, such as “Software Estimation, Enterprise-Wide - Part I: Reasons and Means (June 2007), at

http://www.ibm.com/developerworks/ration… ,

where the author is described “an architect for the Ontario, Canada government’s Workplace Safety and Insurance Board, where he provides architectural mentoring on implementation projects and helps teams embrace RUP and the Enterprise Architecture concepts.”

In this article, he covers the most well-known techniques, classifying them as top-down or bottom-up, and continues on to cutting edge techniques like neural networks and Dynamics-based techniques.

My experience with estimating has led to always determining up-front how close to accurate an estimate needs to be. When using cost estimates as part of a gating process, I find a reasonably supported estimate done in a short time will suffice. I have heard an initial estimating being referred to as “t-shirt sizing”; is it small or medium or large or extra-large, etc. Even this needs some context for a company, usually by classifying past project actual efforts the same way.

This helps with the simple approach of “Is this new Project X the same size as a previous project we have carried out?” Assuming your company has kept the metrics about previous projects, and that is a big assumption, you can then extrapolate the size and cost of any similar new projects.

True, some one has to lay it on the line and decide if a new project is reasonably similar to previous projects, and the person doing that should probably define some assumptions about why they believe so. This allows the decision makers to agree with or challenge the assumptions as needed, until all are agreed on the assumptions and accept the resulting estimate.

If you have no metrics/history to use, you may need to do some project planning to define the tasks likely to be carried out. Again, a whole other big discipline exists for project planning and management, and use of techniques of like Work Break-Down Structures (WBS). A simple web search or a visit to the Project Management Institute (PMI) website will get you started on that as needed. The only thing I emphasize in this approach is that as much as possible, people who would do the work should help in defining the necessary tasks, and then they most certainly should do the estimating of effort (usually in hours or days) of those tasks. They know best what will be needed, and will make sure they are happy with the estimate because they will likely have to work to that estimate when the project starts.

This planning approach must also make assumptions, mainly about what the project would deliver that will provide the expected benefits, and that may not always be very clear when a project heads into the gating process. So again, define assumptions that the decision-makers will accept and then go from there. In the end you will have a number of effort hours or days, and then you need an accepted price for an hour or day. Some shops will use a flat rate for all hours, while others will group the hours by role or seniority to get a range of rates. In either case, you multiply the hours/days by the price(s) and you have a cost. Other costs may be involved as well, especially one-time purchases of equipment or software needed by a project.

To go along with this cost, you will need an estimate of elapsed time for the project to execute and finish, because most benefits will not be realized until a project is over, and (later on) we will want to compute a present-value of future costs. More assumptions are needed; how many people will be assigned, what work can be done in parallel, etc. If you have used a project planning approach, you will have the advantage of defining many of these things already and will have come up with a project duration along with the project effort.

How do you know which IT Projects to do? and not to do?

Any company, and its IT organization, has a limit on the resources it can use on projects, so it has to choose, and choose wisely, from all the ideas and opportunities it may have before it at any one time.

The term that has emerged to describe this is Project Governance. The most common analogy used to describe this governance is “gating”; a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, the rest wait for another chance when more resources are available, or are eventually dropped from consideration.

It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development. As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the company.

The key question then is: what projects does the Enterprise consider to be most valuable? And the follow-up: how does it determine the value of any one project, so it can be evaluated against ‘competing’ projects?

In private enterprise, the single common goal is sustained profitably , through a varying combination of revenue increases and cost reductions. Projects are used to change how a company operates in the expectation that such change will deliver the desired revenue increase or cost reduction, and deliver it such that the value of the changes is not exceeded by the cost of the project itself.

So, we have two aspects of a project that will usually be used to determine its value:

1) Its impact on revenue or costs of the enterprise, commonly known as Benefits.

2) The Costs of carrying out the project (which some refer to as the ‘investment’)

Given these two dollar numbers, which is what they should always boil down to, you can then use them in one or more forms of what is commonly called a ‘Cost-Benefit Analysis’. However, neither number just appears out of thin air, and any numbers you do come up with will never be exact, because estimating is involved.

Next time: getting Costs and Benefits for IT Projects.

David Wright

http://www.authorsden.com/visit/viewwork…

Pick The Right (IT) Projects for the Business

IT Projects have rightly earned the reputation over the years as places where lots of money goes in and no value comes out. We are all aware of the CHAOS studies by the Standish Group that show most IT projects are also usually late, and a large number are never even completed(!).

How did this happen? My view is that, way back when, computers were first used to automate rote manual tasks, and the results from these projects were valuable and easily seen as so. This led to the belief that automating most anything was going to be good for the enterprise but, as projects moved into more complicated/complex aspects of the business, the returns of pure automation began to diminish. Unfortunately, it was still assumed that the value was there, and it was a complete assumption; actually determining what the value was to be was done only rarely.

Early computer projects really were run in the realm of the IT department, likely better known then as the Data Processing department. Business departments had been happy to get their worst drudge work automated, but the techie geek image of IT started at this time as well, so the business would deal with IT as little as possible to get what they wanted, but otherwise considered IT as being on another planet. In this environment, one idea about using computers could snowball into a big project if enough people liked it.

So, projects proceeded into more complicated areas of the business, and they started to break down, some failed, and now Management wanted to know why, and also started asking if all these computer projects were worth what they cost (because costs were not assumed, they were measurable).

But that is the history: all the easy automation projects have long been done.

Next time: how to choose the most valuable IT Projects…

Which projects should you focus on first?

Continued from:

“Get Your Projects Under Control…”

http://businessanalysis56.blogspot.com/2009/05/get-your-projects-under-control.html

If you have too many projects going at the same time, pick the best ones to focus your resources on: but how do you do that?

If no other factors are in play, choose the projects that most closely look to be near completion. This can be difficult, given that “90% done” syndrome ; you may focus on a 90% done project and find it is more like only 10% done in reality(!), at which point I would drop it and move on to a more promising project.

Other factors can be applied in selecting projects sub-set; they depend a lot on how much information you have on your projects, and can include:

- Business Value or Return On Investment: if you already have some notion of the value of a delivering a project, especially a cost-benefit analysis, you can try attacking the projects with the highest value if that is something your business management will appreciate. Many companies are good at defining value or benefit up-front, but only the better companies take the time after a project is complete to confirm if the benefits really were realized. If you company does not do this yet, suggest they start, but avoid this factor for selecting the projects subset until they do start.

- Project Priority, which can be determined based on a combination of Business Value and/or other Project Drivers. This is often a weighted calculation where values are assigned based on how well a project addresses items such as ‘increased sales’, ‘improved decision-making’, ‘better customer service’, etc. . Each project has a priority value to compare to others, and highest-priority projects are initiated first.
If you have a Priority value assigned for your projects, but it really hasn’t been the key factor in initiating projects, then start using it; that’s pretty obvious, I know. What is more likely is that priority did play a part in initiating projects, but has not carried over to decisions made during projects. If your projects are now executing out-of-priority order, see if re-ordering them will help in faster delivery and increased business value.

- When all else fails, Ask. (Or just start with Ask). It will be no big secret if you have many projects underway with no ends in sight. It is also likely that many current stakeholders may not have been involved when some of the projects were started. So, you can meet with these stakeholders to determine what their current priorities are and which projects are of most value to them.
The usual issue with this approach is: who should I ask? In a perfect situation, I look for the person highest in the organization whose span of control covers all departments who sponsored or are impacted by the projects. However, this person could be senior enough in the company that they may decline to help you, preferring to delegate to their reports. Querying and meeting with this group may give you the priorities you need; or, it may illustrate any politics or power struggles that are on-going, for which you may be able to facilitate a resolution or at least a compromise…or not. In the latter case, it may be necessary to escalate this back to groups’ common manager for resolution.

So, one or more of the above factors may assist you in identifying the best sub-set of projects to first target for quick completion. If no strong values or priorities can be discerned, I would default to those that can finish the fastest.

Get your projects under control...

In these trying times…or some variation of that…is the first line in every other article or post of the past 6 months, and I am getting really tired of it.

What usually follows is advice to get things in order, whatever the thing of interest is, while focus is elsewhere and before it turns back to you. However, if your thing of is interest is the slate of current IT projects in your organization, there indeed may be some opportunity here. It’s time to get positive.

Do you have a lot of parallel projects? Probably figgting for the same more limited (than ever) resources? Are they all target-date challenged, i.e. all late or later than late? Now is the time to get them under control.

The absolute first priority is to wind-up as many of these projects as possible, as soon as possible. This sounds like common-sense; it is certainly sensible, but not at all common.

No rocket-science here, you need to allocate all your resources to a subset of the on-going projects, get some successful project deliveries, and then look around for new opportunities. If you have a large slate of current projects, you may need to do this again (and again) for another subset of projects. Keep doing this until the number of current projects no longer exceeds your capacity to resource them, or as close as you can get. Do your utmost to avoid initiating any new projects while cleaning up the current projects.

(Of course, some projects cannot be delayed, especially changes needed for new legislation or other compliance issues. Jump on those immediately and get them done quickly so you can get back to the other on-going projects.)

It also helps if you can manage to identify any existing projects that can be canceled out-right. This will not be totally in your control, as the business unit or sponsor that wants the project done may resist. It is just to your advantage to identify any projects that are clearly no longer needed, and who’s sunk costs should be capped.

How many projects should you focus on as described above? You can’t overload a single project either, without incurring diminishing returns. A rule-of-thumb would be to define the number of people on a typical project team in your shop, and then divide that number into the total number of people you have available for projects. There are many ideas and opinions about optimum team size, usually around 7 plus or minus 2.

Next time: which projects should you pick first?

IT Projects Success - Principle #13: Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables

13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system.

This is a more specific statement of Principle #3; in Cascade, an Information System Architecture is used to integrate the two week deliverables, until a complete deliverable (component, sub-system) is assembled.
In parallel, a release schedule is a great approach to support delivery. Gather the usable deliverables into timed releases that go into production together. As per Principle #11, a Release each quarter is recommended. The business receives what they are paying for often enough to be of value, but not often enough such that assimilation of change is so frequent it causes chaos.

IT Projects Success - Principle #12: Within the three month phase, parcel work into two-week periods.

12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two developers), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire project scope has been addressed.

OK, a 64 word-long paragraph is pushing the boundary of a ‘Principle’, but this point is the basic building block of Cascade. Are two week periods too aggressive? I think not, based on experience. I find developers and a tester like to work in such quick bursts, as delivering more results faster makes anyone feel more productive and accomplished, and illustrates quickly what works and doesn’t work. However, small bits delivered quickly need to be integrated into an overall solution, which leads to Principle #13.

IT Projects Success - Principle #11: Partition large projects into 3 month phases

Continued from:

http://blogs.itworldcanada.com/insights/…

(Want to see more? head over to http://bit.ly/Ypycy )

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

I was lucky to learn this early in the 90’s as Project Management was getting a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools were in use, but usually in limited numbers; MS Project, on the other hand, was readily available and budding Project Managers thought they could now plan the whole world for months or years in advance. What actually happened, however, was constant re-planning as the reality of business change and resource turnover always took their toll. As Napoleon said, “A plan is only good until the battle is joined.” After that, one must adapt to the changes that will always come.

My own experience was on a large project that was broken into a dozen pieces, which were planned separately to a target 18 months away, at which point I was asked to integrate them into one plan while resolving resource conflicts. First thing, we found was that MS Project of that time crashed when you reached around a thousand tasks.

So, it was about this time that some IBM PM consultants were brought on to sort out this mess, and where I first heard the above principle. Yes, you need a plan to get started and to control a project over time. You can even sketch out a plan out over many months to see and communicate the big picture; but, do not commit to any target date over 3 months away, odds are you will miss it. This also means you should do the detailed planning only to the next target date, meaning the full WBS and resource assignment. (At the other end of the detail level, the IBMers also recommended that the shortest task in your WBS should be 2 weeks, no less, otherwise you are micro-managing.)

Once you have a detailed plan for three months, and a high-level plan for the rest of the project, you can add more detail to further target dates as the project progresses, as each interim target is reached or on a rolling month-by-month basis. The level of change in any 3 month period will be manageable, much more than over the whole project.

There is a more recent corollary to the three month principle; the age of the mega-project should be over by now. Any IS project that takes many months or years to deliver the system is destined to fail. Yes, large systems are still needed, but break them into pieces that can be delivered, ideally about every 3 months; longer than that and you start to slide back to the mega-project approach, while shorter than that will not produce enough of the system to be worth delivering to the business. All business works in 3 month quarter cycles anyway, IT should too.

IT Projects Success - Principle #10: Models are better than text.

10. Models are better than text.

I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT). I must offer my respect to the many talented people who labored to produce these documents over the decades; these documents were at least a step up from no Requirements or Design artifacts at all.

Consider what a ‘model’ really is in general; it is a representation of a finished product in a scaled down version; engineers have been literally creating models of what they are going to build for centuries, for such reasons as testing out problems on a small scale, and for presenting a view of the end result to whomever may be paying for it.

At this point, though, let us abandon any other aspect of physical engineering as an analogy for Information Systems development. Software is different; while tools and bridges and buildings have been created to either extend or protect the physical capabilities of human beings, Information Systems are created to extend the our mental capabilities, to help our thinking.

Given that, software can still be engineered, but it is a different type of Engineering. Software or Information Engineering has existed as a known concept since the 1970’s, although anyone who thought to call themselves a software engineer usually incurred the wrath, or at least disdain, of the established Engineering Disciplines and Schools. I am not an engineer, would not claim to be one, but my understanding is that traditional engineering is addressing software within its disciplines. In the future, as software becomes even more critical to our well-being and safety, it may be that those who design and create software will have to be accredited engineers, just like the ones who design and build bridges. I think history shows that quite a few early bridges and other structures were prone to collapse before engineering principles started to prevent it. Software is only a half-century old, so even in the age of internet speed and high change, more time will be needed to bring software in line with other long time products.

In the meantime, it should be a goal all of us in the IT business to adopt useful aspects of engineering to improve the quality of software, and modeling is a key concept to adopt. It almost frightens me that many still promote programming as an art form, that code can be beautiful or exquisite in some way. Well, even the most obscure art needs an audience to appreciate it, and it can’t just be other artists. Software is a product to be used, not admired, so if anything, programmers of the past 50 years have been more like craftsmen, using individual skills and experience to produce useful ‘objects’ for society to use. The problem is that demand continues to out-strip programmer output (remember the backlog!), so improved, repeatable and transferable methods are needed to transform software development from a craft to a true industry.

(see more at http://stores.lulu.com/dwwright99 )

IT Projects Success - Principle #9: Leave a record of what you have done, so the project will not miss you if you leave.

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

If change is the only constant, then resources on a project will change. The risk in such change is that a person’s contribution to a project will be lost, and that the new person assigned to the project will have to start over. This is a particular risk in “quick and dirty” projects where an operating result is produced, but no one else can understand the code that was produced. However, if the contribution involves producing quality artifacts as described in #8 above, there is always a point-in-time record of what has been accomplished so far, which can be used by new project resources to continue the project with minimal disruption.

Last Chance to Participate - Business Analysis Benchmark

This is your last chance to participate in the 2009 Business Analysis Benchmark study - and access your copy of last year's research. Last year, this research was circulated to a readership of 20 million business and IT professionals around the world. Thousands of analysts and project managers leveraged their free access to this study and used the data to communicate the impact of requirements quality on project outcome.

This year's theme is THE PATH TO SUCCESS. The redesigned survey is shorter, and will help participants to both optimize the tactics needed for improving performance given their maturity level, and better define the business value of continuous improvement in requirements discovery and management.

Completing the survey will take you about 10 minutes. As always, access to the research will be freely given, your personal responses are confidential, and I greatly appreciate your participation in this important industry activity. Use this link to see more about the survey, and get started: http://www2.iag.biz/e/464/kira-TakeSurvey-id-1201992/CPC1M/61635542

Or - type into your browser: http://www2.iag.biz/e/464/2009-04-20/CPC2Q/61635542

IT Projects Success - Principle #8: It’s the Deliverable (that matters), not the Task.

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


The final deliverable is the Information System ready to be used effectively by the Business. If you can jump from ‘Start’ to this final deliverable in one “Task”, then power to you. Some people can do this; most cannot. This is again where a team of specialists is most effective on an average project.


This means that the project work will be divided into many tasks, sub-tasks, etc. . . . Once assigned a task, it is the goal of a specialist to produce a deliverable/result/artifact that can be used by the next specialist to further the progress of the overall project. Unfortunately, this simple idea has been the starting point for literally hundreds of IS delivery methodologies, many which spend an inordinate amount of content explaining how to do a task, how to amass all the tasks in Phases, and often insisting that its way is mandatory for success.


What this can lead to is an over-emphasis on the how of IT project tasks, to the detriment of actually completing them with all due speed. Here we see the task that is 90% done for weeks, or the infamous ‘analysis paralysis’ where a project cannot seem to get past Requirements. Ends do not justify any means, but Ends must be delivered.

Can IBM automate decisions? Sure, it's already happening.

News post: Algorithms everywhere: Can IBM automate business decisions?

http://blogs.zdnet.com/BTL/?p=16345&tag=nl.e019

see “Smart (Enough) Systems” http://www.smartenoughsystems.com/ by James Taylor.

This is not about automating decisions made by people, it is about automating decisions that don’t need people. Dig deeper, and this is about Business Rules. In situations where all responses to a question can be defined depending on data about the situation, having people pick an answer is a waste. Biggest example? Credit Checks and your Credit Score, and ‘deciding’ to approve a request for credit. This is being done thousands/millions/whatever times per hour/day, and there not enough people available to do this.

Why do you think IBM bought iLog? Advanced companies already do this. Insurance underwriting is another big domain.

And this is never going to be about Artificial Intelligence. Smarter systems are made of the same stuff as ‘dumb’ systems, they just know more, enough to make a decision based on facts. If the facts aren’t available, the system is not going to ‘think’ or ‘reason’ its way to a decision, its just going to ask for the facts, please.

AS-IS versus TO-BE

Have not seen a great methodology debate (without the word 'agile') for ages. Here is one over at Modern Analyst, with my comment already added: http://bit.ly/WNLN

IT Projects Success - Principle #7: One Architect/Analyst can generate enough work for two Developers and one Tester

7. One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

This is actually one of those “rules of thumb” that have been borne out over time. (The ratio may vary a bit from case to case, like when the experience levels are different across the roles.) This ratio combines with the specialization of Principle #6 to form the strong basis for the Cascade effect covered in Principle #13. … so stay tuned.

2009 Business Analysis Benchmark study

IAG Consulting ( www.iag.biz ) is conducting its 2009 Business Analysis Benchmark study. I invite everyone to participate, as last year’s research was circulated to a readership of 20 million business and IT professionals around the world. Thousands of analysts and project managers leveraged their free access to this study and used the data to communicate the impact of requirements quality on project outcome.

This year’s theme is THE PATH TO SUCCESS. The redesigned survey is shorter, and will help participants to both optimize the tactics needed for improving performance given their maturity level, and better define the business value of continuous improvement in requirements discovery and management.

Completing the survey will take you about 10 minutes. As always, access to the research will be freely given, your personal responses are confidential, and I greatly appreciate your participation in this important industry activity. Use this link to see more about the survey, and get started: http://www2.iag.biz/e/464/kira-TakeSurvey-id-1201992/CI49E/56513172

Or - type into your browser: http://www2.iag.biz/e/464/2009-04-01/CI4AI/56513172

IT Projects Success Principles 3 and 4

IT Projects Success - Principle #3: Use Architecture to describe the business, before and after projects.

Continued from:

http://blogs.itworldcanada.com/insights/…

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

“Architecture” is becoming a more widely used term associated with Information Technology. The number of adjectives applied to the term seems endless: “Technical Architecture”, “Systems Architecture”, “Business Systems Architecture”, “Enterprise Architecture”, and so on, so it must be important.

Why do we need Architecture?

Architecture is not an end in itself; Architecture exists because things need to be built.

Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.

Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.

Applied to IT, a component assembly approach is dominating the industry, from the OO approach of software development, to real-time use of defined services, as popularized by SOA. Specialized agent software is starting to assist in finding services and brokering between different services to perform transactions collaboratively.

For the average company using IT, architecture is needed because it needs focused IT functionality to deliver the highest current value, while trying hard to ensure that the function will work (“integrate”) with the next function that is needed.

It should be emphasized that this is Architecture for Information Systems.; there are methods and approaches being promoted for an overall “Business Architecture”, architecture for the whole business, not just IT. Originating from IT circles, they often look like an IT/IS architecture, which can be confusing. The Architecture in this book is definitely about Information Technology and Systems.

The good news is that you do not need to invent an IT Architecture method for your company. Many authors and vendors have methods available already. When starting out, I recommend investigating/adopting the architecture that started it all, the “Zachman Framework” as developed and enhanced by John Zachman.

(see www.zifa.com for details)

He devised the illustrated matrix framework that cross-references core information concepts against the levels of abstraction that are used by different audiences and participants in delivery of Information Systems.

The key benefit of the framework is that it illustrates how information concepts can be transformed through the levels to produce operating components of the needed Information Systems.

Last two points on Zachman:

- The cross points of the Concept columns and Abstraction rows are called “Cells”; each cell will group the methods or documents (artifacts) that describe the content of the cell. Zachman does not specify what artifacts to use, or what methodologies to use to create the artifacts. The things in each cell on the diagram are just suggestions. Keep this in mind for Principle #10.

- The Framework looks two-dimensional, but it is actually multi-dimensional when artifacts in one cell are cross-referenced to artifacts in other cells, the most obvious example is What vs. How, i.e., what function creates specific occurrences of data.

---------------------------------------------------------------------------------------------

IT Projects Success - Principle #4: Pick the right project(s) for the business.

Continued from:

http://blogs.itworldcanada.com/insights/2009/03/20/it-projects-success-principle-3-use-architecture-to-describe-the-business-before-and-after-projects/

4. Pick the right project(s) for the business.

At any one time, the IT department of an average company is running multiple projects. How did they get started? How were they even defined as a project that needed to be carried out?

No one may actually know. In more chaotic environments, projects can start as a seed of an idea, pick up momentum and resources if a manager or two can see that they will benefit from the project. At some point, the project will bump into another one, usually because they both want the same IT staff or other resources. Strong managers can often come out of these resource conflicts with what they need for their project, while the other managers suffer from their project going on hold or being cancelled. Otherwise, the conflict is escalated until one common, higher manager has to step in and decide who gets what; and this is often the first time the higher manager has even heard about the projects.

I sat in on a senior management committee meeting where the progress to date of a grand project was presented and a request for a budget increase was made to complete the project. The CEO took all this in, and commented that this was very interesting, but given the sizable amounts of money and time expended so far, why the heck had he never heard of this project before?. The next week my manager sent me to see the CIO, who charged me with coming up with a new process for defining, approving, and controlling IT projects, better known these days as ‘Project Governance’.

So, how do you pick the ‘right’ IT projects? First you have to make the choice explicit, avoiding the random start-ups described above; do encourage any and everyone to suggest possible projects. An active strategic and operational planning process will also tend to drive out new projects as senior and middle management look for IT assistance to reach their assigned goals. All these proposed project ideas then become input to a ‘gating’ process, supported by means of valuing the worth of a project like, but not limited to, cost-benefit analyses.