Blueprint? RDS don’t need no stinkin’ Blueprint

Strong SAP SDN post by Mark Chaffen on SAP RDS (Rapid Deployment Solutions) and the case of the missing Blueprint.   I’ve only started to dig in to the topic, so these are my (likely half-baked) first thoughts:

On balance “no Blueprint” is good.  Its exclusion reinforces that a RDS implementation is of a fixed, limited scope.  There must always be some sort of scope statement, of course, and its there.  Unfortunately, “Blueprint” seems to equal “everything and the kitchen sink” in some SI’s SAP glossaries!  Wise to make a clean break in the lexicon. Avoid Death by Change Order.   RDS is designed to deliver only what one needs to execute — the wish list comes later.  Only fill in regulatory, statutory, or other compliance gaps during the initial implementation; otherwise make a conscious decision to remaining requirements into  backlogs that get burned down release-by-release.  RDS still too “new solution” oriented.  There are other ways to expand a SAP footprint… how about RDS for acquisitions, divestitures, or other growth/transformation scenarios?

More kudos for Pro.NET Best Practices (RT @ruthlesshelp)

Pro .NET Best Practices gets a great review from Tad Anderson in the .NET Developer’s Journal http://t.co/I0W5P4lL. 
I loved the reviewer’s lede:

I personally do not find software development an art form. It is not an unpredictable activity driven by crazy business users that come to work every day inventing a new way to operate their businesses just to savagely changing your requirements. Project teams that use changing requirements as an excuse for their dates constantly slipping and bugs being pushed to production are simply not good development teams and they are poorly managed.

The cargo cult of business jargon

Flight of fancy...now boarding!

My first thought when I saw this post by Glen Alleman was ”cargo cult“. 

I’m wary of concepts from hard sciences that find their way into business jargon, largely because the concepts become incantations.  It feels like we’re appropriating the prestige of science, just like a cargo cult’s “focus on obtaining the material wealth (the “cargo”) of the advanced culture through magic and religious rituals and practices.”

In other words, I cringe when I hear incantations like — “complexity”, “emergent”, etc. — as if the words in and of themselves suffice.   It’s nothing but meaningless superstition without insight and actions that solve problems or exploit opportunities.

Using analogy to communicate complexity

Glen Alleman posts here on the need to ensure that analogies fit the domain.  He notes a common problem with metaphors, especially those adapted from math or science.  They sound right to the layman, but are off-key to the expert.

This insight provoked a few thought on analogies in the ERP world.  We often use analogies to convey the complexity of ERP: changing the engines on an in-flight 747 is very popular.  It sure sounds tough, doesn’t it?  And the image is powerful and vivid, but does it have anything to do with how ERP really works with your business?  Also, who has ever done something like that?

I’ve found that it is much more effective to leverage metaphors that are a bit more concrete.  For example, I’ve found that a conversation about ERP as “a model of your business that operates in real time” gets me down a better path.  We can then move on to concrete visualizations that model — from Tinker Toys, to Lincoln Logs, to K-Nex, to Lego, to Erector Sets, to HeathKits — that come from the participants, not from me.

Lenin and Driving Change

When Vladimir Lenin posed this question in 1901, socialism was riven.  Most early Marxists believed that the core prediction of Marx’s theory — an inevitable proletarian revolution — was just around the corner.  But by the turn of the 20th century, the revolution appeared farther away than ever.  If anything, the contradictions among the classes were cooling in advanced capitalist states, not boiling over.  

So why the two-bit summary of a turn-of-the-20th century dispute among socialists?  Simply this: Lenin’s pamphlet paved the path for revolutionaries around the world.  As I was noodling on The Meaning of #Stoos, I re-read it and picked out a few things that change agents can learn from Lenin:

Show that you know “What Is To Be Done?”  The title itself is a clear call to change, which Lenin knew would intrigue and inspire his audience.  It also hints that he had the answer. Show that you know the problem  Lenin realized that Marxist theory was a powerful “call to take the field against the enemy.”   But its guidance was so focused on the economics of workers vs. capital  that most volunteers went into “battle with astonishingly primitive equipment and training.”  Success would take a group of professional revolutionaries  using “all the rules of the art” of organizing.  Furthermore, his arguments hit hardest Read more »

Ranchers and Farmers…living together!

Nice post here by Hass Chapman on hunter-gatherers, play & software development.   I can definitely relate to the way of working outlined.  While we were hunter-gatherers, we did take to agriculture eventually. 

That move is not natural for me, though.  I’m more of a rancher than a farmer.   The challenge for me, therefore, is how to accommodate other styles of work. 

To highlight potential role mismatches, I fall back on models like the “finders, grinders, minders” consulting model David Maister popularized.   Consulting comes to mind because I’ve often heard customers say: “I’d like the folks who built it to be the ones who support it.”  That sounds plausible in theory, but that usually involves taking a “grinder” and making him/her a “minder”.  Which rarely works unless that person is explicitly looking to change his/her lifestyle.

Great example of value of architecture governance (RT @mkrigsman #CIO #entarch)

Michael Krigsman received a lot of good feedback on his post about getting IT and business together. The second point was top of mind as we’re standing up new and improved architecture governance.

A basic governance checklist can catch the type of folly Michael describes. A project that proposes to create an app entirely from scratch — like Michael’s example — should stand out as an initiative to receive heightened scrutiny. Well, it should if you have a set of standards! But that’s another post!

‘Pocket Neighborhoods’ For Sustainable Suburbs

I loved this Atlantic piece about “pocket neighborhoods”, though the suburbs weren’t the application that first came to mind.  This design philosophy appears perfect for those “blighty” neighborhoods I see in town, just off the core.  They’re often convenient locations that become marginal because of a dodgy block or a rundown house (or three). 

Unfortunately, most of our redevelopment arsenal destroys the village in order to save it.  I’m not just talking about old-school urban renewal with its high-rise projects and sterile plazas.  The mixed-use redevelopment now in vogue tends to a gigantism that overwhelms the character of the surviving neighborhood, even if there’s a nod to affordability in the planning.  On the other hand, single home approaches — think Habitat for Humanity — can fix a house or two.  However, they can stick out like a crude cap on a broken tooth.

Pocket neighborhoods are an intriguing response to this challenge.   They have enough scale to completely repair parts of bad blocks – like a well-fitted crown replaces a bad tooth — while connecting to the still-vibrant villages beside them.   If well done, they also don’t scream “I’m poorly-built affordable housing”!

Rethinking Performance Reviews for 2012

Dan Markovitz at Timeback reminds us that performance reviews are a dangerous exercise. Even if we grant their utility,  they have a profound credibility gap to bridge.

Leaders must go into performance discussions with a humble heart.  As Dan’s notes, your colleagues likely will be very skeptical about the usefulness of those chats you’re about to have.

Guidance for building a credible plan

Glen Alleman suggests that you download this and put it to work on projects.  However, for some the defense focus and jargon are daunting or off putting.  My suggestion for putting this guidance to work: first transform the tables into a checklist or two. 

The “validity” topic focuses you on whether a plan is ready for “prime time”.  Use this when evaluating early stage gates.  The ”effective”  items are obviously relevant as one evaluates the quality of your projects’ execution.  These items should be a part of regular status reporting.

Then learn what “level of effort” means!

Follow

Get every new post delivered to your Inbox.

Join 110 other followers

loading
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.


You are viewing a mobilized version of this site...
View original page here

Mobilized by Mowser Mowser