> Product Portfolio > Honeywell Connected Building Solutions - Enterprise IOT
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
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.
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).
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.
Front-end Product Plan for Honeywell Air-Unit Building Solutions
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)
Front-end Project Plan for Honeywell Air-Unit Building Solutions
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.
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
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.
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.
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).
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).
