When You Can’t Juggle Any More Projects

Cover of "Juggling (How to Make Series)"

Cover of Juggling (How to Make Series)

I know a lot of other nonprofit techies out there. When I have a chance, I get to talk with them about once a month. I’ve easily identified one thing about all of us – we all are juggling a lot of projects. To some, we may even be trying to juggle too many projects. Right now, I am personally in that spot where I feel that all of my projects are up in the air and not many of them are in my hands being controlled by me. It’s a very scary spot to be. So, I started to research this “juggling projects” for some insight on what to do and how to do it and unfortunately, there is no step-by-step guide on how to manage this little side-show my tech projects have become in ways.

One of the best resources I came across very early this morning while I couldn’t sleep (worrying that one, or more, of my projects was going to suddenly become a medicine ball and crash down on me) was by Vijay Aluwalia titled Juggling Projects With Forgotten Strategies.  One of the things I liked most was there wasn’t one suggestion that said “Say No” – because most often, I find that the art of saying no is disallowed for my situation right now.  But I want to list her suggestions and give some of my interpretations of what she is pointing to, especially from the angle of the nonprofit techie.

1. Identify the current universe of projects, both  being worked on and desired. – It is sometimes very difficult for me to not focus on all of the projects already up in the air. These are projects that are essentially outlined for me in our Tech Plan. Yet, I also have that internal list of “I would like to do” projects that I know will benefit my agency. It was refreshing just to take a moment and split a piece of paper in two and write down current ‘have-to-do’ projects and future projects. It also reminded me, as soon as one of my current projects is completed, another one is going to be added into the mix. Another thought here is that it’s much easier to juggle projects that I help determine than projects given to me. I need to find a voice about these “I would like to do” projects and advocate for them.

2. Clearly link the expected value of the project to  the strategic objectives. Map out the resources required to implement each  project. – I admit, I’m a bit of a control freak when it comes to really important projects. There are always issues or concerns when I bring in too many other people. Interestingly enough, I read another resource this morning about by Matt Cohen titled Juggling Projects. He quotes Charlie Dancy as saying “The extra hands are an advantage, the extra brains are a problem.” This quote is my stumbling block and I need to learn how to handle this better. However, Vijay Aluwalia points with this suggestion to one way I can make giving parts of a project over easier – link it to a strategic outcome and provide the resources. I can’t just assume that my coworkers have the clear vision that I have of a task so I need to make sure to take the time to provide the vision.

3. Create a decision-making process for prioritizing  projects. – I admit it, my gut screamed “But I don’t have the decision-making process!” when I read this suggestion. But taking a deep breath and truly thinking about this suggestion made me realize that I do have some ways to prioritize projects. I find that I do this much more successfully with steps within projects and very well when it comes to address the onslaught of HelpDesk tickets that I find myself facing. I think for projects that can be clear-cut – rolling out new computers – the best strategy is outlined in David Allen’s Getting Things Done process. This is the way that I address HelpDesk tickets. Take it a step further and explain to others how you are making decisions. I find that my tech department staff is starting to follow these principles too.

4. Conduct a gap analysis on the resource  requirements against higher priority projects. Get the resources you need to  succeed. – I didn’t get to this point of feeling that there are too many projects in the air without realizing it doesn’t seem like there are enough hours in a day. To think that I am going to stop and do a gap analysis right now, well, it’s not going to happen. But I didn’t want to pan on this suggestion because there are some projects, especially with nonprofit tech, that you actually do this with and you might not know it. I equate gap analysis to be like writing a grant for technology. When you are writing a grant, you have to justify why you need the monetary resources to purchase equipment or to develop a database. You gather quotes and you outline the anticipated outcomes of completing the project. You provide timelines of when you expect outcomes.

5. Implement a process for how projects are  initiated, delayed, accelerated and cancelled. – Again, my gut screamed out “You aren’t allowed to cancel projects!” when I read this one. I’m not going to focus on that part of this suggestion. But the other suggestions of initiated, delayed and accelerated really are things that I can control. Last year when I found myself with a network that was beyond maxed out, I had to get that project to replace the hardware of the network accelerated. It wasn’t easy. I found myself having to outline the pros and cons to addressing the issue right then to upper management. It was scary because that list of cons were very scary to  me. Guess what, they were scary to the upper management too. By addressing those pros and cons when trying to identify if a project needs to be slowed down or sped up, you will see who your allies are and more often than not, those pros and cons will provide you the buy-in you need to delay or accelerate.

6. Involve team members from various groups in the  entire process. – I find my champions of certain projects very easily. They aren’t all tech department members. Some of my best champions are from the accounting department and development department. I also think this step points to something that no one really wants to write out as a tip – but you naturally also know who aren’t your champions. Without identifying them and having a strategy on working with them on a tech project, that project can end up in the air a lot longer than you desire. These people appear to me to react more encouragingly towards tech projects when they see more than the tech department driving the project.

