One of the most potentially frustrating challenges in any technical IT field is that the people to whom you report may not understand why various tasks take as long or cost as much as they do. This is a very common problem, especially in companies that aren’t in the high-tech industry, since managers lacking an IT background may have unrealistic expectations about time and cost. This problem can sometimes be exacerbated by efforts to correct these expectations, as a tug-of-war of can ensue whereby the IT professional is perceived as the advocate of overly detailed, thorough solutions, and this may make the non-technical manager push even harder in the opposite direction.
Here are some dos and don’ts about how to correct this dynamic:
Don’t reduce your reported hours to fit someone’s conception of how long something should have taken. If you do this, then the next time a similar task comes up, you may be held to the same hours that you reported before.
Do separate time required to “get up to speed” into a separate category in your estimates and time tracking. Similarly, as an independent contractor, it often makes sense not to bill for any associated “learning” time required.
Do use records of how long a project took last time you did something similar, in order to give sound estimates.
Don’t always insist on the most thorough, complete process possible. While you may think that you’re educating management on the “right way” to do something, you may actually be feeding their misconception that the reason things take long or cost a lot is because of your insistence on a gold-plated solution.
Do show a willingness to find creative workarounds to achieve the desired goal in less time. By finding quicker, cheaper solutions, you can become more believable when you tell management that a particular objective really does require a major investment.
Don’t appeal to “best practices” when explaining time or costs; these may have no tangible benefit to management and again reinforce the perception that you’re the advocate for big solutions when they just want small solutions.
Do explain exactly what features and abilities will be lost when a cheaper alternative is substituted. For example, suppose management wants to scrap the corporate ERP system and replace it with a light-weight investment-tracking app designed for home use. Don’t panic; just do your research on the proposed application and report on which key features that the company was using in the ERP system will no longer be available.
Don’t get stressed out about the fact that what you’re asked to do doesn’t make sense. Always remember that you’re still getting paid.
Do discuss plans and estimates with other colleagues to see if your estimate is in the ballpark and if anyone can think of a faster way to do things.