Every organization is its own biosphere, with unique individuals interacting in an environment that has evolved differently over time than even its direct competition. No wonder that procedures and practices are always different from company to company.

In interacting with many companies, we find that even the process of change management varies widely. The process by which information is obtained, decisions are made and implementations are conducted are shaped by the leadership, market forces and the people that are hired. One of the more common questions we see when managers want to effect change is whether it should be done as a large scale initiative or done in incremental steps. When done as a large scale initiative, the project can take a life of it own but can build significant momentum and force. It can be like a juggernaut that easily moves aside any resistance. The up front planning that is required for a large scale project provides a great discipline to work out the issues early. However, large scale initiatives can get crushed by their own weight. Expectations begin to get set very high, sometimes impossibly high and the only result in these cases is disappointment. The longer a project goes, the more chance there is for scope creep. The longer a project goes, the more chance that the requirements by which the project was built on have already changed. Poorly planned large scale initiatives are notorious for missing dates, going over budget and underdelivering.

Incremental approaches are much more iterative, where bite size pieces are defined and implemented. It’s a great approach to de-risk a project and supply quick wins early and frequently. However, this approach is not without some risk. Without a clear long term vision, smaller scale projects can meander and can result in wasted effort. In addition, an organization can only absorb so much change on a frequent basis. If the process changes every 2 weeks, it may become difficult for people to do their jobs.

An analogy in the software development world is the waterfall versus agile development methodologies. In waterfall, there is strong upfront planning/definition and logical steps that progress towards a final, often large deliverable. Waterfall tends to work better in environments where requirements don’t frequently change and where quality is of paramount concern. In Agile, smaller, mini-projects are defined that embrace an iterative approach to development. Agile works particularly well in environments where the requirements change frequently and technology risk is fairly high.

In the Salesforce.com world, most sales/marketing/support organizations live in a chaotic world where the competitive marketplace changes the landscape almost daily. Iterative approaches tend to work best in order to meet market demands quickly. When we work with a customer, we try our best to understand their business drivers so that a long term vision can be mapped. Having best practices knowledge in many industries help us drive towards a goal for their Salesforce.com implementation that can be used to guide the incremental projects that will get the customer there.

From there, several phases are defined so that there is a path to the goal. Phase I of course is planned in great detail than subsequent phases. It helps us and the customer get quick wins so that we can build momentum for even more success going forward. Having the roadmap handy though helps ensure that we avoid future roadblocks and helps us more effectively plan the subprojects that will have the most valuable impact in the change management process.

And after all, customers are paying for change.