Infosys Microsoft Alliance and Solutions blog

« September 2013 | Main | December 2013 »

October 31, 2013

Global Implementations & Rollouts: Some best practices -3

Welcome to my third blog on Global Implementation: Best practices. I promise this one would be shorter than the 2 earlier ones.
I was talking on the topic of Development in part 2.

I would like to continue and place a few more best practices which can be adopted so that the development plan & strategy is conducive to program road maps

One of the key factors for development is to have very strong  code configuration & release management  in place. A good practice would be to have a proper CM tool like TFS or VSS for controlling development and creating releases.

Selection of the right configuration tool for application code is a matter of the technology been used and its compatibility with the configuration tool.

Once we have decided on the right tool, we should be aware of the capabilities of the tool so as to be able to harness and use it to the maximum.
There are various capabilities with these CM tools like branching. If we are aware of how we are able to manage the branches we can effectively compress the whole program as well, though this is a totally different topic for discussion.

The development strategy, development plan and the CM tool have a major impact on the program road map which we comprehend only after a lot of effort has been utilized and the first roll out is already done.

My next blog on this series would focus on best practices in testing and the impact of testing on global roll outs.

October 18, 2013

Integrated Vehicle Management App (Part 2)

In continuation to our idea of Integrated Vehicle Management application, where, in Part 1 of this blog we discussed about the options that such an application can provide, let us now look at how do we access the vehicle sensor data in our smart phone application. The pace of technology advancement and its penetration into our lives is ever so fast. Programmable cars look like the next fad for the Automobile industry and we are pretty enthusiastic to have the opportunity to program these cars. "Programmable cars", the industry itself seems huge with many players trying to carve a place as it looks like the next major breakthrough for the Automobile industry.

In continuation to our idea of Integrated Vehicle Management application, where, in Part 1 of this blog we discussed about the options that such an application can provide, let us now look at how do we access the vehicle sensor data in our smart phone application. The pace of technology advancement and its penetration into our lives is ever so fast. Programmable cars look like the next fad for the Automobile industry and we are pretty enthusiastic to have the opportunity to program these cars. "Programmable cars", the industry itself seems huge with many players trying to carve a place as it looks like the next major breakthrough for the Automobile industry. 


The GM SDK specifically provides two types of APIs, Remote APIs and In-Vehicle APIs. Though these APIs are self-explanatory by their names, still speaking in a bit more detail about them, the remote APIs enable a user to connect to his car remotely. He can give a command to his car even from a remote location, for example he can close the doors of his car remotely. The best part of these remote APIs is that they are exposed as REST services and hence can be accessed from any type of application be it W8/WP8/WPF/Android app, anything. Below we have illustrated a scenario using remote APIs.


The in-vehicle APIs allow access to vehicle sensor data to the user seated inside the car. This can be accessed through the app running on the vehicle's head unit. However as the in-vehicle APIs of GM can be accessed only through the head unit, it does not align with our idea of being able to talk to a car using a mobile device. To start using the GM SDK, you need to first register on their developer site. GM also provides an emulator which looks like the head unit of a car. Using the remote APIs provided by GM, we have been successful in our experiment of giving commands to the car to lock its doors remotely. Currently we are waiting on GM to provide more APIs in order to enhance the user experience. Example of one requested API being to enable the user to request for the current door status of a car.
SYNC Applink from Ford
Ford has an existing "SYNC" system is based on voice recognition. Using SYNC, by giving voice commands, the user can make hands-free calls or even listen to his/her favorite music. SYNC Services provide the user with the ability to get turn-by-turn directions through the car's audio system.
SYNC APPLINK is built on top of SYNC and makes use of SYNC services to enable the user to operate mobile apps even while driving and that too without the risk of the user taking his eyes off the road. The mobile apps are operated upon using voice commands and radio buttons on the steering wheel. 2013 Focus, Fiesta, E-series, Expedition, F-150, Super Duty, C-MAX, Fusion and Mustang are few cars that are SYNC AppLink enabled. With respect to smartphone compatibility, here is the list of mobile devices and various applications compatible with SYNC AppLink. New apps are regularly being added to the repository.
Current applications using the Ford SDK are mainly radio/music apps which enable the user to access a radio station app on the smartphone through the car and have the music playing through the car stereo and all this happens through voice commands.
Though Ford does not talk of providing remote APIs for remote access to a car, it has in pipeline APIs which can help the user connect to vehicle sensors through phone and subsequently display the vehicle health on a mobile app. Ford SDK by itself is based on Java.
Having explored some of these SDKs, we hope for more releases with enhanced functionality and also new players from the Automobile Industry to help us turn this idea of Integrated Vehicle Management Application into a reality.

