jump to navigation

How to Decide on Customizations 05/13/2009

Posted by TBoehm30 in Software.
Tags: , , , , ,
trackback

Customizing your new software is one of the dangers that can lead to the project spiraling out of control. Too many customized changes or changes that are too complicated will alter the schedule, bog down the staff with work, and lower moral.

I worked with a company that installed a new CRM system with only the vanilla, out-of-the-box screens. The software had great tools for customizations and allowed all sorts of changes without affecting the license, or even the upgrade process. If the company followed the rules, then the upgrade process would take into account the customizations, and not cause problems. The company decided not to allow any requests for changes for the first 3 months.

This turned out to be a terrific rule. Many of the users complained because the system didn’t look like their old system. They weren’t sure what to do when problems occurred. During those 3 months, the users got used to the new system. They figured out how to solve their own problems. They found the workarounds for any issues that were serious enough to change their process.

After the 3 months were up, the changes started coming in. Those changes were well thought out, and would provide value to the business. The changes requested were the kind that IT could get working on, and wouldn’t hinder existing projects. They had new timelines for the new projects, so nobody felt like they were falling behind. The budgets were identified separately for the new projects, so no projects were over budget.

The IT department looked great because their large software project was successfully completed on time and on budget. They surveyed the business managers to find their satisfaction with the project. They got high marks for their project management abilities and their ability to get people working on the new system. The new requested changes would be worked on with full approval from management who have faith in their IT people. This confidence was gained through successful projects, and satisfied users. What a great working environment this was.

I have also worked on projects that were overwhelmed by changes. Our weekly status meetings showed that we should be aiming for a moving target. The work we had finished the previous week was now obsolete and we had to start over. Some of the requests (in our opinion) were absolutely ridiculous. Some of them were most likely submitted for the sole purpose of sabotaging the project. Many of the users were very afraid that the new system would make their job much harder. We ended up scuttling the project because we had no chance for success.

Somewhere in the middle of these two extremes has to be a good model. Users will have legitimate changes to a project while it is underway. Sometimes the project managers won’t have thought of all the consequences until users start testing. Sometimes the users don’t understand the consequences of their changes. Sometimes neither side will understand how complicated it becomes to change large software systems.

The takeaway – create a process to evaluate customization requests for your software. Understand the costs and the benefits of those changes before deciding on if and when to implement. Remember that it’s a global world out there and technology makes it happen.

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: