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

Demystifying the ‘Tech Magic Wand’

Day 255: Magic Wand

Image by amanky via Flickr

Take a moment and think of when that one staff member comes running into your office for support. Their eyes are wide open, they seem to be a bit out of breath from the run to your office, and it is clear that there is a problem. They start explaining the problem to you as you walk with them back to their computer. They have tried everything that you have told them in the past to try. They have logged off and then logged back on. They have then logged off, turned the machine off, waited and then got back onto the network, but nothing is working right. You get to the computer and ask them to logon and – “Poof” – your presence has allowed all the magic to happen and the problem has been fixed without you even touching the keyboard.

This is the Tech Magic Wand.

Our users really believe that we have this tech magic wand. They may even think it is our aura or that we actually have a magic wand sticking in our pocket. And after all of this, the staff person can have a swarm of emotions, probably not all that conducive to liking technology any further. It makes your presence grow in mystic and mythicism. They begin to doubt what they have done and it can actually hinder moving technology forward with the end-user. They may even become more resistant to trying to resolve problems themselves or even revert to old methods. To the extreme, this can become the user that starts the rallying cry to go back to pen and paper.

After reading Switch and hearing Dan Heath speak about the Elephant and the Rider, I do realize that these emotions that the staff members are having are completely Elephant in nature. That Elephant has the strength in telling that staff person that you truly are magical and that they aren’t. So I believe in this instance, you need this staff person to feel that you aren’t magical. This isn’t about appealing to their Rider – they logically know that you haven’t wiggled your fingers and fixed the problem – but the Rider has lost control of the Elephant.

This is where I believe that sharing a story of failure is the key. It probably goes against our desires – no one really wants to admit when they have had bad things happened, but I truly believe that fails are great tools not only for learning, but for also showing others that you haven’t mixed up any magical potion that fixes computers when you are around.

While at the Nonprofit Technology Conference I had one of those moments that the technology got the better of me. Almost a classic #fail. As a tech person, a Tech Director no less, imagine if you were giving a presentation and the laptop you were planning on using would not register the projector? Now we all would probably just go to another laptop. Imagine that the second laptop is communicating with the projector, but the USB drive with the presentation is not being recognized by the second laptop. On top of that, the internet is pretty slow and once the presentation is downloaded via email, there is a protection error in the file and it won’t open up. Now you are the one in need of help – you need someone else’s magic. You – the tech person for your agency – the one who usually performs the magic – needs the assistance of someone else! The horror!

That was me.

But things worked out. The presentation got up and for the most part, except for my nerves being shot and some shuffling of slides in the presentation,I don’t believe this mishap impacted the session. Yet, still now, I admit during those moments, it felt bad.

But it is also good.

Good? How could this be good?

It has given me a tool to humanize me – to show staff members that things like this happen to me too. It shows that even though I might understand technology and work with technology – the machines sometimes get the better of me. This story appeals to their Elephant. It lets them know that they aren’t alone – they can feel that I have experienced the same thing that they have. Some might even feel empathy for what I went through while in front of all those people. It can open up a conversation and it helps to get their Rider pulling on the reigns of those emotional reactions of tech people having magic.

I don’t want to lose all of my magic – I do have tricks for making things work – but in the long run, that isn’t helping me and it isn’t helping them.

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.