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.


NTC Week – And I’m Stuck in Pittsburgh this Week!

Road Construction - common in Pittsburgh - by

I have to admit – the past two years I have been spoiled. I had my first taste of the NTC two years ago in Atlanta. I liked it so much that I even presented during the NTC that was held last year in Washington D.C.  Things were looking good for this year until I didn’t have a session selected for this year’s NTC and budget cuts along with state regulation changes put the landing gear down on any hopes of flying out to NTC in San Francisco this year. I know that I could do the online NTC – but I know unless I could lock myself in a closet with no phone and no email, the money spent for the online NTC could potentially be a wash.

So I know now that I have to plan tho handle this week. I have to battle the depression that I have. The past two years the NTC came at a time that I needed that ‘shot-in-the-arm’ to be excited again about my job. I came back with ideas and energy. Now I have to find a way to reenergize without attending the NTC. (I don’t have this one figured out – so I’m looking for great ideas on this one!)  Without a plan, I will cringe with every Tweet, Status Update, and Pinterest that I see related to NTC.  So, here is my plan to survive while dodging the orange construction cones that seem to be multiplying in Pittsburgh this year.

1. Make a buddy get the important information for me – I have a good friend who does get to go. I’ve already given her a list of vendors that I would like the information back from if it’s good. She knows what my job has been focused on lately and I explicitly trust her to do a good job.

2. Filter, Filter, Filter – I now will know how it feels to be on Twitter and not be at NTC. I am following so many folks that are involved with NTEN and NTC, I know that my Twitter will be exploding. I am going to have to find a way to find the relevant information that gives me pertinent information that I want to grab hold off and not the tweets about things that I miss, but aren’t really relevant to my job (last year it was about the Super Moon the last night of NTC and about a food truck with crab rolls).

3. Roll out new functionality  – Nothing like real work to keep my attention off of what I am missing. There is a lot of it going on at work right now. Starting tomorrow, I start several weeks of migrating my phone system software from one version of Cisco Call Manager over to Cisco Call Center. I’ll get down and dirty with all the change management tricks I have learned from the keynote last year. Anyone try to switch their automated attendant on the phone system knows the politics that erupts and all the chaos that can occur. I need to be ready to direct that elephant and get this project done. In the end, I know the new capabilities will make the caller so pleased and that has to be the focus.

4. Work on presentation for All Aboard! Don’t Leave Your Users at the Tech Project Station – I may not have a session this year – but I do have this wonderful opportunity to discuss Tech Projects in this webinar for NTEN. In ways, I am more excited about this opportunity – I can do the presentation in my jammies if I need too!

5. Connect with my fellow nonprofit techies – It will almost be like a smaller version of NTC when a group of us get together for Bagels and Bytes. The topics will be determined on Wednesday morning and it could be a wild bunch – but they are all in the same boat as I am – and we will all still be in Pittsburgh.

I am going to miss NTC this year so badly. Now it is time to start planning for next year. I can’t miss next year!

Blogger’s Block: Step Two – Find the Why

It has been an interesting week and coming back to blogging has been a great reward of the week thus far. This small series of posts is not to give all the answers to how to battle Blogger’s Block. In fact, there are lots of other great resources out there for that, especially if you visit ProBlogger (and if you are reading my blog, you should be reading his!)

photograph by Mike Gifford at

Interestingly enough, while exploring what I wanted to discuss today, I tapped into another resource that I actually had the luxury of finding out about at work. It is the book, Start With Why, by Simon Sinek. My first exposure to Sinek was by watching a video that our CEO wanted us to watch. At that time, it was about finding the Why at the agency. Today, I am applying this to getting out of Blogger’s Block.

You need to ask yourself the simple question, why do you blog? Now, if your answer is that it is part of your job, you better find a way to continue to blog even if you aren’t feeling the mojo. However, I always find that money, and job security, is a good motivating factor to doing things that you’d rather not do right then.

But if your answer is that you are doing it for some other reason – for your family, for fun, for a way to relieve stress – or whatever other reason you may think of – maybe it’s time to rethink that reason or at least reframe that reason.

It’s not going to be easy to think like that either. I know that my thought process was that I was blogging for other nonprofit techies that may have been accidentally given technical jobs or those who are now acting purposefully.  That was probably one of the biggest smoke-screens I had created in a long time – and I had created it around my own vision of what I do.

