IT Project Management is like a Half Marathon…

I completed the Pittsburgh Half Marathon on May 6th. I finished 13.1 miles in 2 hours and 44 minutes.

I’ve been working on two major events in the past couple weeks. One was training to complete the Pittsburgh Half Marathon. The second event is a webinar titled All Aboard! Avoiding Tech Project Derailments which I am presenting for NTEN. While the two things may not appear to have anything to do with each other, a lot of the things that I have done while preparing for the Half Marathon do apply to my experiences with  managing an technology-based project.

First, how many people sign up to run a half marathon and then proceed to do no training? I’m sure that there are some. I’m sure that there are even some people who manage to finish the half marathon without training. I can’t. I had to start out with baby steps, increasing from my reliable 3.2 miles to 5 miles and then to 9 miles (with a Nike+ sensor that wasn’t always showing the right mileage). 

The same sort of philosophy being applied to technology projects is advisable.  I  had the luck of starting out at my agency as an intern many moons ago. While an intern, the biggest project that I had to manage was related to a community art gallery that ran in our headquarters building.  The art openings would be a success or not with how much work I did. Quickly I learned that it wasn’t about finding the artists. Most of the work revolved around dealing with getting the artist to meet deadlines while it also meant completing the advertising for those art opening to our staff. To be successful, I learned how each artist required different things from me while I learned how frequently I must remind the staff of upcoming events, warnings of deadlines, and how the majority of them preferred to be kept informed.

From those starts in orchestrating art openings, I took on responsibilities for parts of projects. The first one was the installation of the first network for the agency. During that experience I was able to observe how those individuals in charge handled the multiple aspects of the project and how things that seemingly didn’t interact with each other were critical to the completing of the network.

Large technology projects can qualify as marathons. While we would love to wave that magic wand and break the course record, for most runners it is about simply crossing the finish line. They sometimes take on a nature that they weren’t intended. You are looking for the mile markers and not finding them. If you have had the ability to do some previous projects in your organization, you can fall back on your training.

You know how to communicate with the individuals involved. You may know that there are these three people who need to be reminded daily of their tasks that need to be done while there are ten other people who only need to be given a warning that a deadline is pending. There is some internal knowledge that you have of how to communicate where things are – if you have to celebrate every little success, or just celebrate the large successes.

I couldn’t have finished that half marathon without having those training runs. I also know that I couldn’t have finished some of the most recent technology projects, such as relocating our data center and creating a customized application for three departments, without having those first small projects – even ones that had nothing to do with technology.

Now that I’ve completed one race, I’m looking forward to completing the materials for the webinar All Aboard! Avoiding Tech Project Derailments which I’ll be presenting on Wednesday, Jun 27, 2012 at 11:00am US/Pacific. I’m pulling together my experiences with my own technology projects to help others who may be looking for some training on what to do. I also look forward to hearing from others about what type of information they seek about technology project management – so if it isn’t something that I’ve included, maybe I can.


The Right Tool for Easy Access to Servers

Visionapp Remote Desktop software

A tool to harness access to multiple servers and applications.

I can remember ten years ago when I only had to worry about two servers, one for the entire agency and one for the computer lab. I can remember seven years ago when I only had to worry about five servers – one for the agency, one for email, two terminal servers for other offices, and one for the computer lab.  I can remember five years ago, after adding in VOIP, I only had to worry about eight servers because we added three for the VOIP and one additional terminal server.

It was probably around five years ago that it started to get difficult to manage all the connections to the servers for one person. That was the last time that I could easily off the top of my head perfectly indicate how many servers I had in service. The wonderful use of virtualization made it way too easy to do what software vendors wanted you to do – keep their application isolated on its own server. You can blink your eyes and “Viola!” you now have doubled your server counts in 1/4th of the time it took to bring up one physical server.

But this growth did come at a cost to me and I started to use a tool that I didn’t realize that I needed as badly as I realize that I need now. The application is called visionapp Remote Desktop. I cannot even say that I went out and researched this one on my own. One day, one of the engineers from our IT Support Company was on site and I turned around and said “What’s that?” and he started to explain this application that he used to keep not only connections to all of my servers at his fingers tips, but other customers too. I feared to find out how expensive it was, and boy was I surprised.

