Search This Blog

Showing posts with label architecture. Show all posts
Showing posts with label architecture. Show all posts

Wednesday, March 27, 2013

Intelligence and Analysis

Had a chance to attend an industry analysts’ working group. Stars from competing companies met in a special forum to get a better picture of where their profession is going.

First symptom is the explosion of casual data. Their customers see it all around them and want to know how it relates to the professional information they are buying. The short answer is, it doesn’t.

Data is not analysis. Analysis is verifying accuracy and providing context. Figuring out what to ignore is an important part of professional analysis.

But analysts are getting overwhelmed with random data, and anything a customer finds is more valuable to that customer than a professionally curated product.

One analyst tore a small corner off a sugar packet and dropped in the middle of a 16 by 6 foot conference table. “This table is what is publicly available, and this scrap of paper is what our processes allow us to analyze.”

One further comment was that scrap of paper should be cut into pieces representing the processes of the competing organizations.

Customers want their scraps validated, but they sure don’t want to do the work of validation. That’s what they are paying for, usually on a carefully predefined cost basis. ...and other duties as assigned is now desired in that same price. Open source scope creep.
So a first solution is to loosen the vetting procedure to allow significantly more throughput, perhaps using casual data in that process in some way.

A couple of days after the meeting, I remembered the the story of J. P. Morgan’s guidelines for purchasing services, “I don’t want a lawyer who tells me what I can’t do. I hire a lawyer to tell me how I can do what I want to do! ”

Perhaps a solution is bringing the customer behind the curtain, to better understand what they are buying and why.

Tips 4 The Big Chair – Perspective 2.0

Wednesday, September 19, 2012

Redo

Users work differently from makers, for good reason. If you make a mistake buying a book on Amazon, you can usually go back an action, or a screen, call it a redo. Makes sense to just keep hammering keys until you get what you want.

Makers often don’t have redo, so there’s an emphasis on using a planning and structure to reduce rework. I cut that board three times and it’s still too short! Well then, Measure twice, cut once.

Working in an IDE (Integrated Development Environment – programmer’s code-making software) discovering an error can require taking out days of development.

The old observation that one programmer can do the work of a thousand programmers is valid because many programmers spend the next morning tearing up whey did the previous day. One step forward, two steps back.

Sales Lab’s Planned Workcycle addresses the need for Architecture and Design before Executing, and came from construction contracting. If you order a crane, it better be busy the whole time it is on-site, and after it leaves, you best not need that crane again.

The Workcycle also has an original structure for how to do Evaluation which makes Evaluation work a whole lot better. I’ve found it increases efficiency in many types of complex projects.

How does the availability of Redo change the value of Planning, the process of Executing?