When I first took over the position of project manager with a team of programmers answering to me, there was a "Bring Your Kid to Work Day." So, I took my eldest with me thinking, erroneously, that he might see first-hand what his old man did for a living. At the end of the day he concluded that I did "nothing" at work and he wasn't shy about letting everyone he knew know that.
Well, I received a pretty good salary for "doing nothing." In a sense, "doing nothing" was a sign of success; it meant I had no crises to attend to and it happened there were no client or status meetings scheduled for that day. However, I was "working;" it's just that he didn't see my seemingly casual conversations with different folks around the office, both with my employees and with other analysts, as "work." He didn't notice that we were discussing programming strategies, working out solutions to non-urgent problems, and the way that all the various parts of application development fit together. There is a lot more involved than someone sitting at a computer writing lines of code.
First, there's a needs analysis. There's no point in spending hundreds of hours developing something if it already exists, or, if it is not commercially viable. "Commercially viable" does not mean a top seller. What we did was business-to-business sales. In other words, we had to have a client or two who was willing to pay for the product before a single line of code was written. Cost-benefits calculations also worked into the development plan. You could not afford to take on a project that would involve potentially thousands of man-hours if the potential revenues did not at least cover your salaries and other expenses.
Preliminary technical outlines of the final solution were needed by the sales folks because they would have to sell something that did not yet exist. They would also need comparisons to similar products, or products in a related field, to demonstrate where your proposal was superior and worth the effort. Analysts were required for all this work. In theory nothing should be done in the area of development until a signed contract was in hand, but, in reality the preliminary work had to be well underway by that point.
Both general and specific goals of the product were needed as they would get turned into, or were driven by, "deliverables." That is, the description of the end-result that the buyer would have to "accept" before the project could be called complete and final payment was due. The deliverables were also worked into the quality acceptance plan that would be developed. Quality acceptance meant careful definitions of what, exactly, the program was to produce and within what guidelines or parameters. Tests would be developed to measure this. This is called "scoping" the project. One thing you wanted to avoid was some programmer getting a bright idea and spending time on a feature that the purchaser did not ask for.
The actual plan of approach to the writing of the code needed to have a general outline with delivery dates (that is, when various parts were supposed to be done to the purchaser's satisfaction) and detailed plans so that the various programmers assigned to the job knew precisely what was expected of them. Someone had to oversee their work and keep them on track, making adjustments to assignments and personnel as required. That was my job in this case. So, chats with the head of quality control, with the database designers, with the writers responsible for delivering documentation, with project directors, with sales folks, with client liaison, with networking and operations (the back-room folks), and with senior management were all part of the job. Just keeping in touch to insure that everything was in sync and on schedule.
I got my position by default. I had quickly become the top C programmer on the project as well as a specialist in other odd parts, such as a routine that had to be written in LISP (an obscure and difficult language to work with). However, the original project manager proved to be not up to the job and he was demoted to managing the programming team. He couldn't handle that job either. There was no one left in the organization who was specifically qualified, so I just started doing the job. Then the president made my position official and I was given hiring and firing rights. The first person I fired was my former boss. I then set about building a team of highly skilled programmers.
I had a scheduled meeting with my entire team once a week. That's where I'd pass on any news from higher up in the company, discuss points of company policy, and go over any topics of general interest to the team. We'd then go around the table and each member would describe what they had accomplished in the past week and were encouraged to bring any problems they had encountered to the table so the rest of us could make suggestions or offer solutions. I'd also go over the plans for the next week and lay out what was expected from each member. I would make sure that they agreed with their job assignments. I did not want an unhappy, grumbling, and backstabbing team. I think I succeeded in that regard.
I would meet with the company president once a week to bring him up to speed on what was going on in my area. Also at that meeting was the fellow responsible for co-ordinating everything with the client. However, outside of that meeting he never had anything to pass on to me. He spent almost his entire day, every day, on the phone with client reps going over their requirements. It would have been very helpful if he had delivered information from the client to me, but, he never did. So, in the meeting with the president he would go over the charts he had prepared, and then I would report on what was actually going on. It might as well have been two different meetings, as his charts had nothing to do with what we actually did. I did not deliver charts--I verbally reported on what was happening in a conversational mode.
So, that's what I did in one "analyst" position. I also worked as a performance and capacity planning analyst for clients during my career and that had very different job requirements. Ironically, I spent my last five years in a "support" role, which, in a sense, was a demotion for me, but, it was also the job that made the least demands on me and paid the highest income I'd received during my career. I had started in the field as an operator in 1983 making $11,000 a year and wound up in 2004 with a fairly good reputation and an annual income of well over $120,000--in other words, more than 10 times what I had started out with. Not bad for a job where I did "nothing."
No comments:
Post a Comment