Sunday, September 30, 2012

Hardware Inventory

Hardware Inventory

If you are an IT manager and your department manages a network and/or computer hardware and software, then you need an active inventory.  Even if you are just tracking this inventory on a spreadsheet, you need to keep it updated constantly.  This may require some skull-cracking, but it is a top priority.  Your inventory "system" needs to track the purchase dates and costs of hardware and software, who it is assigned to and when it is expected to be replaced.  You'll need to assign a fixed number of years for each type of hardware and software (i.e. like 5 years for desktops and 3 years for laptops, etc.).  Once you have completed an entire inventory with expected replacement dates, you can produce a report that shows how much you expect to spend over the next 5 years and you should be able to report how much total hardware and software inventory you currently have on hand.

Another metric you might want to track is repair tickets.  My company is so small that my network admin/PC repair guy just fixes each machine as the complaint is lodged.  However, if your company has hundreds of PCs and you have one or more designated PC repair technicians, you'll need some method of prioritizing requests and measuring progress. 

Other options

As I've stated before, I work for a small company.  Unfortunately, over half of our computers are laptops.  It's the nature of our business.  To reduce our repair costs, we have used the 3-year on-site repair plan from Dell (not that I'm selling Dell computers, here, you can check into maintenance plans for your favorite vender and use that).  Then we replace our laptops every 3 years.  In other words, we never repair laptops.  Ever.  I like it that way, it's cheap, management is happy, the end user is happy when a technician shows up on-site and fixes their laptop right away.

That's all for now.  I'll go into more detail in a later post.

Enhancement Requests/Work Requests

Enhancement Requests/Work Requests

Everybody want a features.  There isn't a software package on this Earth that I don't desire an extra feature or two.  Every time someone uses my software, they think of a feature that they would like to make their job easier.  It's natural.  It's also frustrating.

Story Time..

When I started my first IT manager job, my company used to treat features as something that was necessary.  If an employee "needed" a feature, some programmer "needed" to jump on it and program it into our software.  This worked initially, when a small hand-full of employees used the software and the size of the software was small.  As the software grew into a huge tangled mess of conflicting features, things got out of hand.  Soon the number of bugs were uncontainable.  Then the complaints about how the software was changing every day started coming in.  To top it off, managers who expected their people to get work done at a fever pace expected features to be implemented in time for them to get that important Excel spreadsheet done by Friday.  It was ugly.  I had to literally change the culture of the company to fix this particular problem.

So my first step was to make sure there was a log of all feature requests and work order requests.  I had to separate these two to make sure that people knew that a work order was a custom output that the IT department did once per request.  A feature was something that was permanently coded into our software.  So there I was with a hundred features, many conflicted with capabilities already in the system, and some features would require serious programming hours to incorporate.  Then there was the "software changes too fast" problem to solve.  So I educated the company owners on the proper way to build software and what the pros and cons were to building new versions every week and building them once per quarter or once per year.  I also got buy-in from management that we would have an enhancement meeting to decide which enhancements would go into the next version.  This ensures that people requesting the enhancement didn't complain that I was playing favorites. 

What is the pay-back on an enhancement?

There are only two reasons you should ever incorporate an enhancement: It will reduce your production costs (i.e. enhancement "A" saves marketing 5 hours a week tracking customer data) or it add value to the product.  Value is something that makes your product more valuable.  If it's more valuable, then you can either charge a higher price, or you should be able to sell more copies.  Never incorporate an enhancement that will cost more to implement than save money on the bottom line or not add value.

Gilding the Lilly

I just love that term.  Gilding the lily means that you are gold plating your own enhancements.  Even developers will want their own enhancements and many times they'll spend fruitless time enhancing software to do what they want it to do.  Don't let this situation continue.  This is wasted man-hours for a feature that most users will not need. 

Next I'm going to talk about hardware inventory.

Software Development Progress

Software Development Progress

If you're developing software you will need to measure progress.  Management will need to know your progress.  They will want to know what to expect and ultimately how much it will cost.  You will need to know if your software is making progress or if you need to shut it down and cut your losses. 

Years ago (in the late 90's), I was promoted as IT manager to a company that had two IT departments merged into one.  The previous IT managers were sacked and I was left with a huge mess to clean up.  If I had to do it all over again, I would have done a lot of things different.  One thing I would have done early on is track software progress.  It took me a year to get a handle on what progress was being made on each of the software packages that we were producing.  This lack of measure in my department opened the door for office politics to get ugly fast.  Part of the problem with the company that I work for is that they were unfamiliar with the nature of software.  In their minds, software was just a big can of play-doe that can be molded into anything needed.  Which is how the previous IT managers treated it.  I knew better, but in order to communicate realistic expectations, I needed to get my documentation ducks in a row.  This included measuring. 

The first step is to nail down a design.  I won't go into details of software engineering techniques in this blog post.  In fact, there are entire blogs written about this subject alone.  Suffice it to say, that the more detailed information you can get down on paper the easier it will be to estimate how long it will take to develop your software.  Initially, you'll need to boil it down to man hours.  This can be a rough estimate at first.  Next you'll need to know what resources you'll have available for the programming, debugging, user manual, help file creating, etc. (whatever you'll need to complete before putting the product on the end user's PC, or publishing to the website).  You may have to present various scenarios to management.  They are going to want to know the overall cost of the project and that comes down to man-hours times cost per man-hour.  Once scenario is one programmer working non-stop until the project is done.  This is easy to manage and is normally done for small programs.  Most of the time, you'll need to use multiple programmers.  Don't forget about contract labor programmers.  Sometimes it's easier to hire a hand-full of programmers to develop the meat of your application and use your best programmers to manage and connect the pieces together.  What you will present to management is a time-frame, maybe a start date and a maybe delivery date.  I have discovered through years of experience that management will have a desire to set the priority of your development. 

Your project starts, now what?

So you presented your estimate and costs to management and they are excited about the product.  Now it's time to roll up your sleeves (or time for your programmers to roll up their sleeves) and get to work.  Each week you should know how much progress is being made.  You can do this by counting the number of completed features, or what percentage of a feature is completed.  Your technique is your choice.  I use the Menlo method of tracking projects, it's simple, it's effective and I can shut down a project in the middle and still end up with a functioning product (with only some of it features, but a functional product none the less).  There are many methods of running a software development project, I won't go into details here.  At this point, I'm assuming you're a new IT manager with limited experience and you need to get the ball rolling.  Anyway, you'll still need to track the total percentage of completion of your project.  This needs to be tracked at regular intervals and presented to management so they don't begin to wonder if their money went down the rabbit hole.  Your progress should indicate a rate if you plot this on a line graph.  Such a graph should indicate approximately when you expect to complete the project.  If your progress is missing your expected completion date then you need to take action as soon as possible. 

My project progress is missing the expected completion date, what do I do?

First, you need to prioritize.  Technically, you should prioritize all the features of your application early on, and focus on the most necessary features first and organize the features down to the least necessary features.  If you're going to miss your delivery date, and marketing already published a delivery date that cannot e changed, then you'll need to cut some unecessary features from your product.

If you can add programmers to your project, that is an option.  This will need to occur early on.  Towards the end of your project is too late to add resources.  Such a plan will only increase the amount of time it takes to complete the project due to organizational issues.

Prepare for Roll-Out (aka Deployment)

Make sure you prepare ahead of time for the roll-out of your product.  You need to think about how you are going to transition from your current product to the new product.  If this is the first iteration of your product, then you are in a unique position.  Most of the time, you'll need to provide some sort of data conversion from an older version.  Make sure you send out notifications early.  If you're going to need an outage, make sure you announce the expected outage times early. 

Next I'm going to talk about enhancement and work requests.

Software Quality Measuring

Software Quality Measuring

Measuring the quality of your software is similar to measuring bugs.  You need to prove that you are making progress.  This will keep management satisified and it'll determine how much time you will be spending with help desk calls.  The first thing you'll need is a minimalist objective way to track bugs.  Bugs can be tracked during development time, and it should be a goal to solve all bugs before releasing the software (although it is sometimes impossible to solve obscure, non-repeatable bugs).  You need a log where you can put your bug information.  I normally use one sheet per bug (and staple screen shots to this sheet if necessary).  You can use a bug tracking software package if you like, but it's necessary to get things off the ground as quickly as possible.  Once you have a book of bugs, you need to have metrics to measure how many bugs are being found per week (or per month, depending on how you plan to report the information).  You'll also need to know how many bugs are fixed in the same period of time.  These two numbers are going to give you a rough idea of progress.  I normally plot these numbers in Excel and show a line graph of how many bugs have been found each week, then I can find a trand line (or curve) and predict what I expect over the next few weeks.  When you're done, your chart had better point downward. 

What if my bug chart is going up?

Oh boy!  You're doomed!  OK, not quite.  There could be many reasons for an increasing number of bugs.  Maybe your product use has increased.  Many of my company's software is used for end-of-year accounting purposes.  Near the end of the year, near close-out time, bugs increase.  Not because there are more bugs, but because now they are being discovered in sections of software that was not previously used or not used as vigorously.  It may also be because of newer users.  New users are very good at finding interface bugs.  Things like typing a dollar sign in the price input box.  Trained users might be trained not to type in the dollar sign, and the software developers who (for this example) forgot to accept only the numeric part of the input were careless due to a rushed production schedule.  None of what I'm describing gets you off the hook.  When managment sees a chart showing the number of bugs rising, you better have a plan, not just an excuse. 

So what's your plan?

Initially, you should find more resources to throw at the problem.  This technique doesn't work when developing new software, but it does work when fixing bugs.  You should have an estimate of how long (on average) it takes to fix a bug.  Then assign enough programmers to the bug fixing task to get the bugs fixed as quickly as possible.  Your goal should be to fix all the bugs on the books before the next report to management is due.  Utlimately, it will end up coming down to fixing as many bugs as you can with the limited resources you have.  You should also prioritize your bugs to hit the most critical bugs first.  Then further prioritize to fix the easiest bugs first.  This technique is also reversed from software development, but your goal is to get the overall quantity of bugs reduced as quickly as possible.  Remember: Always fix the most critical bugs first!  Don't try and reduce the number of bugs quickly by just fixing the easy bugs.  If you have multiple developers, you might be able to get away with this strategy if you assign one developer to fix all the easy bugs, but ultimatly, and work-stopping bugs should get the most resources assigned.  Any bug that causes a work stoppage is costing the company money in production as well as developer time to fix the bug.

I'll get into more detail about bug tracking in a future post, but for now, this is all you'll need to keep your bosses happy and keep the progress of software development flowing.

Next I'm going to talk about Software Development Progress.

Software Version Numbering

Software Version Numbering

As I mentioned in the introduction post, you must track the version number of your software.  You can choose any method of tracking, such as a sequential numbering scheme, or you can follow the stardards used by most IT products (such as Visual Studio).  Initially, I would recommend starting a spreadsheet for each software project that is under development.  The spreadsheet needs information about the project, when development was started and when it was first rolled out for use by the customer/employees.  If a bug is fixed an the application is reintroduced, then the version number must be incremented and noted.  Do not release a version without incrementing the version number!

Another name for tracking version numbers is revision control.  There is software available to track version numbers and there is software available for maintaining source code versions.  Initially, you will want to just track the version numbers just to get control of your softare development.  In other words, it's better to implement a quick and dirty system and get rolling than to stop progress and make a big production out of it.  Later, when time becomse available, you can research products and other more complex methods.

I cannot stress enough how important it is to get version control in place early on.  There will come a day when a dispute breaks out between the customer/employee and one of your developers or between your department and management.  Version control can help resolve disputes. 

Now you're probably thinking "Frank?  What are you talking about?"  OK, it's example time.  I took over as an IT manager for a small company that had two IT departments that were combined into one department (the previous IT managers were both sacked).  None of the software had version control.  The company had a dozen different software applications used by employees and customers for various sub-tasks that the company did.  I was young and green at the time, it was my first IT manager job.  I knew about version control, but I didn't think it was high on my priority list because the department I took over had many other issues that I had to solve as well.  Unfortunately, my version control problem became a major problem.  One program that was used by a customer to enter their data contained a small database for storing local information.  When the customer was done entering their information, they would go to the export menu and export their data to a zip file which they subsequently emailed to our company to be incorporated into our master database.  The problem occurred when a customer sent us a zip file containing a miss-matched database configuration.  It took hours to figure out what the difference was and we determined that it was an older copy of our software that the customer was using (apparently, they didn't install the new version when they performed their work for the new season).  Once the differences were identified, then the hard part of conversion started.  Our other option was to call the customer back and make them install the lastest version and re-enter their data, but we didn't have an knowledge of which version they actually had because we didn't track the version numbers.

In order to resolve any future problems with database miss-matches, we incorporated versions in our software and we always provided a data converter.  So each product has all the previous data converters built-in.  New software will have a new converter added to it if the database was changed.  For example: Version 2 of our software has a converter to go from version 1 to 2.  Version 3 of our software had a converter to go from version 2 to 3.  So if you previously had data from version 1 and you install version 3 of our software, then the software could detect that your data belongs to version 1 and runs the 1 to 2 converter.  Then it would detect that you have version 2 data and runs the 2 to 3 converter.  Voila!  You have the correct version of data to match your software.  The customer is happy, you are happy, all is well.

Example 2

We received a call from a customer that was having problems with bugs in his software.  We had never seen such a bug, but every computer is different and there could be a conflict in the version of their OS, their installed software, etc.  Unfortunately, it's difficult for the developer to look at the code of the latest version and try to fix a bug that may have been fixed in a previous version (I've seen developers work on a bug that was fixed by another developer months ago).  We were forced to send the latest copy of our software to the customer and make them install it and call us back.  Of course, we look like idiots at that point, because we should have been able to ask them for the version that they had installed.  If it was an older version, then we could have requested they install the latest version first, rather than crossing our fingers and hoping they had an older version with a bug that we had previously fixed but not tracked (I'll get into bug tracking later).  As it turned out, the bug was still there and we needed to fix it.  Do we know if the customer was running the latest version?  No idea.  Did we waste their time?  probably.

Version Control Software

As I said earlier, version control software is not necessary, but it can also be used a crutch for tracking bugs and assisting customers with problems.  If you are running a multi-programmer shop and more than one person is responsible for the source code of an application, you'll probably need some sort of version control software.  The purpose of this software is to keep copies of all your revision histories and control the merging of source code.  I can't tell you how many times I've compared the current version of a source file with a previous version to figure out what was changed and why.  It's one more detective tool that can assist in tracking down a bug.  I won't go into version control software at this time.  I'll save this for a future post.

Next, I'm going to talk about measuring the quality of software.

Measuring (Introduction)

Measuring (Introduction)

This will be a mutli-part posting about measuring.  I will list a short introduction to each subject in this blog post and then create one detailed post for each subject in the near future.

Let's say you're a new IT Manager.  You have never done this job before.  You were either hired directly to take over an IT department or you were promoted to IT manager because the previous manager was sacked or moved on.What do you do?  Where do you start?  What if the department you took over is new and standards are not set in place?

That's where measuring comes into play.  You need to get control of what your people are doing and make sure management knows that you are in control of the department.  Both can be accomplished by measuring and tracking.  Now the question is what to track and why?

Software Version Numbering

If your department develops custom software, maybe it's only for internal use, maybe it is a custom application for your customers.  Either way, you need to implement versioning.  I have ignored versioning in my early years to my own peril.  It's difficult to help a customer or employee troubleshoot a problem if there is not way to track which version they are using.  It is also a problem with web applications if multiple users are working on the site and may accidently post the wrong copy.

Software Quality Measuring

In order to make sure you are making progress in fixing bugs, you need to somehow track how many bugs you have repaired and how many more bugs are reported.  This information can be used to predict how many more bugs are expected and it can be used to show that the quality of your software has improved (assuming the number of bugs are dropping).

Software Development Progress

Any project in progress will need to be tracked.  You need to get an estimate together so that you can determine how many programmers will work on the project and how long it will take them.  You'll also need to be able to estimate the amount of bugs you are expecting so you can be more effective in quality control.  Management is going to want to know all of this information because they need to know how much it's costing them to build the software.

Enhancement Requests/Work Requests

You need to keep a list of requests from users.  These possible enhancements to software will sometimes conflict with each other.  That's ok, it's just a rough request list.  In my company enhancement request does not translate directly into "enhancement must be incorporated."  If your IT department is new then you must somehow involve your company management in the decision making about which enhancements will go into the next version of your software.  This gets you off the hook when enhancement requesting users fly off the handle because they didn't get their requests implemented.

Hardware Inventory

If you are in charge of the IT hardware (or in charge of a network administrator and/or PC repair person(s)), then you will need to carefully track your hardware costs.  You'll need a complete inventory of each PC, server, printer, etc.  You can keep it to items costing $100 or more, or in large companies, $500 or more.  I usually don't track mice, keyboards, etc.  You'll also need to track software licenses and hard copies.  Each piece of hardware and software must have a purchase date and the number of years before replacement.  This will determine an annual budget for IT hardware and software.