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.

2. Create a single war / tar of your product directory.

3. Pre-populate all your static data in configuration files and provisions to load them into the database during install.

4. 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.

Baseline as per the wikipedia is an agreed description of the attributes of a product, at a point in time, which serves as a basis for defining change.

Most of us can relate to that statement which means the product or solution has come to a certain maturity in abstraction of its features and now you can call that a baseline. Some companies work a great deal to arrive at a baseline which is what they have worked over months , years to finally arrive at one milestone in their journey and call it the baseline. Now the title is why do some companies decide to throw it away. We shall see how and why this happens ?

Togaf has a concept of going about iterations on how you can go from one state to another in your organization transformation journey. There is a baseline first and target first approach when you go about iterating across its phases for architecture development.

Baseline First : Firstly you go about considering the edifice for building future work is your current baseline and then it becomes the starting point for doing any work henceforth. What this means is that you as an organization has significant has accumulated a lot of collective knowledge and arrived at the baseline which is still relevant and useful in going about the organization churns.Lets say you are a n oil and gas major and all the data models,process workflows,architecture documents ( business,data,application and technology) are at a point where they need further pruning and tailoring to meet the new market realities. And hence any work that you do keeping this as the basis will end up being called as baseline first approach.

Target First Approach : With disruption in every industry at times your baseline becomes completing irrelevant and new forms of transacting , doing business gets precedence. Examples of this would be Banking industry being caught in the wallet war from google,apple etal and further danger from the block chain , bitcoin and newer forms of currency exchange without the middleman. When this is more true for your current state then the baseline or the accumulated knowledge in the organization is found to be not very useful to go ahead with the organization transitions.

In reality this is not very true as there could be pockets sometimes huge areas of the existing knowledge base that can be turned / fine tuned to better meet market or product relevancy in the market. In the case of bitcoin based transactions disrupting banking for example the banking fundamentals such as credit / debit still would remain the same. But again it is upto the organization to see what parts of the baseline is relevant in your journey and then use it to your advantage. This needs good brain storming withing the company weighing the pros and cons and then take it forward.

What’s true in practice

Reminded of a joke that was going on in a company .They estimated that they would need a 100 developers working on the baseline for about 1.5 years to overhaul the product and make it market ready then there was a side remark saying give us 30 developers “throw away your baseline and we’ll rewrite the product afresh in six months.

So the fact of the matter is throw parts of your baseline away where it makes sense keep the ones that aid your transformation. This needs sound existing knowledge of your baseline and also where you want to go. Many organization find this to the biggest challenge “Where are we going and how ?”

Having the clarity of baseline first and target first approach helps …..

Would love to hear from you on what occasions did you have to chuck away your baseline if not great. If so how much of it was throw away and what portions could you keep ?

Image Credit : https://www.flickr.com/photos/strelka/

Was at the open group conference at Bangalore and spoke on “Enterprise Architecture and Keeping your business relevant”. Was off to native and could manage to attend the second day of the conference at Phillips Innovation Campus.

Initial Talk was by Jason Uppal on how EA was used to solve problems in the heath care industry and his experience in the same with some case studies.

Some interesting perspectives on initiatives from the Open Group to take Togaf body of knowledge to colleges along with Computer Society of India and an effort to popularize it apart from being used by the industry alone.India ranks third in the list of Togaf certified candidates and increasing year on year. This was briefed by James of the Open Group.

EA and the Developing World

Far away countries such as Finland and Brunei are also adopting Togaf and there is growing list of developing countries such as Mongolia  which also is adopting Togaf for overall streaming lining of IT services. This was presented by Vish Vishwanath of CC and C solutions.He also walked through the penetration of EA in these markets and how EA can significantly be used to solve newer technology adoption issues. Developing countries will have to go through the same curve where EA can play a good role in packaging and getting your business / IT strategy right. This market is hugely untapped and really be a good case in point to explore and would most likely a candidate where future success stories would be crafted. 

Keeping Your Product/Solution Relevant

Spoke on using EA to help keeping the business relevant. Touched upon how a reference architecture helps create a north star to follow. How a large company can stay agile and make quick turn around as it is said making “Making an Elephant Dance”. Most large corporations are now focusing on learning this key skill. Gave a brief presentation with 18 list of TODO’s for a company (product/solution). Irrespective of the size of the company the ability to dance to various market and customer tunes is what helps it stay on top of the curve. The presentation details are shared here. All of the slides have 18 TODOs listed ( in no specific order ) and each category needs a deep dive into what can fit well for an organization specific context. Overall a handpicked set of initiatives that help a product or a solution to be relevant in today’s times. Even implementing a few of these initiatives to a reasonable degree of seriousness can create the hockey stick effect on your annual performance report , which is the last slide of the presentation. 

Commoditization of EA

That apart there was a talk on how EA is being packaged and off shored an IBM perspective by Sreekanth. This dealt with the issues of putting solution architecture work miles away from where it is being consumed and how technology has progressed in making this happen. How customer’s are now adopting this mode of delivery and look forward to having a robust process framework around this to help with getting predictable and estimates for the same. Ideally they would like to have better control on the work pieces assigned to the team off shored to and be able to estimate and bill accordingly. As a lot of things are new on this front as always it takes sometime to stabilize things on this front. Have come across SAP and other vendors opting for a packaged implementation points sort of a things which is like a work break down structure for your activity at customer location. World is indeed getting flat including off shoring innovation work  till the point that you are not sure your idea is going to fly. In which case more clarity emerges and all trial and product pivoting also is getting off shored.

There was a talk by Hari from TCS on a case study of who they used Archiemate to map customer requirements and showcase value to the customer end user on use of the same. This is a neat initiative that is picking up momentum on tying together business and IT together. UML is for techies and not all business nuances can be conveyed using the same. The business folks are not UML friendly and a free format diagramming visual standard such Archiemate is useful in helping bridging the gap between the two.

Disconnect between Archiemate and Togaf : For people entirely new to these they need to be treated separately and does not pose a problem. For folks coming from the Togaf world there seems to be a missing perspective ( data ) which archiemate has across all the layers and gives primary prominence to Business , Application and Technology at least in the views. The data part of the details are implicit across the visual representation of Archiemate and quite embedded as a part of Business , Application and Technology instead of being treated separate. Quite understandable as bringing data architecture at a overview level can pose the trees get coverage instead of the forest. Anyway it is a step to bridge the divide between business and IT. Have heard about how this standard is helping many approach architecture diagrams without being overwhelmed at the outset with semantics of the new standard or other intricacies of UML which for a person from the business would be hard to scale upto. Certain regions have a good adoption of this standard and certain countries are ok with BPMN / UML or arbitary or No UML as it is referred to where every organization creates a standard that suits its needs the best with legends etc.

A weekend well spent discussing things that matter and can change lives and our part in the same.Attending conferences always keeps you relevant and of course helps one in keeping abreast of what is happening around.

]]> https://sairam.eturnti.com/open-group-conference-2014-bangalore-where-is-ea-now/feed/ 0