Can Your Organization Afford Phones That Crash When Dialing 911? A Lesson in Prioritizing Requirements
Recently, reports of some Android-based phones crashing and rebooting when a user dials 911 have surfaced. While OnePlus was the primary target of these reports, similar reports on phones from ASUS, Sony, and even Samsung have surfaced.
First things first: if you are reading this article in the United States, you may not be aware that you can schedule a test call by contacting your local 911 call center via its non-emergency phone number (https://www.911.gov/using911appropriately.html). For our international customers, check with your local telephony expert; in any case, you are advised to confirm that your devices can indeed call emergency services in times of need.
We made an interesting observation that, in Canada – and this is not legal advice – there does not seem to be a legal requirement for cell phone manufacturers to ensure that their cell phones can call 911 without crashing. There is a requirement on the part of the cell phone carriers. If a customer brought his/her own phone to the network (which would be the case for OnePlus 5) and the device failed to dial 911, it is unclear who assumes that liability. Be that as it may, however, it would be much more preferable if all phones can dial 911 when there is a need without concern. It’s a must-have requirement for any phone, not just cell phones.
We advise identifying must-have requirements early on in your projects. Some may originate from the need to comply applicable laws and regulations, some may originate from business needs, or, as in our aforementioned example, some may originate from foreseeable risks. Must-have requirements affect every aspect of a project life cycle:
- During project initiation. High-level scope statement in the project charter points out requirements and constraints.
- During project planning. Requirements gathering process captures must-have requirements, which are translated to line items in quality, risk, communication, and stakeholder management plans. Risk owners are identified. In Agile methodology, must-have requirements can be translated into user stories in the project backlog and the product owner must ensure that they are prioritized in order to ensure their delivery.
- During project execution. Project deliverables are monitored, sufficiently tested, and documented for satisfying the compliance requirements. Changes to must-have requirements must also be monitored and responded to with change requests or backlog maintenance.
- During project closure. Ensure a smooth transition to operation by properly transferring the ownership of the risks to the appropriate operational body that owns the project deliverables.
Requirements gathering is one of the 45 core IT processes that Info-Tech supports. We have a blueprint titled “Build a Strong Approach to Business Requirements Gathering,” and a small enterprise blueprint titled “Survive and Thrive with Effective Requirements Gathering.” For guidance on how requirements gathering fits into project management methodologies, check out our blueprints titled “Tailor Project Management Processes to Fit Your Projects” for Waterfall, and “Implement Agile Practices that Work” for Agile.
Recommendations
- Test your phones to ensure it can dial 911 in case of emergencies.
- Examine your project methodology to ensure that must-have requirements are properly researched and the responsibilities identified.
- Use our Build a Strong Approach to Business Requirements Gathering blueprint for a rigorous examination of your existing requirement gathering process.
- Delegate the ownership of risks and quality items for must-have requirements to reliable members within your team.
Bottom Line
Capture must-have requirements early through best practices in requirements gathering, and stay on top of meeting them through judicious quality and risk management techniques. During project closure, help your operations staff stay on top of them by transferring the knowledge gained.
Want to Know More?
Build a Business-Driven IT Risk Management Program