The real problems with technology projects and technologists

I actually started writing this blog a week before Obamacare’s website snafus hit the media, but it further underlined my thoughts on what’s wrong with technology today – or rather, with technology projects and implementations.

I’ve had the privilege and honor to work with some extremely competent technologists over the years. Whether they were Microsoft Premiere teams, HP’s 3^rd level engineers, Verizon’s architects, support teams and DBA’s, or VMWare’s Implementation Engineers - these guys know their stuff.

To be as intelligent as we are though, we really know how to screw up a technology project. This has nothing to do with our “hard skills” and everything to do with the lack of “soft” skills.
·         Communication: Be honest with yourself. How well do you communicate? Specifically how well do you listen?
       o   Do you hear in 0’s and 1’s?
       o   Do you take the time to completely listen or are you already formulating your response?
       o   Have you ever sat down and watched a business person work through or on your support product?
     §  You would absolutely gain new respect for the business if you do.
Most techies would rather have their mouse taken away from them than talk with the business. Get over it. Start small by nodding and smiling as you walk by them in the halls.

·         Cross-Team Skills: Do you sit down with technologists from other teams and try to understand the limitations/abilities of the technology they support.
      o   When was the last time a DBA communicated with the application team that the adhoc report they needed put undue stress on the system if ran against production data?
      o   As an App support person, do you let the testing team know you are running “rough draft or dirty” on the newest release?
      o   Do you let a Project Manager know that you are concerned regarding release scope?
      o   Do you as Project Manager let the Business stakeholders know that you can’t meet proposed release dates with the resources available?
At the end of the day, you can only do what you can but if you don’t put yourself out there and talk with the other teams, it’s a great way to fail your team and your company.

·         Narrow versus broad: I’m not talking body style here but vision. What variables does your support area inject into the overall environment?
      o   You may be a great email administrator but do you necessarily understand data management requirements?
      o   Supporting messaging, BYOD admins are feeling the heat from the network guys because the network guys weren’t aware the messaging guys were going to start letting people use their mobile devices at the office.
There are no islands where technology is concerned. Keep in mind that OSI Model.

·         Think like a mortal:  (while I say that tongue-in-cheek) read that as – think like the business/customer/consumer
      o   I am going online to order something – is it easy? Is it obvious where/how I go about my task? Are there help tips to assist me?
           §  Is there an unnatural pause that makes me wonder if something is broken?
           §  Is there feedback that sets the pace for me?
      o   If your app is web-based, do you have sufficient web servers in place to support the potential audience?
           §  Do you consult with the network guys to confirm that the metrics match expectations?
           §  Do you work with the Virtual Environment support team in the event you need additional systems put into the load balancer?

·         Test like a mortal: You cannot test like a techy. We don’t work, think or act in the same manner that someone front-facing does. We don’t even type the same way. Accept it – we are not the business and therefore we need the business to test. Repeat after me: Just because I support the system does not mean I am smarter than or understand the business. Get the business to test.

I think that the traits that make us really good at what we do – also make us guilty of being arrogant – and therefore, unwilling or blind to accept that there are areas we don’t necessarily excel in. So now what? Look at it a little differently. Would you want to go to a doctor who had only received training in the skeletal system? Would you knowingly work in a building designed by an architect who didn’t understand the correlation between temperature change and materials used?  In order to better comprehend the whole, one has to understand not only their working piece of anything but also the impact to the whole.

The problem with technology training is that the focus is too narrow. The courses teach the HOW in the most narrow of circumstances but not the WHEN or WHY. This can be fixed though. Look at COBIT. Look at ITIL. These frameworks encourage communication, broad vision, working closely with the business, working closely with other technology teams. I cannot say enough about how a technologist can grow professionally once they consider the frameworks and their value.