7. Get buy-in from senior management  throughout. – I’ve alluded to several things that indicate that I work hard towards the senior management buy-in on these tech projects. I have an Annual Tech Plan that is written by my department but ultimately is approved by a board Tech Committee. Larger projects get managed by someone in upper management (this can create other challenges, but that’s not for this post). Having this support makes it easier to go upward and say “I’m really struggling with this many things on my plate, I need your help in addressing the details”. If my superior is not on the same track as me, I am not going to get the help I need.

8. Make the data (from all the points above)  visible. Colleagues will be so much more supportive if they see and understand  the bigger picture, why decisions are made in a certain way and how they are  impacted. – I’ve already shared one way of showing the information – making a pro and con list. But there are two other things I have been doing to help support projects. First, for large projects, I provide at least two options on how things can go and I spend the time to make it as easy to understand. This usually means graphics to illustrate the technical aspects. By providing options, they are part of the process. Very rarely do I not get asked “which one do you think we should do?” Second, proof of concept. I don’t just take the word of the vendor that the equipment is going to do exactly what they say it is going to do. I found out from a decade of experience that there is always something about my network that makes it harder after I have made the purchase. So the new digital screen software that I wanted, that company had to provide me a demo and equipment to make sure that it worked in my environment before I signed off on that contract. Vendors are willing to do that and upper management likes to see you taking the extra step to ensure success before starting.

9. Have the courage to make tough decisions and get  senior management to support compliance. – Yep, that gut was screaming on this last one too. I know some nonprofit techs that got this art of saying no down to a science and it is accepted. I know that there are others like me that are in unique situations that make saying no a lot harder. Sometimes I find that the tough decisions that I have to make are to reboot a server in the middle of the day. It really just counts on the environment. Yet, I’ve never had upper management get upset when I’ve rebooted in the middle of the day because they realize that I do not just randomly reboot things without a reason.

I’m hoping that some of you have suggestions for juggling projects. Do you have a book that gives a step-by-step process guide on how to handle it? I’m looking for the resources and I’m sure others are also. I know that I feel better when I can identify that there are so many things up in the air.

And lastly, my own suggestion – plan a vacation or trip to make you look forward to walking away from the juggling act for a while.

Additional reads:

Balls of Steel: Juggling Projects

How to Juggle Multiple Projects and Clients Without Going Crazy

“If the throw is right…” Juggling multiple projects


Relations with a Vendor

While I was just starting out in technology, I did not realize how important my technology vendors were going to be to my personal success along with the success of implementing technology. It took me a long time also to realize that my technology vendors were not just the service provider we were aligned with, but also had to include the company that did the wiring/cabling, phone company/broker, cell phone company/broker, training schools, database developers and the numerous companies who provided us software.

Most things with building the relationship with the vendor have little to do with technology and much more about communication. The accidental techie can also face the challenge of being concerned that the vendor knows much more than they do and may find it personally challenging to believe that their voice can be heard.

I will give you my story on this one. I had worked with one support company for a couple of years and it did not go so well. Ultimately, my boss and our board committee decided it was time to part ways with that support company. I went about 18 months with no support company other than a board volunteer. I knew that he respected my knowledge and I never felt like I didn’t know enough. However, when it was time to get a support company again, it scared me. In fact, one of the first people I met from the new company scared me. I was sure that he knew that I knew nothing (and back then, I didn’t know as much as I do now). I would quake in my shoes and would feel sick whenever having to deal with him. He was very knowledgeable and was full of ideas that helped us immensely.

Overtime, I worked with other staff from this support company. In fact, they are still our selected vendor of choice. I grew in my knowledge and my confidence in my knowledge. I hadn’t worked with this man for a long time until recently again. I looked at him and realized that I wasn’t scared of him any longer and that he did respect what I did. I think it was funny when he looked at me and said, “You aren’t scared of me any longer.” Since then, the joke is that I have him on his toes because I ask lots more questions than I ever did and I will not back down to just accept his answers.

My point in sharing this almost embarrassing story from my past is that I am sure that other accidental techies have probably felt this way in front of vendors. Vendors are to be the experts and you are accidentally in technology. It’s easier to worry about managing the money and contracts with the vendor than it is to want to handle the conversations with technology. It can be very easy to believe that the vendor knows what is right and it may cause you doubt in yourself.

I have some suggestions:

  • There is no such thing as a dumb question – If you are going to build a relationship with a vendor that is going to be strong and good for your agency, you have to feel comfortable asking the questions. The right vendor is going to answer all of the questions for you.
  • Share with your vendor – It is important to let your vendors know more about your agency/organization than just what your technology needs are. They need to know who you serve and how you do your job. One of my commitments when meeting a possible new vendor is to be direct with them and admit we anticipate that our vendors will support our agency in return. Get that kind of committment out there in the open and you may be able to even get a fiscal supporter out of your vendor.
  • Learn who is who at the vendor – I have a small secret – sometimes people will help me outside of ‘work’ to help me get things done. It’s not a contracted relationship and it is a very slippery slope that can get someone into trouble counting on their work regulations. But if you can build a friendship with someone who may be able to give you a quick answer to something or help move a rack in the server room, I couldn’t say that I haven’t done that.  But watch out – the sales representative is not going to go for this. Get to know the roles of the people you interact with before trying anything on the side.
  • Research – The internet is a wealth of information, and I’ll probably share some of those in further posts on this topic. New ideas on how to manage vendor relationships are always out there – so take some time every year to just do a general search on Google and read anything of interest.
  • Stay in touch – even with the big vendors – When I say “big vendors”, I mean those representatives from companies like Cisco, Microsoft, Citrix, and any other large vendors. It helps out for me to touch base with my representatives about once a year. Sometimes this will just be a sales pitch for something that you aren’t ready for, but other times, you really learn some new product that will help you out immensely.

