What Your NG9-1-1 RFP Should Include (And a Couple Things It Shouldn’t)

As a technology vendor and a division of an engineering consulting firm, the DATAMARK team at Michael Baker International has plenty of experience with RFPs from local, county and state governments, as well as the federal government.

Most RFPs provide a very detailed list of what to include and not to include, along with the obligatory statement about the problem to be solved. I say obligatory because “the why” – the reason for the RFP – is often treated as an afterthought when it really should be the main theme. More often than not, the problem isn’t presented in a way that’s most useful and the right questions aren’t being asked. And the outcome? Well, the outcome is a project that meets a scope of work rather than what’s truly needed.

As service and solution providers we know this, but it came to light again in a recent LinkedIn article from Scott Porter, Chief Information Office for the Los Angeles Fire Department. In his article, “Top Three Reasons Your RFP Sucks!” he notes that the public sector should stop telling vendors how something should be done and focus on the problem that needs solving and/or the outcome to achieve.

And we agree. The process proposed by Mr. Porter is more likely to garner the right solution for the problem.

So, rather than wondering why government agencies struggle with their RFPs, we’re offering a list of some things that should always be included in an RFP for an NG9-1-1 solution:

The DATAMARK team is in the business of meeting the challenges of evolving public safety 9-1-1 technology and the eventual overhaul of legacy systems with NG9-1-1, and one of the first steps is having a great RFP.

We’re also helping the industry in its move to NG9-1-1 through the services and solutions we provide, and – very importantly – through education. Check back on our blog often to learn more.

BY DATAMARK / June 28, 2018

Share on Facebook Share on Twitter Share on LinkedIn

Contact Us