How we change what others think, feel, believe and do

| Menu | Quick | Books | Share | Search | Settings |



Disciplines > Change ManagementThe 4D Change Project Framework > Definition

Investigation | Specification | Documents | See also


The Definition phase takes preparing for delivering the project from knowing what is wanted and having an outline of what will be delivered to a clear specification of what will be delivered such that a confident estimate can be made as the time, cost and quality of delivery.

Simple projects

For small and clear projects, Gate 1 and Gate 2 may be passed at the same time, as the deliverables can be specified early and in sufficient detail to make a clear commitment on quality, time and cost. For projects where a more detailed investigation is required before commitments can be made, the Definition phase provides extra time to enable this to happen.

Separate what and how

In Prince 2 terms, the documents delivered at Gate 2 collectively form the PID (Project Initiation Document). It is recommended here that this stage separate the ‘what’ of the specification from the ‘how’ of the plan. This is because the ‘what’, once agreed, changes slowly, whereas the ‘how’ of the plan may vary more often.


Note that the documentation for Gate 2 may vary significantly, depending on the project, how large and complex it is, and consequently the communication and assurance needed. In smaller projects, the only documents that may be needed at this stage are an extended Project Brief and Timeline. Risk Registers and Issue Logs are commonly required. The most likely additional document is a Specification. A more detailed Project Plan and specification change control are more likely to be required in larger projects. Quality and Commitment plans detail plans in these areas.


Activities in this stage include further investigation that allows a detailed specification of what will be delivered.


Investigation in Definition typically continues initial investigations from Discovery into further detail. The goal in all cases is to identify what exactly needs to be done in future work and hence the effort required and the risk involved.

Technical investigation

Particularly when software is being written or used, this phase may include further technical exploration to determine the detail of what technical solution should be implemented. This may include:

  • Developing prototype software to explore concepts and assess performance potential.
  • Building ‘wire frame’ outlines to explore user interfaces.
  • Identifying hardware requirements, including processing power and network throughput needs.
  • Determining software and hardware support and maintenance needs.

Process investigation

Where a process is to be changed, further investigations may be appropriate to understand the size of the task and the changes to be made. Activities might thus include:

  • Mapping the process in further detail to identify precisely what needs changing.
  • Identifying roles and responsibilities and how people are organized and work within the process.
  • Understanding interfaces and interactions with other processes.
  • Identifying timescales and costs, seeking potential efficiencies.
  • Highlighting weak points and where errors and risks may occur, for example at decisions, handover points or where manual transcription of data occurs.
  • Understanding variation and statistical performance (for example across delivery timescales).
  • Understanding systemic effects, for example where an event in one part of the process leads to problems several months later elsewhere.
  • Measurement of performance to determine areas of greatest need for improvement.
  • Determining which changes would return the greatest value.
  • Investigating the impact of changes on various stakeholders, including the risks of resistance to the changes.
  • Outlining alternative designs and exploring the costs and benefits of each.

Social investigation

The project may have significant effects on a range of stakeholders, who in turn may have a significant effect on the project. This clearly needs managing and the social investigation may thus:

  • Review stakeholders with regard to who needs to input to the project and who else is impacted by it. This may include RACI (those responsible, those accountable, those who should be consulted and those who should be informed about the project).
  • Understand the landscape of support and opposition to the overall project and reasons for this. This may include a power analysis to assess potential impact on the project.
  • Present results of technical and process investigations to gain input and understand commitment to potential solutions.
  • Determine the detail of commitment management that will be required and hence the detail of commitment plans.


Specification details the ‘what’ of the deliverables to be created and deployed in the project and is typically in a separate document. If contractors are being used, this will form a core part of the contract with them. The deliverable may include a wide range of items, including software systems, process changes, training courses, service changes and so on.

Note that if incremental development is being used, the specification may initially be incomplete and expanded with each evolution.

Outline design

The Outline Design describes the overall architecture of the solution, for example showing how databases and networks will be used, the overall content of training sessions, etc. It provides the ‘big picture’ which is useful for discussion, communication and agreement. For this purpose it typically makes good use of diagrams and charts. It also has the major purpose of being the basis on which more detailed design is completed. The outline design may thus include:

  • Diagrams that show the major building-blocks of the solution.
  • Pictures of the user interface and otherwise descriptions of how the end-user experiences the solution.
  • Database schema and other information organization structures.

