2
Defining the Project

Q:	Why do most projects struggle?
A:	The scope of the project changes without the resources changing.

What do many people do first when assigned a project to complete? They create a schedule with due dates. Unfortunately, this is a poor choice.

One reason they rush to create a schedule is that project management software (for example, Microsoft Project) is primarily focused on scheduling. But, skipping the project charter and jumping right into the project schedule is the biggest mistake you can make in project management. Imagine saying, “Before I know why we are doing this project, who is involved, what the risks are, and what we are building, I’m going to build a detailed schedule.” That makes no sense, yet lots of people do it. In fact, you may have been doing this, too. If you are, stop.

The project charter is essential. The typical problems that show up late in a project—new features, changing budgets, projects that never end, and stakeholders arguing—all are caused by skipping the project charter (or the define phase of the Dare Approach). Remember, bad news early is good news. You should want to know as much as you can while you can still easily do something about it.

The project charter, at a minimum, is composed of:

• business objectives

• scope

• project objectives

• risk

• stakeholder communication plan

• governance plan

• transition plan.

In this chapter, you will learn from a fictional case study and then you will work on the project you chose in Exercise 2-1. Once you have gathered all the information you need, you should be able to sketch out a project charter in 45 minutes or less. That sounds impossible, but sketching does not mean a final version, simply a draft. In fact, the project charter is always a draft; it is your best guess at what the business needs, and it will change. Remember the difference between controlling a project and managing one—it’s best to encourage communication and collaboration.

Documenting the Business Objectives

The business objectives for a project may seem straightforward, but in fact they are often very unclear. Most project sponsors think the business objective is either obvious (and so there is no need to document it) or too complicated. In this section, you will learn how to create a simple business objective from a narrow choice—there are only two.

Every project needs a primary business objective that justifies why the business is spending money on it and not on another project. There may also be a secondary business objective, although it is normally eliminated when the schedule and budget tighten toward the end. Essentially, the primary business objective is a high-level expression of the business case for the project: What does the company expect to get as a return once this project is implemented? Further, the project should align to the goals of the business. In other words, if there’s no business problem, there shouldn’t be a solution.

Here is a simple way to figure out the primary business objective. We use the mnemonic IRACIS (think of it as the name of the Greek goddess of business), which represents three common reasons that businesses spend money on projects:

• increase revenue (IR)

• avoid cost (AC)

• improve service (IS).

Even special cases are easily covered by IRACIS. Some project work is required to react to government regulation (for example, when accountants need to be retrained in tax law changes). Compliance-oriented projects are avoid cost projects because they are focused on avoiding the costs of huge fines or lawyer bills. Similarly, companies invest in projects to keep up with the competition; these projects are primarily increase revenue projects.

What about improve service projects? Businesses love to use improving service as a way to get permission for a project without much pushback from others. No one wants to deny that service is important. But we’re going to eliminate this option because it is already covered under increase revenue or avoid cost. Improve service focuses on two constituents: customers and employees. We improve service to external customers to increase revenue; we improve service to employees to retain them or, in other words, to avoid the cost of rehiring. So, there are only two business objectives to prioritize: increase revenue and avoid cost.

So, think about the difference between increase revenue projects and avoid cost projects. Companies are usually more willing to invest in increase revenue projects, so it’s easier to get stakeholder commitment. Compare this with avoid cost projects, such as changing healthcare deductibles, which may seem more like an irritating necessity. Clearly, the project sponsor’s primary business objective of revenue or cost avoidance will drive very different kinds of projects. Note that most learning and development (training) projects are actually avoid cost, except for sales training.

In a perfect world, the project sponsor will prioritize the most important business objective by the time you are given the project. But that’s not always the case. So, you (as project manager) may have to create a draft prioritization and share it with the project sponsor for approval. The project manager, sponsor, and stakeholders must share a clear understanding of the business objective before they can collaborate.

What’s the primary business objective for the fictional case study? Is it increase revenue or avoid cost? Here’s one version:

The project to improve meeting effectiveness will avoid the cost of wasted employee time by facilitating workshops on the guidelines that all staff will follow during all meetings.

