Access Services Department
Knight Library

Project Planning and Management

Workshop Nov 7 - 9, 2007

2.1: Define the Project Scope

You want to end up with a Project Definition Document which includes:

You'll be relying on this document through the rest of the project.

Deliverables:
Figure out what the deliverables of the project are. What's a deliverable? It's what you'll end up with for the customer at the end of a project. They're tangible outputs of the projects. Think about the end deliverable first, and then an interim deliverable (a prototype, for example). Work diligently to keep the number of deliverables manageable for that project.

Is/Is not: Now, thinking about each individual deliverable, have everybody "brainstorm their guts out" for what is contained inside that deliverable and what is not. Put little post-it notes all over the walls. Everybody look at everybody else's and if that stimulates more ideas, then just keep writing and slapping and writing and slapping and writing and slapping.

Then make a little chart like this:

IS: IS NOT:




































and one person reads a yellow brainstormed idea and the group gut-reacts whether that brainstorm is or is not part of that deliverable for project. If the group can't consense, then the post-it goes on the middle line.
Also, think of the final list of deliverables as if they're in a bathtub. The "we must have X" need to be drained out of the pool and into the project first, the "we should have XX" drain out second so if there's time we can do them, and the "we could have XXX" drain out last so maybe they can be included if we finish the shoulds.



2.1.1: Project Objective Statement
Based on what the group believes the deliverables are write a clear concise (fewer than 25 words), and complete Program Objective Statement. It should say what you think you want to accomplish by what date. It must contain schedule, scope, and resources.

President Kennedy's program objective statement for NASA back in 1961 said, "I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." And a bit later in the speech: "...531 million dollars in fiscal '62 -- an estimated seven to nine billion dollars additional over the next five years."

It had a scope: put a man on the moon and bring him back. It had a schedule (put a man on the moon by the end of the decade) but could have been more clear about that: Jan 1, 1969? December 1, 1969? Dec 31, 1969? Is 1970 really the end of the decade and 1971 begins the new one? (Remember the Y2K controversy on when the millennium ended....). And it was had resources: (for 7-9 billion dollars).

Regarding being clear, concise, and complete: Albert Einstein said "If you can't say it simply, you probably don't understand it."

Anyway, you need all three elements in your Program Objective Statement: Schedule, scope, and resources. You need to be clear (no ambiguity, no jargon, and must be understandable by anybody associated with the project including customers and Sponsor), you need to be concise (25 or fewer words), and you must be complete (include the Sponsor's scope, schedule, and resource expectations for the project).



2.1.2: Figure out the Management and Planning approach:
"Now that we understand the scope, how are we going to manage this project?" is the question. The three most common approaches are:

And here's where I got a little fuzzy and/or maybe we didn't talk a lot about this, so look it up or ask one of the participants if you can borrow his/her notebook for more info.

But here's another little gem that DOES make sense:


Don't plan past your next point of knowledge.


Here's something on Planning:

  1. Waterfall approach: single process, starts at the beginning, goes through its steps, and ends at end.
  2. Phase Planning: work to the point that you stop understanding, then change the planning for the part you don't understand and by the time you get there you'll have figured out what you don't understand, so start working on that, then while you're doing that start figuring out the next phase that you don't understand so that when you're done with the current phase you'll understand the next one.... etc.
  3. Agile Philosophy: No Idea, here. Check Google. There's lots of stuff.

And now here's a little diversion from the regular program. (Ernie taught us things that aren't in his normal workshops, he said. Don't know why: he complimented us that we were catching on quickly and had some extra time so he'd throw in some more Organizational behavior and Org. theory stuff.... but I bet he says that to all the groups.)

There are four considerations in business cultures that drive decision-making:

collaboration:
customer-
focused		 process:
goes for
efficiency
cultivation:
employee
focused		 competence:
product
quality

Collaboration: heavily customer-focused. Like Nordstrom's. They're very big on customer service. They have each staff memorize and carry around a little card that says something like "do whatever you can to help the customer, and use common sense." Ernie was going to a hotsy totsy meeting and something or other happened to his baggage and he needed a new suit so he stopped into Nordstrom's but it was closed. He banged on the door and a Nordstrom security guard came to see what was up. After Ernie told the security guard his problem the man let Ernie in and they went together to pick out a new suit. $400 later Ernie was ready to pay and the guard said, "Oh, the cash registers aren't up until we open". The guard let Ernie write out his name and contact information and the total he owed, and Ernie said he'd be back after the meeting to pay. "Well," Ernie said to us, "I bet that when the guard told his supervisors the story they said, 'Good job helping the customer, Guard Man,' and then they probably talked a little about common sense." Nordstrom focuses on customers.

Process: efficiency is paramount. Wal-Mart's the example. Ernie says that Wal-Mart doesn't own ANY of its inventory: they're just a big huge box that rents space, essentially, to vendors. Wal-Mart doesn't pay any vendor any money until the customer plops down their $5.29 at the cash-register. Then they pay part of that $5.29 to the vendor and keep the rest for their expenses and profit. That's efficient.

Cultivation: employee-focused. Examples: universities, and dot-coms of the 80s. That's why the dot-coms went bust.

Competence: focused on the quality of their product. Example used to be Mercedes Benz

We need to know which is the dominant culture for us and our organization and for our project. Each organization has a bit of each culture, so each project can have a different "egg", a different focus for that project. You see what I mean:



2.1.3: Validate Scope and Approach with Sponsor
Go back to the Sponsor with your whole document and be sure the Sponsor signs off on it. Note that these validation meetings with the Sponsor are not you talking the Sponsor into liking your choices and what you've done on your project: it's for you to present your interpretation of what the Sponsor wants and for the Sponsor to correct any of your misunderstandings. You're obtaining approval and support. It's back to the "learn more with your mouth closed, Shirien" concept.

Once you're clear that you are going the direction your sponsor wants you can start breaking down the work into bite-sized tasks.



2.1.4: Breakdown the work into bite-sized Tasks
We want the tasks broken into their lowest level, their smallest chunks. Each task should have two words: a verb and a noun. Verb says what you're doing, and noun says what you're doing it to.

Identify the work, break it down in a structured format. (WBS = Work Breakdown Structure). Each task must have three things attached to it: a code, an owner, and a way to know when it's complete.

Time for another brainstorming session with post-its and poster paper. If one function is to survey the faculty, then some of the underlying tasks would be

Ok, there are lots more steps than that, but there's the idea. Now, you have to assign them a WBS number. That just means a numbering scheme:
1.0
1.1
1.1.1
1.1.2
1.2
1.2.1
2.0
3.0
3.1
3.1.1

Just write those numbers on each little post-it note and start assigning somebody to be responsible for that task -- to be the owner. Write her name on that post-it, too. The owner isn't necessarily the do-er; she can be the do-er, but if she's not, she's the one where the buck stops if it didn't get done. She's the one who knows about the status of the task, how long it should take to get done, etc.

Now you're getting ready to make a preliminary schedule.








Return to How To index