Morning Joe: Why IT Needs Software Requirements and the Disaster of Diving In Headfirst

First off, I plan on writing more technical articles at night but just moved in to a new apartment. I have 4 current articles in my queue dealing with optical character recognition of pdfs, tables, and captchas as well as creating a wireless Arduino device.

That said, I am now on my fifth call to IT regarding what should be the simple task of setting up my email in Office 365. I use Linux, as a large number of developers and techies do and sadly, each step to get my email online has been a painstaking process with IT only fixing the problem in front of its face. I have had to have the service first reinitialized, then a key attached to my account, and, finally, I am wrangling access to each product I should already have.

Something tells me that software analysis and the process of discovery could have saved my pain and reduced the number of insults hurled at a few college kids looking to make some side money with 0 industry skills. Of course, that is what we do with college students and immigrants, pay them peanuts, give them a little, and let them handle the work no one wants. On the other hand, the massive IT budgets that make my own look like a needle in a haystack are being misappropriated to pay for God knows what.

In today’s environment, where a day can cost a lifetime, this needs to change. Deploying resources to study upgrades and major changes is a must and that means analyzing the means of failure and working around them.

Failures come from a variety of sources. Sara Base offers a good review of them in A Gift of Fire. They include:

  1. Lack of understanding of the material that can be overcome with research
  2. Arrogance
  3. Sloppy user interfaces
  4. Too Little Testing
  5. Failure to understand a products uses and potential conflicts
  6. Funding
  7. The pressure for profit
  8. Product loyalty and fads (one that I have personally noticed)
  9. An unqualified workforce (another thing I have noticed)
  10. Not understanding the depth and needs of the user base to an adequate degree

In this instance, issues 1, possibly 2, 4,5,8, and 9,10 have created a perfect storm that is now harming every aspect of the institution’s communications.

Most of the issues can be overcome with research and testing of a product. I implore IT to take these issues to heart. It costs time and a great deal of money not to do this.

Advertisements

Morning Joe: When is It Time for Technical Writing in the Work Place?

I work at a startup. If you go unnoticed someone notices. The pay is lower but the people are nice. You learn who people are and teamwork receives the benefit. However, my starup is growing and communications are realing from the same revolving door policy. The solution is clearly technical writing and anyone would say creating a report for a massive project is always a good thing. However, when do simple installs need proposals? This is obviously a situational issue. Here are the factors I see going into this decision.

      How much time does the supervisor have? Creating paper creates flexibility but also says importance.
      How knowledgeable are your superiors? Will the request recipient be able to explain the problem and solution?
      How technical is the problem compared to the supervisors capabilities?
      How costly is the request? A formal report may be necessary.
      Do you have something other than supervisor level knowledge to offer without looking cocky?

You will need to assess the capabilities of the team members as well as higher-ups and technical writing allows you to sell the option.