4 ms·

Something I dealt with a lot in oil & gas engineering, and have never personally witnessed in software engineering, is a "change order". The contract is signed

by ZoFreX 13y ago

Something I dealt with a lot in oil & gas engineering, and have never personally witnessed in software engineering, is a "change order". The contract is signed. At this point, if you deliver on your end of the deal, they have to deliver on theirs†. If they want anything other than what is in that contract - additions, changes, removals - you send them a change order. This is a new document for both parties to sign, covering the new request, and comes with its own price tag on top of the contract already agreed. These are essential when you are engineering an actual physical product, because changing the specification of a natural gas compression plant when it's half built is very, very expensive. Change orders are an excellent tool for ensuring not that scope creep doesn't happen, but that scope creep doesn't turn a profitable project into a loss. † Of course, practically, no-one wants to take on a client that they will have to sue to get the money from. But you should know where you stand when that contract is signed - you deliver your part, they deliver theirs. You can simply say "no" to additional requests and deliver on the original.

cmdkeen 13y ago
Oh it happens - that is how, certainly in the UK, the large consultancies like Accenture and Cap Gemini make their large profits, especially from Government type contracts. They know that the customer will inevitably want change, especially with things like a new senior civil servant or politician wanting to "make their mark". At that point they are the only bidder, so no competition to drive down the price, and the client will generally pay whatever they ask - because it isn't their money they are spending.
smackfu 13y ago
This is extremely common in corporate software engineering, where a contract specifies exactly what will be delivered. In practice, those change requests are usually rejected, because the people with control of the money aren't the people using the product, and the customer ends up paying for something they aren't happy with. A lot of Agile methodologies are a response to this extremely strict change control.
- mindcrime 13y ago
  A lot of Agile methodologies are a response to this extremely strict change control. The problem, from what I've seen, is that developers understand agile development, but the "money people" don't. To them, "agile" is just a buzzword that means "good" and they aren't actually interested in participating in the process. So now you get people who don't understand, or aren't interested in, attending demo sessions, prioritizing the backlog, or reading/writing user stories. And when things don't proceed along a nice, smooth, water-fall like sequence, they get stressed and start complaining. One place I'd say the Agile movement has fallen on it's sword, is in terms of promotion, education and buy-in from the "business community" to the point that they understand that Agile processes require their active participation.
  - PeterisP 13y ago
    If you want to do Agile development, then you also have to do Agile billing - i.e., not a pre-agreed price limit for "thingamajig that does X, Y and Z", but in essence renting the team for each sprint with an understanding of what you'll get in each development (and billing) cycle.
- Silhouette 13y ago
  A lot of Agile methodologies are a response to this extremely strict change control. Which is useful in some contexts, but also why Agile isn't taken seriously in others. The most popular Agile methodologies (if that isn't itself an oxymoron...) are fundamentally incompatible with processes and practices that can be useful in real projects, particularly very large projects where there are many participants to co-ordinate and many stakeholders with an interest in the results but not necessarily the same interest. At some point, a more formal process is the only way you can get anything useful done, and that includes a sensible but controlled process for handling changing requirements.
yogo 13y ago
There aren't change orders per se but usually in one of the clauses in the contract you specify that work outside of the scope (outlined in the contract), once all parties agree, will incur an additional charge or something like that.
mindcrime 13y ago
Something I dealt with a lot in oil & gas engineering, and have never personally witnessed in software engineering, is a "change order". This is commonplace in custom software development in my experience. Having a change control process in place, and negotiating a price-tag for changes to the original contract, happened all the time in my first programming job. We were mainly working for government agencies (municipal and county government), universities, etc., and this was all completely normal.
madaxe 13y ago
PRINCE2, baby. It's heavy-handed, produces mountains of paperwork that you hope to never have to look at again, and allows both parties complete clarity as to what is, and what isn't, in scope. You want to change the scope? Needs a change-request, a re-quote, a re-scope, and it all trickles back into the project plan. The only problem with this process is that it actively encourages the client to find any shred of loosely worded anything in any specification, and interpret the hell out of it, rather than having to go through change control.

by ZoFreX 13y ago

cmdkeen 13y ago

Oh it happens - that is how, certainly in the UK, the large consultancies like Accenture and Cap Gemini make their large profits, especially from Government type contracts. They know that the customer will inevitably want change, especially with things like a new senior civil servant or politician wanting to "make their mark". At that point they are the only bidder, so no competition to drive down the price, and the client will generally pay whatever they ask - because it isn't their money they are spending.

smackfu 13y ago

This is extremely common in corporate software engineering, where a contract specifies exactly what will be delivered. In practice, those change requests are usually rejected, because the people with control of the money aren't the people using the product, and the customer ends up paying for something they aren't happy with. A lot of Agile methodologies are a response to this extremely strict change control.

mindcrime 13y ago
A lot of Agile methodologies are a response to this extremely strict change control. The problem, from what I've seen, is that developers understand agile development, but the "money people" don't. To them, "agile" is just a buzzword that means "good" and they aren't actually interested in participating in the process. So now you get people who don't understand, or aren't interested in, attending demo sessions, prioritizing the backlog, or reading/writing user stories. And when things don't proceed along a nice, smooth, water-fall like sequence, they get stressed and start complaining. One place I'd say the Agile movement has fallen on it's sword, is in terms of promotion, education and buy-in from the "business community" to the point that they understand that Agile processes require their active participation.
- PeterisP 13y ago
  If you want to do Agile development, then you also have to do Agile billing - i.e., not a pre-agreed price limit for "thingamajig that does X, Y and Z", but in essence renting the team for each sprint with an understanding of what you'll get in each development (and billing) cycle.
Silhouette 13y ago
A lot of Agile methodologies are a response to this extremely strict change control. Which is useful in some contexts, but also why Agile isn't taken seriously in others. The most popular Agile methodologies (if that isn't itself an oxymoron...) are fundamentally incompatible with processes and practices that can be useful in real projects, particularly very large projects where there are many participants to co-ordinate and many stakeholders with an interest in the results but not necessarily the same interest. At some point, a more formal process is the only way you can get anything useful done, and that includes a sensible but controlled process for handling changing requirements.

yogo 13y ago

There aren't change orders per se but usually in one of the clauses in the contract you specify that work outside of the scope (outlined in the contract), once all parties agree, will incur an additional charge or something like that.

mindcrime 13y ago

Something I dealt with a lot in oil & gas engineering, and have never personally witnessed in software engineering, is a "change order". This is commonplace in custom software development in my experience. Having a change control process in place, and negotiating a price-tag for changes to the original contract, happened all the time in my first programming job. We were mainly working for government agencies (municipal and county government), universities, etc., and this was all completely normal.

madaxe 13y ago

PRINCE2, baby. It's heavy-handed, produces mountains of paperwork that you hope to never have to look at again, and allows both parties complete clarity as to what is, and what isn't, in scope. You want to change the scope? Needs a change-request, a re-quote, a re-scope, and it all trickles back into the project plan. The only problem with this process is that it actively encourages the client to find any shred of loosely worded anything in any specification, and interpret the hell out of it, rather than having to go through change control.