Tag Archives: project management

How I Spent My 2015 Technology Initiative Grants Conference

I’m back from our (Legal Services Corporation) 15th annual technology conference, which ran from January 14th through the 16th  in San Antonio, Texas.  It was a good one this year, with a great location, good food, great people – nearly 300 of them, which is quite a record for us. There were plenty of amazing sessions, kicked off by a fascinating keynote on international access to justice web app partnerships. Slides and videos will be up soon on LSC’s website. But I did want to share the slides from my sessions, which all seemed to go very well.  I did three:

Are You Agile

I kicked off the first morning doing a session on agile project management with Gwen Daniels of Illinois Legal Aid Online. My slides provided a basic overview of project management concepts, then Gwen did a live demo of how ILAO uses Jira and a SCRUM methodology to develop websites and applications. Having studied agile more than actually practicing it, I learned a lot from her.  The combined slides will be up on LSC’s site. I pulled my intro from this broader presentation that I did at the Nonprofit Technology Conference in 2013:

Shop Smart: How A Formal Procurement Process Can Safeguard Your Investments

On Thursday, I summarized everything I know about software and vendor selection, writing proposals, and negotiating contracts into this dense presentation on how to purchase major software systems.

Security Basics

And on Friday, usual suspect Steve Heye and I led a session on security, factoring all of the things that we think orgs should know in an era of frequent, major breaches and distributed data.

I’ll hit some of these same themes in March at the Nonprofit Technology Conference, where I’ll be speaking on contract negotiations (cloud and otherwise) and information policies (with Johan Hammerstrom of CommunityIT. See you there?

13 Lessons On Building Your Nonprofit Technology Culture

This article originally appeared on the Exponent Partners blog on December 19th, 2014. It was written by Kerry Vineburg, based on a phone interview with me.

EXPONENT PARTNERS SERIES: SMART PRACTICES

Is your nonprofit thinking about implementing a large database project like Salesforce? Nonprofit and technology veteran Peter Campbell, CIO at Legal Services Corporation, recently shared his valuable insights on how to prepare your team and culture for long-term success. His organization, the top funder of civil legal aid for low-income Americans in the country, is developing Salesforce as a data warehouse for their grantee information and document management. 

We asked Peter to tell us more about what practices he uses to help ensure a successful technology implementation. As you’ll see, it’s just as much about working with people! 

Embarking On Your Project

1. When beginning a technology project, agree on the problem you’re solving, that all staff can relate to. Organizational readiness is critical. I’ve worked at organizations that didn’t recognize that their casual approach to data management was a problem, and they weren’t looking for a solution. If your staff don’t understand why they need an application, then you’re in danger of installing something that won’t be utilized. When starting a new organizational project, I identify 2-3 core bullet points that will explain the goals of the project, and repeat them often. For example: “The new system will provide one-step access to all information and documents related to a grantee.” That’s the high-level goal. It should be something where the product users all agree, “Yes, I need that!”
2. When planning technology upgrades and projects, schedule the changes. Plan for gradual change. Early in my career, I had to deal with the Y2K bug and replace every system at a mid-sized law firm in a short period. It led me to this philosophy: replace only one major system each year. It’s a myth that people hate change — people hate disruption. Change is good, but needs to be managed at steady level. If you’re doing regular implementations every year, people can get used to that pace. If you do nothing for 3 years, then switch out everything: 1) you’re putting too much of a burden on your implementers to achieve everything at once and 2) you’re making too big of an imposition on staff. Suddenly, everything they know is gone and replaced.

Getting Buy-In

