Charlie Alfred’s Weblog

Value Modeling Story 1

The previous three posts discussed various aspects of value modeling,  including:

o  How value models focus on the “why?” and “what?” aspects of understanding a problem

o  The significance of objective vs. subjective perceptions of benefit, constraints, and uncertainty

o  How understanding differences between these subjective perceptions help us identify contexts

While these statements sound nice, are they relevant in the real world?   I’d like to use this post to tell the first of several “value model stories.”  These stories describe real-life situations in which value  models are particularly useful tools.

The setting for the first story is a company where I worked for eight years, left for a year, then came back.  This company provides consulting and outsourced software development services, primarily in the medical, industrial equipment, and aerospace industries.  During the year prior to my departure, I was heavily involved in the creation of an internal training program.  The goal of this program was to develop more people with skills to be consultants.  This program was part of an overall business strategy to develop a more significant on-going relationship with our customers.

In our lines of business, consultants faced some difficult challenges:

Variation      Successive project engagements are rarely in the same problem domain

Learning      They lack sufficient time to ramp themselves up in the domain before engaging

Conceptual   They need to quickly discover, acquire information, and make sense of it 

Rapport        They need to connect with their clients and communicate clearly with them

Courage        They must learn to be comfortable with the prospect of feeling uncomfortable

We began with people from a variety of backgrounds: including software architects, principal software engineers, and project managers.  All had been successful in these roles, and were being asked to “step up” to play a more significant role.

The resulting course was an intensive two-week effort involving 15  segments and a full-blown case study which simulated a real world consulting experience.  The subject matter covered a wide range of topics  such as: corporate strategy, finance, systems thinking, systems dynamics, critical thinking, product strategy, value modeling, software architecture, facilitation, negotiation, presentation skills, and writing.  The focus of the lecture material was theoretical and conception.  This was intentional, given the skill sets of the intended participants and the wide variety of situations that consultants find themselves in.  In other words, one of our main goals was to prepare people to recognize and improvise.

Over the course of fourteen months, this course was taught four times to a total of 15 students.  I taught the first three courses, and a team of three instructors taught the fourth.  The course consistently got very good to excellent ratings from the people who took it.

After I left, a related need was recognized to develop more software architects.  The consulting training course contained a segment on value modeling and two others on architecture.  It also contained a few other segments which  were deemed to be relevant to software architecture.  As a result, a software architecture training course was extracted from a subset of the existing consulting training course.

Here is where the value modeling lesson comes in.

Let’s start by looking at the consulting and software architecture students as different contexts, and analyze their respective value models:

Software Architecture

The typical student:

o  enters the course as senior or principal software engineers

o  spends much of their time designing, coding, and testing solutions

o  often works for 9-18 months on the same project

o  starts to get involved after the problem is understood and solution is framed

o  has some experience reading software architecture descriptions, but little experience creating one

o  has not had a lot of experience leading discussions or discovery sessions with customers

Consultant

The typical student:

o  enters the course as a software architect, project manager, or sometimes a principal engineer

o  spends much of their time interacting with customers, discussing plans, problems, or risks

o  may work for 9-18 months on a project, or may work on 3 different projects in six months

o  has a wider perspective on projects and systems, some have created architectures

o  anticipates being “first on the ground” in unfamiliar territory 

So.  Here’s the $64,000 question:  What is the likelihood that repurposing a course to train software architects that has proven to be suitable for training consultants? 

If your answer is “Slim and None, and Slim just left town,”  you would be close.  While the software architecture class did provide some value, it didn’t really meet the needs of the participants.   Specifically, they were looking more for a practical “how to” course, one that was heavier on the process and lighter on the concepts and theory.  They wanted one consistent set of examples, not a wide variety;  they weren’t as motivated by the perceived need to adapt rapidly to unfamiliar situations.  And because they started with less familiarity with architecture and customer interaction, they wanted to spend more time being mentored, while working on a sample problem.

In retrospect, none of this is particularly surprising.  Also in retrospect, it is particularly easy to believe that something that is suitable for one use, is likely to be suitable for one that is pretty similar.  Value models help avoid that sort of mistake, by highlighting how differences in value expectations and constraints lead to different high-priority challenges.

With the consulting training class, the high priority challenge was preparing people to come up  to speed quickly in a wide variety of new situations.  With the software architecture class, the high priority challenge was teaching them what an architect is concerned with, and how s/he goes about discovering what the problem is and how to best attack it.  Similar, but different in some very fundamental ways.

Advertisements

1 Comment

  1. This is wonderful blog. I love it.

    Comment by Shona Sterns — September 9, 2010 @ 1:45 pm


RSS feed for comments on this post. TrackBack URI

Create a free website or blog at WordPress.com.

%d bloggers like this: