Project Requirements Process R040

R040 - Constraints

DEFINITION

Investigate and document all constraints on the eventual solution. Typically these will be technical, organisational and financial.

SUMMARY

Project constraints need to be identified at an early stage, so that:

• the scope of the project can be defined,
• the extent of the choice of solutions available can be identified,
• management and work plans can be validated,
• any conceptual design or architecture decisions taken prior to the project can be tested,
• the expectations of the project’s sponsors and users can be realistically set, and
• the final business solution will be able to operate and meet the needs of the organisation..

Constraints are restrictions which are non-negotiable.  Many apparent constraints may turn out to be negotiable when their impact is understood.  The statement of the project’s constraints should be agreed and formally signed-off by the Steering Committee.  It will be a key input to process R070 System Vision and will later be incorporated into the Definition of Requirements (DoR).

Where a particular packaged solution has already been adopted prior to the requirements work, the constraints should be considered taking account of the known choices, and examining the impact of any constraint in respect of the defined solution.

PATH PLANNING GUIDANCE

This process is normal practice.

DEPENDENCIES

Prerequisites (Finish-Start):

• Project launch

Prerequisites (Finish-Finish):

• Review/Confirm ToR, Scope, Objectives (L010)
• Detail Segment Plan (L120)

Dependent procedures (Finish-Finish):

• System Vision (R070)
• Final report (R150)

RECEIVABLES

• Project Constitution or other definition of project scope
• Definition of Business Needs and Anticipated Benefits

DELIVERABLES

• Statement of constraints - part of Definition of Requirements (DoR)

TOOLS

• Staff Technical Skill Profile

DETAILED DESCRIPTION OF TASKS

What are constraints?

Constraints are those requirements which are a logical, practical or political restriction on how the solution can be achieved.  It is important to identify whether any constraint identified is genuinely non-negotiable, or merely symptomatic of an issue which might be resolved in a different way.

Constraints are considered under the following headings:

• organisational
• technical
• financial, and
• other.

Organisational Constraints

Organisational constraints on the project (where non-negotiable) are likely to include:

• problems of key user availability to participate in requirements definition, selection and implementation (including availability for training).  This type of constraint must be identified early. If not, timescales will slip, or tasks will be delegated to staff who are too junior to make authoritative decisions.  The main effect of this constraint is likely to be an extension of project timescales.

• a fixed departmental structure and set of roles/ responsibilities - is the existing organisational structure fixed (and thus a constraint) or can it be redesigned if appropriate,
• need for multi-site implementation  - this may include the need for flexibility in the solution to deal with regional variations in requirements,
• size of organisation, and variation in size between sites - the number of users will impose a constraint on the solution chosen, as will the need for scalability, where different implementation sites have significantly different user populations,
• need for systems implementation in parallel with re-organisation - an example of this is where the systems project is linked to a business process redesign project; it is likely to impact the availability of user resources, and to add complexity to a number of implementation tasks (eg training).

In identifying organisational constraints, a number of “management of change” issues may be identified (particularly lack of effective project sponsorship and resistance to change by the project’s “targets”).  These are not normally constraints - they need to be overcome if the project is to succeed - and are analysed in process R090 - Organisational Impact.

Technical Constraints

Technical constraints will depend on:

• IT Strategy and procurement policy

• the need to exploit investment in existing technology and infrastructure
• the skills profile of IT staff.

The scope covered by technological constraints may include:

• the approach to “open systems”
• hardware platforms
• systems architecture (eg client-server)
• operating system / system software
• wide and local area networks
• electronic mail and data transfer standards
• workstation platforms (eg PC / Macintosh)
• relational database and reporting tools
• 4GL/CASE tool investment and policy
• the need to interface with existing systems.

They will normally have been identified by the organisation’s IT Director.  The main effects of the constraints will be:

• to limit the choice of available package solutions or options,
• to restrict technical implementation options,
• to influence the size of the technical implementation budget.

Special considerations apply when the basis of the package solution has already been identified, eg where the project is part of an integrated Application Software Solution implementation programme.  The constraints should be compared with the known characteristics and capabilities of the package.  Any major problems will require urgent attention and may lead to a re‑examination of the project.

For example, if an integrated approach is being followed, it should be considered how the company’s technical architecture fits with the architecture.

With a pre-defined package solution, it is important to consider whether the client organisation’s IT infrastructure could support the package’s specific hardware, software and communications options, eg presentation server, application server, database server, systems software, database, communications protocols etc.

A pre-defined choice of package also means that the skills profile may be examined in comparison with the known skills required for implementing the chosen package.  

Financial Constraints

Financial constraints may be absolute (ie there is a fixed amount of funding available for the project as a whole) or more specific (eg budgets have been allocated for specific areas of functionality, user training, technical infrastructure upgrades etc). They are likely to influence the functional scope of the project, the choice of solutions, and user expectations about the delivery of features and benefits.

Other Constraints

Examples of these are:

• time (eg where there is a need to comply with legislation, or where the key benefits would be lost if the system were delivered late),
• adherence to corporate standards and procedures - examples would be the need to follow a particular methodology or purchasing policy.

Identifying and documenting the constraints

Constraints are normally identified through normal fact finding techniques such as interviews, workshops and questionnaires.  Once a constraint has been identified, its potential impact should be considered and reviewed with the project’s sponsor or appropriate decision makers.  It should be established whether it is a hard constraint or an issue which might be resolved in some other way.

The constraints and their potential impact will be listed in the statement of constraints which will subsequently be included in the Definition of Requirements and formally agreed with the client organisation.