3. Gain full executive sponsorship. There’s a common misconception that a new system will just work for you once it’s installed. To fully realize the benefits of a CRM requires cultural change. Every level of the organization needs to buy into the project. You’ll need to harness a lot of attention and energy from your team to develop requirements, manage the project, learn the new system and adapt processes. Otherwise, you’ll invest in a big database implementation and only one or two people will use it.
The importance of a major system upgrade should be set by the executive director and/or board. Everyone should know that the system is a priority. At nonprofits, our executive directors are often better at fundraising than managing a business, and many are somewhat technophobic. They don’t need to be technology gurus, but they do need to understand what the technology should be doing for them, and to take ownership of those goals. The last thing that I want to hear from my boss is, “Here’s a budget — go do what you think is best.” Without their interest in my projects, I’m bound to fail.
4. If one buy-in approach needs help, try a combo. If you can’t convince your executive director or other leadership to be regular active participants, power users can sometimes help convince your team. I’m not recommending an either/or approach, there should be some of both, but power users can engage staff in cases where management isn’t setting clear expectations. For any project that impacts staff, I will invite key users to be on our evaluation team, help with product selection, and potentially be on our advisory committee during the project. For example, we have a grants department liaison, who is charged with getting the right people in the room when we need input from the staff that know much better than we do what the system should ultimately do for them.
5. Incorporate perspectives from around the table. In addition to power users, I also want feedback from “standard” users. Maybe they don’t love technology so much, and maybe they wouldn’t volunteer for this. But they have an important perspective: you need to understand their reactions and what they’re going to find difficult. As the IT director and CIO, I know important things about managing a project. The users know important things that I don’t. If we don’t have views from multiple sides of the table, the project will fail.

Working With Good People

6. Look for partners (vendors and consultants) who understand your mission, not just the technology. In the ideal situation, you want people who not only get database and programming work, but also really understand your mission and business priorities. I’m blessed to have developers on my team who not only understand grants management but are also sympathetic to what the people coming to them are trying to accomplish. When they get a request, they can prioritize with a good understanding of our organization’s requirements. They’re able to answer, “How can I make the most out of what this person needs with my available time?” while being skilled enough to capably choose between the technical options. Getting people that have a broader mindset than just technology is really important.
7. Vary your team and role strategy with your size. At nonprofits, we don’t usually have big internal teams. Someone becomes our accidental techie/database guru. Even large nonprofits are hurting for staff. It’s always been less “here’s the best practice and ideal way to staff this,” and more “let’s see what budget and people I have, and make it work as well as I can.” Not many nonprofits have developers on staff. Hiring can be challenging. It’s a popular skillset, and won’t be cheap. If you’re tiny, you probably won’t hire full-time, you’ll outsource to consultants. But if you have 30 people or more using the CRM, you might benefit from in-house expertise, even if it’s a half-time role.
If you already have developers on staff, that’s great. If they don’t have experience with, say, Salesforce, but they do know database design and a programming language or two, it’s not hard to pick up the concepts. You’re modeling a database, designing it, and then scripting on top of it in a similar language. They can probably adapt.
8. Practice good compensation and retention strategies for your technically savvy (and/or newly trained) staff. I’ve seen a trend over the past 10 years. A nonprofit decides to use a solution like Salesforce and they charge their accidental techie with the task of implementing. The accidental techie gets the implementation done, becomes a guru on it, trains all the users, and then because the organization is paying them an entry-level salary, they leave and go get a much higher paying job as a consultant! It’s a valuable skillset, so don’t be short-sighted about compensating them for what they do for you. You need to be careful and invest properly. Give them raises along with the skillset, to make sure they are fully motivated to stick with you.

Project Management

9. Avoid surprises with good communication. My rule of IT management now is: “No one should ever be surprised by anything I do.” From experience with good mentors, I learned important lessons about communication: if you’re going to make a change, communication is critical. Say it 3 times in 3 different mediums (in email, on the internet, on flyers on the wall on every floor!). Be sure staff know how the technology contributes to the well-being of the organization, rather than being a time-waster, so they are motivated to keep working with it. Communicate well.
10. If possible, hold out for the right team. I put off projects to have the right people in place, rather than hold tight to a project deadline with the wrong people in place. See above for how to find and keep the right people.

Training and Baking The Technology Into Your Culture

