In this article we have introduced the concept of an artefact librarian role.
Put simple, this is the person responsible for defining and coordinating the vast number of materials and documents produced in a typical large scale data migration project.
Having a dedicated resource to fulfill this role just might help your next project run smoother than ever before.
Why do we need an artefact librarian?
If you have ever worked on a large scale data migration project you will have been accustomed to the sheer volume of artefacts that are created.
System documentation, analyst interviews, software versions, workshop minutes, timesheets, test scripts, cleansing scripts – the amount of project paraphernalia can be vast.
A common theme I have witnessed on many projects, particularly those that are slipping, is a complete lack of structure and coordination surrounding these artefacts.
Developers create their own methods of working and store local documents on their hard drive, data flows into the project without any tagging or trace-back, version control is often ignored due to complexity or lack of appropriate software and particularly when there are multiple partners involved there can be no clear standard for document format in place.
Data migration projects are often extremely complex and require a huge amount of cooperation to run smoothly so it is imperative we coordinate and control how artefacts are created, stored and utilised during the project.
What does an artefact librarian do?
First of all, chances are that your project is probably carrying out elements of the artefact librarian role. Project coordinators typically undertake many basic artefact management activities for example but what I would like to see on more projects is a clearly defined role throughout the project.
The artefact librarian should therefore start the project during pre-migration initiation and continue all the way through until decommission and handover.
Here are some of the activities I believe the artefact librarian should be responsible for:
- Creating, teaching and enforcing the documentation standards for data quality rules management
- Setting up a unified project office documentation set that is compliant with the particular project methodology e.g. PRINCE2
- Creating, teaching and enforcing the procedures for any project documentation repositories such as Wikis or online project stores
- Setting up the version control and audit trail processes to ensure the lineage of any project artefacts
- Creating the categories and document naming standards throughout a project
Isn’t this already covered by standard project documentation?
To a certain extent yes, PRINCE2 for example has standard documentation that is perfectly valid for a data migration project.
However, in my experience, the coordination and management of project artefacts is something that always goes astray when there is a lack of adequate planning and responsibility in place, you can have all the documentation in the world but it still requires an experienced hand to implement the actual process.
Quite often this may be the first time an organisation has undertaken a data migration project so it really helps if the coordination of project artefacts is planned right from the outset.
Data migration is a very different project to traditional software development initiatives and as such requires some distinct documentation. It is increasingly important for these materials to be well defined before the project commences to eliminate ambiguity during project ramp-up.
What if we can’t afford or find an artefact librarian?
Most projects have limited budget for tools, technology and resources plus there are probably few people who have the experience of carrying out this role so how should a company proceed?
My advice is to first start by understanding the data migration methodology you plan to implement.
Walk through the project approach and identify which materials will be required at which phases.
Ask yourself questions such as:
- How will these documents relate to each other?
- What will the dependencies be?
- Who needs to sign off each document?
- Who needs to contribute to each document?
- Which documents need to be version controlled or audit trailed?
- Where will the documents be stored?
- What levels of permission will be required for different document types?
- How will the file structure be enforced?
- What wiki or project repository tools will you need?
Once you have a clearer understanding of the project artefacts and processes required for your data migration then start to identify what resources you have available to help you with this process.
Do not underestimate the level of support you will need, particularly on a large project this can be a major contribution and my preference is for a designated role, particularly during the project initiation and landscape analysis phase of a migration.
Post-analysis and discovery you can gradually reduce the level of support required as people begin to learn the artefact management process but there should still be some form of support all the way through the project so plan accordingly.
Many people will no doubt view the role of artefact librarian as largely redundant or too costly.
However, the typical data migration project overruns by a significant amount as a result of excessive development costs or missed business opportunity.
The artefact librarian more than covers their costs by reducing the amount of scrap and rework that can take place when an ineffective artefact management process is enforced.
Once you have implemented a dedicated team member for this role I am certain you will find it too difficult or costly to return to the old unregulated method of working.