Yes, nonprofit geeks out there celebrate – I was able to start using visionapp Remote Desktop for free. Yes, now there is a trial version, but look again at their website, there is a freeware version of this application. If you have more than one server, I suggest you go to their website and get this wonderful tool.

VisionApp Remote Desktop helps with collaboration, administration and management.I started out with just my servers on this and with my credentials to logon to the servers. While I was on the trial version of this software, I didn’t have many different types of usernames and passwords for the servers. It was just the one username and password that I used to be the Administrator. I had a long history of fat-fingering that bad-boy hardened password for the Administrator account and now all I had to do was make sure that I got it right twice when entering in the credentials. As long as I didn’t go changing that password, I was in a good shape.

But this is more than a hyped-up “Remote Desktop” application. The power of this application became much more apparent once I exceeded the 15 connections limit and purchased the software for enterprise use. That was around the time that upper management allowed me to hire another staff member.  I was worried about how I was going to have to get all of this information ready for the new staff member to have access too. When in the Tech Department, that staff member was going to need to have their own access to all of the servers I painfully setup in my visionapp. That is when I found the export option. The export option allowed me to take all the connections that I had already set up and put it into a file, without my credentials attached to the connections. The new staff member installed visionapp, imported the connections, and only had to set up their own credentials. Easy-peasy! No hours of sharing IP addresses and explaining why these three servers have dashes in their names and none of the others did.

That export has saved me multiple times too. When we were suddenly maxed out on network resources and needed another server, the only machine that could operate as one was my desktop machine. (Yes, that’s another story for another time). This started a chain reaction of having to jump from my desktop to two laptops, and the last laptop ended up needing to be rebuilt twice. The easiest process of this was reimporting my server connections to visionapp.

Visionapp Evaluation Process

A flowchart of how the visionapp Remote Desktop evaluation process can go

Last story about how visionapp has made things so much easier. My department has been overseeing a huge transition to a new stand in preparation to move to a new building. During this time, all of our servers have been moved from one virtualized server platform to another virtualized server platform. They have been renamed, readdressed and updated so many times in the past several months that no one would ever want to make a flow chart of the changes. But, since the engineer overseeing all of these changes uses visionapp, no big deal. To make sure that my entire department had the right names nad IP addresses, the engineer simply exported our folder of connections so we could just import the new information. With less than 5 minutes, my department was as up-to-date as the engineer implementing all of the changes.

I’m only highlight the parts of visionapp I believe are the most valuable to me as a nonprofit techie. (Until I went over 15 servers, all of this was available to me as the freeware version.) Visionapp does a much better job presenting all of this material and you should visit their site at to read more about how visionapp Remote Desktop can even help you with more than just RDP connections. (Yes, you can connect to external applications from visionapp too!)

Get Your Tech Maintenance Emails Read

Email email email
Image by RambergMediaImages via Flickr

I was surprised when I found out that my co-workers were not reading important emails about our network. It didn’t just come out. No, I had to learn the hard way as employees were starting to complain about things that they didn’t know about when I had sent out an email explaining all about the change. They indicated that they simply didn’t read that email. Emails about tech maintenance or other tech-related topics had been almost relegated to the trash immediately. That was when I started to use Publisher to make the emails pretty. That worked for a bit – but soon, the emails were being discarded again and complaints were piling up again.