11. Don’t reinvent the wheel; take advantage of the ecosystem. It can be really common for staff not to reach out for help. They may feel like their job is to learn the technology on their own. They should know there are many resources available to them! For example, with Salesforce, I recommend making use of peer support in the community, the Power of Us Hub, and local user groups. When they do seasonal updates, they do a lot of webinars and are good about providing information about how the app is growing. Salesforce also offers training (the Salesforce Foundation discounts by half) and every consultant I’ve spoken with is capable of doing some customized training. I know that other technologies offer resources like this also. It also behooves anybody on staff to know the specific implementation that you’ve done.
12. Allocate a training budget. I always push to have a staff training budget. For my organization, we even hired for a role of training and implementation specialist. We wanted to have a person on staff whose full-time job was training and strategizing how users use software and how to involve them in the implementation process. This should be part of your budget. I can’t emphasize enough how important it is to have people in your organization who know how to train on your applications.
13. Engage staff and help them understand the big picture of the technology. It’s good to get your team working with the database early on in the process, learning what it’s capable of and what it looks like. Engage your users: get people involved in every step of the process, from selecting products to implementation to training and rollout. Make the product demos big group activities, so that everyone can envision how similar systems work and what they might do with the product beyond what they’re doing today. Beta-test your implementations, giving staff lots of opportunities to provide input. Take an Agile approach of regularly showing what you’re developing to the people who will be using it, and adjusting your development per their feedback.
With a committed team that understands your mission, great communication, well-allocated resources, and gradual change, your organization can lay the foundations for a successful solution that will actually be adopted!
Thanks to Peter Campbell for these great insights. Peter also blogs at techcafeteria.com
For even more strategies on ensuring that your culture is ready for your system, check out our free report Nonprofit Technology Adoption: Why It Matters and How to Be Successful.

– See more at: http://www.exponentpartners.com/building-your-nonprofit-technology-culture#sthash.QPFll78h.dpuf

Debating Proper Project Management Discipline

I just had a fun, spirited debate on Twitter about the definition of a project. It started when a friend of mine tweeted this:

Now, my team at Legal Services Corporation recently finished a project (at least, that’s what I call it) to redesign the Find Legal Aid lookup on our website.  I blogged about that effort, which was kickstarted by the DC Legal Hackers, on LSC’s tech blog.  A few things about this:

  • There was no deadline.
  • It was something that we could have outsourced completely, but we wanted to learn the underlying technologies.
  • It was low priority, and my lead developer had a lot of more critical, time-sensitive  projects on his plate.

So we didn’t set a deadline. We pitched the project to management with clear goals (a charter).  After the initial development was done at the DC Legal Hacker’s first hackathon, we identified the four person team that would work on it internally. We reported on it weekly, during our project review.  And we rolled it out when it was finished.

On seeing Norman’s tweet, I challenged the notion that a deadline is a required element of a project. Mind you, many agile programmers work with the bias that iterating until it’s done correctly is more important than meeting a deadline. I doubt that they can actually sell that to their internal or paying clients often, of course.

So I threw my two cents in:

— Peter Campbell (@peterscampbell) April 24, 2014

which brought this reply from someone that I assume is, unlike me, a certified Project Manager, and therefore better versed and disciplined in the best practices:


So, here I am, coming off of a highly successful development and rollout of our little webapp, being told that it wasn’t a valid project.  The entire tweetstream is copied below, but here are the points that I want to make that go a bit beyond Twitter’s 140 requirement.

  • The Project Management Institute (PMI) awards Project Management Professional (PMP) certification to those who complete the requisite hours managing projects and pass the test. I’ve completed their requisite hours, and I’ve taken most of the test prep classes, but I’ve never gotten around to taking the test. So I agree with Rebel that their definition of a project requires a deadline. But I don’t agree with their definition.
  • As with many certifications, what you have to say to pass the test is not always what is going to work in the real world. My first career was working as a cook/sous chef, which I did through most of my very late teens and twenties.  As with technology, I was mostly self-taught. I’ll never forget one day, when working in a French restaurant in Cambridge, Mass., a fresh graduate of the Culinary Institute of America came on board. He didn’t last his first night on the job.  This guy could make some wonderful, complex recipes, but he was overwhelmed when he hit 15 to 20 orders on the wheel. I get the PMI reasoning, but I’ve adapted it over the years in my nonprofit environments where we don’t have the staff or budget to do things to the letter.
  • I absolutely value the governance of a project management discipline.  I firmly believe that you need to recognize targets and milestones if you want to push forward. My tolerance for “no deadline” is in rare cases like the one above. In particular, I need to have work schedules so that large projects don’t end up piling on top of each other.
  • But the trick to successfully getting a lot of things done well in what we call “a constrained resource environment” (e.g. any nonprofit and most of everything else) is to not let the governance get in the way of getting things done. So I take or leave parts of it, being more formal when there’s more at stake and absolutely informal when it doesn’t threaten our outcomes.

