clsteve
Active Member
PwC, but that's not the point.
I think you're thinking about things correctly but I believe you're assuming that the project was somehow "complete" and then all of these changes were made subsequent to that. I think it's much more likely that the expenditures along the way have all been tweaks to make the product function as designed in the initial scope. So it's not like some final product was accepted months ago that they're now tweaking with no new functionality. They're still implementing the initial functionality.
I really don't think we're that far off at all. I just think there's a piece missing which is causing the back and forth - the diff between internally developed by the company versus internally developed contractually with a Provider.The fact that it's an over-run is not relevant. In other words, your ability to estimate does not affect that amount of costs that are capitalized. Actual costs either meet the criteria or don't, and those criteria do not involve whether the costs were more or less than estimated.
Costs that are necessary to "get something to work" sound like capital expenditures to me. For example, if you buy a piece of machinery, the costs of installing it are capital expenditures, even if it costs more to install than you thought it would. Costs of modifying the "true environment" to work with the software, however, are not capitalizable as software costs, but might be capitalizable in their own right. Costs of training are not capitalizable.
With a Provider, each phase must be specifically spelled out contractually and signed off by both parties - deliverable by deliverable, milestone by milestone. That especially includes the Acceptance components of each milestone in the project and for any delivered product-ized code components. The project would not move into the next phases without both the Provider and Disney signing off on acceptance all the way into production. If that didn't happen, projects would never end with the Provider still accountable.
But, they both recognize that the real project costs start after acceptance and testing and often during and after the production implementation of the "code" - of which there are many phases. You try to budget and negotiate them as best you can, of course, and segment them into contracted phases under the Project like data migration and conversion, P&T, or into an estimated and budgeted allocation of man days into a ""Project Support and Implementation" bucket.
But, they're T&M contracts that unfortunately, often blow right through the budgeted allocations.
To the Provider, it's still a change request and enhancement (from their view) , but post implementation maintenance (and enhancement) of the solution from the customers view. No new functionality, just getting it to work - fixing errors - much like a complex series of maintenance releases
We can debate the merits of where things should fall based on each of our experiences. But, let's bring it back to Disney and NextGen. That sure seems to be what happened with seemingly a lot more falling into opex than capex as the project moved into it's later stages FY's '13 and 14.