This article is the first in a series that will look at some of the issues related to managing projects within the not-for-profit and public sectors. It focuses on providing you with more practical tips and tools that can be used easily, and avoids discussing more conceptual topics within project management. This article will look at the first step which is defining the project. Future articles will cover the initiation and ongoing management of the project.

Introduction

My friend Lola just got a promotion at a community service organization where she works. Her success managing a computer implementation raised her profile, and the title “Project Manager” was unwillingly thrust upon her. Her “promotion” was to manage a couple of programmers as they created a donors’ database. She confided in me that she was not really sure what a project manager was, nor what the person would do. She knew that she had to manage the project, but the day to day activities seemed pretty fuzzy to her.

Sound familiar? Probably.

Lola’s experience is similar to many people in the not-for-profit and public sectors. They have been asked to deliver projects, but are not really sure how to do so. They know much about helping people find jobs or assisting newcomers to settle in their new home or even in managing an organization, but they have never been trained on how to run projects.

My advice to Lola, and my advice to anybody managing a project, is first to define the project. “Defining the project” is the project management term for understanding what the project is all about. I do not mean the details of who is working on this task or how it will be governed. Although important, they will come later. I mean the basics: why are we doing this project and what are we trying to create?

Why are we doing this project?

It seems like an easy question to answer. However, many projects fail precisely because they have not answered it or because everyone has a different answer. If you ask five people on the project team why they are doing the project, you will likely come out with six different answers.

When I asked Lola why she was doing the project, she responded, “to create a donors’ database.” No, that’s the “what”. That’s “what” she is creating. But why? Maybe she is creating it because it will be easier to create reports on who gave how much. Maybe she is creating it because it will be easier for the development officers to access the information. Whatever the reason, it is important to understand the “why” because it will act as the benchmark against which all of the project activities and deliverables are judged. In project management terms, the “why” is called the Project Objective.

Resources are especially scarce in the not-for-profit and public worlds. Organizations have to scrimp and save, and compete for every dollar that comes their way. They cannot afford to work on projects that do not meet a specific need. The “what” will be judged against the “why”. Unless the project deliverables are going to meet the project objective, the organization cannot afford to deliver the project.

The project objective is also important because when project changes occur or work gets delayed, the project team is able to prioritize the project activities and deliverables based on what is most likely to achieve the objective. They first complete the tasks and deliverables that are going to ensure meeting the project objective, and then they can worry about other aspects that are not quite as central to the project. If they do not have time or money to complete those other activities, they will still have met their key objective.

Lola is creating the donors’ database because she feels it will allow for more efficient communication with donors. Her ultimate project objective is to communicate more efficiently with donors. If she gets halfway through the project and begins to run out of money, she needs to figure out what activities are most critical to meeting her objective. What activities will help her meet her goal of communicating more effectively with donors?

What are we creating?

This is often an easier question to answer than why we are doing it, but it nonetheless should be answered. In the current example, what the project team was creating is obvious – a donors’ database. But when they come to the end of the project, they might get a surprise. The executive director could ask where the user manual is or whether the people have been trained on how to use the application. The project team did not fully answer “what” they were creating. Now they have to negotiate with the executive director on whether training and the user manual were part of the original project.

In project management terms, the “what” is called the Project Scope. When you write it down, it is called a Scope Statement. It will include a list and brief description of each of the project deliverables and activities. Lola’s Scope Statement – or her “what” – would include creating a donors’ database, developing a user manual, and providing training to the staff.

Identifying the project scope is important for a few reasons:

• It helps everyone to know when the project is complete. Nobody afterwards can say that this was supposed to be done or that was supposed to be created.
• It prevents the project team from getting sidetracked. Work and effort often become derailed during complex projects because the project team completes activities that, although somewhat related, will not directly help the project meet its objectives. The project team can ask itself whether what it is doing is within the project scope and whether it will meet the objectives.
• When changes are requested during the project (and someone will definitely request a change), the team is better able to understand the impact of that change on the project budget and schedule.

Write it down

When you have finished defining the project – that is, identifying the project objective and scope – send it to everyone related to the project.

Just as bad as not defining the project is not adequately communicating it to everyone. If not everyone has a shared understanding of the project objective and scope, you may run into the same trouble as not having adequately defined the project in the first place. After you have written it down, you have completed your first Project Overview Statement. This is the document that you will keep for the entirety of the project, and whenever anyone asks what your project is about, you can give them this sheet.

Summary

The Project Overview Sheet seems like a simple lesson, and one worthy of little discussion. However, my experience on many projects is that unless the project team adequately answers “why”, they are doomed to creating something that does not achieve the ultimate objective. If they do not adequately answer “what”, the project completion becomes a moving target – and you can’t aim at a moving target!

Now that you have defined your project, you are well on your way. But this is indeed just the first step of the process. Managing projects requires communicating, creating plans, and strategies, and addressing changes as they occur. In upcoming articles, we will look at some easy things you can do to help keep your projects on track.

Blair Witzel (blair@mcdoane.com) is a member of the Project Management Institute and a consultant with McDonnell Doane + Associates, an information management and technology firm focusing on the not-for-profit and public sectors. His work centres on managing multi-project portfolios and working with organizations to develop project management methodologies to more effectively deliver projects.