Project management for digital heritage projects

Posted on April 19, 2011
Much work in the digital heritage is project-based. This means that there is a start, middle, and end, and that activities are designed and structured to deliver some products for a specific group of beneficiaries and in accordance with a defined business case.

Projects are always temporary organisations which are built for a specific purpose and which are then disbanded. Projects always have such a specific purpose, and this purpose is always to deliver something to someone. Most projects also are conducted within the scope of a larger programme of action, but for this blog I limit the discussion to individual projects.

Many problems go wrong, and they fail in many ways. They may fail to deliver the expected quality of products or they may exceed acceptable time and cost tolerances. Many projects are scrapped before they reach completion, leaving behind costly messes. Digitisation projects are large and expensive, and the management of these is difficult and should only be managed by professional project managers. Technical personnel on such project have specialized roles which demands considerable experience and knowledge, and the general rule is that individuals should not take on both technical and project management roles on a single project.

The modern view of project management is as a generic discipline which is applicable to a wide range of types of activities that meet the rough definition provided in the first paragraph of this blog. There is an established body of knowledge, called PMBOKÂ (trademark registered to the Project Management Institute), which is directed towards large-scale engineering projects, but which contains guidelines that are useful in any kind and size of project. There is also an established best-practice method, PRINCE2Â (trademark registered to the APM Group), which provides a prescriptive process to deal with the complexities of any size of project over a seven-process model, using a four-level organization structure.

To become an expert project manager requires not only knowing these methods, but also requires the experience of having applied these methods over a range of different projects. It is impossible to provide a sufficient overview of the discipline of project management within these few words and paragraphs, and this is not intended to be sufficient to get you started on the path to running a successful digitisation project. It is rather my goal to provide things to ponder - things which make the difference between a well-run project and a failed venture. Examples are provided which are typical of projects concerning the digitisation of archives.

Business Case

Every project must be justified, not only at the beginning but at every point of evaluation while the project is going. Project overruns in time and cost may mean that the project is no longer viable. If the business case is not met the project should be stopped – immediately. This is difficult to do, due to emotional attachments to projects.

Every project needs a balance between time, cost, quality and environmental factors, and not all of these can be optimized. Given that digital heritage projects have very long term products, time is the most common dimension sacrificed in order to ensure that the quality is maximized, while limiting the financial exposure. Within South Africa there is also a common requirement to transfer skills and to enhance self-sufficiency as a major outcome of a digital heritage project. This balance should be reflected in the business case.

Within every digitisation project the business case is required to identify and address the needs of the stakeholders, and in particular the users who should benefit from the digital resources. This may include provision for financial sustainability, which open up commercial avenues for income production as a by-product of having digital resources available, rather than digitising purely for preservation.


One of the most significant problems that occurs in a project is when the roles and responsibilities are not well-defined and not allocated optimally. The project manager does not manage by consensus but is often required to be a dictator, and it is thus essential that they can perform their responsibilities from a position of authority, experience and knowledge, and not by guesswork and also are not constrained by having to report every decision to a higher authority.

The project manager is placed within a larger project organization structure, and they will report into a project board, whose responsibility is to take the major decisions on direction of the project, but not on the methods of getting to this vision, which should always remain the project manager's responsibility. The project board themselves will report into the sponsor of the project, the business interests that are beyond the scope of the project organization. This is important - since by ring-fencing the project authority, the project board and the project manager can take decisions without having to revert back to the management of the institution. Having the top management involved in micro-managing a project by taking decisions on what to digitise and what not to ditigise will cause undue stress in the project. They should rather approve the rules of selection and then let the project team get on with their work.

These three levels - being the institution, the project board, and the project manager -represent the top three of the four levels. The last level consists of the team managers, who manage the teams that actually do the work and produce the products, and this highlights an important separation between the top three levels, which are responsible for project management activities, and the bottom level, which conducts the work. In a typical project the same people carry out a number of roles, but it is important that these roles are preserved throughout the project.

Within a digitisation project the institution is the custodian who holds the archives to be digitized, and the project board will consist of representatives of the institution, the users/consumers, and the service providers, creating a balanced project direction. The project manager should be a person with significant digital heritage experience who is familiar with the special needs of this kind of project management. The teams are structured for the various technical responsibilities, such as physical archive management and inventorising, equipment and facilities management, digital capture and photography, metadata, information packaging, and repository management.


Every project has the goal of producing products, but what are these products? Some many consider these to be the digital images, videos and audio files. Others may rather consider these to by information packages, containing all of the digital content and its metadata, ingested into a specified repository. Either of these may be the outcome of a project, and it is the scope of the project which determine what the outputs are. In many cases the output of one project are the inputs into the next project.

