Asset Management Experience


Role Description

After leading the information security team successfully, I was asked to lead another program that was in sore shape.  The Asset Management Team was in desperate need to account for all their assets in a short period of time.


Due to Sarbanes-Oxley requirements, Intel had to account for all of its assets. Our division was struggling to complete this task, so I came in to make it happen. We needed to physically track every computing asset that we supported worldwide. The number was over 30,000 systems. It sounds a bit funny, but all these systems were accounted for on the network, but we simply didn’t know where all of them actually resided. We had to look in every nook and cranny, under desks, in data centers, etc. until we could find every one, bar code it, scan it, and then make sure it populated into our asset database. Once we achieved that, we had to dump the information into a master database for the entire company. Each step created challenges.

Getting It Done

I was given a team of about 16 people that represented all 50 sites we supported worldwide. I had to take over from the division’s asset manager who simply became overwhelmed by the task. She stayed on the team to help. Sometimes that was good, sometimes it wasn’t. She was tirelessly dedicated to her job and lived and breathed this type of work. She just didn’t have the skillset to take on a global project. She was a bit resentful of me taking over, but did manage to handle the situation maturely. The only real obstacle was that she had a very narrow view of how to get the work done, narrow in the sense that her ideas were too big for what was required. She was ex-army, rough around the edges, and had no political skills. It was going to take some special care to keep the project focused properly. I had to balance the raw objective of getting the assets tracked with her desire to create a comprehensive asset management process. Normally, I liked to do that sort of thing, but we had deadlines and I had to choose wisely when to leverage her ideas and when to cast them aside.

One luxury we had was an actual database administrator who could customize our asset tool on the fly. He could make bar code scanners work better with the tool and could manipulate the system so that it could upload our data to the master system. He was generally a reliable order taker, so he made my job a lot easier. For the rest of the team, I got a representative or two from all regions to pound the pavement and track the assets. In comparison to my information security program, this was on nearly equal footing in global reach and scale, but it was still a simpler job. It took less time but still managed to create a lot of headaches. I didn’t need to study asset management or train my staff. It was a fairly straightforward task, but the enormity of the asset base and a zillion little, pesky problems required a large percentage of my time.

Once again, I used my experience in starting up teams and programs and set the charter, ground rules, responsibilities, and goals. As before, this work was considered a second priority for my team members despite the fact that we had a legal requirement to get the job done. I had an entirely new stakeholder to deal with, i.e. “Mother IT” who loved to control everything and was a huge morass of bureaucracy. It was hard to even find who was responsible for what and to know who mattered and who didn’t.

To the regional middle managers, this was a necessary but mundane task to provide resources for. It was therefore even more important to make my goals visible to upper management in order to get commitment. The team members were reasonably motivated and ultimately enjoyed contributing to the effort.

I did have to do a little homework. There is such thing as an IT Asset Life Cycle. My asset manager was hopelessly devoted to it, so I tried to humor her by learning it and trying to implement the steps suggested in this model. My memory of this portion of the program has faded significantly. I know we analyzed a lot of flow charts and wrote a lot of documentation, but I can’t remember how it all contributed to the effort, honestly. I think it did help to have this as a foundation, since it assisted us in dealing with asset procurement and making sure anything new that came in the door was tracked properly. It also helped establish a process for retiring assets and making sure they were removed from the system. As it turned out, these two parts of the chain were what caused us to get into a mess more than any others. Bottom line was that this program was more than just hunting down assets, it was intended to be a platform for making sure all assets got handled properly throughout their lives.

After the launch of the team, I needed to find ways to measure status and progress. There were already a few thousand assets tracked properly, but the reporting was not very robust or reliable. I had to give this priority to our DB admin beyond most other duties. Most people were hot and heavy about getting items scanned. I had to refocus the team to make sure we had a useful metrics system. No metrics, no management support. Once we did get our first run of useful reports, it showed that some regions (like the asset manager’s region, for instance) were in great shape and mostly needed to clean up some stragglers. Other regions were a complete mess, especially Europe and Asia (and my own region!). I had to learn the right methods and then extrapolate them across the entire division. Some regions didn’t even have bar codes and scanners, so buying those and distributing them was one of the early orders of business. Once we knew where we stood, I gave my first presentation to divisional staff about where we were. I got good attention to the matter and commitment was less difficult this time around since it was less complex, could utilize less-skilled technicians, and had Mother IT breathing down their necks. Still, some regions continued to lag behind, so I had to increase awareness by sending out regular reports to divisional and regional staff.