Now try drafting the primary business objective for your real project. Consult the project charter in Exercise 2-1 and fill in the box for primary (and secondary) business objective with a tagline for your project. Run it by your sponsor for approval, and then run it by someone who knows nothing about your project to see if it’s clear.

Documenting the Scope

As you may already know, “scope creep” is the number one killer of projects. No matter what a project manager does, the business needs for your project will change over the duration of the project. The longer the project, the more likely the needs will change drastically. Scope cannot be frozen any more than the change in business needs can be eliminated. The best tactic for an effective project manager is to manage (not control) the scope so that needed change is understood by all.

At the start of the project, the project manager, and stakeholders as needed, should document the scope as they understand it. The more stakeholders who are involved in creating the scope definition, the more collaboration will be necessary when the scope changes later in the project. Creating a visual, high-level model called a scope diagram is a valuable project charter technique. Many project managers make the mistake of creating written scope documents out of boring text—a 15-page scope document will be signed-off by all, but read by none. Remember, bad news early is good news, so having people pretend to agree and change their mind later is not useful.

Figure 2-1 is a scope diagram for the fictional case study. This diagram is basic, but yours will be likely more complex. Just like everything else in the project charter, the scope diagram will likely change as the project progresses.

Figure 2-1. Sample Scope Diagram for the Fictional Case Study

As you can see, it’s useful to build this model initially using sticky notes and big sheets of paper. The star in the middle represents the project. The role of the project manager is not shown, but you can think of yourself as being “in the star” role.

The squares represent the project’s stakeholders. The most important stakeholder is the project sponsor. Note that the stakeholders are actually roles, not people. In the planning phase, when you create the project schedule, you will figure out who will actually do each task. For now, you are just trying to figure out what roles you’ll need to get the project done—who you need to either get something from or give something to as your project progresses.

The handoffs from the project to the stakeholders and back, which are documented with arrows flowing into or out of the center, usually determine where your accountability as the steward of the project begins and ends. For example, you could send a draft of a course to the legal department for approval, and then they send approval back to you. They might also send changes back to you. Think of yourself as the conductor for these handoffs—you own all the arrows going out of the project, and the use of anything associated with the arrows coming in. You do not own the stakeholders, of course. Think of the stakeholder boxes as fence panels around your scope of authority as project manager.

A few things to note in the example:

• These are roles. It’s possible, for example, that the project manager also holds the learning and development role, maybe even the learning management system manager. One person can have multiple roles, just like a role (except for the project manager and project sponsor) can have multiple people in it (for example, multiple subject matter experts).

• You should always have a project sponsor stakeholder box. It’s good practice to receive a budget, hours, and decisions from a project sponsor and send the project sponsor status reports.

• Each arrow represents work that someone has to do. In other words, each arrow provides a preview of the tasks that will be scheduled in the define phase. This way your project schedule can contain not only what tasks you’ll do, but what the other members of your flash mob (the stakeholders) need to get done as well.

• Each arrow must touch the star, because if it doesn’t, it means that you don’t know about it and thus cannot manage it. You also cannot have double-headed arrows.

• You can use a dotted line to connect two stakeholders to represent tasks that you do not own. For example, in the figure, the dotted line between the process SME and the learning developer could represent the way these two roles work together, without putting everything they talk about through you. Just remember, if this is the case, you’ll likely want to create an arrow from one or both of them to report on the status of their work together.

The scope diagram pays forward and provides many benefits to the project manager:

• The arrows can be used to double-check the project schedule to make sure you don’t miss any tasks.

• The diagram, with your explanation, depicts the project in a vivid manner, avoiding signoffs on material that wasn’t read.

• The stakeholder communication plan, described later in this chapter, is built on the stakeholders that you’ve drawn here.

• It helps you show how hard the project really is and manage the expectations and engagement of the stakeholders.

Try creating your own scope diagram for your project in Exercise 2-2. Share it with your project sponsor and the other stakeholders for feedback.

Documenting the Project Objectives

