Posts Tagged ‘system engineering’

There “Shall” Be A Niche

November 23, 2014 9 comments

Someone (famous?) once said that a good strategy to employ to ensure that you get something done is to publicize what you’re going to do for all to see:

Reqs Book Publicity

As you can see, my new found friend, multi-book author Jon M. Quigley (check out his books at Value Transformation LLC), proposed, and I accepted, a collaborative effort to write a book on the topic of product requirements. D’oh!

Why the “D’oh!”? As you might guess, there are a bazillion “requirements” books already out there in the wild. Here is just a sampling of some of those that I have access to via my account:Current Requirements BooksOf course, I haven’t read them all, but I have read both of Mr. Wiegers’s books and the Hatley/Hruschka book – all very well done. I’ve also read two great requirements books (not on the above list) by my favorite software author of all time, Mr. Gerry Weinberg: “Exploring Requirements” and “Are Your Lights On?“.

Jon and I would love to differentiate our book from the current crop – some of which are timeless classics. It’s not that we expect to eclipse the excellence of Mr. Weinberg or Mr. Wiegers, we’re looking for a niche. Perhaps a “Head First” or “Dummies” approach may satisfy our niche “requirement” :). Got any ideas?


The biggest obstacle, and it is indeed huge, in front of me is simply that:

“My ambition is handicapped by laziness” – Charles Bukowski

Functional Allocation II

Assume that you’re lucky and your company has a standard, generic product breakdown structure as follows:

  1. Product
  2. Functions
  3. Subsystems
  4. Configuration Items (Hardware and Software modules)

In order to achieve business success, an operating product needs to perform the functions that a user needs or wants for some reason. The functions are implemented by the number of, and interconnections between, the product subsystems. The subsystems are comprised of the hardware and software modules that animate the product.

Depending on the complexity of the new product that is required to be developed, between one and three “allocation” paths from concept to product can be pursued. The figure below shows these paths.

Three Paths

If the problem that the product is required to control or solve is simple, the relatively short bottom path can be selected. If the finished aggregation of CIs do their intended job of seamlessly and elegantly supplying users with the functionality that they want/need, then the product will, in all likelihood, be successful. Profits will flow and customers will be happy. Classic win-win.

If the problem is complex, then the top path should be followed. Consciously or unconsciously pursuing the bottom path for complex products can, and usually is, disasterous. At best, money will be lost. At worst, people can die as a result of the end product’s failure to do what it was intended to do. Even if the top path is correctly chosen, failure to execute the process effectively can produce the same result as choosing the wrong bottom path. For success, the product and the “allocation” process must match. Success won’t be guaranteed, but the likelihood of success will increase.

So, what can cause a business failure even when the product and process are correctly matched at the outset? The list of reasons is long. Here are just a few that come to mind:

  • Technical incompetence
  • Managerial incompetence
  • Massive external or internal schedule pressure that leads to corner-cutting
  • Inter and/or intra-group rivalries naturally encouraged by hierarchically structured organizations of rank and privilege.
  • An unfair reward system
  • An obsession with following a rigid, micro-prescribed process to the letter of the law (dotting all the i’s and crossing all the t’s)

In summary, a product-process mismatch virtually guarantees long term business failure, but a product-process match may, just may, result in business success. The odds seem to be stacked in favor of failure. Bummer.

%d bloggers like this: