---------- Forwarded message ----------
From: Sally Bean <sa
...@sallybean.com>
Date: Fri, Oct 31, 2008 at 9:11 AM
Subject: RE: From Chris Bird a Brit-EA living in Texas..
To: ro
...@objectwatch.com, ch
...@thenetworkeffect.net, John F Schlesinger <
jschlesin
...@computer.org>, nigel green <nigelpsgr
...@googlemail.com>,
Charles Edwards <charles.edwa
...@processwave.com>, Roy Grubb <
roygr
...@gandanet.com.hk>
True, Roger.
There is 'soft' complexity, that arises from multiple stakeholders having
different backgrounds, values and viewpoints, and 'hard' complexity that
comes from large size and multiple interconnections.
For those familiar with Dave Snowden's Cynefin model, soft complexity is
the upper left quadrant (COMPLEX: invisible, un-ordered, unable to predict
cause and effect), and hard complexity is the upper right quadrant
(COMPLICATED: invisible, ordered, able to predict cause and effect given the
right assumptions and information)
This link takes you to his original paper, though he's tweaked the
terminology since then
http://cognitive-edge.com/articledetails.php?articleid=14
I would say from my initial understanding of these ideas, that SIP addresses
mainly the complicated domain (hard complexity), and VPEC-T (5D lens)
addresses the complex domain. Not so sure about VPEC-T (threads and beads) -
perhaps that applies to both?
Sally
-----Original Message-----
From: Roger Sessions [mailto:ro...@objectwatch.com]
Sent: 30 October 2008 21:10
To: ch...@thenetworkeffect.net; 'John F Schlesinger'
Cc: 'nigel green'; 'Charles Edwards'; 'Roy Grubb'; Sally Bean
Subject: RE: From Chris Bird a Brit-EA living in Texas..
Not to take anything away from VPEC-T, but I feel I need to put in a word
for complexity control. I believe that the more progress we can make on
synergistic partitioning the easier it will be to have fruitful VPEC-T
discussions. Conversely, the sooner we have VPEC-T discussions, the sooner
we can have fruitful partitioning analysis. This is why I see so much value
in using both SIP (with its focus on complexity control) and VPEC-T (with
its focus on collaboration) together. They compliment each other nicely.
I think you are all having too much fun there without me!
Best wishes from Houston,
Roger
------------------------------
Roger Sessions
CTO, ObjectWatch
ro...@objectwatch.com 979/836-2244
www.objectwatch.com
blog: simplearchitectures.blogspot.com
-----Original Message-----
From: Christopher Bird [mailto:ch...@thenetworkeffect.net]
Sent: Thursday, October 30, 2008 3:04 PM
To: John F Schlesinger
Cc: nigel green; Charles Edwards; Roy Grubb; Sally Bean;
ro...@objectwatch.com; ch...@thenetworkeffect.net
Subject: Re: From Chris Bird a Brit-EA living in Texas..
Yup, that pretty much covers it!
With apologies to Nigel, I am going to paste in a reply I wrote to him
before I saw you all weighing in!
No doubt that scoping and scope creep are the same for 5D as they are for
other methods - including SWOT.
Where I was coming from was a kind of expectation management angle. When we
start applying 5D, we need to have sonderstanding of what is the "problem"
that we are addressing. Not necessarily the outcome - in fact unless the
outcome is a business outcome it should not be here at all.
But somebody with sufficient USD, GBP, EUR, etc. presumably has some
thought of what needs to be done. That provides some degree of guidance to
us as we apply any/all methods.
Now that guidance is largely directional, but there are likely to be some
hard edged constraints around it. Those constraints will likely be Policy,
but may be Values. ("Don't be evil" for example is a Value, not a Policy).
However that Value isn't enough to decide where any focus should be.
Admittedly it would be a fascinating exercise to take that one Value and
look at all the ways it could unpack through VPEC-T. However, what I suspect
would happen is that we would realize that there are multiple "sub-VPEC-Ts"
that we would need because we could never get a consistent set of Policies,
Events and Content across the full Value system. So somewhere there has to
be some coherence. There may have to be some leveling too. Making sure that,
for example, the Events are at the same level as the Policy. So you don't
(probably) want an ATM withdrawal Event when you are working at the level of
the bank's strategy.
All this demands skillful handling of these powerful concepts - skills that
are and should be absolutely within the tool-kit of any consultant worth
their salt.
My specific comments in the first email were about the book and not the
method. The book - as a first time introduction - made me move around the
levels (what kind of problem we are addressing) too much. I had to
deliberately ignore the swing example while I was thinking about bigger
picture problems. Yes to those of you who are experienced with the
approach/technique, you can move seamlessly up and down the
abstraction/scope or whatever one calls it levels. For neophytes, managing
the levels and the concepts at the same time was one moving part too many, I
felt. But that is pretty minor criticism.
Now to apply it on some juicy problems!
> Interesting question. The scope of the Bank of Ireland engagement was
> the entire enterprise, in particular the parts covered by the four
> elements of their 2012 strategy! These were: channels; payments; core
> banking; and finance. That didn't leave a lot over.
> John Schlesinger
> Home Phone +44 20 7833 5930
> Mobile Phone +44 7794 353 356
> ________________________________
> From: nigel green <nigelpsgr...@googlemail.com>
> To: Charles Edwards <charles.edwa...@processwave.com>; Roy Grubb
> <roygr...@gandanet.com.hk>; Sally Bean <sa...@sallybean.com>;
> ro...@objectwatch.com; John Schlesinger <jschlesin...@computer.org>;
> ch...@thenetworkeffect.net
> Sent: Thursday, October 30, 2008 4:49:06 PM
> Subject: Re: From Chris Bird a Brit-EA living in Texas..
> I think we might be on to something here - something to do with
> Iteration and Agility.... but...
> I still think it depends on the nature of the engagement - I've seen
> VPEC-T to help discover/describe architectural principles to
> challenge/re-think decisions to explore/nail-down shared-services and
> to untangle knotty legacy IT/IT dept attitude issues without hearing
> about any Scope issues - and in an External Consulting context. In
> each case the scope is defined by the contract which then constrains
> the VPEC-T work in one way or another. It's interesting that VPEC-T
> was born in a government contract (CJS)!.
> John - how was scope handled when you and Dave used a VPEC-T approach
> as external consultants?
> n.
> On Thu, Oct 30, 2008 at 2:45 PM, Charles Edwards
> <charles.edwa...@processwave.com> wrote:
> In my past when I used to run my own company Consulting to companies
> on Software Development projects (which included VPEC-T like Business
> RAD sessions), we would structure the contact around a set of iterations.
> - Fixed Price for the first n (2-4) weeks of Inception workshops with
> rough indicative time and money estimates for the remaining
> iterations; At any point they were free to take the outcome of the
> fixed price bit and get alternative quotes for the remainder. (they
> never did)
> - Then Fixed price for next Elaboration iteration (n weeks/months)
> based upon outcomes again with revised rough indicative time and money
> estimates for the remaining iterations; (or another Inception 2 weeks
> if big issues / deltas emerged)
> - and so on, each time refining the quotes and scope until the client
> ended up with a working system that completely fitted into the Business.
> Admittedly - the Government Departments could never take on this
> approach
> - and we simply avoided all dealings with them - but then again I
> would argue they are the most likely to have the worst of the failed
projects...
> "I like hitting my head against the wall, because it feels so nice
> when I stop!"
> regards Charles
> Quoting Roy Grubb <roygr...@gandanet.com.hk>:
> Nigel,
> We've chewed that fat over this during a convivial dinner, but writing
> it down lets me think more clearly.
> VPEC-T addresses issues not formally covered by approaches I've
> encountered in the past, of course.
> Principally, stretching...
> ... Value out beyond the obvious value to the business, ... Content
> beyond formally specified data, and ... explicitly examining Trust.
> One of VPEC-T's beauties, IMO, is that it goes 'looking for trouble'
> with the dual effect of increasing the chances of success (by not
> ignoring those things that might otherwise only be discovered too late
> or not be recognized at all) and, by definition, increasing the
> possibility of the unexpected being found.
> Then, it will depend greatly on the organization under study, and who
> is doing the study. Speaking from the perspective of an external
> consultant, scope is critical. Yes, I acknowledge you are an e.c. as
> well Nigel, but in a different context.
> As someone who has carried out assignments for flexible organizations
> (like DHL as it was some years ago) and over-rigid ones (HK
> government departments and quangos), the ability of the project
> sponsor to accept unexpected results of the discovery process differs
> as does chalk and cheese.
> The discovery that a project as originally conceived has too narrow a
> scope can be severely problematic if the client is not realistic. If you
> have a civil servant looking at a contract, concerned only with not
> having to explain to his superior that he has had to agree to deviate
> from the original contract, then no matter how good the reason, it
> can be a painful and time-consuming process to avoid a loss-making
> assignment for the business analyst.
> Charles' phrase 'in a collaborative environment' sums it up, I think.
> I would never propose a VPEC-T study to a HK government
...