So, work on your vendor relationships and know that it is time well worth it in the long run.

Keys to Transitioning Away From Being A Nonprofit Accidental Techie

Recently, while soul-searching about the things I wish I had known when I declared I was no longer an accidental techie, I wrote a list of things that I found to be keys to that transition. In fact, these keys are going to be the basis for this blog and they are now categories for the upcoming posts in the future. Since I know that I am still in the transition phase of this myself, I may have new categories in the future. There is no research behind my keys. They are my observations based from my experience and maybe they will help others out there.

  1. Finding Advocates – There are natural connections inside of your organization that can help you find the ability to create a network of support who believe in your transition. This may not be your boss. More often it may be a board member or a person from another department. Finding these advocates help you get a voice to have the ability to transition away from being an accidental techie.
  2. Finding Allies –Without the support of some organizations in Pittsburgh, such as the Bayer Center for Nonprofit Management (specifically the Bagels and Bytes group), I do not believe that I would have felt comfortable in identifying myself as a true professional techie. Those allies are out there and they are a support group that everyone needs. Finding them at the beginning is the key and turning around and being part of the allies for other accidental techies is so important.
  3. Vendor Relationships – Vendors can either support or hinder the transition from being accidental to purposeful techie. Even within one vendor you could find a difference in opinions from person to person (e.g. the sales representative wants you to stay accidental while the technicians help you gain skills to be purposeful). Vendor relationships matter so much and changing them while you transition away from accidental techie are vital to making the transition successfully.
  4. Epiphany – The moment your brain clicks and says “A-HA! I’m not accidental!” marks a huge victory. Until you know it and feel it, you will still be accidental in many ways. For myself, I had to have the epiphany moment several times before I truly and honestly started to believe in it. I’ll share some of them with you, but I’m hoping to get some other “reformed accidental techies” to let me feature their epiphany moments because the more you hear about them, maybe you can start identifying your own “A-HA!” moment.
  5. To Certify or Not to Certify – Some industries out there do care about all the certifications and indicators of ‘formal education’ you have in order to say that you are a techie. That alphabet soup can look daunting to a nonprofit accidental techie and it may be something that you feel you absolutely need to do. It is a question that I have struggled with and I still am unsure about what the answer is. There are pros and cons. It’s about finding the balance and figuring out what you plan on doing next.
  6. Toolbox – When maintenance comes into the office to repair a leak they often arrive with that worn red metal toolbox that is bumped and squeaks when it opens to find a mess of tools within. Our tools are different – books, websites, blogs, freeware, smartphones, usb keys, and gadgets. I can help you fill your toolbox up because all techies need a good toolbox – virtualized or not.
  7. Changing Identity – I found that some coworkers had already started seeing me as a techie when I finally said I was no longer accidental. However, I still have coworkers who see me as the social work intern who knows how to install software (and that was a decade ago). Changing your identity for anything is hard. You can’t just go to the facilities manager and tell them to change your ID badge.
  8. Now What? – I guess I had a view that when I dropped the word accidental from in front of techie that my job would suddenly seem easier and it would be an easy street. Yet, what I found, there was suddenly this whole new set of responsibilities and expectations that I was not ready to handle. Overnight it was believed that I would know about technology budgets, tech plans, technology policies, RFP, grant writing, social media marketing, managing interns, creating a department, and a whole slew of other things that I’m still learning are now expected.
  9. Uniqueness – This key almost seems to be at odds against the key of “Changing Identity” but after reading the book Linchpin: Are You Indispensable?  by Seth Godin I got it. There was a reason why I started where I did. I liked fundraising, development, newsletters, marketing, and special events. It tapped into my creativity. While moving away from being accidental, there are a lot of things that I used to do that I had to give up to others. Yet, there are some things that I fight to continue to do, because it is what makes me unique, happy, and in Seth Godin’s words, it makes me a linchpin.
  10. Staffing – Once it was clear that technology in my organization was not going to go away and that by myself I could not keep up with what was needed, I got to hire a staff. But does a former accidental techie hire another accidental techie or do they hire someone who is a trained techie. There are pros and cons to both that make staffing a challenge. How do you evaluate the needs of the position to determine what is needed? How would you feel about hiring a trained techie?

These are the ten top things that I personally thought about in my personal adventure in this transition away from being the accidental techie. It didn’t happen overnight. It has been a decade in the making and there are times that I still feel like that accidental techie. I hope that if you do have tips in any of these keys that you share with me, comment to my posts,  let me integrate your experiences into a post, or even become a guest writer for a post or two. Together, I’m sure that we can help more accidental techies drop that accidental word and be techies.