You will have many project objectives. Whereas the business objective is about what return the project will create from a business perspective (return on investment), the project objectives create measurable and concrete descriptions of deliverables (the metrics) for a completed project. The project manager determines what to build for the project to meet the primary business objective, and the project sponsor then approves the project objectives.

Think of the project objectives as what you promise to deliver to the business when the project is over. It’s your word. A warning: If you trivialize this step (while tempting), you’ll pay for it when you’re trying to end the project.

When this book was first published, e-learning was in its infancy, so the only project objectives were learning objectives. As learning and development projects become more complex, more categories of objectives are needed, including system objectives. Balance writing the perfect project objectives with the need to deliver the project in a timely manner. It’s a draft in the beginning, so you won’t get it perfect at first.

Learning Objectives

Creating learning objectives can be time consuming. Most of us have been exposed to the importance of learning objectives, but we’re not always confident in creating them. Learning objectives create a metric for measuring what behavioral change will exist after the training is completed. Great training programs are driven by well-thought-out learning objectives that meet two criteria:

• The learning must be observable in the learning event (that is, learners must be able to demonstrate that they can perform each learning objective).

• The learning must be measurable (the learners must be tested on what they’ve learned).

However, this concept of behavioral change has become more controversial since this book was first published. Experts have found that very little of the learning occurs in the training classroom and most occurs (or doesn’t) back on the job. Let’s look at what we mean by behavioral change.

When we offer training to learners, it is to learn:

• Skills: What will the learner be able to do? For example, sort a table in Excel.

• Knowledge: What will the learner know? For example, know what Excel is used for.

• Attitude: How motivated is the learner to use the skills and knowledge? For example, someone who doesn’t like math won’t like Excel.

And all three are interrelated—take this equation: (Skills + Knowledge) × Attitude = Performance. If a person does not have skills and knowledge, performance is impossible. If a person has skills and knowledge, but doesn’t want to do it (attitude), performance is impossible. In learning experiences, we set learning objectives to grow skills and knowledge, but our designs should also help learners change their attitudes.

When training is finished, it is easiest to measure whether a person has new skills. Knowledge is usually not the goal of improving performance—for example, people can know about project management without having the skills (or attitude) to do it. Most instructional designers now measure performance change—what people can do that they couldn’t do before.

Skills, knowledge, and attitude can be combined into a measurement of performance. To keep it simple, let’s start with the ABCDs of creating measurable and realistic learning objectives that drive performance. Here is a simplified ABCD version of academic approaches (see research and works of Bob Mager for more on these):

• Audience: Who will be learning? Who will be changing their performance? Be as explicit as you can about the audience. For example, a workshop on project management that includes both senior and junior project managers will not be as successful as modifying the materials to hold a different workshop for each audience.

• Behavior: What will the learner be able to do differently, and how?
How will the supervisor measure that performance change has occurred?

• Condition (optional): Under what conditions will the learning be required? For example, will the learners have job aids to refer to after the learning experience?

• Degree (optional): To what degree will performance be improved? For example, a security guard must call the head of security within five minutes of an alarm going off.

In the fictional case study, the underlying reason for the project is a need to create behavioral change. “All staff” creates a risk factor for the success of the workshop, so decisions have to be made whether it’s better to have many levels of employees in one session or teach teams. A learning objective for the fictional case example could be, after completing the workshop, the business staff member will be able to plan and implement from memory the established corporate guidelines in every meeting. Here, the ABCDs are business staff (audience) gaining the ability to implement the established corporate guidelines (behavior) from memory (condition) in every meeting (degree).

System Objectives

When software and technology are involved in a learning experience there will be additional project objectives. Consider the following categories that likely need clear and measurable system objectives:

• Security: What types of security requirements will be required to log in to your learning experience?

• Backups: Who is responsible for backing up completion and course data?

• Software and hardware: Is the proposed software compatible with the standard technology architecture at your company?

• Accessibility: When can the learning experience be accessed? Have people with disabilities been considered? What platforms will be able to access this learning?

Now return to the project charter template. Use Exercise 2-3 to fill in as many project objectives as you need to be clear about what the end of the project will represent. Run it by your sponsor for approval, and then run it by someone who recently completed a similar project to see if you’ve missed anything.

