If I came to you at work and told you I wanted you to make changes to one or more systems - it's unclear how many are involved). I don't know how big the systems are, don't know what platform they are written in. Don't know how many users there are or how they interface with the system(s). I don't know either the peek, or sustained volume of transaction. Don't know what upstream systems systems feed these, nor what downstream systems need to be fed. Don't know what kind of information must be captured and tracked. Don't know what testing environments are used, what standards the company requires for change. No idea of the resources or budget available either.
Would you say such changes are
- Easy?
- Hard?
- Impossible to say without more information?
How would you feel if you boss, not knowing all the things outlined above, promised that such a project would be easy and that you'd take care of it with no problem?
So you mean (minus the budget question...EVERYONE knows what their budget is) a typical Tuesday? You just described the majority of my conversations with system users (who, by and large, are NOT technically oriented employees) over the past 8 years (since I was in any position to do anything about it).
I would say exactly what I said: Theoretically, the changes you're asking for are TECHNICALLY easy. The programming, itself, is very simple in most environments....and I think we can assume that Disney is using something like Oracle or SQL as their back end and not something off the wall like Revelation (in which, FYI, it would STILL be easy to do). I doubt the TECHNICAL piece (meaning the actual design, coding, and database mods) would be the stumbling block. The SYSTEMS piece might...which I said in my follow up post and is what I tell my users, right before I tell them "Lets book a meeting with everyone involved".
So, now lets look at what we're dealing with to see if the changes make the most sense to implement, based on some of the factors you mention. If there are systems issues, if the system, as a whole, is not designed well, or is overburdened, or the programmers/admins/dba's are incompetent, or a whole host of other problems exist, then changes may not work. If there are operational issues (something I find far more frequently...thinks like budget issues) that prevent the changes from making sense, then the changes may not work. But then, ANY changes in that type of environment are going to be problematic, complex, and time consuming....so when you're talking "easy" you're talking "relative" ease. That doesn't mean the concept being proposed is complex....it means the environment might be. You might suspect that's the case. I'll give them the benefit of the doubt, since we're not sitting in a design meeting, we're just postulating on a Disney forum. Again, the worst you can say here is that I'm being an optimist.
And I've personally implemented this type of thing in similar "tracking" type systems before, where we needed tiered viewing on certain items. What I would consider a pretty large system, running 24/7. We're talking a throughput/turnover of something akin to 10's of thousands of individual items per day, upwards of 100k DB transactions, minimum...items into service, out of service, and back in, with the added complexity of kit building thrown in....with users on both sides interfacing (the "consumer" of the items and the people rotating them through service) with the system. Predictive algos to determine when items should be ready to go back to service. Upstream and downstream traffic with our other corporate systems, one of which is primary in determining which items are needed and one of which ultimately bills for actual item use. It wasn't dealing with tables in multiple restaurants, but I imagine the ultimate outcome of the system is somewhat similar. The biggest difference is that items are booked only a week in advance...not 90 or 180 days...and our items are bar-coded or RF-tagged. Oh, and the tier system isn't to be exclusionary, but rather inclusive, to make sure all possible "alternative" items are available to the "consumer", but those that have no need of "alternatives", based on the work the items will be used for, don't have to wade through them.
Anecdotally: The hardest (and longest) part of the implementation process for the above "tier system" addition? User training. Go figure.
And, FYI, my "boss" (on the technical end), at this point? He'd likely not involve himself directly in that kind of system design/detail work. At least he hasn't, so far. He's way too "big picture" on the food chain...so he'd have me in any meeting on this type of thing concerning "my" systems (or anything new he wanted to throw on my plate).
If I WAS in that position, and it DID happen to me? I'd feel just like every Jr. Programmer sitting in a cube in corporate America does when it happens to them. I'd curse his name and figure out a way to make it happen. Luckily, I'm not there anymore...either in terms of experience or in the way our company operates.
Anyway, I think I've "geeked up" the forum enough, at this point....suffice to say, I stand by my original point, with the clarifications and qualifications I've added.
Love it.
In fact, it's a pretty common happening in our offices: The "theoretically easy, lets see what we find when we get our hands a little dirtier" conversation. I'd say about 1/3 of the time, it's what launches a project. 
