I use the generic term “development” to describe the type of work where IT pros use programming skills to build solutions. The players involved in development include project managers, analysts, support staff, and everyone else who works in the life cycle. Basically, if you are building something that involves program code, you are probably doing development work.

Inside this generic definition of development are two main work functions. One is the work associated with building new solutions, or enhancing existing solutions. Technically, this can all be considered project work, even though some of the efforts are so small that no formal project management comes into play.

The other work function is the care and feeding of the solutions once they are completed. This is generally known as “support,” even though in your organization you may call it another name, such as maintenance or baseline work.

The smaller your organization, the more likely it is that the same people are doing both kinds of work. Just as with any field, the more people the organization employs, the more specialized the skills become. In many larger companies (and some medium/small companies), the project work is more or less separated from the support work. In my experience, I have found that when the projects and support are split, the organization begins to take on a value preference for one group over the other. In at least two companies where I have worked, the culture said that the project (or new development) staff was more important, more valuable, and more highly skilled than the support staff.

What is the pecking order at your company, and how did it get that way? In my experience, I have seen the following arguments on both sides.

Support is more valuable
All companies run on business processes, and the critical business processes are all computerized. All of the fancy production applications that the company invests in will be worthless if not for the skills of the support staff. The support staff makes sure the applications are stable and reliable and that the company business processes run correctly. There is understandable concern when a project team goes over budget or misses a deadline. However, there can be hell to pay if payroll is missed, invoices cannot be sent out, or if the company cannot process sales orders. Support of production applications is definitely more important than project work.

The support of production applications is where the rubber hits the road for most companies. These people need to have excellent troubleshooting skills and must quickly determine the cause of problems and resolve them immediately. The prima donnas on the projects may work overtime when they miss their deadlines, but if there are problems with critical applications, the support staff has to work around the clock until the situation is resolved.

Because development technology changes quickly, the support staff must usually be multiskilled. They may be supporting mainframe technology from the ’70s, client server applications from the ’80s, and Web applications from the ’90s. When prior applications are but a distant, sweet memory to the project staff, the support groups continue to fight the never-ending battles to make sure they work on an ongoing basis.

In other words: No wimps are allowed in the support world!

Project work is more valuable
While recognizing the contribution of the support staff, many organizations believe that projects are the key to long-term success. After all, an organization that focuses too much on business solutions built in the past is probably not going to be in a position to meet the challenges of the future. The goal of many organizations is to squeeze support resources to an absolute minimum, so that the resources can be applied to new projects that build new capability and add value to the company.

The short-term, fix-it-now mentality of support does not work well on projects. Projects require a different set of skills. It is true that the support staff could be taught the technology skills required for new projects, and, in fact, they need those skills to effectively support the solutions. The more difficult challenge is to bridge cultural differences.

Project work requires the ability to build a solution from scratch. You start with nothing, and you analyze, design, build, and test until a solution is complete. It takes project management, analysis, and design skills. In many companies, the people who have these skills and can apply them successfully are generally seen as more valuable than the support staff. The project teams are also the first people to adopt new technology in the company, and they must be able to learn and apply this technology quickly and effectively.

Project staff must have a combination of professional, business, and technical skills to partner with the business clients to build solutions. If you want to specialize in putting your finger in a dike to plug a leak, then support is the place for you. On the other hand, if you want to grow technically and mature into a well-rounded professional, projects are the place to be. It is also the place to be if you want to progress into senior IT management.

Is one set of skills more valuable?
My experience in 23 years of development has included work in both the traditional project and support environments, and I have managed teams and organizations that did both. I found it valuable to consider the skills associated with support and project people, because the two skill sets are not totally interchangeable. This does not imply one group cannot learn the job of the other. However, as a manager, it did help me to understand where the skill gaps were probably going to be so that the proper transition training could be applied.

My general opinion is that each type of role requires a complex and valuable set of skills. Both are critically important, and both are equally valuable. It makes sense to me that similar opportunities for advancement and prestige should be available for both roles. Organizations that informally or formally value one over the other are needlessly building walls between the roles, and, in some cases, causing downright resentment.

What do you think?

Does your organization favor one type of work—project or support—over the other? If so, do you think the distinction is valid? Post your feedback below or send us an e-mail.