What is important is that the products are well-defined and are explicitly recorded, and that both all parties agree on this as the scope of the project. This should be accompanied by reference to standards and practices to be used.

Planning, Scheduling and Resourcing

One issue that confronts every project is the creation of a project plan - but this requires an understanding of what constitutes such a plan. There is a common misconception that the project plan is everything in project management, and that the first step in any project is to create this through software such as MS Project.

The first element of such a plan is to understand the products to be built, and the sequence of these. The metadata cannot be added before the archives are scanned and the digital resources created, and these cannot be placed into the repository before the information package is completed. There are many such dependencies, and it is these which help to create the schedule, with the individual activities then analysed in terms of the resources, equipment and skills needed, and the time they will take, with tolerance on the time and cost. This is what is put into the project software, but only after the individual activities have been determined in advance. It is at this point in the project planning that such software comes into its own as an essential element of project management.

The plan is also required to consider the time taken to check the quality, and also to include considerations for changes and to mitigate risks. One important planning decision is to determine the sequencing of the activities, and whether this is based upon physical location, or by type of archive, or perhaps by some previously-decided significance rule.

What does the Project Manager do?

The project manager must undertake many activities that take place at the start and end of projects, and also for planning and evaluating the stages, but it is the day-to-day activities which demand the most attention and it is these which consume much of the project manager's time. There are three primary daily tasks.

The first task is to structure the project into work packages and to hand these out to the team managers. If no work is handed out, then the work will not be done, and the products will not be produced. If too much is handed over, then the teams will lose sight of the priorities, and will be juggling too many activities. Once the work is handed over, it is then the responsibility of the teams to perform the work, and to ensure that the quality is checked and that there is a sign-off.

The second task is to communicate with the project board and with the rest of the team. The project manager consolidates all of the activities, determines the level of progress and the status of issues, and then produces reports to aid decision-making.

The third task of the project is to deal effectively and efficiently with change.


Quality is defined within the PRINCE2 method as 'fit-for-purpose' and within this the purpose is itself defined in the context of the end-users of the products and what value they expect to obtain from this usage.

Quality is of concern from start to the end of the project - at the start the project manager helps to document the descriptions of the products which include the quality criteria to be used later to determine whether these products are fit for their purpose or not - as the products are created they are then tested against these quality criteria, and this is a required condition for the handover of the product - at the end of the project these quality criteria are used to help with the handover of the final products.

There are many ways to check quality, and in digitisation projects these will include sampling, to ensure that a selected sample of the digital resource meet the quality standards, and to ensure that a selected sample of the archives can be demonstrated to have been digitized. It is not possible in such cases to perform a total check, especially when there may be millions of pages digitized. Sampling is one of a wide range of quality methods to provide sufficient evidence as proof that the job has been performed properly.

Change Control

Within every project there is constant change. This change is driven by issues which arise and which must be documented and analysed in terms of their impact. Those issues with high impact may require replanning. For example, a project to digitize a major archive may be planned based upon the availability of a suitable top-end scanner arising in time for the project. However, if the arrival of this scanner is delayed, or it turns out to be insufficient for the task, then the project must adapt and change. Similar situations arise every day on the projects, and some will have major impact and others may have no impact, but this will not be known until they are analysed.

Changes that are significant must be referred to the project board, who may decide to stop the project, since the outcomes cannot be achieved. For example, if the scanner is unable to be delivered in time, or becomes too expensive, then the project may not be able to meet the delivered quality of product within the agreed budgets and time, and the project board will not have the mandate to continue. This is an important principle of successful projects, that every level of the project management have a mandate to perform within agreed tolerances, and if these are exceeded they must revert to the next level of management, up to the external institutional sponsors of the project.


There are so many other aspects to managing a project, and these simply cannot be included here, and as a result this outline falls far short of even a short introduction to the totality of project management.

The areas omitted include stage-based planning, risk management, configuration management, knowledge management, resource and financial management, and communications - all of which are essential elements of a total project management structure.

I can only recommend that if you are interested, that you seek out project management training which is specific to the world of digital heritage projects. This is something we have been considering due to the significant need within the sector - a special-purpose project management training course aligned to the local NQF curricula which has a focus on a range of best-practices in a method-neural basis and adapted to the needs of the digital heritage types of projects.

I welcome any correspondence on this topic since both project management and digital heritage are areas of my professional activity, and I remain interested in improving the practice of project management within this sector.

Roger Layton is an Archival Platform correspondent and an IT consultant specializing in the digital heritage and is the creator of the ETHER Initiative. He is a professional project manager (PRINCE2 Practitioner) and project management trainer. Contact Roger at or visit his website