Tag Archives: How to

How to use tagging to make connections in the nonprofit web

A tag cloud with terms related to Web 2.

Image via Wikipedia

Probably one of the best innovations of the whole Web 2.0 phenomenon is tagging. A tag is “a non-hierarchical keyword or term assigned to a piece of information” (source). Tags can be used to identify blog posts, bookmarks, photos, videos, presentations, events, etc., and are supported by pretty much every Web 2.0 tool. Tags are generally assigned informally and without regard to a structure of categories; they are more like annotations and are often assigned in addition to categories, such as on blog posts.

The genius of tagging is that it organically builds connections over time between seemingly unconnected content. If my blog post and your video and his bookmark and her photograph all have the same tag, then we can start to see how they are related in some way. This leads to a bottoms-up classification system for web content that is often called a folksonomy.

The problem is that tags are arbitrarily decided on by the content creator, and with language being what it is, one tag can mean many different things to many different people. Take the word development, for instance. In my own little industry, it can refer to the process of creating software or giving aid to low-resource countries. In other contexts, it might refer to child development or personal development or a large and ugly subdivision.

The nonprofit field has bypassed this limitation by coming up with some unique tags to identify our content. If we use these tags consistently, we can easily locate a wealth of content in our particular niches. Here are some of the most useful tags I’ve come across:

nptech: Short for “nonprofit technology,” this tag refers to nonprofits’ use of technology, mostly internally rather than as part of the program offerings.

Examples:

ict4d: Stands for “Information and Communication Technologies for Development.” Refers to groups that are using technology in their development programs, usually international development.

Examples:

web4dev: Using Web technologies, mostly Web 2.0, for supporting international aid and development.

Examples:

km4dev: Stands for “Knowledge Management for Development.” Using knowledge management tools and techniques to support international development.

Examples:

m4dev or m4d: Using mobile technology to support internatonal development.

Examples:

I’m sure I haven’t discovered all of the tags being used by nonprofits using technology, especially in international development. If you know of any other good ones, please leave a comment.

Reblog this post [with Zemanta]

How to create a master GTD project list

Over the past few months, I have been experimenting with David Allen‘s Getting Things Done system to help me manage my work and personal projects. I have to admit, I have streamlined the system quite a bit. If followed exactly, GTD is too labor-intensive and (gasp!) too detail-oriented to suit me. But on the whole, the system has helped me keep on top of my to-do (Next Actions) list and helped me focus, especially at work. (It hasn’t been quite so successful at home, but that’s the subject of another post.)

One aspect of the system that I do like a lot is keeping a master list of projects. The projects list helps me keep focused on what I have committed to work on and keeps me from inadvertantly spreading myself too thin. It’s also proved helpful when I need to report on what I’m doing to my boss or colleagues, write up a workplan for future work or re-evaluate my workload and priorities.

I use SharePoint‘s lists feature for my projects list, but a spreadsheet would also work. It helps to have an electronic version for sorting and filtering and to make updating easier. I wouldn’t call my list format ground-breaking, but one purpose of this blog is to record my systems so I won’t forget them and can build on them. So if you’re bored by this minutiae, move on now.

Here’s what I put on my Projects List for each project:

  • Name: I try to use the same name consistently whenever I refer to the project to simplify searching for related project items.
  • Link: The majority of my projects have an electronic knowledge base, usually on SharePoint but possibly using Web-based project management tools. I prefer electronic storage of files over paper for many, many reasons. It’s handy to have a link right to the knowledge base in the Project List so I don’t have to remember it.
  • Area of Focus: I try to link every project to one of my areas of focus. This helps me recognize work projects that truly fall under my umbrella and keeps me from agreeing to everything I’m asked to do, especially if it falls outside of my primary interests and job responsibilities.
  • Notes about the project that I need to reference immediately.
  • Status: I don’t like to delete projects off my list, so I use a “status” field to sort and filter them instead. I’ve also often found that when a project is technically completed, I still have to do tasks from time to time to maintain that project, so I created an “in maintenance” status (which Allen doesn’t really address). For status, I can select
    • Active — a project for which I am actively working on tasks and have a project plan or tasks list to complete
    • Someday/Maybe, so my Someday/Maybes can easily be converted to Active projects if and when appropriate
    • Completed
    • Abandoned/Reassigned, to distinguish these from completed (and I never know when a reassigned project might come back to me)
    • In Maintenance, for projects where I am not actively working on tasks but may occasionally have a triggered action or a requested action from a co-worker