To combat this, I have to say, I got advice from someone on our Tech Committee. He outlined what he felt needed to be in an email and I have tweaked it to be this process that I now use. It truly was easy and so far, it has been more successful than ever before. That doesn’t mean that each email that pertains to employees maintaining their email boxes or upcoming outages get fully read, but there is a higher possibility now that they are read with the implementation of these few easy things.

  • Create an internal email account to represent a “tech team” – It was difficult to hear that some employees would read emails from another member of the tech department, but wouldn’t read another member’s emails. It made no sense to me. We wanted to get the information out as quickly as possible so it just came from whomever had the moment. Since that was a problem, we simply created a Tech Team email account which we send out important announcements out from to staff. We also receive email on it, although that adoption has been much less successful.
  • Give Clear, Concise Subject Lines – Subject lines can be the one thing that makes your email get read or not. You can learn a lot about this from marketers. Before when the concentration had been on identifying a date that a task was needed or identifying the project, now the focus is about being short. If the email is going to outline a task that employees need to do by a certain date the subject line starts “Action Needed”. If the email is about an upcoming outage, the subject line starts “Planned Outage”. Make sure that these are used consistently if you have multiple people sending these types of email.
  • Use the “High Alert” Flag Sparingly – Everyone believes that their email is the most important and I think that breeds quickly in a tight-knit organization. I remember the one day sitting in my office after sending out an email about an upcoming outage with a high alert flag on it and listening to all the audible warnings ring around my office. Then some people even forwarded it to their coworkers so there was a second round of audible warnings. Then another coworker sent out an email about an upcoming birthday party for a staff member with a high alert. So all the audible warnings started once more. But it wasn’t done because another worker sent out an email with a read receipt and a high alert flag, which meant all the audible warnings happened along with her machine giving the same annoying alert noise when she received the read receipts.  Obviously, these alerts are used too often and should be used sparingly. If you have a good subject line, you won’t need the alert.
  • Create an email template – A consistent look and feel has been the most successful thing in getting employees to read these emails which they previously would not have read. They know what information that they are going to get in these emails and they aren’t concentrating on what pretty color schema was used in Publisher this time. Make sure everyone on your team uses this email template. Make things easy to fill in and send. More importantly, break this email template up into three different sections:
    • Summary – Start off the email with a quick summary of the most important details. Try to keep this to about a paragraph with 5 to 6 sentences at the most. If they read this part, you have done most of the work the email was meant to do.
    • Action Steps – Outline, in bullet format exactly what you need the staff member to do. If you need them to be logged off the network at 6 am, make that the first bullet point. If you need them to clean out email accounts because Exchange is getting bogged down, write that as a bullet point. Use these bullet points to also point them to further information – don’t try to put step-by-step directions on how to clean up their email accounts here, give them a link to those directions. Try to keep this bullet list short too – if you are getting beyond 10 bullet points, this might indicate you need to replan your email as you might be trying to cover too much in one email.
    • Details – This is the section for the employees who want to know the nitty-gritty details. In my experience, most employees aren’t going to care about the details, they just want to know what they have to do. But there are those few and mighty that want to know exactly why or more of the technical reasons behind why they are being asked to do a task. This section, since it is last, provides that information so you don’t have too many follow-up emails with questions to answer. I will provide internal and external links to information that is contained here and if there is going to be any section that has multiple paragraphs, this is the section.
  • Always offer to answer questions – This is the polite thing to do and it makes for more dialogue to happen. There isn’t a feeling that you are separated from the other employees. Most often there aren’t many questions when I follow this process of writing an email, especially in comparison to when I would put all of this information into a pretty Publisher email – where staff concentrated too much on the pictures and graphics and not the content.

This isn’t a completely foolproof solution. There are still going to be some times when the email simply gets lost because you can’t control how much information overload one of your coworkers may have when your email gets sent out. But having this in place helps so when  you do encounter to the complaint that they didn’t receive an email about an outage or a task they needed to complete, you can explain that the email did get sent out and often the conversation will end there. It has been so much more useful for me and all the feedback has been that staff like this method and more are reading these emails than ever before.

Resources from NP Techie, You’re No Accident!

laptop writer

Image by Combined Media via Flickr

I had the absolute pleasure of meeting a wonderful assortment of Nonprofit Techs at the Nonprofit Technology Conference. To know that Johanna Bates, Tracy Kronzak and Barbara Saidel thought of  me to add to their panel discussion for the NP Techie, You’re No Accident made me feel absolutely honored. But the best thing about that session was that it wasn’t about me helping to present something. It was about those who attended the session – about what they needed to learn, hear, know, and simply network about in a forum with other NP techs.

During that session, we broke into three groups for a while, and then got back at the end. While discussing outcomes it became clear that even though we all thought there was a way to break the larger group up, we all sort of faced the same issues and challenges. As a presenter, I learned so much from that session and I need to thank everyone who attended it.

