How is project management different in a nonprofit organization?

I do not want to mislead you with the title of this post. In my experience, effective IT project management is what it is, whether the project exists in a for-profit company or nonprofit organization. However, the culture surrounding the project and some of the challenges differ.

To restate previous content, projects have a specified beginning and end with a product or deliverable, as opposed to operations (business or nonprofit), which are ongoing. In nonprofit organizations, a project may involve setting up an IT network, building a user-friendly warehouse of information or creating a website to collect donations.

Because our friends at the Project Management Institute believe that the discipline and standards associated with project management apply equally to projects in nonprofit organizations, they created the PMI Educational Foundation in 1990 to advance “project management knowledge and the application of project management concepts and theory by society.” Through their Foundation, they offer training and scholarships in project management.

Here are my thoughts on similarities and differences from working IT projects at both types of organizations.

Project Management similarities between for-profit and nonprofit organizations

  • Projects need a plan that identifies goals, defines scope, assigns tasks and has measurable outcome criteria.
  • The project must further the strategic goals of the organization (Should tie to some organizational objective).
  • Projects need a schedule with task detail, dependencies, assignments and periodic reviews.
  • Resources must be acquired, held accountable and managed. See the post on Managing Virtual Teams.
  • How much the project costs really matters – and may be the deciding criteria for whether it is undertaken.
  • Tools for planning, cost and schedule tracking and collaboration facilitation help project managers do a better job (here are some additional comments on tools: “Six Views of Project-Management Software” from TechSoup – for nonprofit organizations and “Collaboration Tools for Virtual Project Teams” and “A Fool with a Tool is Still a Fool” from previous “Fear no Project” posts.
  • Effective communication with key stakeholders is essential.
  • Risks must be identified and managed. You don’t have to go overboard- just identify the most likely and highest impact risks.
  • Project managers should expect changes in the plan during execution.  Be flexible! Expect to have to change the plan to accommodate changes in the environment or organization.

Project Management differences between for-profit and nonprofit organizations (in no particular order J)

  • While folks managing for-profit companies usually have some academic and experiential exposure to project tools and project management requirements, individuals in nonprofit organizations may not.  Actually they quite often do not have a background in project management – so they might try to get the assistance of someone who does.
  • Nonprofit staff and management may understand less about technology and technical terms than people in similar positions in for-profit companies – although maybe not. I have met some really tech-savvy people in nonprofits and some technology-challenged individuals in large companies.
  • Service-oriented nonprofit organizations may find creating measureable or numerical performance criteria challenging, as they are more accustomed to working in a subjective environment.
  • Predictable charitable or grant funding for nonprofit multi-year projects may be even more at risk than funding is in for-profit organization projects. (Agile project development methods provide a process that allows completion of useful tasks without reaching all project goals, this is a way to make progress in case funding is cut or a grant proposal not funded in second or out years.)
  • Stakeholders may be more diverse as nonprofit organizations frequently interface with government and private agencies as well as having ties within their communities. So using stakeholder techniques is even more critical in nonprofit projects.
  • Nonprofits are eligible for free or low cost PM software like that available from TechSoup.

If you have worked on IT projects for a nonprofit organization, please share your insights via comments.

Other resources for managing non-profit or volunteer programs:
http://www.serviceleader.org/virtual/establishing

How to cancel a failing project gracefully

 

A couple weeks ago (August 21, 2011 to be exact), I was watching a “60 Minutes” interview on TV about whistle blowing and a NSA employee’s possible trial for espionage. Interesting stuff, I guess. However, what caught my attention was that the charges revolved around a software development project. (Here’s the full story, if you are interested: U.S. v. Whistleblower Tom Drake.)

The gist of the story began when the NSA needed greater capability to sort through the terabytes of data it collected. Internally there was a tool, believed by the whistle blowers, to meet the NSA’s requirements. However, the Director decided to requisition develop of a new tool, called Trailblazer, that did everything they could imagine needing to be done. Millions of cost overrun dollars later, the project failed and the former head of NSA, Lt. Gen. Hayden told congress, “A lot of the failure in the Trailblazer Program was in the fact that we were trying to overachieve. And that a lot of the failure was that we were trying to do too much all at once.”

Been there. Done that. Got the project coffee mug!

Even when you are project manager for less grand goals than saving freedom and democracy, there comes a time in the life of many projects when the failure handwriting is on the wall. How can you tell when it is time and what is the best way to end a failing project?  Back in 2009, I wrote a post on Spotting a Failing project that was a short piece on the subject. In the current economic environment I have once again been asked to re-visit the subject by several of my clients.  I am not sure I have a nice precise answer to either of these questions, but I will share my thoughts on this often overlooked subject. 

Signs of a Project in Failure Mode

Recurrent cost and schedule over-runs may signal that a project is doomed to failure. Disruptive technologies or changes in the business case for a project can (and should) lead to project cancellation. In addition, customers can lose funding, especially in a recession or on government contracts subject to priority changes. All of these situations provide legitimate reasons to stop working on a software project.

I would like to add a few of my own observations – I have borrowed a couple, some tongue in cheek, from Code Squeeze’s “101 Ways to Know Your Software Project Is Doomed.

Bruce’s top ten signs that your project may be a failure:

  1. The schedule changes every day
  2. No one has heard from nor can they find the project sponsor
  3. The weekly status report is always the same – it never changes
  4. Project resources (staff) are constantly changed out without notice
  5. No one can find the actual requirements document
  6. Every bug is prioritized as Critical and every feature is prioritized as Trivial
  7. Project cost estimates magically match the budget – all the time
  8. The phrase ‘It works on my machine’ is heard more than once a day
  9. All code reviews have been moved to a week before product launch
  10. None of the project team leads shows up for the status meetings; they send a proxy

For those of you working on Government projects who want some insightful information on why government software development contracts often fail, I highly recommend the Clutter IT Journal article, “How do the turkey projects get wings …” by Payson Hall. I also wrote a post about how bad estimating on government projects can lead to failures. The hard part is defining that your project is failing – sometimes you have to re-think what success would be.

How to Terminate a Failing Software Project with Grace

Grace means gaining concurrence from the project’s key stakeholders that stopping an irrecoverably failing project is the best action for all concerned. Or, to quote an old saying, “Don’t throw good money after bad.”

As a project manager, you created a risk management plan during initial project development that included trigger conditions to be monitored to indicate when the project’s success was threatened. I recommend contacting your PMO, portfolio manager or supervisor as soon as the trigger condition occurs. Tell them your plans to investigate the problem and give them a deadline to report results and recommendations. As part of your investigation, talk with your lead technologist in an effort to identify any products from the effort that can be salvaged as deliverables. Do not be offended if managers that are more senior suggest calling in a consultant to get a second opinion or to assist in generating options to project cancellation.

When alerting clients to a potential project failure, it is better to have a face-to-face meeting than to send a report or wait for the next scheduled review. I understand that no one likes to be the messenger bringing bad news. However, if you have done your due diligence in assessing the situation, the sooner you gain concurrence and understanding from customers, the sooner you can move on.

When explaining the situation to customers, present the problem in non-technical language, offer your conclusions and recommendations. If you have a recovery plan, present the options along with their associated cost and schedule implications. If you identified salvageable elements from the project, describe how those can be polished and delivered.

Assuming that you are successful in convincing management, clients and sponsors that it is time to pull the plug, you should still push to perform some key tasks.  Before closing the project, create documentation and lessons learned for inclusion in the organization’s knowledge management system.  I am certain that the organization will not want to repeat the same mistakes again!

Please share your thoughts on how to spot and cancel a failing project.

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

ProjectManagement.com

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management

beyondcenter

Pushing the Edges Out ...

projectxpert

Just another WordPress.com site