Thursday, November 27, 2008

Failure by delivering more than was specified?

I stumbled upon a puzzle. Please help me solve it.

It strikes me as odd, but there might be situations where a provider fails (i.e. the system will not be accepted by the customer), because he delivered MORE than was specified. I'm not talking about the bells and whistles here, that (only) wasted resources.

Imagine a hard- or software product that is designed to serve more purposes than required by the single customer. Any COTS product and any product line component should fit this definition.

Which kind of requirements could be exceeded, scalar and/or binary requirements? I think scalar requirements (anything you can measure on some scale) cannot be exceeded, if they do not constrain the required target on the scale on two sides. Haven't seen that (It's always "X or better", e.g. 10.000 transactions per second or more.
Even if it was constraint on two sides, this simply would mean a defect.

But there can be a surplus of binary qualities, i.e. functions. A surplus function can affect other functions and/or scalar qualities, I think.
Say, as a quite obvious example, the system sports a sorting function which was not required. A complex set of data can be sorted, and sorting may take some time. A user can trigger the function that was not required.
- This might derail overall system availablity (resonse time), a user required quality.
- It might open a security hole.
- It might affect data integrity, if some neighboring system does not expect the data to be sorted THAT way.
- It might change the output of another function, that was required, and that does not expect the data to be sorted THAT way.
(First fantasy flush ends here.)

So, if you find a surplus function in a system, what do you do? Call it a defect and refuse to accept the system?

Eager for your comments!

Monday, November 24, 2008

All you want to know about Stakeholder Management

Alec Satin of the "Making Project Management Better" weblog has a brilliant list of links to Stakeholder management resources.

From his explainatory text:

In this list are articles to get you thinking about some of the less obvious issues in pleasing stakeholders. Primary selection criteria: (a) quick to read, (b) good value for your time, and (c) of interest whatever your level of experience." Markup is mine.


Saturday, November 22, 2008

Engineers discover Planet Project!

I'm proud to provide you with nearly all the content of this blog in a wiki form. Please check out this blog's sister website Planet Project.
A couple of people asked me to choose a wiki, so people can contribute. Of course! You are very welcome, please populate the Planet Project!
A couple of helpful links to the Planet:

While I will still write this blog regularily, all new processes, principles and rules will be published on the Planet only.