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

Development

Disciplines > Change Management > The 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.

Method

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.

Design

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 http://en.wikipedia.org/wiki/Use_case).

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.

Construction

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.

Prototyping

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.

Testing

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.

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.

Documents

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