How a Non-functional Requirement Can Take Down a Project

Everyone’s got a story about a technical project that was brilliantly delivered but ultimately a failure because the users never liked the system.

Well, that’s not the only thing that can stand in the way of a project’s ultimate success.

People in heavily analytical careers (i.e., consultants, project managers and IT directors) tend to classify and label things as quickly as they can: Identify it, classify it, and then you know how to handle it. You know what resources to assign a task based on its type, how to manage someone based on their personality and what angle to approach a problem with based on its critical hooks.

We do this especially with projects: Is a project heavily technical?  Is it an organizational change management activity? Is it a process reengineering project?

The Project

I was working on a project in Las Vegas with a chain of casinos. We were implementing a packaged ERP system: purchasing, inventory, accounts payable, asset management and general ledger. Sounds like a technical project, right?

Not so fast. At the same time, we were instituting a shared services model, where multiple casinos under the same ownership would share an accounting and purchasing department, all of it powered by the ERP we were implementing. That sure sounds like organizational change management, doesn’t it?

Oh, and we were also doing a strategic sourcing project at the same time, establishing a process for strategic sourcing in the company and using the process on a number of pilot products. Must be a process project then, right?

It was all of them. And guess what failed? I can’t even classify it properly. Maybe you’d call it process design; anyhow, what broke the system eventually was a reality.

Plan Meets Reality

You see, a casino isn’t just a gambling hall; it’s also a hotel, multiple restaurants, and possibly other retail operations. Some casinos are also zoos, theaters, amusement parks or museums, and each of those business types has their own business requirements.

It was restaurants that broke our system. A Las Vegas casino on the Strip usually has some pretty pricey restaurants – alcohol especially, but other food items as well can be a big-ticket item. So, to manage this effectively, we were asked to implement the inventory system for the restaurants.

I’m not a restaurant business process expert, so I’m not sure about the wisdom there. If I’m running a burger joint, would I separately track my inventory of hamburger patties or bags of frozen fries? Actually, I suppose I might, although I might try to find a unit of hamburgers larger than a single patty. You need to know when you’re running out of things, after all, and what you need to order. So, sure, a restaurant ought to have an inventory system.

Here’s where reality came in. What’s one of the notable things about a Las Vegas casino? That’s right: It never closes. Most of its shops never close, and many of its restaurants don’t.  When we turned on the system, it worked fine except for one thing: The system just couldn’t keep up with restaurant inventory that was being constantly updated. Shipments of food and alcohol were showing up at every hour of the day or night, and items were being checked out of inventory twenty-four hours a day.

And because of system speed or the way the inventory stored process was designed, it could never catch up to what was actually in inventory at any given time.

Assessment

People problem? Doesn’t sound like it. Process problem? Maybe, only we got the process right. Why should we have suggested changing the process to account for the system performance? Technology problem? Yes, also maybe, since the system wasn’t delivering the outcome we wanted. But again, the system did what it was supposed to do.  It just couldn’t do it fast enough to give good results.

In project management terms, that’s what is called a non-functional requirement. It’s not what the system is doing, it’s the way in which it does it. Another example is system response time: when you load a new page on the website, the load time should be under X seconds.

Somebody probably wrote a non-functional requirement document for the system where it probably specified screen response times for each of the system modules. You know what? It might have even specified a requirement for how frequently or how quickly to process inventory. But we didn’t focus on it. Nothing was done to satisfy that requirement, and we certainly never tested against it. Even a stress test wouldn’t have found the issue, because just loading up an unusually large volume of transactions wouldn’t have uncovered the problem. Only the reality of a real-life transaction load over a real-life span of time would have found it.

Consequence: Project failure, followed by lots of investment to remediate the problem.

So, that non-functional requirements document sitting on the deliverable list might look like a boring time-suck, but you should probably give it its due. It could save your project!