Digitisation projects face unusually diverse and intricate problems such as: collaboration between different institutions, creation of content, website development, developing learning and teaching materials, financial and resource restraints as well as team coordination.
Are there ways in which the specific and difficult problems faced by digitisation projects can be mitigated by investigating different project management methodologies?
Is there anything to learn from the software development community, and their use of agile methodology as an approach to project management?
Cascading Project Management
Many digitisation projects will be familiar with cascading or waterfall project management methodologies such as PRINCE2 . The PRINCE methodology is a very structured approach to project management, allowing distinct project activities such as: a beginning, middle and ending.
PRINCE encourages a robust and structured practice of documentation, allowing a record of progress and decisions and work packages.
It also results in a clear path being constructed; like stepping stones it guides the team on its project journey.
But there are problems with the PRINCE methodology that can directly effect the success of digitisation projects. Below are some of the failings which seem to imapct upon digitisation projects the most. For example:
- Each work package must be completed before being able to move on to the next (hence the waterfall/cascading analogy)
- PRINCE is not good at dealing with change. Most digitisation projects have to deal with software development that requires different versions and changes, and PRINCE is not geared for dealing with these itterations.
- Finally, it is often not enough to simply be linear and logical (think about all those failed Government IT projects)
So what is the alternative, and what can it bring to digitisation projects that a strict PRINCE methodology cannot?
Agile Methodologies
Typically used in software development, agile methodologies attempt to address some of the failings of the more standard approaches to project manage
ment.
Agile shifts the focus of project methodology so that it is the role of the user/customer that is at the heart of the planning for a project.
It also assumes that a project will inevitably change directions and focus and it allows teams to respond to the unpredictability of building software, and to respond and change the direction of a project throughtout its development.
So how can an agile approach to project methodology help digitisation projects?:
- Sustainability is inherently a part of agile methodology, for example: It’s transparent; all about customer collaboration, and; it’s a ‘humane’ way of working, encouraging staff retention.
- Rather than guessing timescales for particular tasks, agile allows for short bursts of development, which can be itterative, and allow for work to be constantly created and improved, all of which can be constrained within the timescales of the milestones.
- Testing, or for Digitisation projects Quality Assurance can be done at the end of each short cycle, mistakes recitfied, and new work spun off.
- Usability and evaluation is embedded within the work, rather than falling at the end.
- Changes can be made at intervals that don’t effect the overall milestones of the project. If you have a set workpackage, then chaging it can impact on every other workpackage.
- Breathing spaces are built into the project. The end of each cycle can be a time for reflection, and allow other team members to engage in areas they haven’t worked on.
- Everyone is involved in the project. Meetings will involve all parties, planning needs to have the involvement of every person, not just managers and directors. New ideas can be born and fed into the planning.
But Digitisation projects are a complex mix of intricate and diffuse problems, so a single project methodology may not necessarily be right to address all the issues projects can find themselves facing.
Is it really Either/Or?
Is there a case to be made for blending the two methodologies? Indeed, it may be that projects already do this, but without consciously acknowledging this.
Digitisation projects are almost always a two part process: the technical side (development of the web page, repository, metadata, OCR etc), and then the practical side of actually digitising the images/documents, transporting the documents etc.
It may be that Digitisation Projects can use a blend of the two methodologies, or can cherry pick from the various methodologies that exist to enhance and maximise the effecacy of their projects.
Project management should never just be an accepted part of the project, instead it must be constantly interogated and assesed as any other risk would be. Maybe our project methodologies are the biggest risk of all!
One reply on “Start from where you are: Agile methods and digitisation projects”
Agile projects have a different priority mechanism.
Project managers are often described as juggling three balls in the air at the same time: quality, cost and time. Traditional projects, and methodologies such as PRINCE, give priority to quality, ie deliver what you say you will deliver regardless of cost and time overruns. Agile projects give priority to time. Activities are ‘timeboxed’. In other words, you agree to devote so much time to developing a particular deliverable and at the end of that ‘timebox’, you deliver. This mechanism allows for incremental delivery, you can deliver something early in the project and test and evaluate it. Often requirements are only finalised once something has been delivered because only then do users know what they did or didn’t want what. (It’s always easier to judge something tangible rather than something abstract.)
To make timeboxing work requires immense trust among the project stakeholders. After all, if you don’t deliver a finished product the user has to be sure you really did try to deliver and weren’t simply taking them for a ride. So this sort of project requires very close attention.
Therefore, the project plan is based on repeated timeboxes, the ‘short bursts of activity’ mentioned in your post. At the end of each time box, the deliverable is assessed and rework can be incorporated into the next development cycle. Note, this is only successful if you have access to your users’ key players. If they cannot be spared from the day job to help evaluate each cycle then don’t adopt this approach.
To help plan the detailed tasks within each development cycle the features users would like to see in the end product are coded according to the MoSCoW principle:
M – must have
S – should have
C – could have
W – want.
The development cycles then work through the list of features, beginning with the ‘must haves’ and so on until the project ends. It is unusual for any ‘wants’ to be delivered as most projects s are too short on budget or time to get that far down the list. But applying the MoSCoW Principle does mean that the vital features are delivered.
So, applying this to digitisation projects embodying your concept of a two part process (the technical side and the practical side) I’d suggest that:
• agile methodologies are appropriate for the technical side because there is scope for negotiation of the deliverables and their definitions may change during the life of the project;
• agile methodologies are not appropriate for the practical side because the source objects have to be digitised and there is no negotiation during the project over the quality of the digitisation or the quantity of source objects.
Finally though, while PRINCE is not a methodology that adapts well to delivering agile projects, it remains an excellent means of defining them. For example, you may not have to define your deliverables in the same detail in an agile project as in a traditional project, but you still need to agree the source of the deliverable definitions and who has the authority to sign them off the agreed
definitions. There is sufficient overlap in project initiation between agile and waterfall projects that PRINCE can still play a useful role.