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. MethodThe 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 methodWhen 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 methodIn 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.
DesignA 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 DesignAn 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 DesignThe 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 DesignThe 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.
ConstructionThe 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. PrototypingDevelopment 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 assuranceQuality 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.
TestingTypes 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 planningDeployment 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:
Commitment planningDeployment 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. DocumentsDevelopment documents will vary depending very much on the project. Deliverables documentsIn 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 documentsFor 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:
Outline designThe 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 designA 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 planThe 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 specificationsTest 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 reportsWhen tests are completed, then the outcome of the tests may be summarized in formal reports. Governance documentsDepending 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.
See also |
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 |
And the big |
| Home | Top | Menu | Quick Links | |
|
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 | |
| Home | Top | Menu | Quick Links | |
|