100 days plan for strategic alignment

I was recently asked about how to plan an strategic alignment between business and IT initiatives, where there should be a focus on the:

  • Follow-up and efficiency of projects initiatives.
  • Track of benefits realization.
  • Portfolio plan where we all can understand the dependencies of the IT projects and impacts on business.
  • Improve the level of knowledge of project managers.

My approach for this situation to define a set of actions at different levels:

  • Strategic level: define vision, values, methods, objective and measures.
  • Tactic level: define specific actions by area.
  • Operational level: work on existing processes, put in place changes to them, increase the efficiency.
  • Communicate, communicate, communicate.
  • The methodology I would apply: Lean Six Sigma.

The summary of activities for the 100 days is:

  • Day 1 – Let us be Honest
  • Day 2 to Day 20  – Map it!
  • Day 21 to Day 40 – Analyse & challenge
  • Day 41 to Day 60 – Doctrine
  • Day 61 to Day 80 – Flow
  • Day 81 to Day 100 – Keep it steady

Let’s explain a little bit these steps:

Day 1 – Let us be Honest

  • Describe the main pain points of the organization, areas where the communications are not good…
  • Imagine the organization you would like to have: how the behavior should be, how the communications should be, what is the way IT should behave to satisfy the goals of the business, how business should behave to explain what they need to IT…
  • Define KPIs  and targets to these KPIs, so we can see how we evolve.
  • Prepare a specific speech for each set of stakeholders about goals and benefits of your plan. The benefits of this speech have to be linked to the needs of the audience.
  • Then communicate, communicate, communicate…

100-days-strategy-plan-1Day 2 to Day 20  – Map it!

  • Draw the current situation you have on your systems.
  • Discover with the different business units, how they are organized,
  • Discover with IT what are the main IT assets, what are the projects on-going, and
  • Capture a snapshot of the projects under execution and forecasted initiatives.
  • Define a list of stakeholders.
  • Start to draw a RACI chart with the main areas of work.
  • Communicate, communicate, communicate…

Value-chain-mapping-ecosystems-CIODay 21 to Day 40 – Analyze & challenge

  • It’s time to take the maps and draw more specific maps or diagrams about how the things are done.
  • The diagrams have to be shared with the others, so people understand how things work (they are so useful, I have seen so much difference between how thinks work and how people believe that it works).
  • Challenge to the people who owns a process to change/improve it: let’s run to simplicity!!!
  • Identify duplication: they are there. Then remove it.
  • Generate a common nomenclature that improve communications.
  • Identify the hurdles and specific pain points the organization have. Analyze the impact on the organization.
  • Deliver specific presentations to the different business departments and units with the specific actions to be done (action oriented & focus on their scope).
  • For a business unit of a country, it should include the actions, the list of projects and the targets we have.
  • For a global stakeholders, the report should include data at its level. It also should include the conflicts identified
  • Communicate, communicate, communicate.

Day 41 to Day 60 – Doctrine

  • You already have improved the situational awareness of the organization.
  • Remove identified duplication of whatever you found.
  • Work on the 20% more important pain points you have identified.
  • Refine the ITIL processes, refine the RACI,
  • Review the main IT projects.
  • Launch with HR a training plan for PMs, so they can improve their skills.
  • Mentor the PMs.
  • Update with PMs the portfolio schedule: analyze the delays and their impacts, get the commitment of the delivery.
  • And communicate, communicate, communicate: different stakeholders, different presentations.

Day 61 to Day 80 – Flow

  • IT have their own flow: work on the existing projects, services…
  • Business have their own intertia too.
  • Push that this inertia goes where we all want to go.
  • Understand that from IT we have a clear map about where we want to go technologically.
  • Understand what are the future business challenges that business unit has. Force them to define it, help them to do it through business cases, impact analysis, proof of concepts…
  • The reports needs to link the capabilities provided by the projects with the business capabilities the BU requires or needs to improve. Define in a measurable way the benefits. Typically the BPO owns the responsibility to measure the benefit.

Day 81 to Day 100 – Keep it steady

  • You’re now ready to start examining structure, mechanisms of learning and the principles of strategic play.
  • The maps will also help you identify where to attack along with where to gamble with respect competition.
  • You have a list of pain points you have to work on.
  • You have a list of KPIs and data about how it was done during these first 100 days.
  • You have a portfolio schedule with linked initiatives.
  • You have a detailed RACI with actions and new responsibilities for the organization.
  • Follow-up the benefits realization of the projects.
  • You have a more or less defined road-map of the business unit needs.
  • You are discussing all the specific aspects with the specific stakeholders: action oriented, please, focus on actions.

Process-improvement-Dashboard-calendarWhat happens after the 100 days?

Ideally, you can do all this in a quarter, and after that repeat in the next quarter, so you are aligned with business changes, and you can also stop and gain perspective every 3 months. Do not lose perspective: the strategy needs to be review and aligned with the changes.

The approach during the second and other coming quarters have to be different. You can define:

  • Weekly calls for operational aspects: issues, actions…
  • Monthly calls: for project reviews, business unit reviews and tactic actions.
  • quarterly calls: for business review at high level.

Retail, some basic lessons I learned

Based on a SAP platform, some basic lessons I learned about retail.

The stores:

  • The POS are terminals that retrieve data from a server, typically located on the same store.
  • The server of the store receives/sends data to a SAP PI.
  • The frequency of these communications depends on your capacity to manage big volumes of data.
  • The technology on the store can be independent to SAP. SAP PI will send the appropriate data format.

ERP

  • The Origin of all data comes from ERP, specially from SAP SD (sales & distribution).
  • SAP Retail will gather the detailed data that goes and come to the POS servers.
  • SAP Retail have all detailed data. The quality and the granularity of the data will determine the ability to posterior data mining actions.
  • Typical problems of SAP Retail are: communications, and reporting (have the ability to gather the required data in terms of volume or detail).
  • The management of promotions and affiliations is other major topic on the processes.
  • To simplify the data complexity, SAP Retail sends the data to SAP SD taking into account that each store is a single customer.
  • Affiliated people can be on a CRM or on SAP SD.
  • SAP PI sends/receives data and transforms it into the right formats. This enable the integration with different POS vendors.

Data mining:

  • For high levels of detailed data: retrieve it from SAP Retail. SAP HANA is not enough for handling big volumes of data. Hadoop is the preferable solution for these big volumes.
  • For detailed data: retrieve it from SAP SD.
  • For generic data: retrieve it from SAP FICO.
  • A serious BW retrieves data from SAP Retail.

Real time & transactions:

  • Frequency of transactions between POS and SAP can be complex when you have so many terminals.
  • The need to increase this frequency can stress the architecture and force changes at that level.
  • The demand of data miners and the need to act on prices at the end of the day depending on the consumption trends can be something complex if the architecture is not well implemented.
  • Majority of transactions are done during the night, but it could be different.