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.

Change Management, sometimes the underestimated process

How many companies fail because of lack of change management (CM)?

Some of them underestimate it, some others do not know it exist and a big number of them that do not want to pay for it.

This last fact is more common than you think. People see value on a SAP consultant, on a Wintel operator and understand the value they produce, so they are fine paying for them.

I do not know why some people underestimate the value of a change manager and the positive effect it has on the projects. I have the feedback of a client that tells me that the CM activities are responsibility of the project manager; I agree for the small projects this is something that can be delegated on the project manager or the architect, but for complex projects or transitional projects is a key element.

I worked on a project where at the end of the inception phase, once the statement of work and the approach was defined, during the first analysis of required resources, the PM of the client told me that the change manager role was not required, that all in the plan was very clear, that all the milestones and activities where clear, why do we need a CM? Very simple my friend, the development of that complex solution with so many modules, functionality, versions and people involved require to have the right control of the software and the evolution that is having across the project.

IT projects have objectives and they are typically aligned with business objectives. The business projects require a clear management of the changes that the project team or the organization wants to implement. The lack of control of the changes and their measure is one of the most common reasons because a business project is not completed successfully.

On the other side there is other type of project approach where the CM is considered as a key asset during the whole life-cycle. If you read agile principles or SCRUM practices, you will see as there is a clear management of the changes.

I have seen people asking themselves why a project was delayed or over budgeted, with the milestones uncompleted, and in some of these times the lack management of the change is the cause.

Example of lack of governance

We are delivering a new service support where we are facing the same situation:

  • We are doing a great job in number of tickets.
  • We are enhancing the application with little details requested by the customer that is enabling them to spend less time when using the tool.
  • We are not closing all the errors of the application, recurring errors are appearing.
  • We are not taking into account some functionality changes are affecting other parts, provoking new tickets appear.
  • There is not enough control of the scope of the application, even when we have a detailed functional analysis that helped us to close the project in a good way.
  • The complexity of the application makes that the use of the detailed functional document is necessary to perform the changes: and this use is not happening.
  • We are able to close 1000 tickets, but not the application with zero errors.

We are suffering a deep lack of governance. Reasons?

  • Communications at product level are not done in the right way.
  • There is a lack of change management process when a functionality is requested.
  • When a new release of the application is deployed, the documents are not properly updated.
  • Client expectations are so high and they are not being managed in the right way.

 

We have a lot of job to do here,

Accepting that this is a "change"

We are finishing the build phase of a project, starting the test phase of the project and know the client has noticed that there is the need to add a functionality.

We have need one week to let them recognize that this is a change request due to the requirement was out of scope. The formal process has been launched today but I would like to review the emotional process that the client has covered.

First , they was annoyed because the functionality was not there: what’s happen? why the application does not do this?

Second, they have saying, hey just take note of other bug and add to the bug tracking list, so that afternoon they seem to be comfortable.

Third, in the revision meeting we classified this bug as “improvement” and told to them. Again they were upset.

Four, they were reviewing the project plan and the gaps of this in order to suggest how to adapt this plan to add the functionality without affecting the plan. No way, the plan was explained, and that was not the solution.

Fifth , the project manager of the client (that belongs to the IT department of the client) and the main contact of the final client (other department) complaint each other: the first says “there’s no more budget you have to use the application without this functionality…”, the answer is simple “…we are not going to pay nothing and accept any application that does not cover the mentioned functionality”. In summary: stress, displeased…

Sixth, the project manager of the client escalates the situation internally in their department. The action is to request formally an estimation of the required functionality.

All this process has been handled by the analyst that is assisting the test phase, the project manager and myself that have been working very hard the communications (so many hours on phone, in meetings and in the corridor… making the message smoother).

Let’s see how it works, there’s still a lot of things to do.

Funny situation, the queen of ambiguity

This is the excellent e-mail I have received today about a problem of a project:

——————————————–
Hello,

we’ve a big problem with the project XXXX.

In module YYY the basis functionality isn’t covered. The users need the possibility to filter on every field. As John (joapen: John belong to my team no to customer’s team) explained that was part of the query tool (what was cancelled in project definition because of the costs) . For us it was not visible that even this basis functionality was cancelled.

The ZZZ department cannot use the module without this filtering function. We need a solution to solve this issue. As an interim solution we discussed with John to insert the Excel export button in every YYY screen. But we are not sure if this will run fast enough in practice.

Best regards
—————————————————————

Reread the following sentence,

“For us it was not visible that even this basis functionality was cancelled.”

That’s a very good phrase after being 2 months working on a functional analysis specification and a detailed design document. I can remember the person involved in this process investing a lot of hours detailing all activities in detail, with a lot of revisions on site with the client.

And now, during the test phase, we are the ones who are not delivered this functionality.

I love this funny situations, we already have started the change management process.

Change Freeze

This period of inactivity is established to protect the IT infrastructure, application and/or other business activities from any change activity that may undermine its stability and operation.

For instance, during Christmas that there is a lot of staff on holidays and each time more and more companies agree this type of stops.

In addition service providers are happy because they also have fewer problems to achieve SLAs and staff can also enjoy this vacation period.

Everybody knows about this period of inactivity but suddenly they realise that this period is coming and they need to deliver something.

What’s happen then?

There is an avalanche of change requests before Christmas, overloading the change management service.

Impact Analysis

Last week we were doing an internal project assurance on some projects. One of the PM was taking into consideration to show the client the need to perform some changes on the project scope.

To mention these changes was the only thing he got ready for that internal session, previous to the customer meeting.

We were talking about the proposition and the impact that this change had on the project. The PM shouldn’t know why it was necessary, he thought it should be done when the client requests the change.

The theory about change management process talks about some steps on the change management process. In addition our methodology helps us with a proposed form to be filled when this process is launch.

The mistake in this case was that it’s on the clients review meetings where this customer revision is done, and at that event is when you as PM has to get ready all the information related to the change; in order the customer reviews the different options available and the impact on the product and the project.

For me the 4 natural steps for manage a change are:

  • Evaluate the impact of the change, taking into account the triple constraint, the product and the stakeholders.
  • Create options and the consequences of these options and how they affect to concepts mentioned above.
  • Review internally with team and management.
  • Show the proposed change to the customer with the assesment, options, pros, cons…

In addition, if we focus on impact analysis, we can launch the typical questions:

  • What are the implications of the proposed change? On scope, on schedule, on budget, on quality,
  • Is now the appropiate time on the project to perform this proposed change? Early changes are usually cheaper that a change at the end of the project.
  • Which system elements are affected by the proposed change?
  • How this change will be introduced into the project plan?
  • Does this chage affects to project buys?
  • Are all the stakeholders opened to perform this change? what are these consequences?
  • Is really necessary the change? sometimes external factors push us to perform a change and the better option is do nothing.
  • Are the consequences of the change worse than to continue without change?

There are other questions to answer, but these are those which comes to my mind now.

To finish, I would like to remember how important is to perform an accurately communications with respect “changes” on a project. Usually a customer doesn’t want to listen is that there are problems that require changes. Other times, they are provoking the change, but they prefer you perform internal changes that does not imply them. I try to walk carefully on this.

Have a good day!