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

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



Disciplines > Change ManagementThe 4D Change Project Framework > Development

Method | Design | Construction | Quality Assurance | Change planning | Commitment planning | Documents | See also


The Development phase involves all work required to prepare for delivery and deployment, including development work on the ‘product’ (such a software development or redesigning processes) plus other material and plans to manage the deployment of these, including training, workshops, meetings and so on.

Depending on the change being implemented, this may be a very large or somewhat smaller phase. It is a trap to skip it altogether as there are always necessary preparations before any change is implemented.


The development phase starts with a specified product, service or other deliverable and ends with it ready for delivery. Development thus includes design, construction and QA as well as preparation for delivery.

There are two major approaches to development which depend on time pressures and the extent to which the solution is fully understood.

Waterfall method

When the solution can be fully and confidently specified, and there is time available to complete the solution as specified, then a simple progression from design to construction is possible, as below.



Evolutionary method

In practice, the Waterfall model is suitable for small projects. In larger, more complex and less certain projects, a staged process is usually more appropriate, as below. This allows for early delivery of a basic solution, with enhancements over time. It also allows for exploratory designs that need to be tried out in practice and then revised from the feedback gained.



A significant part of design involves structuring the deliverables. Designs often use visual methods, such as relationship diagrams and prototypes, to allow for communication and discussion as well as enabling the designer to use visual thinking.

Design decisions often include a trade-off between cost, time and functionality. Significant changes can require repetition of gate approvals, which is why the major design decisions are often taken at an earlier stage.

Outline Design

An overall architectural design gives the shape to the product. This may well be developed in an earlier stage, in Definition or even Discovery, as this give primary shape and size to the deliverables. The outline design should be based on the specification and verified that it will deliver to requirements. It shows the interface with the outside world and often decomposes the deliverable into modules that will be developed separately.

User interface Design

The initial design is often from the viewpoint of the user. Starting with the user helps to ensure the solution is workable in practice and places the user as the key target of the design. User design may start with drawings or PowerPoint representations and develop with ‘wire frame’ shells that can be used for initial testing.

