Today we have vendors selling cloud based enterprise systems which an organization can lease and also configure and customize to fit the organisations needs. Even if there is work in performing configuration and customization, the implementations can still be done quicker than if the system was to be built in house like maybe 10 years ago. This makes business happy because quick implementations means possibly quicker value realization.

If using an incremental approach to conduct the configuration and customization, and at the same time phasing out the new functionality in the organization's countries- then the system can be delivered in an amazing speed. However.. For the system to be successfully implemented it will likely require change in some countries business processes to match the new system functionality, and the end users would have to be trained etc. I therefore wonder if it is common to use possibly natural drivers of having the system functionality delivered in increments to increase the usage of the system?

Say that the first release was OK to satisfy all implemented countries needs but needs some fixes to be seen as good by the country managers, user etc. Possibly the second release would be really well accepted case the technical team working with the system has told everyone how much better this new version will be. Is it common to work like this? Or is the implementation and deployment usually seen as two different things? If so where does adoption/ change management come in?

  • 2
    I don't understand what you're asking. Can you provide a hypothetical example of what you mean? Oct 26, 2016 at 13:54
  • Sorry yes of course. Imagine an rollout in of a new enterprise system in a large global organization. Where the purpose of the system is to standardize the process in each country and also to have one shared database for company data. the system is implemented using an incremental process and its deployed using a phased approach. Would it be common to use the extended functionality coming with new versions of the system, to drive the usage of these newer versions?
    – AV67
    Oct 26, 2016 at 13:59
  • Much better question. Oct 26, 2016 at 16:06

1 Answer 1



Change can be driven from two places. Top down. ie a strategic business decision taken by the owner/board or Bottom up ie users request changes based on their perceived needs.

I find the most common driver is Bottom up. local managers request features based on thing the user wants to make their particular job easier or to support a new project or deal. These are implemented and rolled out to the users in question and may not be used by other teams/offices

However in your scenario the change is Top down. The head of a global company wants to standardise procedure across all offices. Obviously this is going to get kick back from the users but this will be seen as management rather than a technical problem. One to be solved by workshops and training or simply ordering people to use the new software.

Releasing the solution in stages runs counter to the general goal of completing changes quickly so we can demonstrate how much money we saved with my great idea.

  • A lot of projects are hampered exactly by what you describe as bottom-up vs. top-down. After a released first version, development is so overwhelmed by bottom-up feature requests that original top-down time/roadmap plans for incremental improvement are severely delayed.
    – tofro
    Oct 29, 2016 at 13:58
  • depends on how you define hampered. but yeah I know what you mean
    – Ewan
    Oct 29, 2016 at 14:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.