You should also revisit your scope diagram to make sure that the project objectives and the scope diagram are telling the same story. Minimally, the arrows on the scope diagram coming out of the project should map to the project objectives. Take note to add any new stakeholders (for example, security) that you’ve discovered in the project objectives to the scope diagram.

Documenting Risks

Risk is simply the likelihood that your project will fail in some way. It could be late, end up over budget, or fail to meet the learning needs of the customers. The higher the risk, the more likely that one of those problems will happen. Consequently, the higher the risk, the more time the project manager must spend on project management activities, such as convening status meetings, troubleshooting the schedule or budget, evaluating quality, and other activities necessary to plan, organize, and manage the project.

Risk is often unavoidable, but analyzing and managing risk up front in the project charter allows a project manager to:

• Anticipate situations, glitches, and problems, and build contingency plans.

• Conduct project management activities in proportion to the amount of risk—for example, the higher the risk, the greater the number of status meetings.

• Manage the expectations of the stakeholders and the project team.

• Challenge the misconceptions of the business customers.

Risk varies based on certain criteria. For example, risk is reduced when experienced people execute the project. Inexperienced developers, customers, and technical staff can slow a learning event project.

Here is a quick ’n’ dirty risk assessment technique you can use to calculate the risk of a project relative to other projects. It works best when the entire project team and the customers, including the project sponsor, are involved.

First, ask the members of the team to privately write down their answers to three questions:

1.   How big is this project compared with others you have been part of?
(1 = it’s the smallest; 10 = it’s the largest.)

2.   How stable are the requirements for this project compared with other projects you have been part of?
(1 = the needs are completely clear; 10 = the needs are undefined.)

3.   How large will the learning curve be for this project? For example, is there new software, hardware, or processes that have to be learned?
(1 = no learning curve; 10 = a considerable learning curve.)

Then, have the participants average their answers and share them in a team discussion. Finally, agree on what the team thinks the numbers should be and add that to the project charter.

Use Exercise 2-4 to conduct your own quick ’n’ dirty assessment. Like the other deliverables you have created so far, this will help you manage the expectations of your stakeholders.

Sample Risk Assessment

Think back to the fictional case study. Here is how a risk assessment might work out for that example:

1.   Size = 2
It is limited to one hour of learning, so this is a fairly small learning event.

2.   Requirements = 5
People have been studying effective meeting management for years, so although the project manager may not yet know exactly what the contents will be, it shouldn’t be too hard to research this topic.

3.   Learning curve = 1
This is going to be an instructor-led workshop, so there isn’t much of a learning curve.

Average = 2.4

Based on the assessment, this is a fairly low-risk project that shouldn’t require a lot of extra project management. If any of the assumptions change, however, the risk will change as well.

To show how the situation could get messy, suppose the decision is made that the training will no longer be instructor-led, but will instead be implemented as an e-learning program on the company intranet. The learning curve jumps to a 10, changing the average to 5.6. The project is now more likely to run into some surprises, particularly technology issues. The project manager must plan to pay careful attention to the learning curve because it can stall the project.

To make things even more complicated, suppose it is decided that the managers will build the meeting guidelines as a team, rather than using research from outside sources. This approach will require multiple meetings, and likely cause conflict and politics; the requirements rating would increase to 9, resulting in an average of 7. The project manager would need to spend more energy on the requirements of the project to ensure success.

Risk Scenarios

When your risk is greater than 5, consider building risk scenarios, which:

• Provide a more detailed look at the project.

• Allow the entire project team to have common, realistic expectations.

• Identify risks.

• Drive more realistic and less idealistic estimations in the plan phase.

• Help the project manager anticipate and look for symptoms of glitches, thus speeding reaction time to problems.

First, gather the project team and ask them to list glitches that occurred in other projects they worked on. Ask them to brainstorm other surprises that might occur during the current project that relate to people, processes, organizational issues, or technology. Ask the group to rate each scenario for its possible effect on the project. Use the high-impact scenarios (and, if time allows, medium-impact scenarios) to generate a brief discussion of a contingency plan (low-impact scenarios can be ignored). Use this brainstormed list to create a table like the one in Figure 2-2.