‘Use cases’ is a term used in software development that can be applied to other developments also. It simply takes individual scenarios of how the solution is to be used and describes in detail how this works in practice. One way of doing this for process and service situations is to use a story format to give example cases and scenarios (for more on use cases, see

Detailed Design

The detail of design occurs in this stage. Depending on the project, this can be a significant activity. The design should be tested to ensure it meets specification and requirements. It also can be used to design tests of the deliverables.


The primary activity within the development phase is creation of the value-adding items of the project. Whether the project is to create software, deliver training or improve a process this is where it is designed and developed.


Development of the deliverables may be done ‘all in one go’, or may be evolutionary/prototyping, with a number of versions produced, each more complex than the previous, and with increasing assurance of quality. Evolutionary development best suits more complex deliverables and where customer requirements are less certain.

Prototyping can be done in small loops within the Development phase, building, testing and integrating a piece at a time. It can also be done in large loops, with each loop being an effective mini-project including delivery and deployment of the latest increment. In such cases a number of gates may be used in sub-projects.


Quality assurance

Quality assurance activities should run throughout the development process (and earlier phases too) and should not be something that happens afterwards. You just cannot ‘test in quality’, but you can test each step of the way. Development is a series of transformations from requirements through specification and design to the final deliverables. In each transformational step, errors can creep in as the original requirements become compromised and distorted. A careful set of tests ensure that nothing is lost in each transformation and that the original intent is preserved.




Types of testing that can be performed are summarized below. Note that this is a long list of possible methods, and actual testing done should be appropriate to the detail and risks involved.


Type of Testing


Transformation testing

Testing that there are no losses or distortions in the transformations from requirements to specification to design and construction.

White box testing

Tests done ‘of the inside’ by the developer based on intimate knowledge of deliverable detail. This allows all branches within a piece of software to be exercised or differing responses to test questions to be examined.

This is often done as a integral part of development and may well be done during component or other testing.

Black box testing

Tests done ‘from the outside’ based on the specification where the detail of the deliverable is not known. This may be done by a person who is not the developer and is typical of testing in later stages of development.

Component (or module or unit) testing

Testing of individual parts of the deliverable. This makes it easier to catch localized problems before integrating the parts into the whole deliverable. This is often done as the individual components are completed.

Integration testing

Tests of the interface between components, ensuring that the different parts of the deliverable work together as intended. This is often done as the components of the deliverable are brought together for the first time.

System testing

Testing of the whole deliverable, including all components, to verify that it works as intended. This is typically undertaken when the whole deliverable is complete.

Stress testing

Testing for high levels of loading, unusual usage or other ways of stressing the deliverables to find out how they might break or the limits of their use. Note that a stress test that does not ‘break’ the deliverable may be of reduced value.

Random testing

Testing by doing random and unintuitive things.

Boundary testing

Testing the edges of things to prove that specified limits are maintained. In software this includes ‘out by one’ errors.

Recovery testing

Testing specifically for the ability to recover from unexpected failures, breakdowns and errors, for example in ensuring no loss of data.

Security testing

Testing specifically for security elements in the deliverable, for example access controls.

Functional testing

Testing of the deliverable to determine whether it provides specific functionality (which should be defined).

Usability (or interface) testing

Testing of the user interface to ensure that the required functionality is delivered in a way that is easy to learn and use on an ongoing basis, and that unexpected actions by users are handled elegantly.

Inter-operability testing

Testing of the deliverable with other items that are produced or used with others, to determine whether these external connections work.

Regression testing

Testing after a ‘fix’ or late change to verify that earlier problems have not crept back into the deliverable.

Alpha testing

Testing with a small set of ‘friendly critic’ people, often within the development team and before use by customers, but using the deliverable in the manner for which it is intended.

Beta testing

Testing with users under a normal usage environment, but before the final release (and hence in time to fix problems before final release).

Acceptance testing

Testing by or on behalf of the customer that the deliverable performs to agreed specifications and hence meets requirements.

Release testing

Final test before release that the deliverable is ready to go live. This includes all supplementary material, such as promotion leaflets and training.


Change planning

Deployment is where the ‘rubber hits the road’ in many change projects, effectively where the real resistance to change is met. The success or failure of this occurs is often determined earlier in the project, where that resistance is understood and preparations made to address it. In the development phase, this may include:

  • Sounding out key target stakeholders to assess their support or resistance to the change.
  • Understanding stakeholder issues and planning to address these.
  • Discussion with executive sponsors to determine their readiness to handle escalations.
  • Agreement of escalation process for slow or non-conformance.
  • Identifying and developing methods

Commitment planning

Deployment of the change will typically require the most effort in terms of persuading people to accept the change. The work here thus goes beyond simple communications planning to determining how you will gain and sustain commitment of all the people involved, particularly the managers on whom you may well depend to ensure the change is implemented in their area.


Development documents will vary depending very much on the project.

Deliverables documents

In some projects, the deliverable is a document rather than documents being used to support delivery of a more tangible change. For example in a project to determine stakeholder experiences, the main output of the work will be a report, although may also include separate document for the executive summary and a more detailed analysis of the data.

Communication documents

For deployment of a solution there may well be a need to make a number of communications to stakeholders, with possibly different communications to different stakeholder groups (such as managers and individuals). The development phase will thus include writing and agreement of these communications. These may include:

  • Flyers and leaflets that promote and summarize changes and what will be delivered.
  • Presentations to be used by those who are deploying the deliverables.
  • Email messages to broad groups.
  • Web pages to explain what is being delivered.
  • Educational material
  • Change projects sometimes fail because the target audience does not know how to make full use what they are being given. Educational material may thus include:
  • Quick start guides.
  • Detailed ‘how to’ manuals.
  • Training class materials (for trainer and attendees).

Outline design

The outline design document communicates design principles being used and describes the overall architecture. It is usually quite pictorial. For simple projects, this may be a few Powerpoint slides, such as Fig. 12. For a larger project, this may include a discussion of principles and wireframes.

Detail design

A larger project will included one or more documents that describe the design in further detail. Where the outline design decomposes the deliverable, there may be separate detail design documents for each module.

Test plan

The overall test plan discusses the methods to be used for testing and lays out the overall design for testing. In a smaller project, the test specifications may be included in this.

Test specifications

Test specifications describe the detail of each test that is to be completed to test a specific element of the deliverables. Test may be run several times and it is not uncommon for any change to

Test reports

When tests are completed, then the outcome of the tests may be summarized in formal reports.

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, Service Level Agreements (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 3 Checklist

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