During the e-learning development process there is a question that often comes up. How do you manage the change process without allowing endless changes? This is especially an issue during the graphic, script and interactive phases – you could say during of the phases of a project!
Different companies and individuals have different models of working so there isn’t a model that is going to be able to be applied to all development models but here are some ideas for how you can help manage the process regardless of the development model that you are going to use.
1. Agree your sign off group
At the start of your project you will normally have agreed rules and roles for your project. You will have a development project manager, client contact, script writer, subject matter expert and other people in the project team. I suggest that you create a list of those people who are given responsibility for signing off each phase of the project and have this agreed by the project owner.
You all need to agree with this and if there are any changes to this list during the project then this needs to be changed. Any changes to the list are agreed by you and your project sponsor. You should also agree the maximum number of people who in the sign-off group. Don’t have everyone on the sign-off list otherwise you will never get anything agreed or completed!
It is a really good idea to have it documented so that you don’t get any surprises later in the project.
For example you start developing visuals and sending your graphics into the client for sign-off – neither you nor your client realised that all company graphics have to be signed off by the company brand team. You know have another set off people to sign off your work and your client has another set of people on their project team that they have to manage. Who pays who any possible change requests? What is the impact on any possible work required to the project timeline?
From the client perspective they will also have a deadline that will have to meet and changes will have an impact on their project and they will have another set of stakeholders within the business that they have to manage. At the start of the project work together to think about all of the people who need to be involved in the change process.
Within your group you need to have the right people involved in sign-off. Lots of people are more than happy to give feedback and provide positive and negative comments during project meetings but when it comes to formal sign-off they don’t want to make the commitment. Make sure that you have the people who have the authorisation to make the sign-off and it will make it in a timely manner. You don’t want to be waiting for months for people to sign off a stage on your project.
2. Make sure people understand what they are signing off
Make the process clear right from the start. Explain what the sign off process is, why you have it and how it benefits everyone through the project. Explain it at every stage to the people involved. It is likely that there will be different people involved at each stage.
If you are are signing off graphics and they will then go into production make sure that your client and your team are clear about what this means. You need to be fair to your client – for some people it might be the first time that they have worked on a digital or e-learning project so make sure that you explain what a sign-off means and the implication of sign-off.
Explain what you are giving to your project team – screens, prototype, script – and what you are expecting them to look for and to give feedback on. you might also want to give them guidance on what you want be able to change – for example the company logo in a specific position might not be able to moved due to company regulations.
3. Manage the number of changes
In theory you could make as many changes as you want, however you won’t get many projects completed and your timeline will just keep moving. Whether you are the client or the developer you need to decide the number of changes at each stage. Regardless of whether you are the developer or the client you need to be fair to each side – changes cost money and take time. If you want changes then you need to be able to pay for the time that they cost, if you are a developer you need to be aware that if you are working on a custom project part of the process is getting feedback and making changes.
My suggestion is that you have 2 set of changes at each development phase – graphics, script, prototype and delivery. If you are using a agile development model or an more iterative process you might find that you are constantly developing and refining your development process. It is up to you and the client to develop your change process, the most important element is that you both agree how it works.
4. Document the changes – all of them
You should document all change requests, all of them. You collate all of your client requests and log them. Client requests will come from email, phone, fax and in person. You need to document them in a change request log. We use a change request log that gives each one a specific ID and documents the date and details of the request. We can then track each change through the project. When we then deliver a new version of the project we can then deliver a version of the change log and show the client which changes have been applied.
If you don’t log your changes you will have problems remembering what has been changed, what has been logged and generally managing your clients. You can use something simple like excel – just a few columns with headers with the main details will help your change process a great deal .
5. Be fair
You both need to be be fair throughout the process – both client and the developer. If you have specified the project well and completed the development well then the number of changes should be at a minimum. If you are a developer and you are working on a custom development project then there is an expectation that you will need to do some changes – this is why it is a custom project. If you are a client just because it is a custom project and you are a client doesn’t mean that you can change everything on the project! Unless of course that you have agreed that you can do that and you have an unlimited budget and also an unlimited timeline. You should have sign off at each key stages of the project to reduce the number of major changes that you have on the project.
6. Change sometimes happens
Be prepared. Sometimes things happen. There might be a change in process, systems, a merger, takeover or new people get involved in the project and the project that you started with might change dramatically. This might not because of the people involved in the project but you need to be prepared for how you will deal with it if it happens! Act professionally, work together and come up with a solution that will work for both client and developer – you might need to re-scope the project, in some situations the project might be stopped whilst the project requirement is re-evaluated. If you do comes across a situation like this it is best to review the project and look at what is best for the project and the client as opposed to continually developing and moving forward without knowing what the end is.
Communication is the key throughout the change process, you need to work as a team and make sure that your team is informed at all times. It is a really good idea to keep good documentation and make sure that everyone can access all the documents at all times. If you can keep everyone informed and make sure that everyone knows what is going to happen at the start of the project the risk of issues during the change process will reduce.