Figure 2-2. Sample Risk-Scenario Planning Table

You can also give the team the option to determine a preventive or reactive response to the scenario; sometimes creating both makes sense. For example, suppose the project manager leaves. A preventive response would be to cross-train a backup project manager from the start; a reactive response would be to freeze the project while the new project manager is brought up to speed.

Risk management is a critical job of a project manager. The minimal quick ’n’ dirty risk assessment alone provides a baseline, driving two important success factors: a clear understanding by all team members and stakeholders, and a shared strategy for managing the riskier aspects of the project as it progresses. Getting their input on the risk scenarios can further improve your ability to respond to risks. Use Exercise 2-5 to plan risk scenarios for your own project. Brainstorm some events that could dramatically raise the risk of your project and add them to the project charter template.

Documenting Constraints

All projects are constrained by time, costs, and quality, which will drive the manner in which the project is managed. For example, a project to build a course for surgeons on the use of a complicated instrument for brain surgery will be managed entirely differently than a course for managers on how to fill out their time sheets. As part of the project charter, your team and stakeholders can use the simple table in Figure 2-3 to capture the prioritized constraints at the start. You can also refer to it throughout the project to identify whether any of the constraints have changed.

Figure 2-3 shows the project team’s consensus for the fictional case study. In this case, quality is the first priority because the material and presentation are vital to changing attitudes throughout the company. Time is the second priority because a great deal of time is being wasted. Cost is third because the longer the meetings last in their current unproductive fashion, the more money the business loses in lost wages. You can use this type of visual aid throughout a project to help identify whether any constraints have changed.

Figure 2-3. Sample Constraint Matrix for the Fictional Case Study

This visual aid will also be useful for organizing and controlling your response to surprises in the manage phase (see chapter 5). For example, if these constraints are prioritized correctly, you may be able to anticipate that the project will cost more or take more time than originally planned.

As a project progresses, quality can be maintained by cutting back the project’s scope—do a smaller portion of the project at the quality expected. When faced with a lack of time or money, you may be able to deliver a smaller piece of the project without compromising quality. For example, the meeting management materials might end up as a job aid rather than an instructor-led workshop.

Prioritizing among time, cost, and quality is not something project sponsors like to do—they clearly want all three. You may find it useful to replace a numerical ranking system with a descriptive ranking system, for example, 1 = can’t move, 2 = moves little, and 3 = negotiate.

To create a constraint matrix, ask each person to select a first, second, and third priority privately, and then share the results as a team. The project sponsor is the tiebreaker and owns the answer, but take note if the sponsor’s priorities conflict with the documented priorities. All must agree on the priorities before the project can continue. In situations in which the customers are in direct conflict with one another over what the priorities are, the conflicts must be resolved before proceeding, even if it requires escalating to higher levels of management. No project can succeed when serving two different priorities.

Try out Exercise 2-6 to prioritize the constraints for your own project. Fill out your own constraint matrix and fill in your results on the project charter template in the appendix.

The final steps of completing the project charter require creating three critical plans:

• stakeholder communication plan

• governance plan

• transition plan.

Although often skipped, these three steps are the best defense you have against people showing up out of the blue with new changes at the end of a project.

Creating a Stakeholder Communication Plan

The success of a project depends as much on the stakeholders and their perceptions as it does on the project manager. A terrible mistake made by many project managers is the resistance to communicate proactively with the stakeholders. Great project managers build confidence by sending regular, predictable status reports. A stakeholder communication plan lays the groundwork for consensus and buy-in on an ongoing basis.

The scope diagram (see Figure 2-1) is a good starting place for a communication plan. Each stakeholder position represents people with whom communication is essential. With a little thought, you can add other people to the list who are less directly affected by the project, but are nevertheless important to its success. Minimally, each name you include in your communication plan should receive regular status reports. If you need to communicate other information, you can use a subset of this list or use it all. If in doubt, always err on the side of providing too much information. You will then add the tasks required to communicate with stakeholders during the project to your project schedule (see chapter 3).