Functional specification

The Functional Specification details exactly how the deliverable operates. It describes the product or solution in full detail, explaining how it functions, both from the user’s viewpoint and with regard to its inner workings. It may thus include:

  • Sections and sub-sections that break down functions in a logical order.
  • Diagrams and tables that describe items in logical detail.
  • Other detail, such as use-cases, test requirements, etc.

The functionality of the solution is the major ‘what’ that is delivered and leads to the desired outcomes and benefits.

Quality criteria

The success or failure of development of the specified solution is described by a set of quality criteria which can be used later to assess the delivered solution and hence determine whether or not it is acceptable. These criteria thus form a significant check at Gate 3, before the solution is deployed. The primary criteria are related to the delivery of outputs that lead to desired outcomes and benefits. Other criteria stem from these. An acronym for a common set of criteria that can be used is FLURPS, which stands for:

  • Functionality: That the solution performs the functions described.
  • Learnability: That the solution is easy to understand and adopt.
  • Usability: That the solutions is easy to use on an ongoing basis.
  • Reliability: That the solution does not fail.
  • Performance: That the solution is responsive.
  • Supported: That there is suitable support for the solution on an ongoing basis.

It is important when defining quality criteria that they can feasibly be assessed. For example a criteria of ‘satisfying all users’ does not say what ‘satisfying’ means and assessment of ‘all’ might be a very expensive task.

Test requirements

Solution development is a series of transformations from requirements to specification to design to final solution, including other interpretations along the way. At each transformation there is opportunity for error as some necessary things get left out, unwanted things get added and other things are misunderstood and distorted. Thus gaps form between what is intended and what gets specified, designed and created. Testing is the process of assessing these gaps and determining where transformation errors occur.

Testing thus is a process that happens throughout design and development. Test requirements describe what is to be tested and may include:

  • Overall structure, formality and documentation of testing.
  • Testing of specification against requirements.
  • Testing of design against specification.
  • Testing of the solution against requirements, specification and design.
  • Testing of solution components during development.
  • Involvement of stakeholders in testing.

Testing is described in further detail in the section on Development.


Depending on the size of the project, Definition documentation may vary greatly. At minimum, this includes an update of the Project Brief and Project Timeline.

Project Brief update

The Project Brief, as originated in the Discovery phase is updated at this stage, to include any further detail or changes, for example to outputs required, timescales, approach and so on.

For smaller projects, many of the items that would be in separate documents for a larger project may be included in this Brief. For a larger project, the separate documents may be referenced from the belief.


The Specification describes in detail that which will be delivered.

The Specification may form the basis of a contract with an external supplier or consultancy who will be engaged to develop and/or deliver it. It also is used in quality assurance to verify that which is built is that which was required and agreed. Where outsourcing and contracts are being used, then sufficient time needs to be included in the project plan for negotiations, tendering and so on.

In a software development project, for example, the specification could include screen layouts, database schema and algorithms. In training design, it will include the overall methods of training and module contents.

The Specification may also include aspects of delivery, such as maintenance. ‘Wire-frame’ mock-ups may also be used within specifications, for example where the HTML for web pages is developed but without any back-end systems (thus you can click on links but nothing as yet happens).

For smaller projects, the Specification may be included in the revised Project Brief.

Project Plan

The Project Plan details the approach being used in the Development and Delivery phases of the project. This may include details of key project decisions, resources, assumptions made, agreements and collaborations and so on. It also should include consideration of project governance, particularly when it varies from the standard Vanguard governance, including meetings, reporting and metrics. Where the projects uses other documents, such as project meeting minutes, then the templates and process for these may be included. Required conformance to any set of other standards may be noted, such as organisational reporting and documentation standards.

For smaller projects, this detail may be included in the revised Project Brief.

Quality Plan

The Quality Plan describes the methods and timescales for assuring quality across the project, including testing of deliverables and incorporation of feedback and learning into what is being done.

Quality has been defined as ‘fitness for purpose’ and ‘conforming to requirements’. The ultimate test of quality is customer satisfaction and delight. Assurance of that beforehand typically means testing of products and processes against specifications (and specifications before that against requirements). Depending on the project, user acceptance testing (UAT) may be used as a part of the handover process into ‘business as usual’.

