I can’t even recall how many times I’ve been in this situation:  A new release goes out and several new features aren’t working properly.  Worse yet, existing functionality is now compromised.  This was a common occurrence during my incident management days, and I hear about it throughout the IT Service Management world.  The absolute worst reaction a person, or even a team, can have is to suddenly start placing blame.    Doing so really is just futile and a waste of time because in reality, these problems don’t start during build or development.  They don’t even start during design.  The source can usually be traced to a time before any new project is even started.  In fact, it goes all the way to how a team operates to deliver value.

Maybe I’m thinking about this topic because of my recent read of The Phoenix Project.  Maybe it’s in my head since I’m wondering how IT will evolve during the supposed impending IT & business singularity event.  Either way, the quality of a product can’t be tested right before production.  In fact, it can’t be tested in a single event, but things like quality assurance and governance have to be considered during the entire lifecycle, not just as checkboxes on a project management document.  This is where focus on execution needs to occur.  If a team is working efficiently and diligently, calling out flaws during each and every phase, be it an agile or waterfall build, then by the time the product reaches production, everyone can be comfortable in the end result.  With this in mind, here’s some advice on how to get away from focusing on a final product, and instead focus on the actions and execution:

1.  Focus on one thing at a time

I still don’t understand how my wife can multitask, but one thing is for sure, I don’t do it very well.  Since I consider myself to be fairly average (more on that later), I’m willing to bet most people in IT are single taskers.  There’s already been research on the topic so if you want to know more, feel free to do a search on Google.  The fact that focusing on a specific task can decrease defects is why kanban is gaining in popularity.  If you haven’t tried it yet, I strongly encourage you to do so.

2.  Minimize distractions of key resources

Do you know the name of that guy in IT that seems to know everything?  Not only is he skilled to work on 20 projects at once, but he’s also the “go to” person for fixing things.  Keep in mind, every distraction, a.k.a. incident, that your key resources have to fix is more time away from value-adding projects.  If that person’s knowledge is so valuable, then why isn’t it being captured to share with others?

3.  Knowledge is power (also – sharing is caring)

I’ll admit it.  I love being in a position of the “know it all.”  Not only does my ego get stroked, but it feels great to be valued.  Unfortunately, hoarding of knowledge only hurts the entire organization.  The only way #2 can be achieved is by getting the common knowledge scribed into a knowledgebase for all to enjoy.

4.  Go agile

Look, I understand there are circumstances in which the traditional waterfall approach to development is the best way to go.  Unfortunately, those circumstances usually involve consultants and a lot of departmental overhaul, to be revealed as a “big bang.”  If you have a product and want to release new features, and still want to meet #1 above, then you have to focus on a single feature at a time, and to do it quickly.  This also doesn’t mean just developing a new feature and waiting for more to be completed for testing.  It means development, test, deploy….and to keep doing it again.  If you’re running regular releases and are deploying multiple features in a release, at least deploy to a staging environment so all features can be tested as they’re added.

5.  Go forth and fail

I'll be back

I’ll be back

Nobody likes to fail at anything.  I’ve done it countless of times and I still haven’t gotten used to it.  Of course, all the brilliantly successful people will tell you to not be afraid to fail because without taking risks, you won’t even have a chance to succeed.  With that in mind, I’m going to say go out and fail.  Don’t specifically try to achieve failure, but if something doesn’t work you should just look failure right in the eye and say “I’ll be back.”

Please keep in mind, none of these ideas are inherently new to the world.  You can read The Goal or The Phoenix Project to know more, but with today’s technology, it blows my mind with our potential in the IT world.  Sure, “the business” will eventually take over, or maybe it’ll be the other way around, but if you have the right execution and vision for a service, then the opportunities are limitless.

********** END POSITIVE RANT ************

avatar

Started working in IT in 1999 as a support desk analyst as a way to help pay for food during college. Studied Electrical Engineering for two years before realizing biochemistry was more fun than differential equations, and so ultimately graduated with a Biology degree in 2006. Having (reluctantly) failed at getting accepted into dental school, embraced working in IT and has gone broke becoming an ITIL Expert. Likes to jog, sing camp songs, quote Mel Brooks movie lines and make dumb jokes and loves working for an Israeli tech company where December 25th is a regular work day.