Requirements vs. goals and objectives

Harness the ability to change for your competitive advantage.

Trying to predict every eventuality, every change in the market, or every possible change in technology is a waste of time and money.

Moreover, each individual business or operation has its own specific individual needs, which are affected by many things, such as:

• the way the operation is organized

• the architecture of the underlying operational systems

• the specific products used from various vendors

• the features supported by the APIs on involved third-party products

• the performance and behavior of involved third-party products

• the impact of existing habits that determine how things have always been done in an organization or in specific teams

• the business strategy and priorities

• commercial business models

• ...

This applies to any type of project, no matter which technology or industry segment is involved. It is in the nature of these types of transformation projects.

Each project therefore typically starts with specific goals and objectives of the organization, which are then translated into a first preliminary set of "requirements" by the internal users, collected throughout the organization. The latter can be limited or quite elaborate.

Because of the nature of software ICT projects, those requirements will never be fully accurate, nor will they ever be conclusive. They neither have to be nor should be. As a consequence of the complexity of a software ICT ecosystem and the general challenge for users to express their exact needs accurately, many (often very implicit) assumptions are made during the drafting of requirements. Typically, important requirements and expectations will be missing, and other requirements that have been stipulated will turn out to be less relevant than initially thought. Some activities will turn out to be more complex to achieve (e.g. because of unexpected limitations of an underlying API), while others might turn out to be more reasonable than expected.

Furthermore, even for just one single requirement, software and ICT technology offers limitless options in terms of a practical implementation. There might also be different opinions on which options are the most suitable, depending on many factors such as personal preferences, existing habits and practices, and much more. At the same time, the time and resources available for the implementation of the solution remain finite.

Priorities shift and requirements evolve throughout the life cycle of a software delivery project for many reasons. Embracing change guarantees that you get the best possible solution without being constrained by what was foreseen several months before.

Ultimately it is the actual implementation that will define the value of the project. During the execution of such a project, it is therefore vital to stay focused on the original goals and objectives, to use the requirements as a guidance, but above all to aim towards generating value for the business and delivering that value as early as possible, if needed in stages. This ensures that the finite time and resources are used as efficiently as possible to strive towards the objectives that were set forth initially as much as possible.