Quality assurance is a form of risk management, acting to identify and prevent risks of non-conformance occurring. It typically includes assessment of potential and actual gaps between what is wanted and what is delivered, and acting to address these. Testing checks one thing (often a ‘product’) against a specification of some kind, identifying non-conformance. Quality assurance includes planning, recording and management of testing. Quality assurance work also starts early in the project, for example testing the Specification against Requirements.

For medium-sized projects, the Quality Plan may be included in the Project Plan.

Commitment Plan

In many change projects the most difficult part of the process is in the Delivery phase, where the outputs are deployed to a wider group of people, some of whom may be unwilling to participate in this activity, either because they do not want to participate or because operational activities are taking priority.

It is common in change projects to include communications, and these may well form an important part of the Commitment Plan. It is easy to communicate when this simply means telling people about what is happening. The problem is that what is often required is a commitment to specific action. The Commitment Plan thus needs to include activities that will persuade people to participate in and support the deployed change.

An important part of commitment management is in the availability of an escalation process, should people not be participating as required. Typically this requires the support of a senior manager who will change priorities and mandate collaboration for those who would otherwise not participate.

For medium-sized projects, the Commitment Plan may be included in the Project Plan. For smaller projects, this may be included in the updated Project Brief.

Timeline update

The detail of who does what and when should be produced as a separate item that can be constantly updated to reflect reality and the latest forecasts. This plan is then used to track project progress and manage issues such as slippages. Whilst a separate overall plan document may change little, the timeline will usually change frequently.

For smaller projects, where interdependencies are not complex and where there are a limited number of tasks in the plan, this can be adequately done using a spreadsheet. For larger projects, where there are such complexities as multiple people, inter-dependent tasks and the need to calculate the critical path, then MSProject may be more useful.

Governance documents

Depending on the formality of the project, there may be more or less documents that record and communicate other governance activities. As appropriate, these should be managed and stored.

  • Contracts, SLAs and other formal agreements with suppliers and consultants.
  • Meeting minutes, including actions and decisions.
  • Risk Register and Issue Log that handle unexpected and undesirable activities.
  • Change requests and responses, particularly when this involved contracted work.
  • Presentations and communications about the project.

See also

Gate 1 Checklist, Stakeholders in change

Site Menu

| Home | Top | Quick Links | Settings |

Main sections: | Disciplines | Techniques | Principles | Explanations | Theories |

Other sections: | Blog! | Quotes | Guest articles | Analysis | Books | Help |

More pages: | Contact | Caveat | About | Students | Webmasters | Awards | Guestbook | Feedback | Sitemap | Changes |

Settings: | Computer layout | Mobile layout | Small font | Medium font | Large font | Translate |


You can buy books here

More Kindle books:

And the big
paperback book

Look inside


Please help and share:


Quick links


* Argument
* Brand management
* Change Management
* Coaching
* Communication
* Counseling
* Game Design
* Human Resources
* Job-finding
* Leadership
* Marketing
* Politics
* Propaganda
* Rhetoric
* Negotiation
* Psychoanalysis
* Sales
* Sociology
* Storytelling
* Teaching
* Warfare
* Workplace design


* Assertiveness
* Body language
* Change techniques
* Closing techniques
* Conversation
* Confidence tricks
* Conversion
* Creative techniques
* General techniques
* Happiness
* Hypnotism
* Interrogation
* Language
* Listening
* Negotiation tactics
* Objection handling
* Propaganda
* Problem-solving
* Public speaking
* Questioning
* Using repetition
* Resisting persuasion
* Self-development
* Sequential requests
* Storytelling
* Stress Management
* Tipping
* Using humor
* Willpower


* Principles


* Behaviors
* Beliefs
* Brain stuff
* Conditioning
* Coping Mechanisms
* Critical Theory
* Culture
* Decisions
* Emotions
* Evolution
* Gender
* Games
* Groups
* Habit
* Identity
* Learning
* Meaning
* Memory
* Motivation
* Models
* Needs
* Personality
* Power
* Preferences
* Research
* Relationships
* SIFT Model
* Social Research
* Stress
* Trust
* Values


* Alphabetic list
* Theory types


Guest Articles


| Home | Top | Menu | Quick Links |

© Changing Works 2002-
Massive Content — Maximum Speed