Are PM's in the Services or Experience business?

I recently read The Experience Economy after hearing Tom Peters refer to it in an old speech of his I try to listen to annually. The book talks about progressing from selling commodities, to products, to services, to experiences, and ultimately to transformations. One of the things that struck me was the notion of what you leave behind or what does the customer/client get to keep or come away with after the transaction. With goods they obviously get to take home the item they purchased. With services it can be s a bit tricky. Maybe they get a new haircut or a fixed car. When you buy an experience you take with you a memory (say of your Disney vacation) or a new skill (like a certification). After a transformation you walk away with a new outlook or a new organization.

It got me thinking. As a consultant coming in to manage a portfolio of projects for a client, what business am I really in? Frankly I think I've framed what I do as being in the services business. My client gets projects done well, on time, and within budget. My firm bills for the hours I work. I get paid. Services rendered.

Hmmm. What if I wanted to be in the experience business instead?

So now I still manage a portfolio of IT projects on time and within budget. But with my new paradigm I've started to also spend focused time with the business analysts, project leads, vendors, and the executives I work with slowing down a bit and training them on various aspects of what I do for them. I'm leaving behind useful skills in the organization and in their partners that will allow my client to analyze situations, manage projects, lead changes, and do a number of other related things they may not have been able to do before. I want my clients to have the memory of being part of a well-oiled team working toward something that matters. In short, I want them to think back on this time as me having orchestrated a great experience they were fortunate to be a part of--not just as someone who managed a bunch of projects.

This is something I continue to work on. The next step is to create transformations through my consulting.

What business are you in?

Lessons in business analysis from MS Courier

I'm just as excited as the next IT gadget geek to see what Microsoft releases with its upcoming dual screen Courier Digital Journal. But rather than speculate on what features it may or may not have, I want to pause to observe something about the preliminary videos we're seeing pop up--particularly the ones found on engadget.

Watch the videos, and even without sound you get it. You know what this device should do. You have a good idea of who it's for. How many pages of written requirements would it take to convey all the information you just received from this short video?

Watch Joe Levine's TED talk on a proposed mission to Mars and you come to the same conclusion: in a few minutes of video you find yourself saying that's possible. You are previewing the future. It's a simulation, but somehow tangible at the same time. How many words would it take to convey the same information? And how long would that take to digest?

I've spent a lot of years writing requirements documents for software and technology projects. They still have their place. But what is the single most important skill for business analysts of today and tomorrow? Film making.

From Piano Practice to Self Expression

My 11 year old has turned a corner on the piano. Instead of having to remind him multiple times a day to practice and setting up job charts as reminders with rewards for doing it, he stumbles downstairs first thing in the morning and begins playing before he's even spoken to anyone. He sits down and plays when he gets home from school. He plays a few times throughout the evening. The difference seems to be that he's finally hit a tipping point in his skill level where he can play a handful of songs well from memory and he's beginning to feel the release of self expression through his music (I can't think of many motivators more powerful than self expression).

The next time you notice resistance to some new business processes, instead of reiterating the "why we did this and why it's best for the company" speech, try helping the individuals in question gain more skill at using them. Help them to become more proficient.

Isolate and Duplicate

A large part of troubleshooting can be summarized by two words: isolate and duplicate.

Can we make it do whatever it did the last time when it didn't work right--again? And again? (duplicate.)

And under what conditions? What about when we're not doing the "happy path" or normal use case and are on this particular variance? In other words, does your engine light come on all the time or just when you're at a stop light? Or even better, when you're at a stop light in 95 degree heat, etc. (isolate.)

We could all save ourselves and the growing number of technical support staff we must appeal to on a regular basis to get through our day-to-day lives if we try to do these two things before we make our appeal.

Using Basecamp for Requirements Analysis

I'm working on a project now where we're moving from System A to System B and 17 groups within the company will be affected. We naturally set up meetings with each group to explain the motivation for the changes, outline the proposed architecture, and more importantly analyze their current processes and requirements so we can foresee their needs in the new environment and the impact the intended system would have on their workflow and systems. Usually at each meeting we'd have representatives from the stakeholder as well as from the sponsoring business unit who are responsible for the new system--all taking notes.

I wanted the requirements to reflect all of our notes so I set up a Basecamp site for the project and created a Writeboard for each of the 17 groups. I then posted my notes as Version One of the Writeboard and invited the members of the business unit who attended to review/edit them by a deadline (which I posted as a Milestone). This worked remarkably well. Some went in and edited the text while others just added comments at the bottom, but it saved us from having 17 Word files with track changes turned on bouncing around several people's inboxes.

When the deadline came, I simply exported each Writeboard to a network drive and summarized the notes into a requirements document (which I posted in the Files section).

I used this same approach with the project charter.