Reblog this post [with Zemanta]

How to structure a growing IT department?

This is an issue I’ve been struggling with for over a year now: how do we structure an IT department that is growing rapidly and taking on more and more responsibilities?

Over the past five years, I have watched the nonprofit where I work go from a department in a large state university to an independent 501c3 struggling to stay afloat (and furloughing/laying off people to do so) to a multi-project, multimillion dollar organization. In that time, I’ve seen our IT department go from 1 person (during the darkest part of the furlough) to 15 people today plus several consultants.

Over the years, our IT department has become responsible for just about anything that can be called technology and touches our company. Like a traditional IT department, we take care of the network, telephones, desktops and laptops, printers, email, internal systems and web servers for an organization with offices on five continents, some of them in very low-resource settings. We provide cell phones and digital cameras, burn large CD runs, and manage video-conferencing systems. We give trainings in how to use SharePoint and Office.

Beyond that, we work with other departments to help them design and develop Web sites, digital libraries and databases to meet a wide variety of needs. Our internal systems development team designs and programs foundational systems such as a contracts database, a program development database and a consultants database, all of which must integrate with one another and our other internal systems, such as Active Directory.

Finally, we have a strong program in developing Open Source human resource information systems for external customers such as Ministries of Health, in which we not only develop and distribute the software but also strengthen infrastructure, train data entry people and system administrators, lead workshops in how to use data more effectively and a whole lot more. And we’re looking to expand that program into other areas such as health information systems and telecommunications.

Now does 15 people seem like too many for an IT department that does all these things?

What I struggle with is, having “grown up” in this world, my job has grown without really shedding much of anything. Yes, I have people working under me now, but the responsibilities for developing all of our internal systems plus program requests such as the odd website, digital library or database plusmanaging our Open Source software development program all fall on my shoulders. Whenever there’s a failure — an employee flakes out, a deadline is missed, a senior executive is unhappy — it comes back to me.

For a while now, I have been saying, “Enough!” but possibly not loud enough. In return, I hear: “It is too much for one person. We are going to get you help. Just hang in there a little longer.” But nothing seems to work out, and it feels like I am back in the same position, or one that has worsened. When an employee flames out or a consultant disappears, I am the one who has to make everything right again. Even when I do consciously try to rid myself of responsibilities — I have completely given up having much at all to do with SharePoint, for instance — more rush in to fill their place. And there is no one else to do it.

I know where my heart is: Open Source development. I’m having fun, we’re doing some exciting things that we’re going to open up to the Open Source community within weeks, and it has real potential to impact the very people I came to this nonprofit to help. Developing internal systems is important, I agree, but Microsoft technologies don’t interest me at all. And I feel a bit schizophrenic trying to do both at the same time. Plus I feel like I never get to spend enough time on anything to do the job really well.

Here is my dilemma. Do I rigidly enforce my boundaries and let projects languish until we can hire the people to take responsibility for them? Or do I keep up the juggling act? How can I transition internal systems development off my plate altogether? Do we give it to the overloaded guy who’s also managing the helpdesk staff, the systems and network administrators, and all of our global infrastructure? That just doesn’t seem like a solution. Or do we hire someone and hope against hope that they can take the job, make it theirs and meet the demand without much hand-holding or training?

I just don’t know. Ideas are welcome

Reblog this post [with Zemanta]

How to plan a project more effectively

