I have been fortunate to have a varied career in IT. I have worked for managed service providers, cloud service providers, software vendors, as an independent IT consultant, as a consultant for contracting companies and as part of in-house IT teams. It’s the latter that has been the most beneficial to me. I have concluded that to be good at your job at providing hosted services, enterprise focused products or even consultancy, spending some time on the frontline of enterprise IT is invaluable.
While working as part of an EUC team in an organization’s IT department you inevitably work with hired consultants. If you have only ever worked as a consultant, it can be really enlightening being on the other side of that dynamic, seeing things from a customer’s perspective. I have worked as a consultant and had engineers treat me as though I was an enemy coming in to take their job when all I wanted, was to get the project finished and move onto the next customer. I have also been the customer dealing with a consultant who acts like a complete shmuck trying to pour poison into the ears of management to build themselves up and make the IT department look crap in comparison. Neither serve the interests of either party.
Lesson #1: Remain professional. Don’t be a schmuck.
Consultants Can Be Awesome
The reality is that there is only so much an IT department can do themselves. They are typically sized to maintain operations and make steady enhancements along the way but are not sized appropriately for handling large projects along with their day-to-day workload. For example, a Windows XP to Windows 7 migration with thousands of apps is almost impossible to complete for a typical EUC team alone.
Bringing in good IT consultants for large projects you are struggling on can be like someone throwing you a lifesaver when you are struggling against a raging torrent. Unfortunately, when bad IT consultants are brought in, it can be like someone throwing an anchor on top of you.
Lesson #2: Know your limits. Ask for help when you need it.
Consultants Can Make Things Worse
What is very difficult is the fact that Statements of Work even when reviewed and commented on by IT teams tend to be relatively inflexible and usually accepted without much change to benefit the customer. I have lost count of the times I have reviewed a contract as a customer and let my management know the requirements for us as an IT team to help ensure the consultants could complete their work would take a lot of time and co-ordination to put in place. Perhaps the start date for the project would need to be pushed back. Unfortunately, in my experience the start date has usually been non-negotiable by the time the in-house engineers got a chance to review the paperwork.
The fact IT teams are usually operating at capacity can be forgotten by both management and those selling products and services to enterprises. If you have a silo’d environment and requirements include actions taken by other teams then you can’t just flip a switch to get what they need. What happens when you decide to do a Proof of Concept with a vendor for a product you are interested in but you don’t have a DB server ready, you can’t access the software due to the download getting blocked etc. Fail to prepare, prepare to fail.
What happens when you can’t provide what the contract said the consultants require in a timely manner to complete their work? The clock is usually tickin’ with the meter running. Before you know it, you could run out of hours and the project hasn’t been completed. What’s more, if the work includes new technology for the enterprise that the IT team does not have experience with, and the consultants time gets burned up you are creating more technical debt for an already stretched team. Deliverables such as documentation and knowledge transfer should be mandatory.
During my time working as a consultant and even for service providers, time management and getting these pre-requisites were key. It’s not really the fault of these service providers and consultants if they burn through their hours due to the customer fumbling. The reality is they can’t wind up tied permanently to a single project. There has to be a time window to complete the work but a half-finished project with missing deliverables like key documentation and training on the tools used can be worse than getting no help at all.
When working on application packages for customers, we would typically give a 6-month warranty on packages. If the customer took 9 months to complete User Acceptance Testing on an app and it ended up not working then they would have to pay for the re-work. Customers can feel this is unfair, but it has to be this way for staffing reasons.
Lesson #3: Have your ducks in a row before the project start date. Frontload the work if possible and free up resources to assist as needed and validate the work when completed. Set your management team’s expectations. Ensure you are comfortable with the project scope and what it will mean in the long-term.
Customers Are Not Always Right
Of course, there is a flipside to this too. Some customers can be completely naïve or even worse, dishonest. Some customers will get help for a project and then try to move the goalposts, particularly when smaller named companies are involved thinking they will go along with it rather than risk losing the work and getting into a legal dispute with a company with more money to burn.
As an independent IT consultant, the hardest part of the job for me was simply getting paid. I provided some consulting to one of the largest oil companies in the world and got ghosted.
I provided consulting to a company in the Midwest US who moved the goalposts after I had completed the work claiming they needed a different solution than the one I provided. I ended up getting burned enough times that I swore off the idea of being my own boss.
Even when getting paid, sometimes the result wasn’t worth it. I was hired by the lead of an EUC team for an App-V implementation,. What I didn’t know, due to lack of experience at the time was that this person was a bit of a cowboy. They didn’t work well with other teams. I was asked to setup on a single server for a Proof of Concept. It turned out this person wanted a single server setup because getting a dedicated SQL Server and full production servers in place would require help from other teams who had a low opinion of the team lead and would be less than helpful. My PoC got rolled into production. It worked and the user load was small enough that it wasn’t a problem but still, it’s not a setup I was happy to put my name to. I went along with it but should not have.
Lesson #4: It takes two to tango. Consultants, vendors and service providers are right to push back if a customer requests something they feel uncomfortable with.
Conclusion
This is long blog post with a few key takeaways that I would like to impress on fellow techies. If you work in an IT teams, always consider the requirements of you as a customer and ensure you can provide them in a timely manner. If you have a warranty for the work, ensure when it is completed you have the time to fully test and validate it properly. Make detailed documentation and knowledge transfer part of your deliverables. This is possibly the most important takeaway!
When buying new products weigh up the amount of effort required to learn and use the product against the value it provides. Also factor in that even if a product is awesome for others, every environment and needs are different. For software vendors, you should reduce the complexity of trying and buying your products plus make maintenance and upgrades as painless as possible.
I worked for a company where an executive once likened our dependency on external contractors as a drug dependency and he had a point. If an IT department is relying on external resources to help implement every new technology brought into the place then they are stunting the growth of everyone in the department. You shouldn’t pacify workers to the point they are unwilling to learn something new without the assistance of outsourced help. You learn more by doing than by simply observing.
For service providers and consultants, when hired for a job, consider the overworked IT teams you are coming in to assist. Try to leave them in a better place when you leave than when you came in. Please don’t upsell to managers and executives without fully explaining the effort required to maintain the tech after you leave. It can be handy to assess the skills of the team you will be working with to figure out if you think they may need someone else on their team permanently to support what you build or possibly if someone on the team is a good fit to train up. When you feel the urge to talk bad about members of the IT team, bite your tongue and keep it to yourself. You ultimately make yourself look unprofessional.
Consequently, spending most of my time working as a full time employee on EUC teams is what makes me a terrible fit for a sales or technical pre-sales role. I have a hard time trying to convince people a product is right for them without being sure it is actually a good fit. It is also why in the near term at least, I intend to focus more of my time research and blogging time on products and solutions that I feel are worth learning and provide enough value to IT teams to make them worth learning.
Photos by Regine Tholen, Sebastian Herrmann & Toa Heftiba on Unsplash
