Monday, May 17, 2010

Why, What and How

If you want to define a RFP (Request for Quotation) / RFP (Request for Proposal) or you have to answer those requests you are forced to define or understand requirements for a particular product or solution.

There are lot's of good sources showing how to write and handle requirements. But often they miss one important fact which makes either the creation, prioritization and understanding of requirements much easier. The Why instead of the What.

Rational
  1. First set the baseline for effectiveness. (Why)
  2. Than define what you need to be effective. (What)
  3. And at the end define the efficiency. (How)

What is the rational, the reason for a particular requirement. If you try to understand the Why or if you forced to define the Why the resulting requirements / usage of the requirement are much more valid than without doing this.

The "What" does not tell anyone the real intention of a solution. The why provides the motivation and business value and therefore the baseline for effectiveness which makes or makes not a requirement right to exists.

ToDo
  1. Before you start to define any requirement try to define the major "Whys"  you intent to solve. Keep in mind that there must no requirement which cannot be derived from those high level whys.
  2. derive each use-case / requirement from one of the major why areas and add a specific rational for the individual use-case / requirement.
  3. classify / prioritize the requirements based on the rational.
  4. Derive the "How". In this step the statement of efficiency is the key for selection of the right solution.
Result
  • The defined requirements are much easier to understand and alternatives can be much easier identified and qualified.
  • Prioritization can be much easier coordinated to management because the consequence of a decision for the "Why" and therefore the company / department goals are always clear even if someone does not have detailed knowledge of the subject matter.

    =>ensure effectiveness
  • Definition of the system requirements / How can focused on efficiency.
    =>ensure efficiency
To see the same idea from sales / marketing point of view watch: Start with Why: How Great Leaders Inspire Everyone to Take Action.

Sunday, May 16, 2010

facebook - openbook

if you have a facebook account or knowing people having account, try http://youropenbook.org/. I'm always amazed about the data people commit to companies like facebook.

try it out as long as it is available.

XSLT Version 2.1

XSLT Version 2.1 Draft published. As mentioned in the published draft the main goal is making streaming of transformation easier for implementors.

Streaming makes life easier whenever you have to process huge input streams of information to reduce memory footprint and deliver already processed chunks to the next consumer before the complete stream is successful processed.

On the other hand XSLT 2.0 which is a recommendation since 3 years is not widely adopted from implementors of XSLT engines -- Saxon, AltovaXML and few commercial ones-- so far.

Why? The main reason is complexity compared to the corresponding benefit. The implementation of a XSLT engine passes the 2.0 conformance tests is expensive and complex compared to the benefit for most users / use-cases. As in any commercial product each new feature / requirement should be qualified against the value and cost / effort it brings into the standard.

The interesting question would be -- how to measure benefits of a feature? How to interview the "users" of a standard? There is no trivial answer and that might be the main reason why standards tend to get over complex.