This AHDS Information Paper addresses at a relatively simple level some of the main issues faced by academic researchers when planning a major research or resource enhancement project. It covers the issues which will need to be addressed in a funding application to the AHRC, but will also inform other researchers, including those already involved in digital resource creation projects.

Most projects can be neatly be divided into three main sections. The planning stage covers that part of the project from initial concept to funding. The effectuation stage covers the part from funding to delivery. The continuation period refers to the post-delivery period. Each period is vital to the success of a project, though an emphasis on first two stages is usually made. (Yeates, 1991).

All projects must start with an initial concept or vision. During most research projects these concepts are put to the test; in digitisation projects the vision is achieved. This should be a clear and concise statement outlining what you want to do, why you want to do it, and why it is important. It will also need to consider any previous work done in the field and how it will be enlarged upon in your project. Your concept should be reasonably rigid and your vision statement should encapsulate precisely what you want to do. This means that further work on the project plan will avoid creeping scope, which is a blurring of the boundaries of the project.

The 'project scope' should consider the aims and objectives of the project. Objectives or goals should be concrete outputs, but are not necessarily deliverables. The following section explains this project management terminology.

Aims and objectives are often used interchangeably, but refer to subtly different things. Aims are broader but more ephemeral: objectives are concrete and measurable, but more prosaic. Aims should be encapsulated in a short statement of intent that provides a summary of what you intend to achieve or the problems you aim to solve.

The JISC (Joint Information Systems Committee) suggest that objectives should be SMART. That is:

S pecific
M easurable
A chievable
R ealistic
T imed

Each of the following headings in this section should be considered before moving forward on a project.

There are two forms of study which can be carried out in advance of the creation of a detailed project plan. Firstly, a feasibility study which may also encompass a pilot study and secondly, a user-needs survey.

The main aim of the feasibility study is to address whether the objectives of the project are achievable. This is done by attempting to answer the following questions in as much detail as possible.

• What materials are to be digitised?
• Are they suitable for digitisation?
• Are there existing catalogues?
• Will, and in what ways will digitisation benefit the collection?
• What are the potential sources of funding?
• Is the expected time-scale adequate?
• Are there sufficient resources allocated?

The feasibility study should also address the question: Is the project necessary? Since projects usually have outputs there is a need to discover whether those outputs are useful to the end-user. It may be that you feel that the only end user is yourself. This is not usually the case, especially as there are several national and institutional repositories that preserve and disseminate outputs from projects. Whatever you may produce is likely to be of value to other researchers, and considering their potential needs will be of value to the way in which you plan your project.

Undertaking an analysis of user-needs to discover what your potential users want or how they might use the results of the project is a valuable pre-planning element of any project. It is a rare project which has outputs which are not reusable by others - though it is often difficult to see how others might put your own research outputs to use. Putting a few simple measures in place at this stage might facilitate further use - a use to which you had not originally considered at the outset of the project.

User-needs analysis should cover the broadest range of your target audience as possible. This does not necessarily mean that a large number of people should be questioned, but that all possible potential user groups, from school teachers to other researchers and from undergraduates to special interest groups. A broad, but targetted audience may bring all sorts of unforeseen comments that derail or deflect from your initial concept of the project, but it will be as well to reflect carefully on these and gauge their relevance to the project, and if necessary alter the scope of the project. For example, some researchers making machine-readable versions of the census enumerators' books for the nineteenth century omit certain variables because they feel that they are not important for their own research - in fact the Genealogical Society of Utah inconsistently omitted the column relating to disability in their transcription of the 1881 Census of Great Britain making the whole of this part of their work problematic. (Goose, forthcoming).

The combination of your original project scope and vision with the feasibility and user studies should leave you in a position to draw up an initial project plan. While a project plan should cover as many eventualities of the project as possible, you should always remember that a project plan does not have to be followed rigidly. Project plans almost always evolve over the life of the project, it may be revisited, revised and altered as necessary during the progress of the project.

While it is normal to have some flexibility between proposing, planning and executing a project, major variations in deliverables and deadlines may need to be approved in advance by the funding body. In many cases, your application and letter of grant represent a contract that you are legally required to fulfil. As a rule of thumb, if your variation means a change to your initial proposal, a change to project deadlines or a change to deliverables, then you may need to have these approved by the funding body. Each funding body may have different conditions - read the small print!

