This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it.
This year has been exceptionally stressful. The project I’ve been working on for most of the last 2 years is coming to fruition; I have an additional new interim job; and I have a major uptick in outside professional commitments. Normally I’d have just let myself get buried and then frantically spend months trying to dig myself out. But knowing my normal pattern, I decided I needed a change. I heard about Getting Things Done (GTD) previously and knowing a little bit about the system, thought it might be able to help.
Getting Things Done is the name of a productivity system created by David Allen. The system is outlined in Getting Things Done: The Art of Stress-Free Productivity. There are also a lot of online guides, resources, and seminars put on by David Allen’s company. I’d first learned about it from Lifehacker, who put together a good introductory guide. Since I was hoping for something to deal with stress, this seemed to be just what I was looking for.
Getting Things Done centers on five steps:
- Capture – Getting everything in your mind into a trusted system
- Clarify – Processing those things and determining if it needs to be acted upon, filed, or trashed.
- Organize – Putting things into a system so that you know where they belong
- Reflect – Reviewing lists and items and keeping the system up to date
- Engage – Using the system to determine your next actions
Right away this process really spoke to me. I tend to keep much of my work in my mind. Since I live and die by formalized product management systems, this has never had a negative impact on my work; no missed deadlines or the like. What it did do was cause havoc on my subconscious. Difficulty sleeping because my mind would dredge up all the things I probably should have done or trouble focusing on tasks like writing because I was so distracted were common. Allen addresses these issues clearly and often in both the book and the overall system. By creating a system you know you can trust, you can get these things into that and out of your mind. While my overall adoption of GTD has been slow, it has certainly helped free up my subconscious. Even better, I am much closer to being stress free than I was when I started.
The other area in which GTD shines for me is its workflow. The system begins with an inbox that collects everything: email, notes of random ideas, paperwork (this can be electronic or physical, GTD doesn’t require any specific tool). Contents of the inbox are then processed, or clarified, to determine if the item is actionable or not. If no action is needed it can be filed, moved to a ‘someday’ list, or trashed. If it does have an action, ask yourself if this can be accomplished in 2 minutes and if so just do it. If it will take more than 2 minutes it can be delegated to someone else or deferred to a later date. Those deferred items then make up the bulk of your next action lists.
If my only take away from GTD was the 2 minute rule, buying and reading the book would have been worthwhile. I’d heard of the idea before, but finally putting it into action has made all the difference. I can’t even recall the number of times I’d have to write an email, but decide I didn’t ‘feel’ like doing it. So I’d put it on a list of things to do (at this point I’ve probably taken longer than if I just wrote the email) and put it off. Then I’d forget or it’d get buried in my to-do list. Finally realizing I still needed to send that email, but then feeling bad for it taking so long would create stress, so I might even put it off further. Needless to say, this is no way to work or live. Forcing myself to do those simple tasks, even when I don’t ‘feel like it’, has led to less stress, fewer distractions, and quicker turnaround on almost all areas of my work.
Coupling the 2 minute rule with the overall GTD system has allowed me to handle increased responsibilities while decreasing my overall stress. That’s right: more work, less stress I can’t think of anything else I more highly recommend. There are plenty of primers out there on GTD, but do yourself a favor and pick up the book. Not only is it an enjoyable read, it is also a useful reference to revisit. The gains I’ve made using the system makes me sure I’ll stick with it and but continue to grow with it.
I want to revisit Agile Project Management, something I talked about before. That first post was a brief introduction to a project management system that is gaining popularity. What I didn’t talk about at the time were the problems I see with Agile. Despite being called Agile Project Management, it is actually more of a work management method than a project management method. Agile will never be able to tell you if you should be doing a project, it will only give you the most efficient framework for doing the work.
These differences become clear if you look at books covering the different project management methods. Take Agile Project Management by Jim Highsmith and look up budget in the index, you get a range of four pages. Those pages are actually a summary of Beyond Budgeting: How Managers Can Break Free from the Annual Performance Trap by Jeremy Hope. Look up cost and you find absolutely nothing. Compare this to PMBOK where budget has four different index entries and cost has an entire column on an index page. Agile is wise to put aside issues. Attempting to work them into Agile would complicate the system and take away some of the efficiencies it promises. The fast and loose way Agile suggests playing with budgets and costs might be possible in a startup or large tech company, but it becomes increasingly difficult in the library world. For example, if the project requires new skills among the team, Agile assumes the next sprint (timeboxed work period) will make training a priority and relevant team members will stop work on the project and jump straight away into training. A company facing a deadline for a product launch might be able to do this, but you’d have trouble finding a library that could.
Agile also makes some assumptions about roles that could potentially cause problems. The Agile team structure of Scrum Master, Product Owner, and Team Members puts a great deal of responsibility on single individuals. If a team has a dedicated product owner with a laser like focus, it stands to reason they will be able to easily assign priorities and guide the goals of each sprint. However if the product owner doesn’t have these traits, or perhaps simply misunderstand the message from a group of key stakeholders, an entire sprint could be wasted. And if you’re talking about a large team of developers , the costs in money and personnel hours could be monumental. Agile was created to solve the problem of projects that were either misguided from the start or unresponsive to change. Agile allows for more times to catch and correct problems and to be more responsive to change, but it does so by often relying on a single person.
So, is there place in project management for Agile? It’s wide spread adoption clearly shows this is the case but right now it can’t completely replace traditional project management. If you look at the traditional PMBOK process areas: Initiating, Planning, Executing, Monitoring/Controlling, and Closing; Agile only really addresses Executing and parts of Monitoring/Controlling (some aspects of Closing show up in the retrospectives). I don’t think there’s anyone out there that really likes working on Earned Value Management but it is crucial to guide what projects you take on.
I enthusiastically await a post-scarcity future where everyone can ignore budgets and costs like Agile does. But sadly we aren’t there yet and it seems as distant as other things you see in Star Trek like replicators, transporters, and warp drives. So until that time comes, there won’t be one project management methodology to rule them all.
I’ve fallen a bit behind on the blog lately as my last couple weeks have been a blur of workshops, preparing for an upcoming conference, and not making as much progress on my presentation I should be. Things should get back to normal once the conference is wrapped up next week.
The conference in question is the Ex Libris Users of North America Annual Meeting in Minneapolis. If you happen to be going and see me please say hi, I’d love to chat. And if you’re so inclined I’ll be giving a presentation about moving our locally hosted discovery system to the cloud (if I ever finish it). That will be on Sunday, May 8th at 2:00 pm in the Elk Lake room.
I’m also starting to prepare for a more general ‘what librarians should know about project management’ type talk later this year. This is proving a more challenging than I’d originally thought it would be. This is mostly because I could probably yammer on about project management for an entire day (just go listen to my Circulating Ideas interview). So I thought why not just ask directly:
What is it you’d like to know more about in the realm of project management?
Let me know and I’d be more than happy to also answer specific questions should you have any.
I’m going to take a slight departure from project management to talk about something closely related, coding. There are countless pieces out there written by others far more qualified than me about the necessity of librarians learning to code. This idea had become so ubiquitous I really thought that my ability to get a job would be predicated on my ability to learn how to code. I’m happy to say that isn’t the case and while I learned a great deal in my efforts I have to wonder if I could have spent that time learning something much more useful.
Technology has always been a part of my life and I’ve been something of an earlier adopter for a many things but I never had any formal STEM type education. My undergrad degree is in political science and I worked in politics and law. It was really not that long ago that I would still routinely use a typewriter. During library school, I took a web fundamentals class that was largely based around learning HTML and CSS and some of the back end server things necessary for setting up your own site. I had some previous experience with this from playing around on the web but the class really helped to pull that together. Around that time I also setup some self-hosted WordPress sites (something I still do and really enjoy).
But upon finishing school and starting to look at jobs and figuring out what I wanted to do, beyond librarian, I kept hearing about the importance of learning to code for new librarians. While reviewing job postings, this started to become clear as I saw many positions looking for a unicorn that could do pretty much everything (often including coding). Seeing this, I took it upon myself to learn the skills that seemed to now be required if I was going to get a job.
I picked up some reference books (I tend to like the Head First series for starting out as they are actually readable) and starting trying to self teach. I thought PHP and MySQL would be a good place to start as I could beef up my web skills and add something more to my resume. As I started going through the book and working on the exercises I was struck by something I hadn’t really ever encountered; not being able to pick up a new skill with ease. I’ve always been a quick learner and eager to develop new skills but none of that seemed to apply here. Work was difficult and I made many mistakes. I thought maybe it was the book so I checked out Code Academy. While that helped a bit, I would take one step forward and then hit a wall I couldn’t overcome. This lead to frustration and I’d take a break. But after a few weeks all I succeeded in doing was forgetting anything I had actually learned previously. Then I would start again only to become frustrated even more quickly. After an extended period of not working on anything, I thought I’d try something completely different. Maybe it was the PHP stuff that just wasn’t for me. What if I tried Python?
I started this next attempt with very realistic expectations of where I was at. So much so I got a book on learning Python for grade schoolers from the library. I thought “If they could do it then so could I.” But the reality is I couldn’t do it. And this time it didn’t just lead to frustration, it was full on depression. Clearly there must be something wrong with me if I can’t even meet the challenge of a book geared towards children.
Around this time my pre-library job became very busy and I was able to put this out of my mind. Shortly thereafter I saw the posting for my current job and ended up where I am now. I got that library job (doing some very interesting work that I really enjoy) despite not being able to learn how to code. What I realized is that I am something of a technology generalist and that works out great for the work I do as a project manager. I often have to talk with developers and turn around and summarize the information for others in a way they can understand. My attempts at learning how to code have helped that greatly but I can’t help but look back at the frustration and time I spent and wonder if there would have been something better I could have been doing.
Perhaps the most valuable lesson I learned was just how difficult coding can be, espcially for those that don’t approach the world in very logical way. Those that are able to master that in addition to the many other facets of librarianship truly have my respect. But coming in at close second is the fact that there is no one magic skill set that will make you the best librarian. Libraries need those that can code but they also need metadata experts and people with exceptional public service skills (something we often overlook at times).
I still occasionally dabble, working on deep search box to tie into the discovery system or a simple bookmarklet that lets you get at xml behind the records. Nothing incredible but enough that I can convince myself it was all worth it. But more importantly, I have a much better understanding on where my strengths are and the type of work where they can be best applied. I’ll probably never try another earnest effort at learning how to code and frankly I’m happy for it.
I’ve had a number of people ask me about project management certification, certificate programs, and education options and just how useful or necessary they are. Sadly, there is no one right answer and a great deal of it will depend on situations but a primer on what’s out there would certainly be helpful.
Project Management Institute (PMI) Certifications
PMI is the professional organization for project management and handles it’s formal certification process (I’ve talked about PMI before). PMI currently has 8 different types of certification but I’m going to pare that down to just the primary two that will be of interest here: the Project Management Professional (PMP) and the Certificate Associate in Project Management (CAPM).
The PMP is the primary certification for project management. If you ever go looking for a job in project management outside the library world, you will almost certainly see this as a requirement. Requirements for the PMP include a four-year degree, 3 years project management experience with 4,500 hours leading projects, and 35 hours of project management education (more on that later). The application to sit for the exam will require you to outline those 4,500 hours and applications can be pulled for a full audit. Once your application is approved you have one year to sit for the exam. The exam must be scheduled at a testing center and is 200 questions. It is rigorous and often requires extended study outside the required 35 hours of education. You can sit for the exam three times in the year after acceptance. For anyone who is only occasionally running projects or doing so as a secondary part of their job this is almost certainly overkill. The 4,500 hour mark is also a significant threshold that many would have difficulty making.
A better option in most cases would be the CAPM. The requirements are much less: a secondary degree and 1,500 hours of project experience or 23 hours of project management education. For those looking at a career transition, this is a great way to get a start at making the 4,500 hours required for the PMP.
In most every case a continuing studies certificate program is what I recommend people do. These programs have become so ubiquitous most schools have them. And if it’s the case your current place of employment or alma mater offers them, you might also be able to go for a greatly reduced cost. The fact that there are now so many of these programs can make evaluating them difficult. A good starting point is if they will complete the education requirements for the PMP or CAPM. If they are unable to tell you, you can search a list of Registered Education Providers here. I completed the project management certification though my current employer and found the program to be informative, easy on a new comer to the field, and very engaging.
The rise of project management has included a growing number of undergraduate and graduate programs in project management. This is a difficult one to summarize as the programs end up often being located in a very specific field. For example, we offer a Master of Project Management program but it’s in in School of Engineering and is solely focused on large scale construction and engineering projects. I have seen similar programs focused on software development or manufacturing. If you are looking for a career change, this might be a great option for focused experience but for most cases it will be complete overkill.
Up and coming
As project management continues to grow and develop, new options are showing up all the time. The rise of Agile has carried with it new certifications in the various roles or the system as a whole. I completed a Scrum Master Certification and PMI has recently rolled out a new Agile certification. Beyond project management specifically, there are also any number of business certifications and programs that would be of immense value to a project manager.
So what then….
The various options out there make it difficult to make definitive recommendations, but I think for most anyone in the library world would find a good continuing studies certificate program to meet nearly all their needs. Especially if it can be done in a way where you are getting a discount that will not break the bank. As I said, I completed the one at my place of work and the books (which I probably didn’t have to buy but I knew would make great references) were by far the most costly part. I’ve completed my PMP application but have been holding off on sending it in. While I meet all the requirements, it was very clear I don’t currently have the time to give it the attention it requires. Hopefully once I wrap up my major projects later this year I can start updating you on the whole PMP process.
I have talked previously about self-assessment and the popular StrengthsFinder in particular, but wanted to highlight a lesser known tool: the Thomas-Kilmann Conflict Mode Instrument (TKI). While I celebrate the focus on the the positive provided by StrengthsFinder, I find the TKI to be much more valuable for it’s attempt to tackle the difficult subject of how we handle conflict.
The TKI is very similar to StrengthsFinder in that it asks you to weight a pair of statements. It is far less intense however, with only 30 questions compared to the 200 of StrengthsFinder. The questions are well designed so that both options are socially desirable. It can be easy to think of things related to conflict as being bad or a problem so this cuts out the ability to game the assessment.
Upon completing the questions you will receive a report that gives you a percentile breakdown as well as the number of choices you made for five different categories:
- Competing: this is an assertive and uncooperative, power-oriented mode. Someone in this mode puts their own agenda ahead of others and will use any means to achieve it.
- Collaborating: this is both assertive and cooperative. Someone in this mode will work with others to find a solution that can satisfy everyone.
- Compromising: this is a middle ground between being assertive and cooperative. This is in many ways the ideal state to strive to.
- Avoiding: this is unassertive and uncooperative. This is the classic case of someone who avoids conflict and will not bring up issues that might result in it.
- Accommodating: this is unassertive and cooperative. In most ways this is the opposite side of competing. Someone in this mode will sacrifice their own agenda for someone elses.
As with StrengthsFinder, simply knowing where you fall on this spectrum might be of tremendous value. In my case, there was no surprise when I fell in the 97th percentile in competing (something I’m sure anyone who has spent much time with me would agree with). However, what was of great value for me was the rest of the information in the report. It outlined cases where each of the 5 categories is useful and some questions to ask about the style.
The information in the report is really supplemented by the book, Introduction to Conflict and Teams, which I highly recommend getting if you think about taking the TKI or using it for a team. It has a wealth of information about each style. There are clear sections outlining how someone in a particular style views other styles and how they are viewed in return. Also key points for dealing constructively with other styles are provided.
While my being far into the competing spectrum wasn’t a surprise, how helpful the tips for dealing with others styles really was. While it might not be obvious where someone else falls (unless you have taken it as a group and shared the results which I think is the most impactful thing to do) you can certainly guess at which might be most applicable. Now that I have a framework for both conceptualizing this and some guidelines in how best to interact, I’ve found myself to be a much better team member and much happier in my interactions with others.
Since I already wrote about stakeholder management I thought I should write a follow up post on a related topic. While identifying stakeholders is crucial, that’s really only the first step. How you engage with those stakeholders at the beginning, and throughout the project will be crucial for your projects success. It’s easy to overlook the communication plan, especially for smaller projects with tight teams, but taking a moment to create one will be worth it. It will make work easier down the line and it will aid in catching up new team members.
Much like the stakeholder registry, I suggest using a spreadsheet for tracking your communication plan. There are seven key pieces of information you will want to include in the plan. If done shortly after the stakeholder analysis, your plan will be easy to complete.
- Audience: Who is this message for? You will want to be sure to include as individuals (or as a part of a group) all of the key stakeholders you identified. It is also worth considering other groups or how groups might overlap and adding rows for them. Examples might include: Dean of Library, Department Heads, Project Team, and External Stakeholders. Be sure to also consider what your organization wide communications, such as the library or university, will look like. These might be the only messages about your project some people get or read.
- Vehicle: What are the communication methods being used? Email and meetings are the most common ways but think about others, especially informal ones. A brown bag lunch event might be a great way to generate staff interest in a project. Also consider any reports or status updates you might be giving.
- Frequency: How often will the communication occur? Team meetings and status reports will be regularly scheduled for a reason, so do the same for things like all staff status updates to keep yourself on task.
- Medium: Closely tied to vehicle, what form will the communication take? Is it verbal (as in a meeting) or a hard copy that is distributed to everyone?
- Source: Who is providing the information? We often end up with several sources of information about a project so tracking which should be included in what forms is important.
- Sender: Who is delivering the message? This usually ends up being the project manager but try to include others, especially with different communication styles, to get the message out.
- Sensitivities: Does this audience have any particular sensitivities? This might be topics or parts of the project they either care about or don’t want to hear at all. This is a great place to also capture notes about communication style. There are people that like a simple email and others that like a quick phone call. Using the non-prefered method can create stress and often end up with needless back and forth.
- Dates: When will the communication take place? This is straight forward but also consider here any recurring communication needs. This is also an excellent place to track that communications have gone out when they needed to.
- Goals: What is this communication seeking to accomplish? All too often we communicate for the sake of doing so. Make sure you have a clear goal for why you are doing this and it will help to evaluate if your communication plan is working properly.
Once you’ve completed this for the relevant stakeholders and methods of communication, you are really all set. Remember to review and update the communication plan as needed. Also be sure to review those goals you set. If needs are being met you are in good shape. Otherwise some adjustment might be needed. Like any part of a project, it is important to be intentionally iterative in how you approach communication. Somethings will work, some will need to be changed, and others will fail totally. But if you are carefully tracking them, you can be sure your project won’t fail as well.
Steve Thomas was kind enough to have me on his excellent podcast, Circulating Ideas, to talk about project management. You can listen to the episode here. Steve also currently has a kickstarter running to create transcripts of all the wonderful interviews he has done over years. There are a wealth of interviews with librarians from a vast array of backgrounds covering all sorts of topics. It’s really a wonderful resource for librarians and having them in transcript and ebook form would be a great. If you can, consider supporting his efforts here.
Having made a go at running a podcast gave me first hand experience on how difficult and time consuming it can be. This is probably why Mindy and I only hit about 8 episodes over the course of a year (if you are curious, I recently moved everything here). I have the utmost respect for Steve and what he’s been able to accomplish with Circulating Ideas. So please, even if it’s only a couple dollars, go and support his podcast.
Stakeholder management is important for librarians, especially given the current budget concerns and focus on outreach. In the library literature, I don’t see much on the subject beyond the idea that stakeholder management is important. So how to go about it ends up being a lot of guess work. Luckily this is a very established part of project management and there are some great tips and tricks out there for doing so.
The first step of stakeholder management is the identification of stakeholders. This can be trickier than you’d think. At its most basic, a stakeholder is any person who could impact or be impacted by your project. Unfortunately, that doesn’t help much as it can easily become a situation where everyone is stakeholder. The easiest way to narrow this down (which will also be useful later) is to think in degrees of impact. You might not be able to catch everyone but if you start with the most impactful and work your way down you will get a good initial list. As a first step, I create a new spreadsheet and just start listing names. When I start to struggle to come up with the next name (you can also think in terms of groups) I stop and review the list. This usually generates a few additions to round out the list. Next I find someone else who understands the project and what it is seeking to accomplish to review. If you can find multiple people, all the better. The more points of view you can apply to the list the better it will be.
For smaller projects or ones with a small stakeholder base, the list itself could be sufficient for knowing who is invloved. Normally, you need to add some additional information to round out the list and help group stakeholders together. There are many ways you can do this but I’ll present the most common two: Red/Green/Yellow and Power/Interest.
The Red/Green/Yellow method is a great starting point if you’ve never tackled this kind of thing before. It’s very straight forward and easy to get started. Simply review your list of stakeholders and assign each one a value, either Red, Green, or Yellow. Green means the person is a supporter of your project and could be counted upon to lend resources, support, or influence on behalf of your project. Simply put, these are your go to people. Red means the person does not support your project and might actually be working against it. These are the people you need to win over and will have to spend much more time trying to influence. Yellow means the person is either on the fence about the project or you are not yet able to determine where they stand. The main goal in dealing with these people will be to figure out how to move them to Green or to ensure they don’t become Red. Once you’ve made it through your list, you should now have a clear idea of your supporters and detractors are.
The Power/Interest method comes at this from a different perspective. Each stakeholder is assigned a Power (the amount of influence they have in organization and on the project) and Interest (how involved or how much attention they will pay to the project) value ranging from low to high. You can then create a grid with Power and Interest as the axis and plot the stakeholders accordingly. Splitting each in half you should end up with four quadrants. The conventional wisdom on handling the groups is as follows:
- High Power/High Interest: Manage them closely. These will be your key stakeholders. They hold the power to influence your project and it is certainly on their radar. If you can turn them into supporters they will make powerful allies.
- High Power/Low Interest: Keep them satisfied. These stakeholders have the potential to really support or sink your project but it is just not on their radar. Figure out how best to keep them satisfied. Often this can be as simple as figuring out the preferred communication method and level of detail to keep them informed.
- Low Power/Low Interest: Monitor this group. You can’t be all things to all people and if there is a group to ignore (or pay less attention to) it’s this one. They aren’t concerned about your project and even if they were there isn’t much they can do about it. The main thing here is to make sure that situation doesn’t change.
- Low Power/High Interest: Keep this group informed. They might not be able to make a massive impact but it’s good to know those people that are highly engaged in your project. There might come a time where you need support and this is a great group to get it from.
Whichever method you choose, you should end up with a list of your stakeholders and a way of grouping them together. This can then inform your communication plan (which I’ll talk about later) as well as the management of your project has a whole. You can successfully complete a project without doing a stakeholder analysis but you open yourself up to many potential pitfalls by not.