There were also some resources that I mentioned that I need to share. Some are books and some are websites. I don’t believe any of these resources represent my “secret sauce” that I need to protect. I think all them can apply to all kinds of jobs that are out there. This is just one easy vehicle to share this information. I did not include resources like NTEN‘s website and TechSoup. Some of these I spoke about in the large group, smaller group and even after the session ended until the end of 11NTC.

I have to admit, I added lots of books and resources from the other presenters in this session and from the attendees. It expanded my “Books I Want To Read” on my LinkedIn profile quite dramatically. I have several of them ready to read while I ride the stationary bike so I’ll have enough reading materials for a couple of months to come.


Other Resources

Practicing Finding the Elephant and the Rider


“Practice is the best of all instructors” – Publilius Syrus

Last week at the Nonprofit Technology Conference, I got to hear Dan Heath, coauthor of Switch, speak about change. I loved the book Switch and while a lot of what he spoke about was in the book, it was helpful to hear it, to have it repeated in a way that it started to really take root in my head. Now that the NTC is over, I know that I have to continue to practice identifying the Elephant and the Rider in order to be able to get change to happen. Identifying it in other situations, outside of work, is one of the best ways to do this.

My notes from Dan Heath’s plenary made a lot of references to my thoughts about something that I have accomplished in my life. This past fall I celebrated the milestone of losing over 100  pounds of weight. A diet was an example often mentioned, but my notes took it one step forward and that is with my success with using Weight Watchers.  I am going to walk my way through the change that I have been able to be successful in, using the points that Dan Heath identified, to show that we all things in our life that we have made changes but we may not have identified the elephant and the rider.

One of the easiest ways to start impacting change is by some sort of feeling making the Elephant react. The example that was given was how some organizations can use pity to get a donation. My need to lose this weight happened when I felt that embarrassment and shame that occurred while at an amusement park and I couldn’t fit into the ride. I was sitting in the seat as three men tried to push down the harness, even in the larger seat. That feeling was enough to get my elephant to move. I really saw how large I had become. I felt how it felt to hold up everyone else on that roller coaster and then the shame of having to get up and walk away without ever riding the ride.

The path to my change was made easy on many levels. This was because the management team that I worked for knew that health for the employees was important and they offered to bring the Weight Watchers at Work program into the office. It was easy to just walk down the hallway and go to a meeting with other coworkers. During that first time, everyone was working together. There was no one showing up with donuts and pizza. Most of us were all in Weight Watchers and we helped each other. But Weight Watchers at Work couldn’t be sustained forever, and I needed more than a sixteen week program.


I went back to Weight Watchers the following fall with my mother, knowing that I had success with the program before and that I needed to be there. Plus, Weight Watchers had done a lot of things to help my rider. I think they have so many things in place that helps the Rider know that this is the right way to go. Every week you hear success stories. Most meetings start out with “Who is happy?”. The question isn’t “Who lost weight?” – it’s “Who is happy?”. There are some weeks when I was happy when I didn’t gain weight and that got celebrated with stickers and applause.  Celebrating other’s success was just as important as celebrating mine. As my leader would say almost once a meeting, “If you have had a good week, the meeting needs you. If you have had a bad week, you need the meeting.”

Success stories are the bright spots and they are celebrated vibrantly. Not only with the meetings, but with weekly newsletters that includes tips and stories from others who had been where I was. The Weight Watcher magazine features these stories along with the website. It was absolutely not difficult to find the bright spots. But bright spots weren’t just success stories.

One of the tools you start with at Weight Watchers is a tracker. It’s a food tracker. Now this might not seem like a bright spot, but it can be. If you keep your food trackers and you get into a slump, one of the best tools is to go back to the previous tracker for a week that you were successful in losing weight. You can then follow what you had done in previous weeks (repeat your bright spots) or you can look at the differences between the good weeks and bad weeks and see what things you need to adjust slightly.

Losing weight was so difficult for me. It took over five years in total for me to lose that 100 pounds, but Weight Watchers gave me a path. It was written on food that I bought at the stores (the value of points were right there on the frozen meals). There were times when I even wrote the number of points on the boxes of cereal and other foods as they came into the house. Visually, that number represented a path that I had to take. It made it simple and I didn’t have to force my rider, who could easily be tired, to think about what to do. High numbers were hard to swallow and low numbers were items that I wanted to select.

