Chapter Thirteen: How Your Work Is Tracked

You are the very visible author of your programs. All of your work in every program is testimony to your skill or lack of skill.

In the real world of corporate programming, the programmer is often the project manager of his own programming projects. Indeed, only projects that involve several programmers are normally assigned a project manager, whose primary responsibility is to coordinate the activities of the programmers. Whether your project has a project manager or you are your own project manager, you need to be familiar with how a project lands on your desk so that you can shine at every opportunity.

How a Project Usually Starts

The IT programming manager normally receives requests for programming projects from managers of end user departments. Typically, a manager is dealing with a large backlog of user or mandated requests for programming work; he needs to record, prioritize, and acknowledge the requests before attempting to assign them to programmers.

When a project is a go, the IT programming manager forwards the approved request to a programmer with the project documentation and authorization, with a note ( please ) do it. At least for small projects, the programmer is then totally responsible for assigning the project number ”normally through a project change management system ”and then designing, coding, testing, and documenting the project before turning the completed project over for final review and implementation. Any programmer questions about the project should be handled in the programmer s daily one-minute review with his or her manager or the programmer s weekly summary report to the manager (or clarification with the manager, as needed).

Every programming manager makes some kind of estimate of the time it should take to complete a project, even if he doesn t tell the programmer what that estimate is. The estimate will vary according to the skill of the programmer ”sometimes by a factor of five for the same project, depending on the programmer s previously demonstrated performance. The estimated project time and the actual project time will vary according to the programmer s skill, the productivity tools utilized, and the manager s ability to communicate the project requirements; the time and effort the manager puts into reviewing the progress of the project; and the time spent in testing, final project review and turnover of the project.

Of course, your manager will probably ask you for some kind of rough estimate of the completion date of the project; for large or critical projects you may be asked for rough estimates of the time it will take to reach various checkpoints. My advice on giving estimated completion dates is to be honest (not too optimistic) and give the date by which you think you can produce a quality product.