Forums
Managing the requirements for an application is a huge challenge. The hardest part of the challenge is that, very frequently, the user's don't know what they really want or need. Prying it out of them, and giving them an application that actually solves the real problem they have, is an art.
The worst situation is when the users are absolutely certain that they do know what they want. This was the situation that Irini found herself in.
The project started, as many such projects do, in the wake of a disaster. One of the company's many Capital Improvement Projects (CIP) slipped through the cracks during budgeting. It ran six months past schedule, but managed to close out with a few hundred grand still unspent in its budget. When someone tried to reallocate that money, the management team in charge of managing CIPs found out, they went full code-red, trying to do two things at the same time: understand why that project got lost in tracking, and also why when they tried to reallocate the money, it kept getting reset in their Enterprise Resource Planning (ERP) system.
Eventually, that lead them to Sofia, the VP of Finance, and managed them all through a spreadsheet she had created by herself. The ERP kept getting reset because she manually updated it based on the contents of the spreadsheet. The project got lost because she manually color-coded the projects in her spreadsheet, and one day accidentally hid the row, instead of making it yellow.
No one liked that there was a manual process. No one liked that only one person ever touched this system. Management wanted a robust, backed-up IT system, and wanted to open the management of this process to more of the finance team, so Sofia wasn't the only failure point.
The solution was clear: gather requirements from Sofia and either purchase a product or develop something in house to replace the spreadsheet. Very quickly, it was decided that "develop in house" was the only way to customize the tool to what Sofia's process already looked like, and "standardizing the process" was not an option.
Irini was on the IT team that was chosen to build this product. A business analyst tried to sit down with Sofia to suss out her actual requirements, but hit a brick wall. The spreadsheet already did everything she wanted. The spreadsheet was the requirements. She gave the analyst a copy and sent him on his way to get something built.
As mentioned, Sofia manually color-coded the rows in the sheet to help with project tracking. Fortunately for the development team, her spreadsheet included a key, describing what the colors meant. Unfortunately, it was this "technicolor yawn", as Irini puts it:
Now, as "re-implement this spreadsheet as an application" goes, this isn't terrible. It's an ugly, complicated set of rules, but at least it's documented. But what we have here is a case of one person's idiosyncratic style of organization determining the features for all users of the application.
This is what the users said they wanted. This was what the dev team implemented. Everyone on the dev team suggested that maybe they needed a better way of letting users filter, sort, and prioritize their capital projects, possibly even allowing each user to manage custom filters, but no- the spreadsheet was the requirements.
When the app launched, the Finance team was excited to have more control over their capital projects. Then they started to use the application, and quickly got confused. It was built, not to solve the problem of managing projects, but to fit Sofia's workflow, and her workflow alone. It was impenetrable and opaque to everyone else. After a few months of endless tickets as users got lost in the confusing interface, most of them gave up.
Sofia stuck with it longer, but she hated the application. As it turned out, automatic color coding was a big anti-feature for her, because the rules she had in the sheet were just guidelines, and she wanted to be able to apply any color to any project based on information that existed only in her head.
The application is still technically running, but nobody in Finance is using it. They've reverted back to "Sofia has a spreadsheet for it."