I might get that PMP certification someday, although, at this point, it might be when I retire.  But, with a few exceptions, I have a good track record of overseeing some great accomplishments in my career, and I expect that to continue until the day that I can retire.  And I’ll do it by applying appropriate standards and bucking them when they get in the way of the end goal.

Here’s the tweetstream:

 

Trello: A Swiss Army Knife For Tasks, Prioritizing And Project Planning

This post was originally published on the LSC Technology Blog in May of 2013. Note that “LSC” is Legal services Corporation, my current employer.

One of the great services available to the legal aid tech community (lstech) is LSNTAP’s series of webinars on tech tools.  I’ve somehow managed to miss every one of these webinars, but I’m a big fan of sharing the tools and strategies that allow us to more effectively get things done. In that spirit, I wanted to talk about my new favorite free online tool, Trello.

Trello is an online Kanban board.  If you’re unfamiliar with that term, you are still likely familiar with the concept: most TV cop shows have a board in the squad room with columns for new, open and closed cases.  Kanban is the name for these To Do/Doing/Done boards, and they are a powerful, visual tool for keeping track of projects.

You don’t need Trello — you can do it with a whiteboard and a marker.  But Trello’s online version can become very useful very fast.  Like the best apps, the basic functionality is readily usable, but  advanced functionality lurks under the hood.  With no training, you can create a todo list that monitors what’s coming up, what you’re working on and what you’ve finished.  Explore a little bit, and you learn that each task can have a description, a due date, a file attached to it, it’s own task list and one or more people assigned to it. Because Trello is just as good as a one-person productivity tool as it is as a team coordination tool.

I can report that the IT team at LSC has dived into it.  Here are a few of the things we’re using it for:

  • Our project big board.  We keep all of our upcoming projects, with due dates and leads, in a Trello board.
  • Individual task lists.  The developers track their major deliverable dates, the rest of us the small things we’re working on.
  • Strategic Planning – anyone who has ever done a session involving slapping post-its on the wall will appreciate this simple, online version of that exercise.  SWOT analyses work particularly well.

At this year’s Nonprofit Technology Conference, where I first learned about Trello, it was successfully being used as a help desk ticket system.  I’d recommend this only for small programs.  A more powerful free ticket system like Spiceworks, or a commercial product will be able to handle the volume at a 50 person + company better than Trello can.

But here’s the real case for a tool like Trello: it goes from zero to compellingly useful in seconds.  While I won’t knock enterprise project management systems, I lean toward the ones that give me great functionality without taking up a lot of my time.  I’ve hit a couple of stages in my career where the immense workload begged for a such tools, but implementing one was too big a project to add to the list.  I bet that you’ve been there, too. Trello lacks the sophistication of a waterfall system like MS Project or an agile one, such as Jira. But it can get you organized in minutes.  And, in our case, it doesn’t replace those more sophisticated systems. It supplements them at the high level.  We do both traditional projects (deploy servers, install phone systems) and agile ones (build web sites, program our grants management system).  We can use the proper tools for those project plans, but keep the team coordinated with Trello.

Here’s our 2013 project board:

 

Note that we only assign the project leads, and the main use of this board is in the project review that kicks off our weekly staff meetings. But it’s helping us stay on task, and that is always the challenge.

