Monthly Archives: February 2016

There are no Pit Stops In Enterprise Transformations really ?


IT Transformation , Digital Transformation , Keeping Your Lights ON while you make changes to your bread winner applications in the Enterprise, move certain others to the cloud, rework on your SMAC strategy, going digital, change your tires while your speeding Enterprise needs to overhaul itself at the same time needs to keep moving and least not loose time at a pit stop.While all of these sound easy to write about but when faced with the challenge of turning your enterprise around , you need a mindset, culture , appropriate tools, talented people who understand the nuances of the change , tools required and how to go about it.

Firstly Mindset : You need to know that people need to change the way they think about the they are standing on a burning bridge with water beneath if you were to borrow a line from the Nokia chief’s mail to its employees. Unless people perceive it this way change is difficult to force it down their throats. Fluidity in all process and people boundaries such that people can reach out and interact with folks across their immediate process lines. This needs a mindset change which can happen when their is strong management support towards moving away from silos and encouraging decentralization.

Be Proactive ALWAYS – Look at the windscreen and not often at the rear view mirror

Usual mindset is look at time, money , resources and progress once you have finished your product or solution. Instead create a pro active process measurement and improvement dashboard where you are measuring everything while moving instead of reflecting when it is all over. This is process independent and no matter which agile methodology you use or which project / process framework you are currently executing. The idea to embed metrics in your journey can be right from the beginning where you look at

1. Review all internal process.

2. Requirements stability

3. Change Management processes

4. Your speed of execution , ability to close projects / activities within time and budget.

5. What market forces are currently influencing your product / solution.

Once you start improving these factors then your outcomes or business results follow on account of these steps or measures.

Tools at the Pitstop

One of the ways to capture these would be to implement a balanced scorecard.

Digital flexibility: 

This key skill would mean how often are you ready to change gears midway and skill / re-skill yourselves when you hit transformation roadblocks.

Integrated Operations data : Ability to respond to complex process data and act on them in real time when transformation is underway.

Experimentation and POC hotbeds : Ability to rapidly experiment test beds where simultaneous low cost fail fast experiments and proof of concepts can be carried out and more importantly reduce the cost of failure.

Data driven decision making : Put check and capture data of all kinds which can be useful to driving change and arrive at decision based on those.

Eliminate , Eliminate all kinds of communication barriers across teams. How do you stop one . Meet review and action on the points that are found as causing delays. Delays can be anything from waiting for snacks in queue in the evening to not getting appropriate sign-offs in time. Teams working on agile communicating with non agile or semi agile waterfall teams can slow things down. Use your own process tailoring to get across these barriers.

Promote quicker decision making using the following concept decentralize implementation and centralize interoperability

Wiping the dust off the screen , spare tires and everything in between.Re work on your strategy when there is a downtime .

What to do when others are racing as hard as you as well.

1. Remember what you are transforming is not only a technology issue and see it is as a business problem and technology is a leverage. Most often companies do not learn

2.  Always eat a part of the pie instead of full fledged transformation on all cylinders. It is nice to say we are changing the whole machinery while the vehicle is moving instead it is better to change the parts one at a time. It is not easy in a large transformation program but things become much easy to test waters when strategy is broken down to segment and then to the solution level. Let’s say 5 competing product lines are ready for transformation and then out of them only 3 are handpicked for transformation , then out of these 3 pick 10 % functionality and iterate and continue this till you can increase your velocity.

3. Get people to meet the change agents often instead of hanging organization change mandates across the hallway, coffee stations , places where your resources spend most time. Else they end up being fodder for light banter during coffee breaks. Strategy should be de-centralized and no one person’s or team’s prerogative to succeed. And communicate , live them day in and day out instead of them being poster board material.

4. Setup innovation and design thinking workshops across the length and breadth of the organization for people to go about doing there jobs with more fun and independence at what they are doing. Do this when during happy days and not so happy days in the company. Make this part of your core routines then it becomes easy to flex think and act nimble.

This is not the full list of course would love to hear from you on what points went to your refueling enterprise journeys.

Image credit : pixabay

Applying Design Thinking for Product Rollouts.


All companies have a lot of issues /problem with their product roll-outs or solution delivery mechanisms. Let’s look at how product roll-out issues can be addressed and how design thinking can be used at various stages to help it get to a well-oiled devops machinery where roll-outs are just another day to day affair.