People prefer either visual (learn by seeing), kinesthetic (learning by doing), or auditory (learning by hearing) communication; few are equally proficient at all three. Consider the style of the person with whom you are communicating and adjust your communication accordingly. (For information on how to assess learning styles, you may want to look at my earlier book, The Accelerated Learning Fieldbook, Pfeiffer, 1999.) For example, an auditory budget client may be happiest with a phone call, whereas a visual executive may prefer a pie chart showing the same information.

Creating a Governance Plan

A governance plan determines who makes what decisions. Confusion about who can make what decision can paralyze a project and limit the ability of a project manager to successfully deliver value. You should answer two questions:

• Who can say when the project is done?

• Who has the authority to change the project’s scope, requirements, budget, and schedule?

For the first question, it is preferable for one person, often the project sponsor, to determine when the project is finished. The second question can be clarified by answering three questions describing a person’s role on the project:

• Accountable: Who owns the completion of the deliverable?

• Consulted: Who is asked for advice (that doesn’t have to be taken)?

• Informed: Who is told what is happening and has no decision-making authority?

Answering these questions could allow a company to trim its standard curriculum development process from 18 months to three months by primarily eliminating redundant approvals and sign-offs.

Create this plan at the start of a project when everyone (including the project sponsor) is more open to this discussion, rather than waiting until the end when patience is wearing thin. If you wait until the project starts and conflicts occur, it will be more difficult to set the rules.

Creating a Transition Plan

After a training program is developed, it is often transferred to another team to manage the logistics of offering the program and maintaining it. In other words, developing a program is a project, whereas maintaining it and managing logistics is a process. The plan for transitioning to the maintenance team is traditionally created at the end of the project, but that’s too late. Similar to the governance plan, leveraging the positive attitudes at the start of a project is also useful when establishing the hand-off of the finished project. Minimally, consider including a transition manager stakeholder on your scope diagram. That way you can include this person in your status reports and nurture a more informed partnership for the end of the project.

Here are some things to consider when transitioning a project:

• What artifacts will the transition team need for a seamless turnover? (Examples include train the trainer, facilitator guides, logistic guides, supply lists, and masters of all forms.)

• How will you transition? (For example, how long will you support them if they have questions? Will you choose a date or phase in the cutover?)

• What can the transition team learn from the pilot classes?

• How can you support the team’s ability to market the program?

Use Exercise 2-7 to create stakeholder communication, governance, and transition plans for your own project.

Summary

In this chapter, you have read about how to define a project by creating a project charter. Asking the right questions of the right people can promote collaboration and create an environment for success. Managing the scope, risks, and constraints of a project allows you to share and maintain a mutually agreed-on baseline. As you may have noticed, software tools aren’t prevalent for building a project charter. Using simple Microsoft Word templates or interactive PDFs shared in a project folder with clear naming standards is the best bet.

The first time you create a project charter, it may take you a while. However, once you’ve got the feel for it, thanks to experience and reusability, creating a project charter will take you less than an hour (given you have all the information you need). Remember, the project charter is always a draft until the end of the project—it will change.

The big complaints from project managers are usually: the project is stuck, everyone changes their mind all the time, people keep changing things, and they won’t let me end the project.

These complaints stem from the lack of a collaborative project charter. Because the project belongs to the business, the project manager cannot say no. However, the scope diagram provides a visual of what’s in and out, allowing the project manager to negotiate and say, “Yes, and the impact will be this …” A lack of communication, governance, and transition plans guarantee that the project will be difficult to end.

If you skip the define phase, your project will surely see quality diminish or run over in cost, scope, or time, if not all of the above. A little time at the beginning can save a tremendous amount of time and stress later on.

Practical Exercises

Now let’s try some of the techniques. Think about your own project for a moment and consider how you might put the define phase into practice. Use the following exercises and the project charter template in the appendix to create the following deliverables for your project:

• business objectives

• scope diagram

• project objectives

• risk assessment

• risk-scenario plan

• constraint matrix

• stakeholder communication plan, governance plan, and transition plan.