What are your favorite tools for team coordination and project management?  Let us know in the comments.

The Five Best Tools For Quick And Effective Project Management

This article was first published on the NTEN Blog in March of 2011.

The keys to managing a successful project are buy-in and communication. Projects fail when all participants are on different pages. You want to use tools that your project participants can access easily, preferably ones they’re already using.

As an IT Director, co-workers, peers, and consultants frequently ask me, “Do you use Microsoft Project?” The answer to that question is a resounding denial.

Then I elaborate with my true opinion of Project: it’s a great tool if you’re building a bridge or a luxury hotel. But my Project rule of thumb is, if the budget doesn’t justify a full-time employee to manage the Project plan (e.g., keep the plan updated, not manage the project, necessarily), then MS Project is overkill. Real world projects require far more agile and accessible tools.

The keys to managing a successful project are buy-in and communication. The people who run the organization need to support it and the people the project is being planned for need to be expecting and anticipating the end result. Projects fail when all participants are on different pages: vague or different ideas of what the goals are; different levels of commitment; poor understanding of the deadlines; and poorly set expectations. GANTT charts are great marketing tools — senior executives never fail to be impressed by them — but they don’t tell the Facilities Coordinator in clear language that you need the facility booked by March 10th, or the designer that the web page has to be up by April 2nd.

You want to use tools that your project participants can access easily, preferably ones they’re already using. Here are five tools that are either free or you’ve already obtained, which, used together, will be far more effective than MS Project for the typical project at a small to mid-sized organization:

  • GanttProject. GanttProject is an open source, cross-platform project management tool. Think of it as MS Project lite. While the feature set includes identifying project resources, allocating time, and tracking completion, etc., it excels at creating GANTT charts, which can then be used to promote and communicate about the project. People appreciate visual aids, and GANTT charts visually identify the key tasks, milestones and timeframes. I don’t recommend diving into the resource allocations and the like, as I think that’s the point where managing the project plan starts becoming more work than managing the project.
  • Your email app. It’s all about communication: setting expectations, managing expectations, reminding and checking on key contributors so that deadlines are met. Everyone already lives in their email, so you want to visit them where they live. Related tool: the telephone.
  • MeetingWizard, Doodle, etc. We might gripe about meetings, but email alone does not cut it. If you want people to understand what you’re trying to accomplish — and care –they need to see your face and here the inflections in your voice when you tell them about it. By the same token, status updates and working out schedules where one person’s work depends on others completing theirs benefit greatly from face-to-face planning.
  • Excel (or any spreadsheet). Budgets, check off lists, inventory — a spreadsheet is a great tool for storing the project data. Worthy alternatives (and superior, because they’re multi-user): Sharepoint or Open Atrium.
  • Socialcast (or Yammer). Socialcast is Facebook for organizations. Share status, links, and files in a microblogging client. You can create categories and assign posts to them. The reasoning is the same as for the email, and email might be your fallback if your co-workers won’t take to microblogging, but if they’re open to it, it’s a great way to keep a group of people easily informed.

It’s not that there aren’t other good ways to manage projects. Basecamp, or one of the many similar web apps might be a better fit, particularly if the project team is widely dispersed geographically. Sharepoint can replace a number of the tools listed here. But you don’t really have to spend a penny. You do need to plan, promote, and communicate.

Projects don’t fail because you’re not using capital “P” Project. They fail when there isn’t buy-in, shared understanding, and lots of interaction.

Peter Campbell is currently the Director of Information Technology at Earthjustice, a non-profit law firm dedicated to defending the earth. Prior to joining Earthjustice, Peter spent seven years serving as IT Director at Goodwill Industries of San Francisco, San Mateo & Marin Counties, Inc. Peter has been managing technology for non-profits and law firms for over 20 years, and has a broad knowledge of systems, email and the web. In 2003, he won a “Top Technology Innovator” award from InfoWorld for developing a retail reporting system for Goodwill thrift. Peter’s focus is on advancing communication, collaboration and efficiency through creative use of the web and other technology platforms.

