Development is sexier than maintenance. It can be bold and exciting, whereas maintenance is, well, maintenance. So, it’s no wonder that you might gravitate toward doing new stuff. It’s more fun. And frankly, it looks better on your resume. But will more development make you more successful?

Before we can get down to attacking that question, let’s understand some terms.

Active websites are in a constantly revolving cycle of “development” and “maintenance.” By development we usually mean “enhancements.” New sections of content, new interactive features, new stuff. Development can be the addition of a new menu tab on an existing site all the way to a frenetic scramble to launch a brand new site. By maintenance, we usually mean a semi-static state of keeping what you already have going. By development, we usually mean striving for higher ground. Revamping your banner would most probably be a development activity. Whereas adding a press release in the news section would be a maintenance activity.

What “state” the site is in depends on the degree of activity expended in each of these broad categories. If you’re doing more development activities than maintenance activities, then your site is in a development cycle. More maintenance activities and, well, you get the picture.

It won’t surprise you to learn that development costs run significantly higher than maintenance costs. Some estimates put a month of development costs at 10 times that of maintenance costs. So, this distinction in broad categories of activities is not academic. It’s important to know how you’re spending your time and what benefits you hope to gain from the outcomes. If the big boss calls up one day and says, “I don’t like blue,” and your site has lots of blue, guess what, you could be moving into a development cycle. Adjust your budget, kiddo. The boss may not see it that way, but that’s the way it is. From the web technical team’s standpoint, maintaining a blue site is far cheaper than developing a red site. Unless, and this is a big unless, there is a business issue. In other words, the boss knows that red will result in higher sales of the company’s doohickies.

As a site manager, you need to know the ramifications and expected outcomes of the changes. If it’s broke you have to fix it. If it can be better, then you have to know why it needs to be better.

This sounds very simple and self-explanatory until you remember the lure of development. Adding new features, graphics, and functions are endlessly attractive for content managers who have cool stuff to add and programmers who just acquired a new tool, but will they make the site more successful?

All proposed enhancements to the site should be subjected to a business analysis before they can be approved. Ask the following questions:

1. Is this proposed change a fix, modification or enhancement?
1. Fixes are elements that are broken and must be fixed to avoid system or communication failures. These are automatically approved.
2. Modifications usually refer to system components and content that are either out of date or need to be supplemented, e.g., content updates and software upgrades. These should be easy to approve or deny based on site policy and guidelines.
3. Enhancements refer to the implementation of elements that did not exist on the site before. These need to be cost justified.
2. What is the impact of the change? Whatever the change, how will it affect the rest of the site?
3. What will happen if the change is not made?
4. Is it possible to gauge the economic impact,or some other measure that is deemed important to the company’s success? For example, will the change win notice from the press? Does it reduce the workload for your employees (such as replying to emails, fulfilling orders, etc.)?
5. Does the change make a difference internally within the company, or externally, to your customers? Or both?

Once you know what kind of change you're requesting, and what it's impact will be, you can determine if now is the right time to make that change. Make the fixes now, then work with your design team to schedule and prioritize modifications and enhancements.

Published in 2003