Re: Any ideas on how to capture and share VPEC-T war stories...

[Gary Wood]

Hi al

I’m new to the group and have had a couple of email exchanges with
Nigel, and I promised I’d post the content here as it is relevant to
the war stories theme :

“….As I work with clients, I have found that there are an incredibly
small number of technology implementations (esp. Ent. Software/ERP)
that realise the benefits they were targeting. It also saddens me to
say, that most of the business users expectations of success (as they
define it) are very low, and it's not surprising based on our track
record- This was brought home to me a short while ago when talking to
business user (participant!) of a system we thought was successful
when she said " you gave us what we asked for but it turns out that
wasn't what we needed". It just so happens that the customer
generated process maps we followed were what management thought they
should be doing to operate, rather than what they were actually
doing. So this implementation has a significant chance of getting
into user adoption hell and becoming a non-trusted artifact of the
business. My initial thoughts were that we as a business and indeed
and industry need to be much more rigorous in the change management
practices to ensure the business embraces new capability but it so
much more than that. In the example above even if we had a massive
amount of emphasis on the CM, we still would have encountered problems
as we in actuality answering the wrong question.
So, my interest in VPEC-T is somewhat selfish; I need to demonstrate
clients that a large emphasis on the non-technical elements will have
enormous benefit in the successful adoption of tech downstream. That
does not necessarily mean that we have to do that work, but the
constituents tasked with the delivery of new technical capability
absolutely need to take a holistic approach, even if some of the
aspects of the VPEC-T framework make for some uncomfortable
conversations. By doing this, I feel there is scope for us to
differentiate from less enlightened competitors….."

Gary

[nigelp...@googlemail.com]

Thanks for the post Gary, it's great to hear thoughts from folk with a
business-development' focus. Your observation:

"It just so happens that the customer generated process maps we
followed were what management thought they should be doing to operate,
rather than what they were actually doing. So this implementation has
a significant chance of getting into user adoption hell and becoming
a non-trusted artifact of the business."

Is right on-the-money for me and pointsthree critical aspects of the
problem: -

1. the false belief that the top-down, grand-design (or CxO-led-buy-
your-way-to-standardisation-with-a-package) works,
2. a lack of understaing of the value of Enterprise Architecture by
the business (and often the IT dept.!)
3. the lack of focus on behaviour-based Enterprise Architecture by
architects.

n.

[Roy Grubb]

"you gave us what we asked for but it turns out that wasn't what we needed".

a.k.a. "the user doesn't know what she wants until she sees what she gets"
[still].

Roy

[nigel green]

Henry Ford "If I'd asked my customers what they wanted they'd say faster horses'
n

--
Mobile: +44 789 1150 181
Twitter:taoofit

Please visit:
http://www.LIThandbook.com
http://servicefab.blogspot.com

[John Schlesinger]

Dear Roy,
spot on. The only way around this (that I know of) is to develop incrementally. If you can, the agile approaches with 6 week increments are great. Otherwise, spiral is great with slightly longer increments (say 6 months). The idea here is to do a vision and scope, get money to develop the plan, spec and design and then get money to develop and test (a two-phase commitment of funds). Then you redo the vision and start again. It stops funding decisions being made on wild guesses and ensures that projects deliver while giving the customer and the user (usually not the same person) a chance to see what they are getting as early as possible.

Yours,

 

John Schlesinger
Home Phone +44 20 7833 5930
Mobile Phone +44 7794 353 356

---

From: Roy Grubb <royg...@gandanet.com.hk>
To: vpe...@googlegroups.com
Sent: Tuesday, January 13, 2009 10:28:19 AM

[Christopher Bird]

It is again further support for the grand lie that you can actually and realistically do process decomposition. Process abstractions are handy partitioning mechanisms for thinking about the broad functions of the business. It is handy, for example to think in terms like "Order to Cash", but it isn't necessarily helpful to decompose this into tiny step details. Certainly not as a design principle.

 

We do need processes - as outputs not as inputs. We need to describe to people how to use what was built - we don't need to make the process definition the primary input to the development.

 

If we are trying to discover how current systems work, then we should not rely on what people think they do, we should attempt to determine what they actually do. Wit systems that isnt necessarily hard - we can easily (well relatively) insert some kind of sniffing/analysis technology (e.g. OpenConnect's Comprehend tool www.oc.com) that shows exactly what actions have been taken. Of course that doesn't take into account actions in the process that occur outside of the system being monitored.

[Adrian Apthorp]

A quick response to the subject line of this post. I wonder if a variant
on one of the pattern (or anti-pattern) templates might provide a useful
way of distilling the effect of VPEC-T dimensions in certain situations.

...oh and have a browse of the original anti-patterns book. Not quite
the thrust of VPEC-T, but one or two related anti-patterns...

[Adrian Apthorp]

I think one of the common mistakes that is made with detailed
(physical) process models is that they are treated as a requirement
for the information system, rather being designed in concert with
designing the IT system to deliver an overall design for the target
integrated (business) system.

To Chris's point it is the abstracted views that help to establish the
system boundaries.

On Jan 13, 1:37 pm, "Christopher Bird" <seabir...@gmail.com> wrote:
> It is again further support for the grand lie that you can actually and
> realistically do process decomposition. Process abstractions are handy
> partitioning mechanisms for thinking about the broad functions of the
> business. It is handy, for example to think in terms like "Order to Cash",
> but it isn't necessarily helpful to decompose this into tiny step details.
> Certainly not as a design principle.
>
> We do need processes - as outputs not as inputs. We need to describe to
> people how to use what was built - we don't need to make the process
> definition the primary input to the development.
>
> If we are trying to discover how current systems work, then we should not
> rely on what people think they do, we should attempt to determine what they
> actually do. Wit systems that isnt necessarily hard - we can easily (well
> relatively) insert some kind of sniffing/analysis technology (e.g.

> OpenConnect's Comprehend toolwww.oc.com) that shows exactly what actions

> have been taken. Of course that doesn't take into account actions in the
> process that occur outside of the system being monitored.
>

> On Tue, Jan 13, 2009 at 4:07 AM, nigelpsgr...@googlemail.com <

> --
> My kitchen bloghttp://seabirdskitchen.blogspot.com