Reality is, I find that when I do blog, it is to write something that maybe another person will related with because I rarely get that type of interaction on the job. This blog isn’t part of my job but everything that I write in it is about my job. But being a nonprofit techie can be a very lonely place in that nonprofit. Add to it that I am a female nonprofit techie, makes it even a bit more difficult to find that other person who gets it. I can find other techies, but if they work for for-profits, their experience is so different. So, I turn to the world of cyberspace and I write.

There is another reason why I do this. It helps me organize my thoughts about a single thing. Too often I spend my days multi-tasking my multi-tasks. If I could have six hands, I’d be trying to have eight different tech gadgets in action all around me. Taking the time to write a post, about one thing, allows a focus that I don’t generally get. It’s a refreshing thing to do.

Remembering that why – blogging is refreshing to my mind – starts to knock down those hard cemented blocks of Blogger’s Block. It’s not a big sledge-hammer taking those blocks down, but it is chiseling away at the magnitude of that wall I have been facing.

Blogger’s Block: Step One – Admit to it

An example of some of the excuses I told myself for having Blogger's Block.

I have to admit that I have had a terrible case of Blogger’s Block. The excuses have been many in the months since I last posted. Those excuses went from “After you get the new building open and staff settled, you’ll start-up again” to “I’ll just play one game of Slingo before writing a post”. It can be such an easy cycle to get stuck within and breaking out of it can be difficult. Every single day there could easily be just one excuse, or there could be a hundred excuses. Rationalizing Blogger’s Block is simple.

I also believe that Blogger’s Block is worse than Writer’s Block.

These terms may appear on the surface to be the same thing – the inability to write. I’m not going to say that they aren’t related to each other but I do see a distinct difference with Blogger’s Block.  The biggest reason why they are different in my mind is related to how much time is spent building up your followers to your blog.

If you are a blogger, you know that you not only have to spend the time writing the posts, but you have to spend the time building the relationships, cross-posting on social media sites, and following up on similar posts on other blogs. After spending time getting that established, it is even easier to lose that work. Those connections slip away faster than it took to build it up and you might find yourself back at square one.

Now I hope to be on the road to recovery. I’m finally pushing aside those excuses (and ignoring email until I finish this post) and pushing past what I haven’t done to focus on what I can do now to get back to this blog. It may end up being square one, but maybe I’ll help someone else avoid this pitfall with some wit and wisdom from my experience.

Characteristics of your early adopters to tech projects

Apple Store, University Avenue, Palo Alto, CA

Image via Wikipedia

We all have seen the news stories of the line around the Apple store when iPhone was released and then again when iPad was released. It’s pretty clear to see that those customers outside that store are the early adopters of Apple’s technology. They are completely invested in trying the new tool out and they willingly go forth knowing that first generation usually will have some blips and beeps that aren’t exactly right.

So when you are facing a new project, what qualities or characteristics do you need to see in the people around you to know that they are your early adopters? For me, I have found that often what I need in an early adopter of a tech project is not always the same person who is standing outside of Apple waiting to have a new iPhone or iPad in their hands. Sometimes, I have found that those Apple early adopters are amongst the most difficult people to get on board with my tech project.

