Project Management and Change Management

I've been trying to get caught up and ahead on the reading. I read a few of the articles on change management and project management.

The PMBOK articles seemed a little over the top really. Most projects I've worked on have been one man teams. I've worked computer jobs, and have worked on computer programming projects. As such, the project life cycle is something that I've encountered before. What I've run into in the work world is both fancier and less fancy than what is normally in the book.

For starters, part of this depends upon the sales department.

You see, if the sales folks are drumming up projects, you get requirements from the sales department folks. Hopefully, they haven't attached dollars and resource committments to the requirements before asking someone technical if the thing was possible short of half a billion dollars. Don't get me wrong, the sales folks generally are the ones bringing money into the company (which is a good thing), but if they promise something undeliverable you'll have unhappy clients (which is a bad thing). Generally good sales folks strike a reasonable balance on this one.

The next step is to work out enough detail that once agreed to neither side will feel cheated. That isn't how its stated in the book, I suppose. But that is the idea. The project folks need to know how big the project will be, and what their committments are. The client folks need to know how much it will cost and whether it will do what it needs to.

Assuming that the project goes forward, the next step is to figure out what will happen. Generally, this entails someone understanding the project, working out a schedule, breaking the project out into pieces (if it big enough to worry with this) and so forth. Generally, it is a good idea to talk to the client and confirm all the known facts of the project. This is particularly true if time has lapsed since things were written down the first time.

When I was programmer, I generally tried to read through the requirements (they were generally two paragraphs on a one page fax). I then tried to read through the project notes created by the person who wrote the requirements document. This was normally a technical person. I then tried to track down all of the documentation and data files associated with the project. Then I worked through it. I would then perhaps take a tiny step toward solving the project, enough that I could see what the hard, tricky bits would be. I looked for all the areas that I would need client opinions or approval. This might be how to use a client code, what do to do with weird data (names that are two long or have some weird character or phone numbers that are obviously fake or prices that are negative... weird).

Then I called the client. This was a change from when I first started at the firm. Generally I called right when I got the project. This was, in fact, the recommended method. However, as some of the projects had been in the queue for weeks, I decided that a couple of hours wouldn't make that much difference. In fact, it did. It meant that I didn't make the "other" phone call -- the one that normally came one day later with all the questions about the project. Since I normally had to call and leave a message with the client both times, this meant that it could take days to get running.

Having done all that, the next thing was to program the project. Generally, the projects were sort of all of the same type, just different flavors. For me, I tried to get enough info to finish the project without needing to call the client. The reason for this is that client contacts were much slower than normal work. When I called a client, I would either get the client and continue working or I wouldn't get the client. When that happened I would ask the client to call me back. If there was nothing else I could do on that project, it would move to the bottom of the stack. (The projects had file folders. I actually moved it to the bottom of the stack. My stacky tray held projects on hold, my desk held the project that was current.)

This actually meant that "good" clients got better service. Good clients were responsive, and good clients had opinions. Also, good clients cared about doing their jobs well. That may sound silly, but not all of our clients were good clients.

Oh, and good clients don't yell at programmers when they have a bad day. This is very important.

The next step was to show everything to someone else and have them see if it was correct. This involved highliting each character (including spaces) that we changed in any document or program. This also entailed having sample data and instructions (which have been used somewhere) which were also checked. Assuming that everything checked out, then it was time to deliver the project.

The next step was to inform the client that the project was ready for delivery. Generally I tried to log onto their system and get to the point where I could deliver the button with one more keystroke. Then I called the client. Assuming that they said that delivery was ok (it was possible that there was something else to consider), I would then deliver the project. The next thing to ask was when they would next be ready to use it. Occasionally, this would be immediately. If so, I'd check what I had done and walk the client through.

Then you wait. I had to support my stuff for a period of one month (or longer, depending) -- no questions asked. Obviously, part of the goal here was to not get calls about bad software. A bug that a client finds in one month is probably big, glaring and obvious. Leaving a big bug in a project is bad. Spelling the company's name wrong would fall into this catagory. After a month, the questions were from other people in my company (generally high up people), so small bugs were also bad. Also, you don't get paid to fix bugs. Really. We got paid hourly (as a company) to write the software. We got paid to fix the bugs early, we didn't get paid to fix the bugs we found late. The little bugs were the nasty ones. Oh, and generally the little ones have been around long enough to mess up everything else, which then needs fixing. Really, this is something to be avoided.

So, that is some of my experience with the project life cycle.

Later I may talk about "change." I decided this was getting crazy long.