My Theory of Practice

July 10th, 2008  |  Published in Consulting  |  2 Comments

I finally had the reason to begin to more completely articulate my theory of practice. My theory of practice is different than my consulting philosophy. They certainly are consistent with each other, but they are distinct. A theory of practice, in my mind, outlines the methods and ideals behind how I get work done with clients. This theory includes the following elements that I think are key to my work:

  • Listening. Listening, both at the beginning, and consistently through an engagement, to their goals, ideals, “points of pain”, and points of confusion.
  • Educating. One of the most important roles I play is educating clients about the technology that they will be engaging with, based upon what I’ve heard while I’ve listened. This is also an ongoing process.
  • Intermediation. The role I play most often currently is providing a clear and understandable avenue between the client and a technology vendor (such as web or database development shop). The client is quite knowledgeable about their organization, mission, and goals for a project, but often not knowledgeable about technology. The vendor is expert at what they do, but cannot always provide a channel of communication that the client can really work with. I provide that clear channel, so both sides benefit.
  • Learning. Those first three elements make up the communication arm of my practice. The other arm is learning. I can’t do what I do without being a technology expert. And I can’t stay a technology expert without continually learning. Reading, research, collaborating with others, getting my hands dirty with servers and code, playing with new applications and new APIs - all of those things keep my technology expertise fresh.

More specifically, what methods do I use to help clients make their way through the entire process of a technology project:

  • Qualitative and Quantitative (where appropriate) assessment of requirements and needs, including surveys and interviews with internal (and/or external) stakeholders
  • Research - both standard internet research as well as outreach and interviews with relevant people
  • Writing - writing requirements, RFPs, documentation
  • Project management - keeping a project on track
  • Evaluation - evaluating projects as they are happening, and when they are done.

Responses

  1. Michele Martin says:

    July 11th, 2008 at 6:06 am (#)

    Michelle, I love this! What made you decide to write a theory of practice? This is a really interesting professional development activity, I think. . .

  2. admin says:

    July 11th, 2008 at 10:26 am (#)

    Thanks, Michele.

    Actually, a client had a grant proposal, and it included the consultant’s “theory of practice” which of course is something that most organizational development/effectiveness type consultants have, but rather few technology consultants have. I’d had bits and pieces of this in varied places, and in my head, but it was a good time to get it all down. Glad you like it. I think, actually, all technology consultants, whether they do what I do, or hack code, should do this exercise.

Leave a Response