Integrated Vehicle Management App (Part 1)

Now is the era of smart phones and apps that run on them. While doing our own work on Windows Phone 8 we were debating on what kind of application to build. An idea came based on the experience of one our team members. He had recently bought a vehicle and given a 3 months wait period. During these 3 months, he and the dealer had no clue on where the vehicle is and if it will really get delivered in 3 months or earlier or later. What if there was a way to track the status of construction of the vehicle? Similarly what if after purchase we could keep a tab on our vehicle via the application itself? Thus was born the idea of an integrated vehicle management application.

The high level features of the vehicle management applications were thought to be as:
1. Pre-sales: Augmented reality (AR) based display of vehicular details when viewing vehicle from phone's camera
2. Booking: Booking details confirmed from the vendor on the phone app via backend integration of existing dealer management system with our vehicle management server app.
3. Manufacturing: Regular alerts on manufacturing process and the construction stages shown via 3D model of car. Additionally ability to suggest modifications like seat design, interior finish, exterior paint etc. to the OEM 
4. Delivery: Vehicle Readiness for delivery at dealer location notified via app
5. Daily Use: Managing vehicular alerts, vehicular details, Bluetooth connectivity, Insurance management, RTO or any other such vehicle aspects
Let's detail out the features listed above to show the finalized set of requirements with which we have built in the "Vehicle Care" (the name we gave to our app) application.
The journey starts from the moment we go to a dealer/vehicle showroom with intent to purchase a vehicle. We access the "Vehicle Care" app on my smartphone and as we view a car, using the camera of my phone, we can see details of the car augmented onto our phone screen. We can view detailed specs of the car, see any promotional videos and even look up reviews on social networking sites, right from the phone while viewing the car. No need to discuss with a salesman any longer. The app via the augmentation can even display available loan options.

Having finalized the car to buy, next we make a booking with the dealer who confirms the booking in this system. The dealer's dealer management system is configured to then send a message to our server application our mobile number (or any other appropriate field) to identify us. The server passes the booking information to our phone app via notification in a format that our phone app understands. This hence allows our app to remain dealer agnostic and work with any dealer out there.

As part of the booking details, we can view the expected delivery date, delivery status of our vehicle, the dealer details along with a map to guide us with directions to reach the dealer, and other details of the vehicle like engine details and features of the vehicle. Through the app, regular alerts on the manufacturing process are delivered to us and we can view the 3D models of the vehicle as it goes through the various construction stages. We also have the additional ability to suggest modifications like seat design, interior finish, exterior paint etc. to the OEM before the respective stage is crossed. This gives us a sense of ownership of our vehicle much before it is actually delivered to us. Once the vehicle is ready for delivery the dealer informs us through a notification. Using the phone app we can track several bookings made over a period of time and we can also track all the vehicles that we own.

Once the vehicle is delivered, we can now exploit several more features of my app. We can now interact with our vehicle using the app on a daily basis. We configure the phone app to display details of this new vehicle along with all other vehicles that we own and are previously configured with the app. The "Vehicle Care" app helps us care for our vehicle in several ways. Regular alerts are sent to us in advance like for service dates as well as Insurance premium due dates. The app can connect to our car to read the various sensor data like tyre pressure levels/ fuel levels / engine oil levels and all this can is done from within the comfort of our home. We can turn on the AC of my car while approaching it so that We are greeted with a comfortable environment in the car. There is even a facility to remotely lock /unlock the doors or switch on/off the engine of the car using the app.