Weight Watchers isn’t a diet to me, which is probably the biggest identification of a change in my environment. A diet means that I was saying no to things, depriving myself. There are times that I can allow my elephant to have that craving for chocolate and peanut butter, but I have created an environment that puts me back onto the path right after that elephant has been satisfied and gets the rider back into control. This is the way my life is now, it’s not a diet.

Now this has been a simplistic look at one way that I have forced myself to practice identifying the elephant and the rider, but I know that for me to really become an agent of change, especially after I know that I have used the carrot and stick a lot at work, I need the practice. I can’t make the changes that I want to implement without getting really good at this and making it part of the tools that I have in my toolbox. If I don’t know how to use that circular saw, I’ll never get it out – and I believe it is the same with change.

#FAIL As A Tool For Nonprofit Techies

AC power plugs and sockets

Image via Wikipedia

I have to admit that I’ve been in a happy place since I saw the title of the most recent NTEN Connect edition dedicated to all of the talk around accidental techies in nonprofits. All of the features practically sing to me (yes, almost like an episode of Glee). But probably the one that I felt like I could really identify with was Case Study: An Accidental Techie #FAIL Story.

One of the reasons I feel so comfortable with Melissa Barber’s feature is that I really believe that one of the best ways that nonprofit techies (accidental and all others) can help each other out is to admit where we have failed. We shouldn’t be ashamed of what hasn’t worked out right in the past, because I think in ways you really learn from failing.

I do have lots of fail stories. I haven’t been working in technology for ten years (most of that as the accidental techie) without getting a vast catalog of fail stories. I’m also willing to share, because maybe my fail stories can help someone else with a project that is hampering them (Or at least it will provide some humor for those who have lived the same type of failures right along side me).

So, with much to fanfare, I must share my favorite all time fail story. It was probably about eight or nine years ago, when the word technology was just starting to sneak into my created job title and description. My agency only had a couple of servers, lots of new computers, a couple switches, and lots of problems. We had been bounced back and forth between vendors and our former support company a couple of times to the point that a board member gave us a random suggestion to try out.

Basically, something wasn’t communicating properly in our network and things would just stop working. The suggestion the board member gave us was to make sure that it had nothing to do with power. He told me to go around and unplug every computer, monitor, server, switch, printer – anything that could be remotely technology. It was a Friday night and at that time, I still had another part of my job that required me to coordinate an art opening that of course was occurring that evening also.

My direct supervisor at that time and myself slipped away from the art opening and started to pull plugs everywhere. We even double checked each other. Then we went into the server room and unplugged servers (we did do a shut down first), and we did the same with the switches. That’s when we realized the battery backups were running. As we did with all of the other equipment, we pulled out the power plugs, but the battery backups continued to have power. We rationalized that we had to run the power out so we started to plug things in like fans and other things to drain the power, but those battery backups didn’t seem to lose any power at all.

Finally, we called the board member but got no response. When he finally called back, we were in the server room just staring at the equipment. He asked us if we had turned the power off with the toggle switch. Looking over at my boss at the time, we both realized we had no idea what he was talking about. Laughing at us, the board member told me to pop the face plate off and to use the power button to turn off the battery backup.

The lessons did I learned that night?

  1. Always learn where the power buttons are on all new equipment when it comes in and if it is hidden behind a faceplate, keep the faceplate off.
  2. Try not to mix duties when doing something import.
  3. Pulling out all of the power didn’t fix the problem.

Ultimately we found out that the NIC cards of the brand new computers, of a brand I won’t name, didn’t communicate with switches that came from the same brand that I won’t name.  This brings me to one of my biggest lessons learned – the cheapest option isn’t always the best. We ultimately had to buy new switches (we weren’t going to replace over 45 NIC cards) and the problem for a while was solved.

I may have not learned these lessons at that time if I didn’t fail at doing that simple suggestion. I may not have learned that until it was even a bigger problem going on. I always know that I’ll remember that night (Ironically, I think it was a Friday the 13th too) and whenever I try to explain to others that failure isn’t a bad thing, this is the story I bring to the table. 

