How we change what others think, feel, believe and do
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.
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.
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.
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).
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 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.
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:
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.
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.
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:
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.
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.
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 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
When tests are completed, then the outcome of the tests may be summarized in formal reports.
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.
And the big