The top route depicts a typical early installation; by installing early, the user gets to run the software and thus gets to respond meaingfully. The middle path has the symbol CP, which indicates critical path. The critical path method has not seemed as common as it once was. Small projects usually do not need the critical path method. The bottom route also has five boxes, which represent five units of work;
|
Perspectives from a Manager
Usually I serve as both a manager and programmer on software projects. At the AQMD, however, when I first started, there were nearly forty active projects and many were not purely software. We had weather stations to install; we had air chemistry experiments to monitor with computers. We had so many topics, that I did not do much more than manage on a few projects.
People and Persons
Too often the generalities of people are praised rather than the skills and nuances of persons. The term people applies to psychology or to populations or countable groups of persons. The term person emphasizes the characteristics of individuals. Each person is a different individual, with different feelings, desires, skills, habits, and nuances.
Persons are Most Important: the Boss
The manager works for a person; keeping the boss happy is a prime responsibility. In many ways, this perspective is the personal view of the organizational mandate: keep the organization going. A manager always hopes and prays that the organization deserves preservation, and certainly most do. (see Organizational Malfeasance xxx.) The boss needs knowledge and insight. Generally I follow long term principles, but even then, surprises happen. Keeping the boss aware of the reasons, keeps the boss out of hot water. Hopefully, the manager performs well enough to increase the confidence of the boss and the success of the boss.
Persons are Most Important: The Managers
The managers of the other departments usually work closer to the profit centers than do the IT managers. It behooves the IT manager to keep those managers happy; they have clout and influence, which the IT manager wants pointed in helpful directions, The other managers also carry the vision of the organization. Some vice-president might declare the vision, but the managers put muscle towards fulfilling the vision. When implementing change, the IT manager needs the co-operation and influence of the other managers.
Persons are Most Important: The Clerks
These persons work for other managers, but these persons are essential to the success of the IT manager. The warehouse manager might want new software, but the buy-in of the warehouse clerks is essential. When the clerks buy-in because they see benefit, the implementations go so much smoother. Repeatedly, a good clerk has propelled a project towards success. Friendships built over years also have fortified the position of the IT manager. When the important clerks like the software, the likelihood of success by the IT manager improves.
Persons are most Important: Co-Workers
The manager usually has other persons who contribute to his success and the success of the organization. The manager has the responsibility to encourage his co-workers. I was educated as a team programmer and very successfully employed as a team programmer. A very few programmers work best as solo actors. In fact, since so very few programmers blossom as soloists, the manager probably should avoid hiring soloists.
Over the years, I have personally known several outstanding programmers; all of them had loyal comrades.
The Programmers Pyramid plays a larger part than most people ever understand. A small team of A programmers can out-perform a herd of C's
Tuesday Noon Target Dates
Over the years, I guided big projects towards completion on Tuesday at noon. Actually, by the prior Friday, most essentials were running and on Monday, permissions for user became active. By Tuesday noon, the finale was anti-climatic.
Thursday Noon Target Dates
When we as a team were on schedule as of Thursday noon, I would encourage the programmers to declare their bonus projects for Friday afternoon. As a team, we tested or debugged or documented so that as a team, we were on schedule.
Friday Afternoon Fun
So many managers and workers outside of IT never understood our Friday afternoon fun. Each week that we were on schedule, each programmer could pick a special, small project for Friday afternoon. Usually, we wanted short, well defined tasks that would require fewer than four hours. Some times, I would agree to a longer project, which would spread across a few Fridays. Sometimes two programmers would gang up on a short project.
The psychology seems backwards, but the results were progressive. Because we as an IT team had met our schedule, each programmer could pick an additional small project to do on Friday pm. Usually, these were tweaks and fixes that did not merit membership in the main project planning. Typically, a programmer had told a clerk that some fix was easy and expect it on Friday. One year at APU, Dr Wallace came and asked how a particular secretary got her request when her vice president had weeks more to wait. I explained our overall planning that includes costs and benefits and risks; I explained how the queues worked. I also explained how that secretary had asked for a tweak that many other secretaries also wanted. Her tweak satisfied many persons, and a programmer did it within an hour. The project for the VP had hundreds of remaining hours and partial deliveries.
Dr. Wallace laughed as he understood the irony: because we got a lot of work done, we gave ourselves the reward of more work. Psychologically, finishing those Friday projects was also important
It's my Fault
Honesty and integrity are essential to IT teamwork. If a person makes a mistake and properly informs the manager, then the mystery of cause and the challenge of future prevention both diminish. We know why,
Programming is Fun
Test the Documentation
A week later, read the documentation
Hire Accomplishment
Hire Potential
Ever Improving
Under Promise; Over Deliver
Usually I serve as both a manager and programmer on software projects. At the AQMD, however, when I first started, there were nearly forty active projects and many were not purely software. We had weather stations to install; we had air chemistry experiments to monitor with computers. We had so many topics, that I did not do much more than manage on a few projects.
People and Persons
Too often the generalities of people are praised rather than the skills and nuances of persons. The term people applies to psychology or to populations or countable groups of persons. The term person emphasizes the characteristics of individuals. Each person is a different individual, with different feelings, desires, skills, habits, and nuances.
Persons are Most Important: the Boss
The manager works for a person; keeping the boss happy is a prime responsibility. In many ways, this perspective is the personal view of the organizational mandate: keep the organization going. A manager always hopes and prays that the organization deserves preservation, and certainly most do. (see Organizational Malfeasance xxx.) The boss needs knowledge and insight. Generally I follow long term principles, but even then, surprises happen. Keeping the boss aware of the reasons, keeps the boss out of hot water. Hopefully, the manager performs well enough to increase the confidence of the boss and the success of the boss.
Persons are Most Important: The Managers
The managers of the other departments usually work closer to the profit centers than do the IT managers. It behooves the IT manager to keep those managers happy; they have clout and influence, which the IT manager wants pointed in helpful directions, The other managers also carry the vision of the organization. Some vice-president might declare the vision, but the managers put muscle towards fulfilling the vision. When implementing change, the IT manager needs the co-operation and influence of the other managers.
Persons are Most Important: The Clerks
These persons work for other managers, but these persons are essential to the success of the IT manager. The warehouse manager might want new software, but the buy-in of the warehouse clerks is essential. When the clerks buy-in because they see benefit, the implementations go so much smoother. Repeatedly, a good clerk has propelled a project towards success. Friendships built over years also have fortified the position of the IT manager. When the important clerks like the software, the likelihood of success by the IT manager improves.
Persons are most Important: Co-Workers
The manager usually has other persons who contribute to his success and the success of the organization. The manager has the responsibility to encourage his co-workers. I was educated as a team programmer and very successfully employed as a team programmer. A very few programmers work best as solo actors. In fact, since so very few programmers blossom as soloists, the manager probably should avoid hiring soloists.
Over the years, I have personally known several outstanding programmers; all of them had loyal comrades.
The Programmers Pyramid plays a larger part than most people ever understand. A small team of A programmers can out-perform a herd of C's
Tuesday Noon Target Dates
Over the years, I guided big projects towards completion on Tuesday at noon. Actually, by the prior Friday, most essentials were running and on Monday, permissions for user became active. By Tuesday noon, the finale was anti-climatic.
Thursday Noon Target Dates
When we as a team were on schedule as of Thursday noon, I would encourage the programmers to declare their bonus projects for Friday afternoon. As a team, we tested or debugged or documented so that as a team, we were on schedule.
Friday Afternoon Fun
So many managers and workers outside of IT never understood our Friday afternoon fun. Each week that we were on schedule, each programmer could pick a special, small project for Friday afternoon. Usually, we wanted short, well defined tasks that would require fewer than four hours. Some times, I would agree to a longer project, which would spread across a few Fridays. Sometimes two programmers would gang up on a short project.
The psychology seems backwards, but the results were progressive. Because we as an IT team had met our schedule, each programmer could pick an additional small project to do on Friday pm. Usually, these were tweaks and fixes that did not merit membership in the main project planning. Typically, a programmer had told a clerk that some fix was easy and expect it on Friday. One year at APU, Dr Wallace came and asked how a particular secretary got her request when her vice president had weeks more to wait. I explained our overall planning that includes costs and benefits and risks; I explained how the queues worked. I also explained how that secretary had asked for a tweak that many other secretaries also wanted. Her tweak satisfied many persons, and a programmer did it within an hour. The project for the VP had hundreds of remaining hours and partial deliveries.
Dr. Wallace laughed as he understood the irony: because we got a lot of work done, we gave ourselves the reward of more work. Psychologically, finishing those Friday projects was also important
It's my Fault
Honesty and integrity are essential to IT teamwork. If a person makes a mistake and properly informs the manager, then the mystery of cause and the challenge of future prevention both diminish. We know why,
Programming is Fun
Test the Documentation
A week later, read the documentation
Hire Accomplishment
Hire Potential
Ever Improving
Under Promise; Over Deliver