The old school way of approaching to solve would be to define the problem and then try and solve it. Identify what the problem is and then solve it as it is said “A problem identified and defined in most certainly problem solved”.

What does Design thinking tell us? There is no one way of defining a problem and it needs to be looked at its entirety in the complete ecosystem that it manifests or resides and offer holistic solutions around that. It is multi-pronged approach as opposed to find it define it fix it and get over with it. The earlier approach involves straight jacketing the problem into a pre-defined way and then narrows the team into thinking it is limited in its scope and offer solutions around them. This is the reason why solutions although can be cleared off a product management bug tracking list shall not wow the customer or help create awesome products in future.

Learn from anyone and everyone involved in the product roll-out

Whom to involve in this process to get a full rounded perspective of everything that this issue stands for. Since the above one is related to product install and deploy the below mentioned folks can be looked at for brain storming sessions. Involve people from engineering, architecture and also include/take his opinion the courier boy who delivers the tape cut to the deployment folks as well if it applies to your scenario. Involve everyone related and not related as well idea there are no stupid ideas only things that we learn from.

Product managers , domain experts ,developers,architects,QA team, release team, actual users on location, customer end points, production sites at site remote local global and involved in deployment and rolling out patches. Talk to everyone and anyone who could be remotely connected to the issue and whose perspectives can help.

Empathize with team involved in roll-outs, internal and external

Many have pain points , bad UI experience many have database issues, script issues and so on, some of the install tool features need a UI training and are not intuitive enough, some have pre install / post deployment issues, in short it not how the user would have liked to use and see them done.

How can design thinking help here?

To arrive at what can iron out the pain points ask the following questions

  1. What is ? Product roll-outs what is it
  2. What if ? What if we can bundled it all in one piece.
  3. What wows ? One click end to end install – Ideal State
  4. What works ? What is doable in this quarter ?

Define what issues are there in your product roll-out

Let’s say you have all these problems / issues laundry list with you. Now your next level of brainstorming would be to create options or alternatives on how you can make the world a better place for the customer by ticking the bucket list of issues with alternative solutions. There could be more than one alternative for an issue.

Ideate around the various approaches

For an easy and effortless deployment / install of the product pain point, the solutions / alternatives could be as follows

  1. One click install which will explode the entire product in the relevant tree / directory structure.
  1. Create a single war / tar of your product directory.
  1. Pre-populate all your static data in configuration files and provisions to load them into the database during install.
  1. Auto run all the initial SQL seed data by means of a trigger or stored procedure.

Now we see all of the above can be the options for solving one pain point which came out when we created our laundry list. Ideally this can happen as a result of having a design thinking workshop or huddle where one and all concerned are invited and stick their pain points around post it notes.

Now the most important points while tailoring solutions under the context and culture of the end user/customer/roll-out team that you are trying to solve the problem for and more importantly EMPHATHIZE with them. What works best is think you are the one who will actually be using the system. Drive this mind-set in the team. When a group of people think on these lines you shall be amazed at the perspectives that come out. Before you lose all these different suggestions click the post it notes on the whiteboard with a camera and save it for consumption as and when you need refocus on the issues.

All of this produces qualitative data which can then be used to arrive at stories.

Capturing Product Roll-out Stories

Document scenarios where roll-outs have failed and under what conditions and complete the story board with who the actors involved were.

For example the roll-out happened when most of the support staff was on party etc.

Roll-out was not complete as the sys ops person did not have enough admin rights to restore the tape etc.

Weed Out / Flush your Idea board

Weed out ideas from your idea board that lack a wow factor and concentrate only on the top 5 or 6 concerns to start with.

Rapid Prototyping

Row towards the shore like you’re going to run out of fuel anytime and eventually focus your efforts towards building a working model.

Create solutions / stories on which of these solutions shall you apply in create hot beds to prototype solutions around them. Create quick and rapid prototypes of the solutions where it is easy to turnaround if things do not go around fine. Look for the ones which results in a compelling experience.

Test out your prototypes in the Real world

Run the prototypes through multiple test beds and more so in the real production scenarios and quickly run through the results by eliciting feedback with the larger team. Refine Refine Refine and put the feedback /results into the product effectively and action them till you have a product that resonates with the customer well.

Have a product that people fall in love with instead of creating just another product for people.