As mentioned above, we had to get the data in front of people in a clear and concise way. We really hit the jackpot when my French representative on my team created a masterful looking e-mail interface for our report. Every week, we sent out a beautiful, clean, and useful report on what percentage complete each region was. It was our best and most effective weapon. I hardly had to do any convincing to middle management since our divisional director got the same report and could see plain as day how his management team was performing to goal.

Along the way, we had several irritating problems. Sometimes the bar code scanner didn’t work, sometimes the assets wouldn’t load into the database properly, sometimes we knew we had assets on the network but couldn’t find them, and sometimes we just couldn’t get all the data to transfer to the IT database correctly. There was a lot of painstaking work to prioritize the work, get the right fields to populate, and get the regions to follow procedures we put in place. Bit by bit, the database admin got closer and closer to making the tool work more reliably and the screaming from IT became less and less.

The other difficult problem to overcome was to make sure the entire division embraced the asset life cycle process. Technical support engineers were constantly buying or borrowing computing assets from every direction and plopping them on the network. They’d also take them off the network, stick them in a closet or send them to another site and do nothing to track their physical locations. We had to create a thorough process that wasn’t too overbearing but could close all the gaps that humans create for themselves. To this end, we documented a very solid process via a great amount of feedback from engineers at the sites. We also had to put together an enforcement policy so that the process would stick without having to chase people around all the time. We had to automate everything we could. This is a difficult task when talking about physical locations of items that can be moved willy nilly at any time. It was especially difficult in Europe since many of the sites were small and didn’t have the personnel to watchguard the process. Once we did get a reasonable process in place, we set up training sessions across the globe to make sure people were doing things properly. We also set up a way to cross-check the assets we showed on the network with the assets we showed in the asset database. Whenever we had a mismatch, we required my asset management team to investigate it and work with the local support engineer to account for the system properly. Gradually, we closed more and more holes and the accounting of our assets improved quickly.

In some cases, we had to fenagle odd computers so that they would report all the data that IT required. Some systems would easily report out information such as serial number, model number, operating system, hardware configuration, etc. quite easily. Others didn’t. We had to enlist savvier engineers to develop scripts to pull that data out on a case by case basis. Again, this was a painstaking process that often seemed to be a situation of managing exceptions rather than managing the norm.

The last step in the chain, that of dumping our data into IT’s central repository, became a pain in the ass, too. Suddenly, things became political since IT was objecting to our division having its own database. They just wanted us to load our system information into their repository directly. There were too many reasons why we couldn’t do that beyond just the time required to shift gears entirely. I had to get upper management to fight that requirement off. I also worked hard to solve our data transfer problems so that it would be one less thing for IT to complain about. If we could make the transfer work flawlessly, then they would likely leave us alone. Ultimately, that strategy worked. Once we fixed our irritating database problems, the data transfer became routine, they saw our data loading and catching up with all the other divisions, and what was done was done.

In the end, our weekly status reports revealed where regions weren’t performing and enough pressure was put on them to address the problems. I didn’t have to be as much of a bad guy as I did during the information security days. The data spoke for itself. We grew closer and closer to the 90-100% goal in place for tracking our assets and the urgency and hysteria in the program began to wind down. The timing was good since I reached a point where the program could manage itself and my division could prepare itself to see me go on to Russia.

Lessons Learned

As usual, I had to learn how to work with a prickly personality. There’s always one in the bunch, it seems. I found the right balance in working with her. I really wanted her to feel like her opinon mattered and that some of her grandiose plans could be realized. That kept her motivated and supportive. If I had lost her support, she could have brought the whole program down. I had many leadership and management techniques that I could teach her so that she could see how to get things done without acting like a drill sergeant. I think she appreciated that and made it much easier to get her on board.

I also reminded myself how valuable it is to get something to measure as soon as possible. Data draws attention to itself and requires a lot less manual intervention to convince people what goals and behaviors are needed. Getting the team to contribute instead of just having them take orders is another valuable lesson. I can’t tell you how pleased I was to have my French team member create that report. It was a striking moment for the program and I will always encourage people to use their creativity and inherent desire to help as much as possible.

Finding the right people who have the right skill at the right time is an invaluable instinct to have. I seem to possess this skill fairly well and so it’s always good to reach out to people you don’t expect can help to come in and save the day.

Lastly, despite the grandiose plan my asset manager had, I was very glad I didn’t skip over it too much. The IT Asset Life Cycle created a great foundation for our work and it gave us more credibility when people saw that we were using an industry model as our process. Sometimes, people get turned off by this, so you need to use this wisely. But in this case, using a tried and true way with some theory behind it gave us that extra strength to convince people we were doing the right thing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s