Discovery

Background

What is an SOP?

A standard operating procedure (SOP) is a text document that describes:

• A situation, such as smoke detector alarm going off.
• The solution describing how the reader should handle the situation, such as Check if there is a fire > Call the fire department.

Security managers write SOPs to make sure all operators handle each situation that comes up in a consistent manner and in compliance with the law.

Business Problem

I identified the following business problems.

• Lack of Control for Security Managers
  Security managers are not in control with the current SOP system.
• Not Contextual
  Long documents make it hard for the operators to find what they need to do in case of an emergency and often end up being not used by the Control Center team. This may cost lives and/or money.
• No Due Diligence
  Even if an operator is acting according to the procedure, there is no record of when he did something and what he did. This information is required for post-event reporting, improvements and in case there is a lawsuit.

Suggested Solution

I proposed a solution comprising the following functionalities.

• More Control for Security Managers
  Provide more control to security managers by using the digitized standard operating procedures (SOPs) and including information about managing complex workflows to ensure regulations compliance.
• Trigger Based on Rules
  Enable (rules-based) triggering of the relevant section of the SOPs in the Operator Console.
• Action Tracking
  Allow tracking and time stamping of the actions completed by the system and the operator.
• Automated or Semi-Automated Actions
  Allow automated or semi-automated actions to save time. Rules can trigger actions either automatically (such as sound an alarm when the fire detector identifies smoke in the building) or based on the feedback from the users (such as call a number selected by the user from a list).

UX Concept

Main Flows

I created user flow wireframes using PowerMockup.
Click image to enlarge.

Figure 4: Flow in Wireframes

Getting Buy-in

I completed the above stages when my boss, the CEO, was away for two weeks visiting customers. When he came back, I showed him the concept and user flows.
He agreed that this editor would bring great value to the customers, and it supports his long-term vision for the Control Center solution. However, it was clear that the development of the complete solution will take more development resources than what we could spare as a start-up with a limited development team.

Prioritizing Requirements

Challenge 2

I had to prioritize the work based on the limited development team available to work on this project. I had five front-end developers and two back-end developers for a one-month development project.

Solution

I summarized all the requirements and priorities using a product map. After we presented the business logic and main flows to the Development team, they felt obligated to the project.
Based on my research and development complexity estimates, I prioritized the features and selected which features should be developed first and which should be developed later.

Features by Priority and Effort

Figure 6: Product Map Based on Priority and Development Complexity

Deployment