IMG_4568Image by .nele via Flickr

I have been reading David Allen’s Getting Things Done (late on the bandwagon, as usual), and his chapter on project planning really resonated with me. My job is pretty much planning and managing projects. Officially, I manage software development projects, but I find myself managing all kinds of projects for the organization, some related to my role in IT, some not. So I am constantly on the lookout for a more effective way of planning projects, which often seem to get frustratingly stuck before we really get started doing things.

David Allen’s description of a natural project planning process makes perfect sense to me. The reason we get stuck is that we’re trying to do something unnatural. Usually we start with trying to figure out what to do rather than why we are doing it. Or we get caught in the trap of defining the problem with no ideas for how to solve it. And Allen is definitely right when he points out that when you don’t follow the natural planning process, eventually you fall into reactive mode, where you go through the process anyway but in reaction to a failing project.

The following is my summary of Allen’s natural planning process, with a couple of additions based on my own experience and learning in planning projects for an arguably dysfunctional nonprofit for the last four years.

First, what is a project anyway? A project is any desired result that requires more than one action to complete. A project could be development of a system or website, planning a meeting or conference, deciding on a new type of laptop or installing a software upgrade.

Project planning can effectively be done in one, two or three meetings, as long as the meetings follow the natural planning process in the order outlined below. This should result in all the output needed to produce a vision statement, project plan and outlines for other necessary documentation, such as business rules and use cases.

The seven stages of a natural planning process are:

  1. Define the purpose of the project.
  2. Why are we doing this project? What are our intentions? What problem are we trying to solve? What untapped opportunity are we capitalizing on? Be as specific as possible. The purpose will provide the focus for the project and also help guide you through the actions to complete the project successfully.

  3. Set the givens of the project.
  4. What are the constraints, such as time, budget, resource, technology, geography or legal constraints? What policies — internal or external — do we have to adhere to? What standards do we have to uphold for successful completion of the project? What expectations do we have of people working on the project? What other boundaries can we identify?

  5. Craft a vision of a successful outcome for the project.
  6. What will the project be like when it successfully appears in the world? How will we determine success? What will have changed when this project is completed? The vision should include clear, specific outcomes by which to measure success.

  7. Determine the stakeholders of the project.
  8. Who is affected by the project? Identify everyone who has an interest in the project, including all members of the project team. What are their goals that they want to achieve with this project? Are all stakeholders represented (if not, perhaps call another meeting)?

  9. Brainstorm tasks and requirements for completing the project.
  10. How will we accomplish the vision? This is a time to get all ideas out of people’s heads and captured. Do not critique or organize ideas at this point. Document every single idea. The goal is to figure out all the things that won’t work as well as all the things that will.

  11. Organize all output generated into a project plan.
  12. First identify the significant pieces generated during the brainstorming session and weed out anything that is not feasible. Then sort by one or more criteria: components, sequences and/or priorities, for example. Detail each to the required degree. This may be done during the planning meeting or by the project manager for presentation later.

  13. Identify next actions.
  14. Next actions are any specific, discrete tasks that can be accomplished now to move the project forward. There may be several next actions that can be done in parallel, or there may be only one upon which all subsequent tasks are dependent. Next actions may include additional planning sessions. Each action should be assigned to an owner with a timeline for completion, or an owner can be given responsibility for a component of the project and then determine the next actions for themselves.

    When one action is completed, the next action should be identified and assigned, if necessary. Assignment or review of next actions should be done at the end of each project team meeting.

Not all of these stages need to be conducted in a formal planning meeting or documented; that depends on the project. More formal or complex projects require the project planning team to complete and document each of these phases.

If a project is stuck, revisit these phases to determine where the blockage is occurring. For example, if you can’t determine next actions, you probably need to go back to a previous phase and make sure it is specific and complete. If you don’t have a vision of how the project will be successful, it is very difficult to determine what needs to be done to move the project forward.

Reblog this post [with Zemanta]