I’ve noted a few characteristics and I really hope that this drives some conversation, because early adopters are the life blood of almost any tech project. I’m always looking for new ways to convert over more to this category and I might not see something as a sign of being this type of person – but you might. Let me know what other characteristics you would include on this list.

  • Leadership – There are two things I must mention under leadership – I need both types – the leaders with official power and the leaders without official power. Most tech projects do not get launched if there is not a member of upper management who has given their blessing. If I can’t get that leader to bless the ‘go forth’ movement, I have to go above them – to the board tech committee. That is very rare now. But the more important leader you need to get into the early adopter category is the unofficial leader. This is the person that others might go to for help because they are afraid of tech staff. This is the person who you know if they discount the project that their word will care far more harm. I find most of my time is spent with these types of leaders – but no doubt about it – you need both leaders.
  • Ability to give constructive feedback – There are some people who are going to find every single thing wrong with a project. If it is a database project, they are going to hate the font, color, logo, and even the pace of the cursor blinking speed. This person is just providing criticism – not truly useful feedback. Constructive feedback never feels like an attack and it provides more information. Maybe the issue with the font is a true issue. The person providing constructive feedback would indicate that the font is an issue and then provide examples about why it is an issue. That why is so important! For more about constructive feedback, read The 4-1-1- on Constructive Criticism.
  • Independence – Counting on the scope of your project, you may not have a lot of time to provide one-on-one training. Early adopters are more than happy to explore on their own. In fact, they often prefer to be given a little bit of information and go off on their own. While this can be scary (they might run into something that isn’t done!), it is so useful for you. Your time can be spent on preparing for those other users who need more guidance and assistance.
  • Sees the ‘light at the end of the tunnel’ – Again, your type of project impacts how important this is. Switching out hardware probably won’t be hard to sell the end of the project. But if you are in a project with lots of twists and turns (database development is my example here again), you need to have someone who can see that after a lot of work up front, the work will be less at the end. Too many people get hung up with how much ‘extra’ work there is at the beginning of a project. Their fears get in the way as they begin to fear that it will always be all this extra work to make it happen. Your early adopter needs to be invested in your vision of the end of the project. They then become your voice with others when you start pushing the project out to others.
  • Ability to market the project – You are not the best person to sell your project to other end users.  Your early adopter is the best person to sell your project. These early adopters should be able to communicate either verbally or written the positive points of the project. They will tie in the ‘light at the end of the tunnel’ vision along with benefits they have found. Your early adopters are going to find benefits that you haven’t even thought of – and they should be able to tell others about it. They need to be able to talk to you, of course – but more importantly, you need them talking to others.
  • Not always tech savvy – While I would want users who are a bit more tech savvy if I was working on a completely mobile solution, I know the big kudos that can be gained if you get that person who isn’t as comfortable with technology involved in your project. Often users don’t believe me when I saw that I’m targeting the project for the non-technical comfortable person more than the ones who may have been out buying an iPhone or an iPad that first day. Truly, projects fail if you aren’t able to address that user who struggles with figuring out the power button. If you can get someone like in as an early adopter, you are tapping into a valuable resource that in the long run will make the project more successful.

Early adopters are so important that I plan on spending more time on this topic. It has been a very vital part of my job of late and I know as a nonprofit techie I cannot always find enough tips on how to find, manage, assist, encourage, develop and maintain these early adopters. They make the projects successful.

When the Fuzzy Front End Reappears – Beware!


It would be nice if projects were as easy to manage as a teddy bear. Image by estherase via Flickr

I will honestly admit, I didn’t know what was meant by the fuzzy front end until I was looking for some resources about keeping custom application development on track. I had heard about the agile methodology and the scrum methodology, but I hadn’t heard the phrase the “fuzzy front end” until recently. Part of the reason I’m sharing this is because I’ve been in a situation where some of the tenants of what marks the fuzzy front end have reemerged towards the end of a project that I’m working on. It’s really scary because the fuzzy front end should really be the beginning of a project.

For those involved with innovation, the fuzzy front end is that odd period of time at the very beginning of a project when you know that you have to do something and you are gathering all the requirements and desires about the project, prior to developing a project. What is interesting to me is that in the articles I have been reading about the fuzzy front end, almost all point out that the key activities that go on in the fuzzy front end are not always the same. More importantly, even within the same organization, this period of time does not happen with the same steps.

