Posts Tagged ‘methodology’


 Methodologies abound in change management and process engineering. I’ve worked extensively with a few, been exposed to a few more and have read about countless others. I have my opinions on many of them but that would take days to ramble through and not necessary today.

What I want to talk about today is the need to define your own approach. I don’t mean you need to invent one (That would be quite the assignment), and I don’t wish for you to regurgitate the text book definition of a method you favor. What I mean is that we all have a way of approaching projects that have evolved over time based on our own experiences and our exposure or study of methodologies.

What is the benefit of doing this, you might ask. Sometimes we are so busy doing our jobs we don’t take time to reflect on how we are doing them. This is a good exercise to explore how we currently think even if you never show it to anyone. Our approaches should be fluid so this is good periodic exercise to see how we are changing.

I have come to find that there is nothing like having to explain your approach as a way of synthesizing what it is. You must organize all the thoughts and actions you might take into a workable and actionable framework. You must clarify the reasons and objectives behind these thoughts and actions. You must clarify expectations and roles.

You might also find holes or weaknesses in your approach. If necessary you can then go in search of tools and techniques to fill the holes. A good motivator to search out knowledge.

As you do this you begin to see where a whole trove of philosophies you’ve adopted fit. Like all the blogs that have come before this for me. These ideas and techniques all fit somewhere in my method. Then they begin to become more present. More available.

Once you have done this your ability to walk a new partner through your approach becomes much easier . Communication becomes so much easier. You feel much more in control.

You might even have more than one approach depending on the context of the project. That’s good. Flexibility is valuable.

I’ll end by giving you an abbreviated example of my approach. I call it the Lewis and Clark method. You can tell I’m not a professional method designer because first letters of the sections of the method don’t spell anything. They just make sense. This method assumes I already have a vision or a goal for my project.

Explore, Map, Analyze, Decide, Move, Repeat


Look around. Get to know the people, the lay of the land. Educate. Build bonds. Build skills.


Visualize the situation. Get down as much as you currently know that lies between you and the goal. Don’t map too far ahead. Educate. Build bonds. Build skills.


See what the map tells you. Gather more information and data based on what you know and where you want to go. Look at the map again. Find some places you can reasonably get to. Educate. Build bonds. Build skills.


Make the best decision you can with what you currently know. Be flexible. Take what the beast will give. Choose your destination. Identify necessary resources, give assignments and roles. Educate. Build bonds. Build skills.


You can send a scout by doing a prototype or you can do a pilot by using a whole team. You just need to move and be directionally accurate. Educate. Build bonds. Build skills.


Once you are near or at your sub-goal you start over by exploring the new conditions.

This is just a shell and I could add all sorts of actions around relationship building and communication and so on. I could visualize it. Make a presentation with all sorts of paths and graphics (which I did do about a year ago).

But this alone allows me to talk about my approach with ease. Once I had more specifics on a project I could begin to fill in with more specific tools and techniques I might use.

You’ll notice I repeated educate, build bonds, build skills. That’s the piece for me that is so often missing. So I put it in all phases to remind me.

Your approach will look different because we all have different backgrounds and experiences. Give it a try. See what you can learn about yourself.



I don’t know when it was I realized I had my own personal philosophy on how to get things done. I suppose it’s unique in that it’s my own alchemical amalgamation of existing philosophies. Perhaps this was bound to happen since my basic view on life has always been that there is no one method or school of thought that has all the answers. I suppose a quite pragmatic view at the end of the day.

Perhaps it was my dislike of absolutes and excessive certainty that led me to my alchemy. Consistent run ins with consultants and experts excessively tied to their methodologies rankled my sensibilities. I naturally rebelled.

At the end of the day that probably wouldn’t have mattered much (you see us process people have large egos and we all think we are right), except that I noticed the reactions of the people they were supposed to be helping. Defensiveness is natural when trying  to “help” an organization. So that was never alarming. What was alarming was the unnecessarily high levels of distrust and dislike exhibited by the organization. Exhibited in reaction to the ego-driven, heavy handed, unempathetic demeanor put forth. A serious turn off.

I didn’t want to be like that. I couldn’t be like that.

So while other engineers were designing their future states, I was building relationships. Methodologies were useless if no one wanted you to be there. So that’s where I began to diverge. And that’s when I became a misfit.

Now there are many other qualities that make me a misfit that we’ll get to eventually.  But I like it. I find advantage in it. And it works.

So we’ll talk about those kinds of things. And some of it you’ll love and some of it you’ll hate. And that’s just the way it will have to be.