Balancing IT Scheduling, Budgeting and Customization

Likewise, if your business colleagues were instrumental in selecting an application but you know it's going to be difficult to introduce the app into your existing architecture, then you must say so up front, informing everyone involved that they're probably stretching time lines or increasing costs.

You're not being "part of the team" by agreeing to all of their demands at the beginning of a project; you're risking the project. I agree with the CTO I recently spoke with who said, "The goal is to serve the end customer of our business." But too many IT people--including many in top positions--tell businesspeople what they want to hear instead of what they need to hear.

Yes, there will be times when customization will give you functionality your competition doesn't have--to support a new line of business, for instance. But to customize something that applies throughout your industry--or something even more generic, like a customer or prospect database--will only cause you headaches without much gain. For such applications, a product sold to 20 or 200 other enterprises will offer everything you need; you just need to adjust business practices.

You will also be called on to implement systems that use a database your organization doesn't support. Again, this is fine, as long as the database is underpinning a vertical-market product with only one or two vendors, not something generic.

It is a difficult path to walk down, but you must insist that business colleagues quantify their needs so you have something to compare to the up-front and ongoing costs of customization. Adding code to an application or machines to a data center costs money. If the customization will save hundreds of man-hours a year, then it might be worth extending the project deadline by six months and taking on those costs. But everyone must be on the same page.Don't accept thin rationales for customization. "Our users wanted the UI redone to suit our corporate needs, so we're serving the customer," is one familiar refrain--until deadlines start slipping. By the end of the project, assuming it isn't killed, you start hearing, "We have to limit the amount of change ... " or "This project is too far over budget--what can we cut?"

I'm an application developer by choice. Customization makes us feel like we have more control, but reinventing the wheel costs us millions of dollars each year. Help your users understand that customization is the path of last resort.

In the end, most users would be happier with an on-time implementation that doesn't quite meet each little requirement than a project that runs months over schedule or thousands of dollars over budget. Understand what your users really need. Know how to explain the costs to them clearly, in their own terms. Wherever possible, simplify projects to deliver them on time.

Don MacVittie is a technology editor at Network Computing. Previously, he worked at WPS Resources as an application engineer. Write to him at [email protected].