When The Client Asks For An Elephant, Don’t Come Back With A Camel And A Story

Do you realize that these requirements introduce a lot of security risks?

Yes, but. . .

How do we even know that the client is going to need physical devices?

Well. . .

I mean could they use an emulator instead of an actual device?

Ah. . .

And how often will they need to access each device. I’m not sure we even know enough to start building their solution. There are A LOT of unknowns.

What do you do when the client asks you for something you don’t necessarily want to build? We had built an environment for our client that was pretty locked down.

– 24 Hour security
– 100% camera coverage including all entrances and every desk
– A one strike policy on cell phones. Bring it on the floor one time and yred
– Turnstiles that prevented “passback.” Meaning, once the system knew you were “inside,” your badge could not be allowed to gain access until you went “outside”
– No paper
– No pens
– No laptops
– No thumbdrives
– Frosted windows on the ground floor.
– Multiple card readers to get in and no line of sight from outside the production area
– No internet access
– 100% of calls were recorded

I worked for Microsoft for nearly a decade and we didn’t have anything approaching this level of security even in our most sensitive areas. My current employer took security very seriously. Our agents had access to credit card data, insurance information, pretty much anything you would need to steal someone’s identify.

The call floor was a secure as we could make it.

And now, the client wanted us to take on a new line of business supporting their mobile customers and provide our agents for this new line with

– Cell phones
– Laptops
– iPads
– Nooks
– Kindles
– Multiple computers

It was a security officers worst nightmare. The client wasn’t much help. This was the first time they were outsourcing their work to a 3rd party provider. They could tell us what hadn’t worked for them, but they were less helpful on what would work.

We had multiple internal meetings. It wasn’t necessarily IT vs security, but as the IT project manager, I was trying to figure out how to provide the service the client wanted, and security was trying to protect corporate ass-ets; ours and theirs.

The executives had already signed a contract and they were looking to us to figure out how to fulfill it. Unfortunately the more meetings we had the more scenarios security came up with for how someone could use these tools to steal member information. We were getting further from our goal not closer. And we had a deadline for providing our client with a technical proposal.

Project Managers have an interesting role. No one reports to us, but from the client view-point, we own the technical solution. And yet, I couldn’t build it myself.

Look guys. We could speculate all day on how they might use these tools.

And we have to answer those questions before we can proceed, Rodney.

No. No we don’t. The fact is we will never understand the role until we actually start taking calls. So, we can pool our ignorance and try to guess on an answer, or we can do exactly what they asked us.

What do you mean?

I mean that the contract says we put these items on the production floor. We make whatever security restrictions we can, but ultimately we do what the contract asked us to do.

But, the security. .

Right. Put it down in a document and we provide it to the client along with our proposal. It’s called a Risk Register. We get them to sign off on the risks. What we cannot do is keep delaying because we want to have perfect clarity before we make a move.

Your job as a consultant or a project manager is to provide the best advice possible to the client. However, once the client makes a decision, sometimes you have to actually give them what they have asked for.

Rodney M Bliss is an author, columnist and IT Consultant. His blog updates every weekday at 7:00 AM Mountain Time. He lives in Pleasant Grove, UT with his lovely wife, thirteen children and one grandchild.

Follow him on
Twitter (@rodneymbliss)
Facebook (www.facebook.com/rbliss)
LinkedIn (www.LinkedIn.com/in/rbliss)
or email him at rbliss at msn dot com