Motley says: "Consulting? I guess your answer from here on out is ‘It depends’" (HPT Part 1)



    Summary


     


    Motley:  How could a consulting methodology help me? There's no way - I work in a product company.


     


    Maven: Human Performance Technology (HPT) is an effective consulting methodology that uses a simple process to identify the root cause of human performance issues and build creative solutions to those problems.


    ______________________________


     


    [Context: Maven and Motley are having a discussion on what Maven used to do before joining the company]


     


    Maven: Did I ever tell you that I was once in the consulting world?


     


    Motley: It depends. Hahahaha. Isn't that the consultant's answer for everything?


     


    Maven: Very funny, wise guy.


     


    Motley: Yeah, I'm quite the comedian. I'm not surprised in your background though given that you are always trying to solve people's problems around here. I even heard you talking to Morton the other day about some problems his daughter is having. You get your hands into everything!


     


    Maven: Sometimes I can't help myself. I love to see the world improve! Did you know there is a method to my madness? I use a technique called Human Performance Technology, or HPT. You don't have to be a consultant to use it - all you need is a systemic human performance problem to solve. It's more of a problem solving technique  than a consulting technique.


     


    Motley: "Human Performance Technology"??? You make it sound like we're all robots. So you use computers to pop out the answer when faced with a consulting problem?


     


    Maven: Not exactly. "Technology" is used in a broader sense. Here is an overview of the technique:


     


    clip_image001


     


     


    Motley: Wow. That looks like a bunch of psychological gobbly-goop. I'm not sure I even want to hear all the background on that stuff. Looks complicated.


     


    Maven: Actually, it's quite easy! Here's how-


     


    Motley: Wait! I, errrr, have a plane to catch.


     


    Maven: You have to work on your "stretching the truth" skills, bud. Anyway, this won't take long. What do you do when you have a problem to solve? Say, for example, someone comes to you indicating that builds keep breaking. What is your process for solving that problem?


     


    Motley: Easy. Put continuous integration in place as we discussed.


     


    Maven: You've been paying attention! Well, continuous integration may or may not be the right solution. The trick is not jumping to solutions, but examining the problem. The first step is to assess the business need.


     


    Motley: Well of course the business needs no build breaks.


     


    Maven: Yes, but it is important to understand why. What is the impact to the business' bottom line? Should we solve this problem over something else? What makes this problem more important than others? You want to ensure you are putting effort into the right problem.


     


    Motley: Well, for build breaks, it's pretty obvious. The daily build is our lifeline. Without a build everyone on the product team is blocked and we potentially delay shipping the product, which affects the business. It's also a quality issue.


     


    Maven: Cool. Next you want to think about what your ideal future state looks like. This is called your "to be" state, or where we want to be when we are executing near perfectly. What is that ideal future state?


     


    Motley: Hmmm… for builds, we want a build without compiler and link errors every day. I would also think we want the Build Verification Tests (BVTs) to consistently pass.  In addition, I want statistics gathered on every build around code churn, I want instantaneous communication in the rare event there is a problem with the build, I don't want a full-time build person looking after it, and most importantly, I want a latte automatically made for me every time the build passes.


     


    Maven:  Well, I'll try and forget the last one, but the rest are great! Before we can get there, however, we need to understand the current state. What is the state of the build today?


     


    Motley: Periodic build breaks that still happen too frequently. Developers that are still too sloppy. We've been trying to address the issue with continuous integration (CI) but the CI server is being overloaded by the problems that developers are checking in. It's far less than ideal. Plus, I am not getting my lattes.


     


    Maven: Now that we have an understanding of where we are and where we want to go, it's important to understand the gap that is getting in the way of us getting there. Not only do we want to understand the symptoms but the real problems that are causing the gap.


     


    Motley: Right. Back to the root cause analysis discussion we had. The "Five Why's" for example.


     


    Maven: You bet! In addition to asking "why", we can leverage the six dimensions shown in the diagram above to help us get to the root cause of our issues, and also help us come up with creative solutions to our problems.


     


    Motley: I thought you said this won't take long!!!


     


    Maven: Bear with me here. Doesn't this model sound great? Don't you want to know more?


     


    Motley: I just felt another gray hair pop out, and it's your fault. Fine - finish off your model...


     


    ______________________________


     


    Maven's Pointer:  There is a central organization that focuses on HPT called the International Society for Performance Improvement. HPT analysis leverages various other disciplines including behavioral psychology, instructional systems design, organizational development, and human resources management. The central idea is to improve human performance by focusing on measurable results while looking at the big picture (a systems view). HPT is a systematic approach at identifying and solving performance problems in the workplace and beyond.


     


    Maven's Resources: 


Skip to main content