The Cults That Get Things Done

This post was originally published on the Idealware Blog in December of 2009.

Here at Idealware, an organization that’s all about nonprofit-focused software, we understand that the success or failure of a software project often has far more to do with the implementation than the application. So, in addition to discussing software, we talk a lot about project management. To many of us, it seems like the only thing worse than devoting our scant resources to the task of building and maintaining a complex project plan is living with the result of a project that wasn’t planned. While I’m a big a fan as the next guy of PMP-certified, MS Project Ninja masters, and will argue that you need one if your project is to build a new campus or a bridge, I think there are alternate methodologies that can cover us as we roll out our CRMs and web sites, even though I know that these projects that will fail expensively without proper oversight.

The traditional project planning method starts with a Project Manager, who plays a role that fluctuates between implementation guru, data entry clerk and your nagging Mom when you’re late for school.  The PM, as we’ll call her or him, gathers all of the projected dates, people, budget, and materials, then builds the house of cards that we call the plan.  The plan will detail how the HR Director will spend 15% of her time on a series of scheduled tasks that, if they slip, will impact the Marketing Coordinator and the Database Manager’s tasks and timelines.  So the PM has to be able to quickly, intelligently, rewrite the plan when the HR Director is pulled away for a personnel matter, skewering those assumptions.

My take is that this methodology doesn’t work in environments like ours, where reduced overhead, high turnover and unanticipated priorities are the norm.  We need a less granular methodology; one that will bend easily with our flexible work conditions.  Mind you, when you give up the detailed plan, you give up the certainty that every “i” will be dotted, every “t” crossed, and every outcome accomplished on schedule.  But it’s possible to still keep sight of the important things while sacrificing some of the structural integrity.

First, keep what is critical: clear goals, communication, engagement and feedback.  The biggest risk in any project no matter how well planned, is that you’ll end up with something that has little relation to what you were trying to get.  You need clearly understood goals, shared by all internal and external parties. Each step taken must factor in those goals and be made in light of them.  All parties who have a stake in the project should have a role and a voice in the plan, from the CEO to the data entry clerk.  And everyone’s opinion matters.

Read up on agile project management, a collaborative approach that is more focused on the outcomes than  the steps and timeline to get there.  Offload the project management by focusing on expectation management.  The clearer the participants are about their roles and accountability for their contributions, the less they need to be managed.  Take a look at the Cult of Done (their manifesto is at the top of this article).  Sound insane? Maybe.  More insane than spending thousands of dollars and hours on an over-planned project that never yields results? For some perspective, read The Mythical Man Month (or, at least, this Wikipedia article on it), a book that clearly illustrates how the best laid plans can go horribly wrong.

Finally, my advocacy for less stringent forms of project management should not be read as permission to do it haphazardly.  Engagement in and attention to the project can’t be minimized.  I’m suggesting that we can take a more creative, less traditional approach in environments where the traditional approach might be a bad fit, and for projects that don’t require it.  There are a lot of judgment calls involved, and the real challenge, as always, is keeping your eye on the goals and the team accountable for delivering them.

Evaluating Wikis

This post originally appeared on the Idealware Blog in August of 2009.

I’m following up on my post suggesting that Wikis should be grabbing a portion of the market from word processors. Wikis are convenient collaborative editing platforms that remove a lot of the legacy awkwardness that traditional editing software brings to writing for the web.  Gone are useless print formatting functions like pagination and margins; huge file sizes; and the need to email around multiple versions of the same document.

There are a lot of use cases for Wikis:

  • We can all thank Wikipedia for bringing the excellent crowd-sourced knowledgebase functionality to broad attention.  Closer to home we can see great use of this at the We Are Media Wiki, where NTEN and friends share best practices around social media and nonprofits.
  • Collaborative authoring is another natural use, illustrated beautifully by the Floss Manuals project.
  • Project Management and Development are regularly handled by Wikis, such as the Fedora Project
  • Wikis make great directories for other media, such as Project Gutenburg‘s catalogue of free E-Books.
  • A growing trend is use of a Wiki as a company Intranet.