Typically cars today are equipped with anti-theft alarms, but the challenge say in an apartment complex is that when the alarm sounds off, no one is sure whose car is it? With the app, a alarm sounds off on the phone as well due to direct connectivity between the vehicle and the app. Another possible way to protect the vehicle is the optional alarm that we can configure based on proximity of the phone. The system could be set to sound off an alarm in case the car is switched on and is moving without our phone in blue tooth range. This is optional because we may not be driving the car on a particular day. All in all, the app helps me immensely in managing my vehicle(s).

When we talk of features in a car we can broadly split them into two categories, giving commands to a car remotely and accessing data from the sensors in a car on the smartphone app while being seated inside the car. We came across few players in this field who talk about providing APIs to help us implement our idea. We shall talk about these players in more detail in our next blog.

October 3, 2013

Challanges in a Multi-vendor Project

Over the past 6 years I had the opportunity of working in multi-vendor projects. Apart from the complex nature of projects which is typical of multi-vendor projects, there are business and competitive aspects between vendors which present numerous challenges. This blog tries to analyses the structure of project teams in conjunction with multi-vendor setup and the challenges posed.

Typical parameters I would break this down are:

A. Customer Maturity:

1. Customer is IT mature - in the sense it understands the team dynamics, understands the vendor dynamics, understands and has laid out processes, roles and responsibilities

2. Customer is naive: here, there is not clear definition of roles, responsibilities, the dynamics of teams and vendors in the whole setup. And of course a customer can lie anywhere in this spectrum

B. Teams and their role in the whole project value chain:

1. Multiple vendors providing same value in the project - eg. There are Business Analysts of different vendor doing requirements OR developers of different vendors doing development.

2. Multiple vendors but providing different values in the project - eg. Vendor A is totally taking care of Business Analysis and Vendor B is taking care of development and so on

3. Where one vendor reports to another vendor - Cases where the customer PMO is handled by a vendor and other vendors have to report their statuses to it.

In this discussion, I am not considering independent contractors.

From experience what I have seen as high risk situations are:

Vendor service offerings overlap with each other



Highest Risk

L, H

Medium Risk

H, H


Medium Risk

L, L

Lowest Risk

H, L




Customer Maturity

The typical risks and mitigations in multi-vendor scenarios are:

Sr. No.


Mitigation steps by customers


Teams of different vendors not working in a constructive way - this typically leads to "leg pulling" and "blame-game"

1. Inputs and outputs from a team or team members are clearly defined

2. Include teams in common reviews and handover sessions to ensure all are on page and be specifically monitored by customer manager


Customers having overheads of dealing with the vendors account managers who constantly look for opportunities to expand their portfolio. Here the competing vendors will look for "failures" of others or try to interpret any failures to other teams and try to score from it

1. Do not entertain account managers who frequently present proposals to take over another vendor work. This exercise should be periodic (quarterly or as per budget cycle) and opportunity be given to all vendors.

2. Have periodic reviews (fortnightly or monthly) with account managers on current team project only


Different teams build walls in terms of trainings, ramp-up, hand-over of items etc.

1. Have clear output deliverables defined in handovers, trainings and handover

2. Ensure there is concurrence from receiving team

3. There is clear documentation available for above exercises


Teams covering facts and creating a perception which is not correct. This case is very specific to a scenario where one vendor is in powerful position (eg. of a PMO) and reporting to the customer

1. Have status reports of each team be submitted which should not be tampered by PMO. The PMO status report should be an extract form each of team reports

2. Have a communication channel with each vendor in terms of periodic reviews in presence of PMO. In this case the PMO should not be the anchor for the discussion, either vendor or customer manager should anchor

3. Create another forum of escalation above PMO but below steering committee for the vendors which should address operational issues if PMO is unable to facilitate

Apart from the above steps, in general the softer aspects of team building will always help the project:
- common event celebrations
- team building exercises
- making vendor teams our own - i.e. they should not be referred as vendors but "my team" or "XXX Project team". This will bridge the gap of "us" and "them", not only between customer and vendor but between vendor team members.

Over the next few write-ups, I will try and present some actual project situations where I faced these challenges and cases where our customer project managers effectively mitigated some.

Do share your valuable feedback on the write-up or post any relevant situation from your experience to add to the discussion.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter