Product Portfolio  >  Honeywell Connected Building Solutions - Enterprise IOT

Honeywell_home-hero copy.jpg

This page is under construction and the new page will be live soon.  For now, you may refer this for it's content.

Honeywell building solutions deals with all IOT enterprise products related to setting up corporate and factory equipments like air equipments, light equipments, central electric equipments, etc.  And all of these are billed with Point : Asset ratio to the client.  Which mean each and every asset (air-conditioning unit, etc.) have points (on point, temperature regulator point, electric pass point, etc.) attached to it, which is regulated through a centralised digital system solution.

Product Role:  DesignOps, UX Lead

Members Involved:  Ben Coleman (Business Head),  Liana Kiff (CSO),  Roshan Valder (UX Lead),  Tanya Mahajan (UX Designer),  Aaron D'souza (Back-end Architect) and Others [from Business, design and tech side]

Please NOTE: The purpose of this is purely to showcase portfolio.  And by looking further down, you agree to Non-Disclosure agreement stated at the footer

Context for revamping Honeywell Connected Building Solutions

honeywell01_scope.jpg

Scope

Honeywell Building solutions had bits and pieces of product solutions which were not connected to each other.  The primary idea of connected solutions were to connect all the product solutions within single umbrella.

Connection of all the IOT products within one umbrella requires further modification on the digital regulatory system.

Challenges

Changing/ revamping a legacy system comes with it's own set of challenges:

Users:  The field engineers who installs such system and then the system administrators who runs these installed system will have to learn a new process altogether and currently it takes a whooping 30 days to install a solution within current ecosystem.

Legacy improvement halt:  With IOT products, the SLA time for customer request resolution is too less, since it incurs cost.  Revamping the solution, means halting the legacy improvement to avoid talent wastage, which in turn increases customer grievances.

Business Stakeholders Mapping:  Mapping of different stakeholders at different sprints is ideally impossible to achieve, with a fixed product development timeline.

honeywell01_challenges.jpg
honeywell01_challenge-redressal.jpg

Challenge Redressal

The solution for following challenges have been suggested to the business owners and taken a grant on :

Users:  The users will be involved in from the grievance accumulation to testing of interactive wireframes.  Which will provide them 'while development training' and assurance for the 'good change'.  This in turn will also help the product to be better, since it includes the users in real time.  The 30 days installation time needs to be cut at-least to 10 days (since the retention rate decreases from prospects post 15 days).

Legacy improvement halt:  The current SLA for solution is 2 months.  Only high priority grievances will be addressed for 2 months.  More talents will be hired on contract to complete the project within a maximum of 3 months time.

Business Stakeholders Mapping:  A proper sprint have been planned and all the stakeholder meeting time have been scheduled prior to 3 months.  In case of non attendance, the next in line team member need to join in.  In case of government announced holidays, the meetings will happen office off-hours which will be compensated in an hourly basis.

Front-end Product Plan for Honeywell Connected Building Solutions

Problem Statement and Stakeholder Mapping

Each and every bits and pieces of solutions (for instance, lighting, fire alarm, etc.) comes with it's own set of rules and problems to be connected with other solutions.  The stakeholders have been mapped accordingly to analyse the possible connection channels through assets (if possible) or through equipments (if not possible through assets).

honeywell01_problem-statement-and-stakeh
honeywell02_understanding-the-current-sy

Understanding the Current System

When it comes to IOT legacy system, any suggestion for change comes with a host of constrains (from tech, business and feasibility aspects).  Understanding the current system and finding out the loopholes or issue pointers within the system is much efficient than starting without a thought from the BRD (Business Requirement Document).

Product Ownership Segregation

The Honeywell building solutions had seven primary components of solutions (as in, Air unit, Fire unit, Camera unit, etc.).  In the interest of time, the units' ownership have been divided to separate teams.

honeywell02_product-ownership-segregatio

Front-end Product Plan for Honeywell Air-Unit Building Solutions

honeywell03_system-kt.jpg

System KT

Air-Unit division works with few primary elements.  Namely in a hierarchical manner as Sites, Buildings, Floors, Equipments, Assets, Points.

The phase of installation happens in two phases: pre-op and post-op.

Pre-op involves field billing teams and equipment testers.

Post-op involves field engineers and QA.

Post installation, admin and QA are involved in the process (one site usually have one engineer and grievance redressal officer in the field all the time).

Product Roadmap (suggested)

Creating SOP for all the services (in parallel)

Creating PRD for the UX and Development (in parallel)

Wireframes for Business Stakeholders

Test interactive prototypes with Field Engineers

Upon 80% success rate on prototype, move to VD with suggested changes (Honeywell design guideline)

Post VD test again with the Field Engineers on increase in time efficiency

Add all the error states

Analyse the Cost of Mistakes

Forward PRD and Interactive Product Guide to the dev team (most of them are full-scale developers)

Follow up based on dev sprint

5 mins stand-up everyday and weekly stakeholder meetings for the updates on sprint

Move to QA

Iterations (with prioritisation - based on 'cost of mistake': feature charge sheet

Final test with field engineers

Showcase to the higher management

Iterations & test

Release date announcement

Bond test

Release (Training to field stakeholders and delivery of SOPs)

honeywell03_product-roadmap-suggested.jp

Front-end Project Plan for Honeywell Air-Unit Building Solutions

honeywell04_timeline.jpg

Timeline

The total available working days were (65 days x 8) = 520 hours.

The completion for front-end of the project will take 6240 man hours (as per project head projection), excluding the approval cycle.

The budget has been managed by the project managers (which was not to be disclosed).

Based on that, contractors have been hired to complete the project on time.  The contractors included product and UX managers, Visual designers, front-end developers, and back-end architects.

Talents

Changing/ revamping a legacy system comes with it's own set of challenges:

Users:  The field engineers who installs such system and then the system administrators who runs these installed system will have to learn a new process altogether.

Legacy improvement halt:  With IOT products, the SLA time for customer request resolution is too less, since it incurs cost.  Revamping the solution, means halting the legacy improvement to avoid talent wastage, which in turn increases customer grievances.

Business Stakeholders Mapping:  Mapping of different stakeholders at different sprints is ideally impossible to achieve, with a fixed product development timeline.

honeywell04_talents.jpg
honeywell04_gantt-chart.jpg

Gantt Chart

The roadmaps have been presented to the higher management within gantt chart alongside sprint details (milestone reviews and goals).

The decided number of sprints were 13 sprints (each sprint consisting of 5 working days).

The overlap of product team and tech team starts only post 3rd sprint solely assigned for product.

Agile and Execution for Honeywell Air-Unit Building Solutions

SOPs (in parallel)

Standard Operating Procedures for IOT product (mostly with safety solutions such as building) plays an integral part since it's a combination of digital, physical material and field manpower effort for overall success of the product.  The SOPs have been broadly divided into five categories

Digi Product Development

Material

Manpower

Grievance Redressal

Emergency Handling

honeywell05_sops-in-parallel.jpg
honeywell05_prd-in-parallel.jpg

PRD (in parallel)

The PRD forms  a part of digi product (while the product is still in a feasible development stage).  It includes a part of BRD and tech requirement including the UI.

Wireframes (+IA) for Business Stakeholders

The IA flow with post its (bucketing as per EPIC stories) have been presented to the business stakeholders as per heuristics and UX expert suggestions.

honeywell05_wireframes-for-business-stak
honeywell05_ut-with-field-engineers.jpg

UT with Field Engineers

Later, an interactive prototype have been presented to 5 of the field engineers of different states (considering linguistic differentiations).

• Screen sharing remote testing

• Volunteers were requested to 'speak out loud on their actions'

• Each of them have been provided with similar 5 user tasks to complete (which forms part of the EPIC stories)

• They have been tested twice in a day after a break with the same user task to check accurate efficiency in performing task (since for enterprise products, first test always takes more time than real time use)

• The metrics involved cutting short the installation process SLA from 30 days to  10 days (while automating every possible system). 8 hours through the digital products.

VD

Post UT and iterations on the hypothesis based on analysation, the product has been transferred to Visual team to standardise the elements as per Honeywell design system.  The average digital installation time recorded in the UT turned out to be 8.5 hours.  The enhanced VD was expected to bring it down below 8 hours.

honeywell05_vd.jpg
honeywell05_final-prd-and-dev-sprint.jpg

Final PRD and Dev Sprint

Post VD and PRD with all the Coverage Matrix, Feature List (with error states), Cost of Mistakes (prioritised for each and every features) + all the business and user use cases have been shared with the dev team's scrum master to organise within their sprint plan.  While rest of the low priority journeys are in their way for design as per design sprint.  The ideal day during this phase seemed something like this:

• Attain the Product and Design team Stand-up

• Review the weekly sprint VD releases with Business team (move it to iteration phase or pass it to dev team)

• Attain the dev team Stand-up

• Review the weekly sprint dev releases with Business team (move it to iteration phase or pass it to QA and sales team for review and plan for release)

QA and BOND Test

In Honeywell, QA forms an integral part since most of the product have greater safety risk if there's any kind of product mistake.  Thus in such a case, cost of mistake of the overall product is predictably too high.  To reduce the mistake rates, QA team plays an important role.  And each and everything needs to have a final scrutiny pass from the QA team, who looks through all the possible use cases (whether included within the PRD or not) and then test all those use cases.  Post which it moves to the iterations or business owners note (to release).

honeywell05_qa-and-bond-test.jpg

Conclusion, Release and Metrics

Post approval from all the stakeholders (including bottom-level users: Field Engineers), it moves to the sales team for release date announcement.  Here are the calculated metrics:

• The installation cycle time reduced to 36 days from 56 days

• The reduction of installation time became an USP to on-board 3 more prospects

• There were no release made to the product team on the revenue increase (but it was shared that the change increased 20% cost-effective revenue for the first month post release)

• The click-through analytics implementation on the features helped in reducing customer grievances to the Call Centres to almost 45% for the second month post release (this was done through UX study on the analytics analysation on a weekly basis and solving it within another dev sprint and released as bug-fixes).

honeywell05_conclusion-release-metrics.j