Almost any popular Wiki software will support the basic functionality of providing user-editable web pages with some formatting capability and a method (such as “CamelCase“) to signify text that should be a link.  But Wikis have been exploding with additional functionality that ramps up their suitability for all sorts of tasks:

  • The Floss Manuals team wrote extensions for the Open Source TWiki platform that track who is working on which section of a book and send out updates.
  • TWiki, along with Confluence, SocialText and other platforms, include (either natively or via an optional plugin) tabular data — spreadsheet like pages for tracking lists and numeric information. This can really beef up the value of a Wiki as an Intranet or Project Management application.
  • TWiki and others include built-in form generators, allowing you to better track information and interact with Wiki users.
  • And, of course, the more advanced Wikis are building in social networking features.  Most Wikis support RSS, allowing you to subscribe to page revisions. But newer platforms are adding status updates and Twitter-like functionality.
  • Before choosing a Wiki platform, ask yourself some key questions:
  • Do you need granular security? Advanced Wikis have full-blown user and group-based security and authentication features, much like a standard CMS.
  • Should the data be stored in a database? It might be useful or even critical for integration with other systems.
  • Does it belong on a local server, or in the cloud? There are plenty of great hosted Wikis, like PBWorks (formerly PBWiki) and WikiSpaces, in addition to all of the Wikis that you can download and install on your own Server.  There are even personal Wikis like TiddlyWiki and ZuluPad.  I use a Wiki on my Android phone called WikiNotes for my note-keeping.

Are you already using a Wiki?  You might be. Google Docs, with it’s revision history feature, may look more like a Word processor, but it’s a Wiki at heart.

From Zero to Sixty: What type of Project Management tool is appropriate?

Here’s another recent Idealware entry (from 9/25/2008). Note that the Idealware post has a healthy comment stream.

It seems like every month or two, I happen across a forum thread about project management tools. What works? Can you do it with a wiki? Are they necessary at all? Often, there are a slew of recommendations (Basecamp, Central Desktop, MS Project) accompanied by some heartfelt recommendations to stay away from all of them. All of these recommendations are correct, and incorrect.

Project software naysayers make a very apt point: Tools won’t plan a project for you. If you think that buying and setting up the tool is all that you need to do to successfully complete a complex project, you’re probably doomed to fail. So what are the things that will truly facilitate a project-oriented approach, regardless of tools?

  • Healthy Communication. The team on the project has to be comfortably and consistently engaged in project status and decisions
  • Accountability. Team members need to know what their roles are, what deliverables they’re accountable for and when, and deliver them.
  • Clarity, Oversight and Buy-In. Executives, Boards, Backers all have to be completely behind the project and the implementation team.

With that in place, Project Management tools can facilitate and streamline things, and the proper tools will be the ones that best address the complexity of the project, the make-up of the team, and the culture of the team and organization.

Traditional Project Management applications, exemplified by MS Project, tie your project schedule and resources together, applying resource percentages to timeline tasks. So, if your CEO is involved in promoting the plan and acting as a high level sponsor, then she will
be assigned, perhaps, as five percent of the project’s total resources, and her five percent will be sub-allocated to the tasks that she is assigned to. They track dependencies, and allow you to shift a whole schedule based on the delay of one piece of the plan. If task 37 is
“order widget” and that order is delayed, then all actions that depend on deployment of the widget can be rescheduled with a drag and drop action. This is all very powerful, but there is a significant cost to defiing the plan, initially inputting it, and then maintaining the information. There’s a simple rule of thumb to apply: If your project requires this level of tracking, then it requires a full-time Project Manager to track it. If your budget doesn’t support that, as is often the case, then you shouldn’t even try to use a tool this complex. It will only waste your time.