Now, I’ve been in a project for a long time and I’m seeing a lot of the things that we were seeking answers for at the beginning of the project, occurring again right before we are ready to wrap up the project. After spending so much time trying to prepare for what was needed, a new wealth of ideas, concerns, and requests are flooding in. In reading material by Johan Frishammar and Henrik Floren titled “Achieving Success in the Fuzzy Front End Phase of Innovation“, they outlined 17 success factors. I’m well beyond the fuzzy front end, but I am finding out that several of their success factors are really good strategies to combat this second wave of input that feels a lot like I’m at the beginning again.

  • The presence of idea visionaries or product champions – This success strategy that Frishammar and Floren outlined really harkens back to a person or persons who are forward thinking and can think of the large picture. I have found that a lot of the reasons why we are struggling to complete and we are re-evaluating stuff that was done years ago, is because the focus was now on the nitty-gritty details, and not the overall picture. I’m too in the trenches right now to be seen as the idea visionary or champion – so I had to bring in someone else to be that person – our CEO. The entire team had a discussion on the history of the project and how it is to fit into the bigger picture. It was a nice shot in the arm for some.
  • An adequate degree of formalization – I haven’t heard too many stories of other nonprofits being really rigid in their structure, but I know that formalization varies from agency to agency. I tend to believe that I’m in an organization that is pretty darn flexible. While that is great for almost everything we do, it also makes project management difficult. As this project has had bumps in the road, we’ve had to put more formal methods of documenting what is going on into place. If this was done at the very beginning, and assignments given, it wouldn’t be seem as a band-aid  for the situation. But now that we have identified the struggles we have had, putting in a structure has helped out. It is perfect to know that you are sending out minutes of meetings outlining decisions that were made. It gives a formal outline of what was done and tangible proof of agreements.
  • Project management and the presence of a project manager – It was hinted to in the last step that I identified. Now, I cannot stress how vital it is for someone to play this role. If you are struggling with a project and no one has really stepped up to be the leader in coordinating efforts, take the time to either identify the project manager, or take the lead yourself and be the project manager. It might mean more time on your side, but the group will gain traction and start moving forward again with just this simple change.
  • Beneficial external cooperation with others actors – I believe that the agile methodology and the scrum methodology shows how a team can move forward a project in development. But if you are having new ideas or requirements arriving at the table, late in the game, it can be harmful. I believe that you are never going to build a project that satisfies every single persons need, but when new people are inserted into your group, if they know nothing, someone has to give them the guided tour. Someone has to educate the new member to where you are and how you are operating. If you get too many new members, your entire group changes and adjustments have to be made. I wish I could include every bell and whistle that is desired by every user, but it isn’t possible. What’s important is to get the most important and critical items, and know that it isn’t all going to happen.
  • Project priorities – This success step can be awfully difficult to address if you are in a project that crosses between multiple departments. I like to compare this to when upgrading to a new version of Microsoft Office. There are some departments that the biggest concern is how different is Outlook. There are other departments that are more concerned if Word operates better. Of course you then have the accounting department that is all about Excel. When you have a mixed team working together on a project, each member is probably going to have a different priority. If you have to stop forward progress and identify what are the priorities of this project overall, then stop and do that. It gets everyone back on the same page and you combat the feeling that you are heading back to the Fuzzy Front End.

I know that this is a process and also realize that while we near the end of this particular project, we are also nearing the beginning of the fuzzy front end again. It happens when you start mentioning “phase two” or “next version”. These aren’t bad things.  But it can be a game changer if you cannot find a way to identify these items for this next cycle and find a way to close the project that you are on right now.

I’m finding the reading about the fuzzy front end interesting and exciting. I want to learn a lot more about it because I know that as a nonprofit techie, I am going to really be involved with it more in the future.

Show Your Techie Some Love Today!

Today, we are appreciated, thanks Karen!
Image by insomnike via Flickr

Did you know that today is SysAdminDay? This day, created to celebrate and appreciate System Administrators means so much more to me because I know that nonprofit techies out there all function at some level as a System Administrator, even if they do not feel that they do.

On the website, they have a page that outlines all of the things that System Administrators do. I see it. I appreciate it. Yes, I do most of that stuff. Until there is a holiday for the Nonprofit Techie, this is the next closest thing.

Now I know that most people aren’t going to go out and buy gifts for their nonprofit techie or their system administrator today, but I think this day should give everyone a moment to pause and think about all the specialized things that these individuals do, that you might not quite understand. It might seem as if this person as a magic wand that they wave to fix things. It might seem as if this person has some sort of magnetic field that when they arrive at your desk all things start to work again. It might seem like geeky voodoo. But really it is just skills that these nonprofit techies and system administrators have that other types of workers do not have.

Yet, I know that it sometimes hurts when our skills are seen as a magic wand or  magnetic field, and especially worst when seen as geeky voodoo. Technology is needed by the organization, and all too often, especially in nonprofits – where the technology department sits isn’t natural. Are we a support to users and therefore only focused on customer service or are we a program that is needed to run the agency? Should technology be separate from the fiscal department or not? Should technology be development, marketing, or media also? It’s all things that add to demands of the job.

Today is just a day to think about these special people who help organizations run. If you run across one today, simply thank them for their work. Let them know that you realize that it”s really work for them and not some magical wand. I know from experience it is so nice to hear from some end-user in a department that I rarely ever see simply say “Hey, good job”.

Of course, if you feel that you need to go out and buy a gift, I don’t know a nonprofit techie out there that would turn away an iPad.

Previous Older Entries