PLANNED ACTIVITY

Once you have completed steps 1 to 6 above and have a better feel for the shape of the problem you will be in a position to put together a plan that will involve the correct Data Stakeholders in Data Quality Rules and prioritization exercises. The plan will inevitably be iterative and release based. So:

7. From the created fault log, start prioritizing the faults and create realistic estimates of how long they will take to correct.

8. Institute a tight release and configuration management strategy. In the hurly-burly of a struggling implementation there is always the temptation to bypass normal controls and fix things on the fly. Once you become aware of previously fixed bugs reappearing you will know that your configuration management policies are compromised (that is if you have any, of course). Step in before this happens — it hugely discredits any deployment exercise. The published releases will tell the business what is being fixed and which releases they will be in. The components of each release must be under the control of the key Data Stakeholders, both within the programme and within the enterprise. Set up a suitable forum where these decisions can be made.

Hint In these circumstances I usually institute a weekly release strategy with a weekly meeting of key Data Stakeholders to agree the release policy. Once the major issues are resolved this can become fortnightly, monthly etc. Extreme formality is required. The releases should be documented in terms of the Data Quality Rules they implement, the date they will be implemented and given a formal release number. Keep the meetings focussed and short! Less than one hour is best. They are not designed to fix the problems but to prioritize the solutions. I also institute the use of proper configuration management tools if these are not being used. But the tools only work where there is discipline in place.

9. Be aware of Golden Rule 3. You are now very much at risk of loading that which is expedient as opposed to that which is necessary. It may be that for political or practical reasons less than optimum data needs to be released but more than ever you need compromises led by the enterprise and accepted by the enterprise. If less than optimum data is released, do you have a plan for correcting it in a later iteration? Has the reason been sufficiently well communicated to the other Data Stakeholders?

The situation should now be under control. I am not saying that you will be popular with the programme sponsors or the enterprise or even that you will hit your deadlines, but you will have a rolling release plan that will inform the enterprise of when a stable deliverable of acceptable quality will be reached. You will be managing via Data Quality Rules. These are designed to be built up into plans. You will be identifying your key Data Stakeholders and bringing them into the project to lead prioritization decisions.