Therefore Strategic Technology Services

Saturday, 29 June 2013

Strategic Planning – It only counts if it happens

I have been involved with the development and execution of strategy for more years than I would care to recount. My most profound observation in this regard is bound to disappoint … Even the best strategic plan will only add value if you implement it.

I once had the pleasure of compiling a strategic plan for a Client, only to receive the complaint that I had put forward the previous year’s plan in error. Having not been involved in the previous year’s strategic plan, I was a little perplexed. On further investigation it became clear that the “new” strategic plan that the Team had put together was indeed very similar to the previous year’s plan. The underlying issue was that the previous year’s strategy had not been executed … at all. A year lost, and a year in which competitors had sadly covered a lot of ground. In short, too many strategic plans fail because, once approved they proceed directly to “file 13”, never again to see the light of day.

How does one ensure that strategic planning actually results in tangible benefit? Some thoughts in this regard follow.
  1. Strategic plans are often drafted as “high level” documents and not broken down to the tactical level. For a strategic plan to have legs, it needs to be broken down to the tactical level … something that the staff that need to do the actual delivery can relate to.
  2. Make sure that there is sufficient funding available to allow your Team to deliver against your strategic plan. Your strategic planning should be done before the annual budgeting process, to ensure that there is sufficient budget available to make execution viable. Oddly enough, I have seen any number of cases where the annual strategic planning has been done after the budgets have been set!
  3. Make sure that the staff that are accountable for delivery of your strategic plan have the necessary skills to guarantee success. In my experience, the primary skill required to deliver against a strategic plan is the ability to project manage in a cross functional context.
  4. There needs to be alignment between the tactical layer of a strategic plan and the KPIs of the staff that are accountable for delivery. Staff must have a clear understanding that their performance with respect to delivering against the strategic plan will be taken into account with their next Performance Appraisal and will affect their financial well being.
  5. I have frequently worked in environments that do not have a culture of delivery. For the sake of your business’s long term ability to deliver on its strategic vision, it is essential that a culture of delivery is developed.
  6. Ensure that tasks are allocated to staff that carry the appropriate levels of authority to allow them to succeed.
  7. Regular progress reviews must be done, and performance, or the lack thereof, must be managed accordingly.
  8. Someone needs to own the overall plan. That someone should be the Chief Executive Officer or the Managing Director. The owner of the strategic plan needs to take complete accountability for its successful delivery and should be incentivised accordingly.
  9. A strategic plan is a “living document”. It should be frequently reviewed to continually refine it. Strategic plans should be “versioned” documents.
  10. Frequent reviews of performance relative to the strategic plan are essential. Every two weeks or monthly sounds about right. I have seen cases where strategic plan performance reviews are done quarterly or biannually … and by the time you work out that delivery is falling behind it may well be too late to affect a recovery.

Saturday, 22 June 2013

What is a Database Migration?

Therefore has recently assisted the Imperial Health Sciences IT Team to perform a database migration from Oracle to DB2 for its SAP system. During the course of the project it struck me that not many folks are familiar with what a database migration entails. The following definition, lifted from Wikipedia, may help. Of course SAP provides many tools to make the process a little less daunting ... but its still one of the scariest things that you can do in the IT space. 

Data migration is the process of transferring data between storage types, formats, or computer systems. Data migration is usually performed programmatically to achieve an automated migration, freeing up human resources from tedious tasks. It is required when organizations or individuals change computer systems or upgrade to new systems, or when systems merge (such as when the organizations that use them undergo a merger or takeover).

To achieve an effective data migration procedure, data on the old system is mapped to the new system providing a design for data extraction and data loading. The design relates old data formats to the new system's formats and requirements. Programmatic data migration may involve many phases but it minimally includes data extraction where data is read from the old system and data loading where data is written to the new system.

If a decision has been made to provide a set input file specification for loading data onto the target system, this allows a pre-load 'data validation' step to be put in place, interrupting the standard ETL process. Such a data validation process can be designed to interrogate the data to be transferred, to ensure that it meets the predefined criteria of the target environment, and the input file specification. An alternative strategy is to have on-the-fly data validation occurring at the point of loading, which can be designed to report on load rejection errors as the load progresses. However, in the event that the extracted and transformed data elements are highly 'integrated' with one another, and the presence of all extracted data in the target system is essential to system functionality, this strategy can have detrimental, and not easily quantifiable effects.

After loading into the new system, results are subjected to data verification to determine whether data was accurately translated, is complete, and supports processes in the new system. During verification, there may be a need for a parallel run of both systems to identify areas of disparity and forestall erroneous data loss.

Automated and manual data cleaning is commonly performed in migration to improve data quality, eliminate redundant or obsolete information, and match the requirements of the new system.

Data migration phases (design, extraction, cleansing, load, verification) for applications of moderate to high complexity are commonly repeated several times before the new system is deployed.