Why hire a local consultant?

Posted by Robert Merrill on July 25, 2009 under uFunctional Values | Be the First to Comment

When you’re on your own like me, you take what comes in terms of client engagements. There’s that daughter in college, after all. And I can’t seem to shake this food addiction.

But my compass consistently points towards local, part-time, long-term engagements. That’s what I sow and cultivate.

I have a value-proposition reason, a forward-looking reason, and a personal reason.

  • Change for the better grows best in a steady, soaking rain of consulting, not a cloudburst.
  • Rapidly rising travel costs and finally-effective telepresence technology are about to transform the economics of consulting.
  • I don’t like to travel.

The Information Age has already transformed consulting. You no longer have to fly in the expert knowledge. You can webinar it, podcast it, blog it, feed it, Tweet it, Kindle it, or still use old-school ink-on-dead-trees. Information isn’t the problem, it’s application. In the area I know best, software development, the gap between “best practice” (if there is such a thing) and current, local practice is typically huge. Good-enough information that soaks in steadily, beats a downpour of best-of-breed information that runs off.

In the traditional  “Airborne Consulting” model, the high-powered experts parachute in. Read more of this article »

Jack and Jesus talk Work-Life Balance

Posted by Robert Merrill on July 14, 2009 under uFunctional Values | Be the First to Comment

No such thing as work-life balance.” —Jack Welch
No one can serve two masters. You can’t serve both God and Money.” —Jesus Christ

Why I’m able to sell

Posted by Robert Merrill on under uFunctional Values | Be the First to Comment

I heard that. Stop laughing.

No less than the Harvard Business Review just confirmed what I felt all along—the only reason I can sell at all is that I sell for a company I love.

Read the third comment to the HBR article—it saddens me, but also renews my determination to be different. Right now, uFunctional is just me. I love what I do (most days, anyway) and I believe in it. Get me started talking about software-intensive businesses and how to form a combined team of bizzies and techies and create value by creating software, and you can’t get me stopped.

It’s a problem. I just posted a comment to Roxx Allaire’s post, “What are the 7 Keys to Success in Sales,” that a key skill is Listening. Oops.

If uFunctional ever grows beyond just me, I hope I have the courage to keep it a team that those who represent it can love, and summarily fire those who would undermine that.

Failing that, I hope I have the courage to scuttle the whole thing.

Function Points and Agile Methods (I promise I won’t tell)

Posted by Robert Merrill on July 13, 2009 under Agile BA, Agile Methods, Estimation | Read the First Comment

If you’re an IT shop considering agile methods, your existing Function Point Analysis (FPA) capability can be a a valuable asset. It freaks many agile-methods advocates out when I tell them, but I routinely follow a user story workshop with a Function Point count.

I already knew FPA when the project-contracting house I worked for went agile. I found I could count the Function Points from a couple of dozen user stories in a half day or less. (Often I discovered some missed stories in the process.) With some project history on hours per FP for the teams I supported, and some multiplication, I had a quick, factor-of-two effort estimate. Flip the factor-of-two uncertainty off of the effort and onto the scope (you know those stories are going to change, anyway), and there’s the core of an agile project proposal. We had about a 1-in-3 close rate, and less than 10% of our projects failed.

Now that I’m consulting for software-intensive businesses and their software teams, the same estimate can be used to request a team and a budget through your established governance process. Read more of this article »

Non-functional requirements template

Posted by Robert Merrill on July 2, 2009 under Business Analysis and Requirements | Be the First to Comment

From Use Cases to User Stories, I’ve always struggled with how to treat the non-functional requirements. I haven’t tried it yet, but this article by Ryan Shriver on Qualities and User Stories contains something that looks like it just might work:

Name: A unique name for the quality

Scale: “What” you’ll measure (aka the units of measure, such as seconds)

Meter: “How” you’ll measure (aka the device you’ll use to obtain measurements)

Target: The level of performance you’re aiming to achieve (how good it can be)

Constraint: The level of performance you’re trying to avoid (how bad it can be)

Benchmark: Your current level of performance. Read more of this article »