Why MY Methodology?

Enjoy this sample of the Introduction for Just Do This where I describe why I wrote the book and what my Methodology is.

How I Discovered the Need for a Methodology

In the years before I worked for a large worldwide consulting organization, I was already noticing that my clients were very often frustrated. Tasks that should have been simple became complicated. They often took risks from the pressure to be more “Agile,” for which they weren’t ready. Very little was documented in the environments in which I found myself working, and all too frequently I would be tasked with “taking over” for someone who could not articulate where they were in a process because… they had no process. They just showed up to work, broke some things, fixed others, and were quite often either fired or sent to work in the Spice Mines of the Service Desk.

During my time with this and other consulting organizations (including my own), I learned how and had the opportunity to help them grow processes of their methodology. I taught their staff what I’d discovered about how to have proper documentation processes—methods which have continued improving since I left. I learned, firsthand, the difference between a professional consulting group that lived up to the value of their hourly rate just from having a better process than the companies they were serving and the groups who did not.

Over the years, I have helped several other companies hone or start their own services methodology. One, in particular, had a Professional Services process that involved over 12 steps!

I learned to keep it simple, a concept you’ll see throughout the book. As a part of being on various IT teams, either full-time or from contracts, I learned the value of a daily mindset of what I’m going to teach you. Change Control meetings went smoothly, and most importantly, there were fewer outages caused by changes being made. We spotted problems earlier and reduced costs.

Contrast that with a friend who has his team obsessed with the “new” way of working—an overtly complicated “DevOps” inspired methodology—which has tripled the amount of meetings, doubled the amount of staff effort, and caused several late nights of working… all to get a project “ready” faster.

We probably shouldn’t even talk about what happened when it all went horribly wrong, but I hate to see those “resume-generating opportunities” happen. I hate to see things go badly like that for the customer. I really do.

Equally dangerous is the reality for a misguided acquaintance who runs a small Managed Services Provider and cannot seem to escape work. He and his staff often work around the clock, never really able to relax. They are always fearful of what is around the corner, and typically serve the loudest complaint, because they operate with no real methodology at all. More or less, projects are swept aside, until there is a loud complaint about it that happens to be louder than the trouble complaints (that should go into a ticket system that they don’t even have). A simple methodology by which everyone could realistically abide would easily boost their business output by 50% or more, make for happier customers, and boast a staff that doesn’t “rage quit” (as they have dealt with so often).

That doesn’t even scratch the surface for the crushing reality of about 80% of the companies for which I’ve worked. Their stories always seemed to be the same—they have a small team that is already stretched beyond their capacity, and the team members rarely have the knowledge or experience to handle the technology with which they are tasked.

It isn’t just that they don’t appreciate the true nature of work, it’s that they rely on contractors to do so—contractors that are usually there for a short period of time to accomplish a single goal. This is not bad in and of itself; I would argue that a company that doesn’t rely on contractors in some capacity probably isn’t growing. The issue is that they have staff who don’t want to learn complicated methods. They want to go home, at the end of the evening, to their families. Adding contractors or throwing more staff at the problem doesn’t fix it. In fact, sometimes adding a contractor makes the staff groan because their eight-hour day just became an eleven-hour one.

And that, my friends, is the bottom line:

What does a Methodology do?

To me, there are several reasons to embrace a proper methodology, primarily which are:

• Reduce risks
• Reduce costs
• Leave things better than you found them
• Avoid resume/CV-generating opportunities
• Advance your career
• Take vacations
• Never worry about your evenings again

I’ll discuss the WHY of developing a methodology in much more detail as we go along, but before we do that, let’s begin with the end in mind and start with what a methodology is!

Introducing the riskLESS Methodology

To best accomplish this, the methodology I am starting you with has four phases:

1. UNDERSTAND
2. PLAN
3. CHANGE
4. MAINTAIN

I’m willing to bet that if you work in Information Technology at all, you already are familiar with these concepts, but it’s possible you never gave them a name. Most importantly, don’t miss the keyword of “iterative” in the definition of the process. Iterative, in this case, means that the intention is for each phase is to feed into the next, allowing for the possibility that it may need to come back with corrections. Iterative, in that you always expect the cycle to restart, but knowing each goal must be met before you continue.

Put simply:

After you UNDERSTAND (assess), you PLAN (from a design) what you will then CHANGE, with the goal to MAINTAIN. Then, in maintaining, you will also discover new needs or requirements, which leads you back into Understand, Plan, Change, and back to Maintain.

In our next article, we’ll dive deeper into what a methodology is – with more examples from the book, Just Do THIS, available now!