Thanks to Melissa Barber and NTEN for making me remember this valuable lesson.

Addressing Tech Change

As I have transitioned into the position of Technology Director, I find myself often having to explain why technology changes and why staff should change also. There are lots of resources out there for explaining how change is going to happen, but sometimes I find myself having to ‘advertise’ change or rather ‘market’ change. Reframing this for staff can become difficult.

Recently I wrote an article for the staff that I work with about some tips for them when it comes to technology change. I’m including it here in case you find it useful. I’m sure that you will find ways to rewrite things to best suit your situation and I hope that this just saves you a little bit of time.

Technology ChangeTechnology happens, it's not good, it's not bad. Is steel good or bad? - Andrew Grove

Technology is continually evolving, so changes in technology are inevitable. Sometimes these changes make things easier while other times the technology changes so drastically that some find it impossible to embrace the new. Those who have to implement new technology also know that it can be difficult for the new technology to be embraced. But when everyone  works together, changes to technology can be a win-win for everyone.

Change can be hard. Technology changes can be even harder if you aren’t comfortable with technology. To provide maybe some guidance, we have some tips:

  • Learn something new everyday – Some people will tell you that this tip will even keep you young. It’s a great habit to get into so that when changes do occur, you are already in the habit of learning. To work on this tip, set up a calendar appointment to remind you to learn something new or put a sign up near your desk with this phrase. Then follow thru with the action – go to a website and search information on something you don’t know. 
  • Keep yourself organized – There are people who do thrive on chaos, but most people would say that if you are trying to learn something new or adjust to something changing, chaos can be a detriment to the process. Take time to clean your technology up – get rid of old documents in your My Documents, keep up with email and don’t let it get out of hand, and refresh your Internet Favorites to include some of your favorite places to get technology tips.
  • Work smarter, not harder – Remember that technology is to be a tool to assist in work, and not a hindrance. If you can embrace the new software is to help out, it will be easier and you’ll adopt to the new functionalities much quicker. It can also take a lot of energy to fight against change or to hold onto the old ways. Invest the energy and try to embrace the new.
  • Don’t reinvent the wheel – The beauty with technology change, it is always happening and others are handling it too. There are lots of resources out there on the internet and you should use them. Instead of trying to make a form from scratch, use a template available from Microsoft, or go find one of the millions of free templates that are available on the internet from others who want to share their work to make it easier for others.
  • Sometimes it is best to make a clean break and forget the old way – The best recent example of this is how Weight Watchers changed their weight loss program. The leaders told everyone to forget the old and to use the new. Those members who did that found the new easier to live with. Those members who tried to combine the two found lots of difficulty. Finally those that didn’t try it at all, were discouraged and upset. You will not always have to forget the old, but in some cases, forgetting is good. It will free your mind and allow it to hold onto the new information.
  • Celebrate and reward your successes and help others do the same – Let your coworkers know what you are trying to learn to do and let them know your progress. When you complete something and feel that surge of pride, let others know about it. It makes you feel more confident in yourself and helps you prepare for learning the next thing while it also boosts the morale of others around them. Maybe you then become a motivating factor for someone else to try to learn something new. It’s a win-win!
  • I think I can, I think I can, I think I can – The worse thing you can do is give up. If you believe in yourself, you can make it happen. There are going to be times when it might seem like there is just too much change and too many new things to learn – that technology is just moving too fast! We all get there (even those of us who are creating the technology changes get lost), but if you throw the towel in, you’ll never get thru it. Take on the little engine mentality and keep on telling yourself to keep on trying. You’ll get there.
  • Rely upon your coworkers and identify their strengths – You should never think you need to be good at all things. That will never happen. We have a vast variety of people in our agency and there is a good chance that someone that works near you may be good at what you are struggling to learn. Instead of trying to do it all by yourself, ask around and see if others might know what you don’t. You might be surprised that the person right beside you can turn the light bulb on for you and shed some light on those places you are confused about.
  •  Always be prepared – The Boy Scouts have it right – never be caught off guard and in this sense, always be ready for the next thing to change. Change will continue and things will never stay the same. Be prepared for what will be next and be ready to face it on rather than hide from it!

Previous Older Entries