Throughout the lifecycle of a typical enterprise software project, new requirements
will often need to be implemented or changes made to existing requirements.
Not all change is planned, and there can be a variety of reasons for it, such
as:
- lack of alignment between business functions and IT;
- the organization wants to apply the software to more areas of the business;
- introduction of new regulatory requirements;
- feedback from customers or employees;
- software projects falling short of expected benefits; and
- business as usual changes.
The challenges associated with such changes are not easily overcome by adjusting
existing business rules, but rather require the optimization of business processes
and flow changes.
Change can end up being expensive, as code that has already been designed,
built and tested must be thrown away or heavily modified. As software systems
are often built up in multiple phases, the existing code base should be designed
in such a way to minimize the impact of change, and to help reduce the test
effort going forward. Various techniques including using a BPMN approach, facilitating
business configuration, and data-driven processes can help minimize this change.
This approach fits in with Forrester Group's philosophy that business must "Design
for People, Build for Change". But there are some significant obstacles
that must be overcome on this journey.
Communication is key
The lack of alignment between different functions in an organization is an
important factor to consider when building for change. The clarity of communication
between the rest of the business and IT is rarely what it should be, and it
is not uncommon for incorrect assumptions to be made on all sides. Clarity of
goals is made even more difficult in larger scale projects, as getting access
to the right people to refine the requirements becomes even more challenging.
The IT department is often left to implement a system from requirements specifications
that are frequently lacking in clarity or enough detail to work effectively.
Conversely, requirements specifications can also end up being too detailed and
take so long to produce that the requirements don't keep pace with what is really
happening at the business level.
-1-