An important systems development project has just been completed. It is only natural to want one or more developers to remain behind. What if something goes wrong? What if everything grinds to a halt and you have a crisis on your hands? No manager wants that.
As a developer, I have always found a manager's desire to keep me on after the completion of a project a poor use of my skills and very frustrating. I would like to share some of my experiences with you and discuss how and when it is best to let a developer move on to the next project.
Hanging on to developers after project completion
At one company I was personally requested to automate the manpower reporting. At the completion of the project the same finance manager who requested my services wanted me to remain to support and maintain the system. This required very little of my time, and I became bored, unchallenged, and dissatisfied with the situation. I didn't want to offend the manager who provided work for me, but I needed to cut the ties and move on to a new project.
I did find a new project to work on by asking other department managers if they needed my services. Hopefully I didn't burn any bridges in the process. Both the company and I benefited by putting my skills to work on a completely different kind of system that was badly needed. The finance manager found another employee to run and support the manpower reporting system one day a week, and I was still available to maintain the system. Out of respect I should have done a better job communicating my frustration and needs directly to the finance manager, but I have no regrets about seeking a new project to work on.
How long should the developer stay?
A developer should not complete a project, pack his or her bag, and run for the door either. The support baton should be handed off to the appropriate in-house professional. Yes, the developer should be available for training, but the documentation should be the basis for the information passed on to the users and the support team. Testing the documentation is just as important as testing the software. There is no better way to do that than to have someone unfamiliar with the system try to support it by using the system documentation. If the documentation is lacking, the developer should update it just as he or she would a software update.
How long should the developer stay? The answer is until the system is performing as designed and can be run without the developer's help. That could be five days or five months. Consider a formal sign-off of the system by checking off each successfully completed task.
Managers should, when possible, let a developer develop. Good developers are by nature creative and need to be working on new projects. I also understand that there are times when a manager needs a developer to remain on to support the system and provide fixes or upgrades. If this is the case, let the developer know why he or she is needed to stay on.
The final word
I don't want to understate the importance of the support role. I know from personal experience how important and difficult that job function can be. I accepted my last IT position at CSC after hearing of the need for a VB programmer. Somehow I ended up spending more than a year in a support role for systems I knew nothing about. Surprisingly I wasn't bitter about it. I do remember saying out loud when leaving work one day "What am I still doing here? I should be writing VB code," or some such venting of my frustration.
I didn't learn many skills that could be used as a developer. You don't learn many useful technical skills building an OS/2 based data bridge and supporting systems long since past their prime. I learned that support wasn't for me. I also learned some project leadership and people skills. I was very fortunate to work with some exceptional support personnel in Norwich, Connecticut, willing to help me with the project.
I don't know how pervasive the use of developers as support personnel is among IT managers. I would like to hear from developers who feel they were stuck supporting systems after the project completion. If you are a manager, please share your perspective as well in the forum.
Alan Norton began using PCs in 1981, when they were called microcomputers. He has worked at companies like Hughes Aircraft and CSC, where he developed client/server-based applications. Alan is currently semi-retired and starting a new career as a writer for TechRepublic.