In most cases the project plan should be considered in two distinguishable parts. Firstly, as an outline project plan which is used to secure funding. Secondly, on the basis of the first, a full-blown project plan which can be used in the execution of the project. The outline plan should not omit any of the areas mentioned below but should be more concise than the full project plan.

The project plan provides a concept-document for the project. It gives the project leader a concrete basis on which to carry out the project. It is designed for the project manager and not for the funding body! The plan enables progress and performance to be monitored and evaluated throughout the project. The plan also provides a point of contact for all people within the project, not just the project manager and all the project staff, but also any advisory or management boards and of course the funders.

The plan should be made available to all relevant staff and should be understood by the whole team. What should a good project plan contain? The main headings covered by the project plan should include:

Outline what you will have achieved at the end of the project. In a digital resource creation project these are usually digitalised images, metadata, a user-interface and some documentation. However, there are many other outputs which one should consider within a plan. These include demonstrators, workshops, documentation, reports, software, technical and user manuals, and FAQs amongst others. It is important to consider all things which are expected to be created during the lifetime of the project. Throughout the life of the project the project manager should review these deliverables on a periodic basis. It is possible that the deliverables may alter and sometimes they will need to be delivered before or after the planned delivery date.

(See the section on relationships between tasks)

The main elements of workflow is activity path, this is the path through which tasks must be carried out in order to complete the project. The project's workflow needs to be effective and efficient. It may be possible to estimate workflow from a feasibility study or pilot. Note that projects with poorly specified workflows can fail. It is important to allow for slippage (but not too much!). It is also important to know when in the project and why slippage may occur (see risk assessment below.)

Some projects are enhanced by carrying out a full pilot project. A pilot project differs from a feasibility study in as much as a pilot is like a small scale rehearsal of the whole project whereas the feasibility study is only a small scale rehearsal of part of a project. Pilot projects are the best way of understanding workflow. They allow the identification of problems and help to reveal a clearer picture of what the project will require in terms of staff, equipment, time etc. They may also allow the testing of the methods which are to be used within the project. Demonstration of a successful pilot may enhance the success of a project proposal. However, a pilot will not solve all your problems - good planning and adaptability is just as important.

While planning for workflow an emphasis needs to be placed on time management and scheduling. These, along with workflow help to ensure that the project finishes on time.

There are a number of formal methods for scheduling for example hierarchical decomposition and PERT (Project Evaluation Review Technique). Both of these methods depend on identifying and estimating the duration of each and every process within the project.

Hierarchical decomposition is the 'top-down' method inasmuch as one starts with the main goals and iteratively breaks these down into smaller tasks.

PERT considers tasks, their duration and dependency information. PERT charts start with a node from which the first task originates. The task is represented by a line which gives it name, identifier, duration and people assigned to the task. The completion of a task is denoted by a new node. The chart is complete when all tasks come together at a completion node.

An example of a PERT chart

In CPM (Critical Path Method) charts, the critical path of the project is highlighted. The critical path is a set of dependent tasks which take the longest to complete.

A Gantt chart is a matrix which has on the vertical axis all tasks to be performed. The horizontal axis always covers time, and sometimes covers personnel, financial details etc.

Using project management software like MS Project can assist in the process of creating a formal time-line for the project. Elementary tutorials are available on the Web.

It is also worth considering 'milestones' as key moments within the life time of a project. Milestones give fixed markers when certain key tasks have occurred and/or have been brought together. These allow one to fix times in the future to judge the progress of the project and also to celebrate the achievement of a substantial section of the project.

Roles and responsibilities need to be defined to understand staffing needs. Remember that recruitment is sometimes difficult, and money may need to be set aside for recruitment (and not just at the beginning of the project.) Different funding bodies may treat these costs differently; the AHRB expects these costs to be found from overheads whereas the JISC which does not allow overheads in project budgets, does allow costings to include this form of expenditure. If you have likely candidates for the posts but who might need training, this is the point to consider it. Staff training is a vital element of the staffing budget. Also having staff does not just involve monitoring the tasks which are being carried out, there may need to be an element of overseeing (but also see monitoring.)

