I say ‘fail’ with full knowledge that failure can mean many things:
- Failure to fulfil explicit project goals.
- Failure to meet stakeholder expectations.
- Low user uptake.
All three forms of failure can occur together. For those of us that have participated in an EDRMS project, or have been a user on the receiving end of a new EDRMS, we can identify with all three forms of failure.
Below I have listed some examples of each form of failure:
1. Failure to fulfil explicit project goals.
A common project goal is break down internal organisational silos of information, and to enable any user (irrespective of business unit) to access appropriate and relevant information irrespective of internal author.
For example, a Customer Service officer, on answering a telephone call from a customer, should be able to view at a glance all recorded contact by the organisation with that customer. In so doing, the Customer Service officer is able to understand the customer’s history and s/he will be better equipped to understand the context of the customer’s call and to better respond to their needs.
In reality, post-implementation, will the Customer Service Officer be able to see a view a single view of the customer?
2. Failure to meet stakeholder expectations.
A common expectation of Senior Executives (for example) is to achieve improved internal responsiveness to internal SLAs (Service Level Agreements).
For example, in a government agency delivering direct services to members of the public, staff are required to formally respond to a query or a request to receive a service within a specified number of working days. Receipt, routing, analysis and response to the query or request might require multiple internal teams to communicate efficiently and in a timely manner.
In reality, post-implementation, will the SLA be met following the rollout of the EDRMS?
3. Low user uptake.
A common expectation is that following the rollout, a majority of the organisation’s network users will use the new system for their normal work. However, how will this be defined?
For example, statistical reports might be prepared that show:
a) How many users have logged onto the system at least once in a given period?
b) How frequently have individual users logged onto the new system during this given period?
c) How many users have carried out routine actions within the system within the given period (e.g. created a new document, edited a document, conducted a search, actioned a workflow task)?
d) How frequently have individual users performed each of these routine actions during this given period?
Having read my thoughts, I’m sure many of you are thinking (screaming at your laptop screen…?) ‘Surely this guy knows about all the problems that hamper an EDRMS project?’.
Next time we will list a number of the specific problems that can bring an EDRMS project undone.