Here's how it can happen:
You spec a building or home. They do their planning, secure materials, allocate time and dollars. Some of those might be your dollars, required up front, depending.
Construction starts. Many elements, such as the foundation, really do need to be established prior to finished work, and the work in progress, as well as many specified features have dependencies.
Say the project is 3 months.
One month in, after many dependent features are done, you redesign the spec, and there are costs. Both parties can agree to modify costs, but there are now unknowns, unless sufficient planning time is taken to understand what needs to be undone, what can be kept, what has to be modified, and what needs to be new are all made clear.
Say the 3 month date has a little flexibility, but not a lot. Say you plan on moving in, or perhaps launching a business to which you've committed time and material investments that will prove expensive, if the business isn't equipped with a building to receive them.
That planning time might, in and of itself, prove deadly to the project.
At that critical point, a decision needs to be made:
1. Roll back the changes and continue with original spec, perhaps firing off a secondary project to meet new requirements. They would not fail in this case, unless it really is their fault.
2. Perform rough planning, which will seriously increase risk, and let cost run free in order for the contractor to meet the date. They could now fail and it could be according to mutually agreed upon terms, which the project manager would need to account for. Both parties could fail, and both could be at fault.
3. Terminate the project, cutting losses. This is a fail, but a cheaper one.
4. Do the planning anyway. There is some failure, but the whole thing is "pot committed" and whatever costs are associated with moving the date and changing requirements are going to be accepted and paid regardless. In this mode, both parties could succeed, but will have to account for cost overruns and time.
Etc... There are other choices here, but that shows how there can be a failure on one or both sides.
A secondary complexity is whether or not the project as defined will actually meet requirements. Oracle needed to advise on this, and potentially just didn't do their due diligence, accepting the project, which may well have been doomed to failure anyway. Their fault.
(this is one I check religiously BTW It is extremely painful when it happens. And it's painful in that, "but you got what you paid for" way, where the customer really will say, "but it doesn't meet requirements, why didn't you advise me, or turn the project down?" All hell, all the way down when that happens!)
This is why I really want to understand the project management, lines of communication, change protocols, research, requirements specification, etc... before making any judgement. There could be fault on one or both sides here, and I suspect it's both.
My gut says Oracle saw a nice project and it would make their services numbers, and it's from a State, so there is "slush room", and that typically means you bid like crazy to get it, promise stuff, and then work it all out along the way. (high risk of failure, but good revenue --extremely tempting to the services sales team, who should deny a deal like this, but won't)
And the other half of that would be Oregon not actually thinking requirements through, making changes and managing their vendor poorly.
Both sides are very highly likely suffering from a lack of planning and established communication protocols.
So that's my guess. Who knows until discovery digs the goods up for us?
Want some popcorn? It's going to take a while.
Posted on August 23, 2014 - 12:27 PM