There are other issues regarding staffing issues; these include staff retention (which is generally a matter for the institution hosting the project as funding bodies disallow these costs at present; timings - it is often difficult to get multiple members of a project team to start at the same time (and sometimes unnecessary too.); interview panels need to be organised with appropriate members and so on.

Projects should have a designated Project Manager. This need not be a full-time post, but the proportion of that person's time devoted to project management should be agreed in advance. The Project Manager is usually responsible for the effective management of the project. Often the project manager will be different from the person who initiated the project - who may become a project director or chair of the relevant management or advisory committee. If the project manager was not part of the original proposal, they need to be fully briefed by the author of the proposal but be sufficiently empowered to change the project.

There are generally two types of project committee. The most usual is the management committee, sometimes specific advisory committees are also appropriate. Management committees allow monitoring of the project by outside evaluators and provide a control on the project director. They also usually allow for repetitive but clear reporting from the project manager. Management committees often provide evidence of a project with effective checks and balances, and can often help project managers/directors if problems become too overwhelming. They demonstrate clear management structure. Advisory committees differ from management committees in as much as they offer subject-specific or technical advice to the project team.

Some funding bodies, especially the JISC, place a considerable emphasis on the role of the various stakeholders within a project. Stakeholders are anyone who has a vested interest in the project, or will be affected by its outcomes. Projects should consider carrying out a stakeholder analysis at the start of the project, as it helps identify just who is important to the success of your project. Stakeholders can usually be considered to be internal to the institution and the project, and external. It is important that all parties, both internal and external need to be satisfied as to validity and outcomes of the project.

Issues surrounding copyright and intellectual property rights etc. should all be addressed within a project plan. If there are several partners in a project, they should also be addressed in the consortium agreement. If work is being contracted to outside suppliers then the relevant contracts should stipulate the correct copyright/IP regime in advance. It is often useful to conduct a rights audit for this. For further information about these issues see AHDS Information Paper: Copyright and Other Issues in Digitisation

In digital resource creation projects sourcing of material is not always as simple as it may seem and it may take a considerable time to obtain the source materials. It may also be necessary to budget for the conservation and relocation of original materials. Alternatively, if the real world materials being digitised are too large or fragile to move, it may be necessary to move the digitisation equipment to it. The former has a cost implication in terms of conservation, the latter in terms of travel and subsistence

Standards play an important role in any digital resource creation project. A detailed project plan will need to consider, content capture standards, metadata (such as Dublin Core), terminology/controlled vocabularies, interoperability, authentication, open URLs, web accessibility standards, and learning standards and justify why chosen standards are valid for the project in question.

In terms of metadata it is usually valuable to assess levels of existing metadata, and if present, to consider the problems, timings and costs of data migration, normalisation (reformatting) and designing databases.

The following areas need to be addressed within the project plan: digitisation process; digitisation workflow; cataloguing and metadata; preservation and records management; programming and scripting development, security and data protection.

The digitisation process is best understood through the various Guides to Good Practice published by the AHDS. Further information and workshops on digital images are also provided by TASI (Technical Advisory Service for Images) and HEDS (Higher Education Digitisation Service).

Some of the key areas which should be considered in the digitisation process are in hardware (i.e., scanning device/digital camera); editing rules (cropping, contrast adjustment and colour control); software; platform; potential file sizes, image profile (resolution, bit depth and colour space); short and long term storage, and back-up procedures.

The preservation of any digital resource is of considerable importance, and the AHDS's guidelines on how to deposit resources may continue to be useful for any potential resource creator.

It is worth factoring in project time to ensure that your resource will conform to the standards required by the various AHDS centres. These standards will ensure that data will be preserved for future use and reference

According to the JISC, there is an important difference between QA (quality assurance) and evaluation. Quality assurance relates to the technical aspects of the project where there are explicit standards. All deliverables (databases, images, texts and metadata) should meet with specified the specified standards and the project plan should specify what checks will be in place for metadata, images, delivery interface. Quality Control/Quality Assurance should be ongoing. This will allow for the current state of affairs (known in project management jargon as 'actuals') to be compared with the plan. Evaluation is more subjective and covers quality in terms of usability, look and feel etc. Evaluation may also include 'usability' testing with real users, or commissioning evaluation studies.

Budgeting is a vital element of the project plan. Given that many projects attempt to create a project on the basis of a fixed and known sum. The project plan must give accurate in-depth assessment of all costs, e.g., staffing, hardware, software, specialist applications (web design, watermarking, e-commerce applications and other contract services), storage space, network infrastructure, input and output devices, consumables, digitisation, security, travel, publicity, etc. It may be necessary to obtain quotations and it is important to ensure that costs are valid for life of project (i.e., don't ask for salaries for 2005/6 at 2004/5 costs). Sirius web is a useful tool for calculating staff costs within the University sector.

Furthermore, your University Research Office and University Computing Services should be able to assist in staff costings and infrastructural costings (remember that computers need to be installed and maintained!). You must also make sure that equipment specified in the project plan is fit for purpose.

Some funding bodies, including the JISC require that a consortium agreement is signed by all partners and sent to the JISC before the project commences. This is a useful strategy and should be undertaken in all large-scale projects. Consortium agreements can range from informal letters of agreement to legal contracts. The JISC suggest that these should cover why there is a need for a 'consortium' (i.e., a collaboration or contractual agreement, what the membership of the consortium will be and what the broad responsibilities of each party are; what are the financial arrangements within the consortium; how will disputes be resolved; how parties may leave the consortium; who owns each of the project's assets (including hardware and property rights).

If your project is creating a digital resource you should carefully consider the appropriateness of various delivery mechanisms. Basic delivery mechanisms are hardcopy (for projects where the digital resource is not the delivery version (i.e., is a by-product of research)), the internet (usually the world wide web) and via the AHDS.

If the internet is the main delivery mechanism, you should consider who will be creating the user interface and how much will this cost. (There are benefits and disadvantages of doing this in-house or by out-sourcing). You should also consider whether user authentication systems such as Shibboleth would be necessary. (This is particularly useful when you have HE/FE-based funding and also feel that the resource has commercial value.)

If you intend to use the internet as your main delivery mechanism, you should not just consider, trialing, evaluation and usability (not just in terms of accessibility, though this is vital) but also ensure that they are factored into your original project plan.

In a well managed project it should be possible to have a phased delivery policy. This means that not only can you trial some material on users, but ensure that the system works. A phased policy of bringing resources 'on-line' in discrete portions can allow you to boost your usage figures if your site is well designed. You will also have to consider user support, and if necessary provide a 'help desk' facility.

Risk assessment is one of the key concepts of project management. There are always uncertainties in projects, and it is as well to have an idea about what these potential risks are and how strategies can be designed to address them. The JISC suggest four questions which need to be answered:

1. What could possibly go wrong?
2. What is the likelihood of it happening?
3. How will it affect the project?
4. What can be done about it?

Answering these questions is not always easy, but it is worth considering them during the construction of an outline project plan, and also when constructing a full project plan post-funding.

Risk assessment should identify weak areas and potential pitfalls and allow for the pre-planned strategies to cope with them should the risk occur. All project members to be informed of potential risks and remedies at the beginning of the project, and they should also play a role in identifying risks.

The main risks in digital resource creation projects centre on unrealistic targets. It generally takes longer than expected to make a machine-readable version of a text because not only does data entry have to take place, but verification should also follow. Other important risks are: altered deliverables; recruitment, retention and staff changes; equipment delivery, specification and failure; technological change and legal permissions. It is vital not to hide problems but to be upfront about them and to try to manage them.

Projects, especially if they are resource creation projects should be sustainable. This is usually managed by the AHDS in the form of its preservation and dissemination strategies. However, in situations where projects may have commercial potential, there may be a necessity to restrict free access to a created resource. If this is the case, a well-defined strategy needs to be in place to ensure that preservation and dissemination of these resources through other services is successful and long-term. The AHRB funds the AHDS to carry out these services and it is likely that projects which find it impossible to deposit their resources at the AHDS will not be considered favourably.

However, in the planning stage it will be of value to consider the different options available for sustainability when the funding ceases. Different projects will have different needs at the end of the project. It may simply be that a resource needs to be deposited with the AHDS: however, it may be that a web-based resource has been created which needs continued maintenance. As such how these costs will be met needs to be considered. It is not sufficient to expect further funding from a research body to maintain a web site regardless of its importance. There are a number of 'commercial' models which may prove useful. The models may not always be appropriate, but they do provide a starting point.

• Advertising model - where the project is supported by advertising revenue.
• Merchant model - where the project sells material on the traditional retail model.
• Affiliate model - where the project offers financial incentives to affiliated partner sites (e.g. the British Library has a partnership with Amazon).
• Community model - where users invest in a site (e.g. contribution of content, money, time, hosting).
• Subscription model - where users pay for access to "value added" content (e.g. high resolution files);
• Utility model - where funds are raised via metered usage or pay-per-view;
• Infomediary model - where data is collected about users and their purchasing habits and selling this data to other businesses (generally an inappropriate model for the academic world, but has been suggested by the JISC.) If this route is followed beware of potential Data Protection issues.

These business models also apply to the continued development of an on-line resource.

Furthermore, in terms of the long term ability of a project to remain visible, it may be worth considering whether the outputs of any particular project can be integrated together with other resources? Finally there is always re-purposing. Some considerable should be made of whether any resource can be repurposed for other users. Commercial licensing, for example, may be an option for "selling" the product.

Good documentation is fundamental to the success and the sustainability of any project. Documentation should cover all processes within a project. All decisions, systems, processes and workflow methodology should be recorded. Documentation is valuable because it ensures continuity in the event of changes in the staffing of the project, or in alteration of suppliers. Documentation also aids the monitoring, reporting and evaluation process and provides ordered, comprehensible and comprehensive details for audit and reporting to the funders. Finally, documentation, establishes the relationship between original documents and digital resource

The project manager should keep a full record of all aspects of the project. The main purpose of this is to provide an institutional memory. Solid documentation is one of the best methods of risk-management, especially since one of the most important risks in any short term project is staff recruitment and retention. The key documentation in any project is the project plan. The project plan should not be seen as a fixed document, it should evolve throughout the project. Other documentation includes institutional or technical evaluations; information relating to image capture, editing and processing; license agreements and contracts (vital if dealing with sub-contractors) and procedural manuals.

Documenting the use of standards which are being adapted by the project should not be seen as a minor output of the project.

Marketing

Marketing can largely be divided into two stages. Firstly, during the planning stage, identify the market (i.e., potential users). Secondly, during effectuation, 'do' the marketing. This can be done by running training sessions or workshops, either one-offs or part of a program. An exploitation plan which details how one will market your resource will prove invaluable to the project and assist in getting the widest audience. Exploitation plans should consider project identity, logos, a website, newsletters, workshops, conferences, targeted mailings etc.

Communication

Clear lines of communication within the project are also important, especially if the project is directed by more than one person, across different sites, or parts of the project are sub contracted to others. Clear and consistent reporting lines are important because they allow for monitoring to occur. Monitoring is the process of ensuring that all aspects of the project are running to plan. If things are going wrong, frequent monitoring will ensure that problems are picked up as soon as they occur and before they impinge on other aspects of the project.

It is also useful to have communication lines with external stakeholders. Some of these may be considered as the Management or Advisory Committees; others may be through publicity and promotions.

In any project a number of decisions will have to be made well in advance of the action being carried out. This is not as inflexible as it often seems. Project plans are expected to be flexible documents and should be subject to frequent (and hopefully relatively minor) change throughout the lifetime of the project. Managing a project is not about rigidly adhering to a plan, but attempting to use the plan as a framework for ensuring that problems, which will undoubtedly occur, are resolved with the minimum amount of fuss and effort.

Project management can not be carried out by rote; however, there are a number of key elements which can be put in place at various stages of a project to help in assisting the smooth running of a project. All projects involve a certain amount of uncertainty and managing this as efficiently and effectively as possible can help to ensure the success of a project.

JISC Project Management Guidelines

N. Goose, 'Evaluating the 1881 Census Transcription: a Pilot Survey of Hertfordshire', History and Computing, forthcoming, 13.2.

D. Yeates, ed., Project management for information systems (London: Pitman, 1991)

Page last modified: 13th March 2008 by
Email the AHDS | Site Index | Other Relevant Services | Latest Collections