Organizations are constantly in the midst of implementing or rolling out huge projects that impact the business, users, and customers. This process is rarely easy when you have deal with unexpected challenges, whether it is technology related, a scheduling conflict, or whatever. That is why it is critical for the success of the project that you and your team remain flexible throughout the implementation. Rob Murphy, a Program Manager for the U.S. House of Representatives, recently led one of our Web Forums and he discussed the idea of project flexibility. The House is in the process of implementing a Financials ERP so Rob spoke about some of the challenges they have encountered and how being flexible has enable them to be successful thus far. You can read the full IMF Report on Rob’s presentation here.

Below is a snippet from the report where Rob talks about the advantages of limiting project customizations…

“When it comes to large technology projects, many organizations tend to stay pretty close to vanilla in terms of their approach. Certain companies may flat out say “no we are not going to have any,” “you can have one or two different levels” or “if you have some they have to be this type of characterization.” They can have only so much effort and impact, which is excellent. You definitely want to limit it because these are very complex applications, even without customizations. They still roll out patches and fixes regularly whether it is desktop computers and very simple software or more complex. There will always be patching and fixing taking place. Vendors and IT organizations know that so any time you can limit the complexity on your end it is an advantage.

You will reach a certain point on most projects where customizing becomes a necessity, whether it means minimally invasive tasks like designing your own reports or possibly more invasive items. The project team at the House started out with the idea that they were going to stay vanilla and only do a couple of items, some of which were required. They may have been for reporting or regulatory needs but there were certain items they had to produce. The software package that was selected may not have all of the features, fields, and data that are needed. Consequently those fields and reports will need to be created…“