Without a dedicated Project Manager, the goal is to find tools that will enhance communication; keep team members aware of deadlines and milestones; report clearly on project status; and provide graphical and summary reporting to stakeholders. If your team is spread out geographically, or comprised of people both inside and outside of your organization, such as consultants and vendors, all the better if the tool is web-based. Centralized plan, calendar, and contacts are a given. Online forums can be useful if your culture supports it. Most people aren’t big on online discussions outside of email, so you shouldn’t put up a forum if it won’t be used by all members. The key is to provide a big schedule that drills down to task lists, and maintain a constant record of task status and potential impacts on the overall plan. Gantt Charts allow you to note key dependencies – actions that must be completed before other actions can begin — and provide a visual reporting tool that is clear and readable for your constituents, from the project sponsors to the public. Basecamp, Central Desktop, and a slue of web-based options provide these components.

If this is still overkill – the project isn’t that complex, or the team is too small and constricted to learn and manage the tools, then scale down even further. Make good use of the task list and calendar functions that your email system provides, and put up a wiki to facilitate project-related communication.

What makes this topic so popular is that there is no such thing as a one size fits all answer, and the quick answer (“Use Project”) can be deadly for all but the most complex projects. Understand your goals, understand your team, and choose tools that support them.

Lessons Learned: Effective Practices In IT Management

This article was first published on the NTEN Blog in May of 2007.

Peter Campbell, TechCafeteria.com

I’ve spent more than 20 years in the sometimes maddening, sometimes wonderful, world of IT management. Along the way I’ve worked under a variety of CEOs with very diverse styles, and I’ve developed, deployed and maintained ambitious technology platforms. In order to survive, I put together three basic tenets to live by.

1. Management is 360 degrees: managing your superiors and peers is a bigger challenge than managing your staff.

2. To say anything effectively in an organization, you have to say it at least three times in three different media.

3. Follow Fidonet’s basic social guideline, “Do not be excessively annoying and do not become excessively annoyed.”

At a high level:

  • Work for the mission. Even in for-profit environments, I’ve managed to the organizational goals, not the individual personalities. You will avoid more political damage and navigate your way around the politics far more easily if you do the same. Don’t be scared of board or boss, and don’t cave in easily. This doesn’t mean that you countermand direct orders, but it does mean that you speak up if they don’t make sense to you. If you are in a political environment where, at the top, personality and ego trump mission in setting organizational priorities, then get out.
  • Make your priorities well known. Don’t ever assume that people are reading your business plans and proposals, and know for a fact that they haven’t read your emails. The key to successful project planning is communication, and that means face to face discussions with all parties with a stake in the project, especially those that you don’t particularly mesh with. Avoiding people who factor in your ability to succeed is a sure way to fail.
  • Take every opportunity to educate. Successful deployment of technology depends on joint ownership between the technology users and purveyors. Staff won’t own the technology if they don’t know what it does for them. In order to successfully manage technology, you need to constantly inform all parties at to what it can do for them.

Some other handy practices:

  • Run the IT Department as a lab – give your staff ample voice, diverse projects, and credit when they succeed. IT people, particularly in non-profits, are far more motivated by learning and accomplishing things than they are by money.
  • Value people skills, especially among your staff. Ability and comfort to communicate can be a more valuable talent than the ability to configure a Cisco 1750 blindfolded.
  • Marketing is not a dirty word! Sell your initiatives with PowerPoint, Project, and whatever else wows the suits.
  • Design for your users, not yourself. Stay aware that techies do not use the technology the way that everyone else does, and there is nothing wrong with everyone else – they just aren’t techies. So make sure that the software is configured to their needs and desires, not yours.
  • Consultants Rock! (and I’m not just saying that because I’m now a consultant). If you are doing your job well, a consultant can help you build resources and improve your status with management. Simple fact: The CEO will always listen to the consultant say exactly what you’ve been saying for years.
  • Be opportunistic. Apply for grants – you don’t have to wait for the grant writer to do it. Call different people at that vendor that you’re seeking a charitable discount from, not just the ones who think it will lower their commission. And then, back to marketing – let the CEO know every time you succeed.

Peter Campbell is a Business Technology Consultant focused on assisting members of the nonprofit/social services community with revenue-generating projects and promoting organizational self-sufficiency.