- Working with technical experts
- Involving students
- Building teams and collaborations
- Producing a plan
- Embedding, maintainance and future development
While the aims and objectives define what it is you are trying to achieve, the project plan is how you are going to achieve it. A project plan exists to clearly spell out the expectations of the parties. Think of it as a map, the guide to getting there.
Like the project proposal, an explicit project plan is useful even if you are the only person working on the project. It needs to include:
- Roles and responsibilities (for project teams)
- A breakdown of tasks and deadlines
One of the defining features of an e-learning project is that it straddles the areas of education and technology. Even if you are hands-on with the technological side, you will almost certainly be dealing with technical experts. Communicating your educational needs to programmers and other computer experts until you get a shared sense of what is possible can be difficult and time-consuming.
Finding a suitable technical expert can also be quite difficult. Technical developers are often ‘back-room’ staff whose core duties do not involve the demands of front-service users. Quite often they are young, enthusiastic and helpful but usually overworked so recruiting them to give you more than brief advice can be difficult. Keep in mind that strange as it seems, directly helping academics is probably not part of their job remit. Technical experts in the University sector are often positioned lower in the hierarchy than you would expect from their level of expertise; you might find highly competent assistance from students in computer science, maths or engineering.
If your technical expert has a formal involvement in the project, there are still cultural barriers to overcome. Due to the fast moving world they work in, many of their skills are self-taught ‘on-the-hoof’ rather than by any formal training. This means that it is often difficult to gauge their level of knowledge, but their high level of adaptability might offset this.
The technical expert will want to take away from meetings a clear understanding of what you expect them to do. They may be working on a number of projects at the same time with overlapping deadlines - you are just one. Despite being highly creative and obliging, there is a limit to how much time they can spend reworking a badly described or frequently changing requirement. They will be filtering all you say to distil an exact specification.
A technical expert may come to a meeting with the following list of objectives probably in this order:
- Identify requirements;
- Detail costs (time, money, skills);
- Set deadlines, deliverables, tasks and roles.
- Communicate the possibilities
- Identify the technically interesting parts
The first is a matter of communication perhaps between individuals with very different mind-sets. An early prototype is perhaps the best way to establish that you have communicated your wishes. A prototype usually raises additional possibilities but try not to be distracted by unimportant ones. It is your responsibility to ensure that the core functionality is met first.
Remember that an experienced technical expert may have more experience than you in analysing a project of this type. However, inexperienced technical experts are often optimistic about timescales so allow for this. Try not to make the meeting a one-way process though. They may be able to offer ideas that you would otherwise be unaware of so let them into your thinking and your goals
Your students are the main focus of the project so it makes sense to involve them as much as is feasible in its development.
Students can be actively engaged in projects in a variety of different ways, including:
- On Steering or Advisory Groups.
- Working on project developments.
- Taking part at dissemination events.
- As sources of data and information.
- As the central focus of the outcomes of the project.
- Trials and pilots of materials.
- Participating on discussion lists
- As case studies.
- Providing feedback and evaluation.
Project teamsIf there is more than one person with a formal involvement in the project, they will have different roles, responsibilities and accountabilities and project team issues come into play. Much of project management literature focuses on project team issues. As this may only apply in a small way to your project, we will try to tease out the essentials here.
Project rolesYou may be filling all the project roles from project manager to content provider to technical developer in which case communication between roles should be fairly straightforward! However, if there is even one other person with formal involvement, you will need to establish what is expected of each.
CollaborationDefining project roles is particularly true of inter-institutional developments. Achieving a successful project with collaboration partners spread across many institutions is notoriously difficult in the University sector. We will not deal with this here as it will not apply to most but instead refer you to briefing papers from other sources
Timelines and deadlinesBe realistic and err on the side of caution. What seems achievable in the hot light of the initial creative fire becomes daunting when you are coming at the work perhaps cold and squeezed between higher priority work. A standard rule of thumb is to allow an additional 10% for unanticipated delays.
You might consider spreading out stages of development work across several months, rather than trying to find large chunks of time in one term.
The plan documentDo not become too concerned about learning to use dedicated project management techniques and software tools. If you are already familiar with these and they seem appropriate then by all means use them. It is partly a matter of taste – these tools can force you to become too mechanistic in your approach. Remember that the prettiest flow chart can be just decoration.
Your plan is a dynamic working tool and not written in stone and what is important is that you use it. Reviewing progress and adapting the project plan can help you find ways to cope with slippage and changing circumstances.
Assessing risk and anticipating problemsRisk assessment should and usually is considered formally for large team based projects but with small projects there are fewer sets of eyes to see approaching disasters. Thus, in the planning stage it is even more important to consider risks and establish contingencies. A brainstorming session with all involved is often the best approach.
For projects with a precisely defined plan, successful developers have procedures in place to adapt to change and ensure good communication is maintained with any stakeholders at key stages. But beware the unexpected. You may have thought about some of the risks during the project such as your key technical developer or contact leaving, unanticipated workload or illness. Build in some coping strategies to deal with these, but also consider what happens as the project is nearing completion or after the project has finished? See ‘Embedding, maintenance and future development’ below.
If you are accountable to anybody for the success of your project, it is wise to keep them informed of problems and how will be addressing them. If you do so early, it is usually possible to renegotiate timescales
Ideally you want the fruits of your labour to be embraced by a wide circle of colleagues and the burden of maintenance and future development removed from your shoulders by embedding the change your project results in into department practice. This is not going to happen without planning for it. Waiting until the project is finished before addressing these issues is a common mistake. Your strategy for achieving embedded change needs to be part of your project plan and goes beyond dissemination activities.
E-learning is a fast changing area. While the core teaching and learning design of your project may remain valid for many years, the actual technology may date very rapidly and may need reviewing on a yearly basis. Many educational development projects do not anticipate this and good work is often lost because of it.
There may be no more funding or time allocated to keeping the outcomes of the project up-to-date or even operational. Just because your head of department gave you time to work on the project does not mean that (s)he will allow you additional time to take it through future development cycles. Central or departmental technical support such as server support and data backup should be considered at the outset to ensure that long term support is possible.
We assume, sometimes incorrectly, that successful work will be widely recognised and embraced by departments and so embedded and resourced. Besides raising these issues at the start of a project and reaching understandings, you should not neglect to promote your work within your department. If its usefulness becomes common knowledge, and there is support for others to explore an approach in their own practice, it is more likely to survive and become embedded in a departmental strategy