The Way I Evaluate Requests

…or Why I’m a Buzz-kill.

————–

Recently, a system administrator acquaintance was asked to add a bar code to attendee badges for their big meeting.

They wanted to collect information on which sessions people attended during their conference.

On the surface, seems simple.

Change the badge report within the system to add a bar code.  Maybe with a little fiddling to make it pretty.

The system administrator figured he could quickly knock up a report that showed the collected information.

He also figured the vendor already had a solution available.  Especially since many conferences now use bar-code or QR code scanners to track attendance.

3 60+ hour work weeks, 2 failed attempts at solutions, multiple phone calls with 3 vendors, and many thousands of dollars later – they just barely managed to get QR codes (NOT bar codes, and scanned with cell phones rather than bar code readers) onto the badges in time for them to hand them out to the attendees in their packets.

Any reporting against the collected information was likely written in his hotel room late at night after all of his conference obligations.

He was not a happy camper when I talked to him before the conference.

And his boss, who fortunately knew about the whole thing, is actively figuring out how to better evaluate these types of requests.

—————-

Was this particular scenario avoidable?  Maybe not.

The killer here was a faulty assumption that the vendor already had a solution that worked.

I also suspect that the request was taken at face value without asking questions.

 

Because, on the surface, the ask is simple.  And it may BE simple.  But it can get complicated quickly.

——————–

As a project manager, I need to identify those icebergs quickly.

Because those are the “small” scope changes that can quickly derail a project.

These are the questions I asked myself (and would have asked the requestor) when I heard this particular story:

1. What are they trying to accomplish with this solution?
2. What did they do before to capture this information?
3. What information are they trying to get out of the systems as a result of this solution?  Is it just attendance? Are you also trying to capture evaluations with the same solution? Is there information you wanted to have available to the attendees from the system at the conference as part of this solution?
4. Are the reports containing that information already available or do they need to be built?  If they need to be built – is there a report already available we can base this report on with minor changes?
5. Who is the audience for the report(s)?  Will it be different reports for each audience (ie – a report for staff, a report for executives, a report for presenters)?  Does there need to be a dashboard?
6. Do the reports need to be available real-time, on-site?
7. Is there a solution within the organization we can use – or do we need to source one?
8. What is your vision for how this solution will work?  Are you going to have people in each room scanning on entry? Will it be self-reporting and the members do their own scanning?  Will you be scanning just on entry or on entry and departure?
9. Are there any restrictions around this solution?  How is the WiFi? How is the cell signal? What potential sources of signal interference are there (hotels and conference centers are notoriously bad with wireless and cell service)? Will you be using your own cell phone with an app or is the business expected to source a bar code scanner or cell phones specifically for this purpose?
10. When is the final badge print required for the conference prep team?  Do we have something in place in case this needs to be done on-site?

These are just the questions I came up with on impulse.  Usually, there are many more….

You can see why I seem like a buzz-kill.  Always asking uncomfortable questions.

<div style=”position:relative;height:0;padding-bottom:75.0%”><iframe src=”https://www.youtube.com/embed/f68VXKMZT1Q?ecver=2″ width=”480″ height=”360″ frameborder=”0″ style=”position:absolute;width:100%;height:100%;left:0″ allowfullscreen></iframe></div>

—————–

It’s not about discouraging them from putting bar or QR codes on badges.  Collecting that information will ultimately help them better serve their customer and provide more interesting sessions.

It’s about figuring out what it will really take to fulfill that request at that time and in that time frame.

And do so in a way that provides greatest value while not burning through money and your best engineering resource.