Thursday, October 25, 2012

Ragnaring the PMP Exam: Planning (Part 1)

You wonder why I start forming my teams at least 4 months in advance? In a formal project management setting, there are, wait for it, 20 steps in the planning phase. That' 48% of the project management official steps. FOURTY-EIGHT PERCENT.

Follow along, Ragnarians.

By now, you should have:
- Your first team email
- Team information google doc

In a vacuum, you get to do all the planning processes in a linear fashion. Yeah, no. The second that someone wants to fund my dream job in which all I do is organize Ragnar teams, theres a chance it could work like that, but in Ragnar life, it's just not going to happen. Trust me when I tell you, none of these planning phases are a one time bet. Open up your google docs, we're about to make some processes!

Lesson 4: Collect Requirements
The point of this phase is to understand all of your stakeholder's needs. For this step, we'll be talking about the team as a whole, instead of individuals. We'll take team needs and apply them to specific project objectives.

Example: Team Rated Ragnar wanted to be the Homecoming team at DC (I'm still a little sore we didn't win, can you tell?) To fulfill this business (read: team) objective, we had a few requirements:
- Best team name ever
- Most awesome glowing vans (ever)
- Seriously ridiculous glowing apparel (glowhawks!)
- Ragnar Spirit (red carpet treatment)
- Mascot (RAGBEAR!)

Lesson 5: Define Scope
This is your second team email. It's much like your first email to the team, but now, everyone has paid up and you have an official team. Let's make the wall of truth for realz.

The point of a scope statement is to make sure everyone is on the same page and when, months from now, it's 2 weeks to the race and someone says "I didn't know" you can say "yes, you damn well did." Maybe not in those words. My wall of truth scope looks like this:
- I understand the general way that Ragnar works 
- I will be ready to go at 2pm on Thursday; no, this does not mean that my plane gets in at 2pm
- I will not make plans for Saturday night
- I will not pressure my teammates to make time goals - we are here for a fun time, not a fast time
- I will be grateful to all staff and volunteers on course (and say thank you!)
- I will respond to emails from my captain
- If I cannot make the race, I am responsible for my replacement and cannot be refunded my entry fee

That scope/email does the following:
- Provides a description (This is what our team is going to accomplish)
- Provides acceptance criteria (when we're at the start line, what needs to be done)
- Project exclusions (what we aren't going to do:
- Project constraints (i.e. budget and schedule)
- Project assumptions (what every team member is assuming they will be able to do, and what happens if they can't...i.e. show up to the race)

Lesson 6: Create the WBS
Think of the WBS (work breakdown structure) as that massive, step-by-step checklist to get you from registration to standing at the finish line, drinking beer. Anything that isn't on this list is a "would be nice, but not crucial" item. For Team Rated Ragnar, glowing vans are a crucial item. Procurement of glowing items is on my "WBS." 

Make another google doc with the following categories:
- Task
- Person responsible
- Due date (this is cheating - WBS don't have time frames)

Your WBS should go down to the level of detail where it's actionable and not able to be further subdivided. Let's take glowing vans:

1) Decorated Van
1a) Determine Van Theme (glow)
1b) Determine How to Accomplish Theme (lots of glowing stuff)
1c) Order lots of glowing stuff (
1d) Acquire Decorating supplies (tape, contact paper, scissors)
1e) Decorate van

That process is called decomposition. Also known as what happens to your brain when you try to do it by yourself. Instead: decompose the major tasks into small tasks and give to your teammates.

Important note, though there isn't a time frame in your WBS, your work packages (i.e. "Decorate Van")  should be:
- Scheduled
- Cost estimated
- Monitored
- Controlled

Lesson 7: Define Activities
While the WBS is defined by deliverables (decorate van!), what happens in that task list I started up there is actually called defining activities. More decomposition! This is bullocks because I don't need to give my teammates a step by step list on how to order stuff on line. This may come in handy when designing a shirt though. That's tougher than it seems.

One theory is the "rolling wave" theory - which I used for my first team - it was basically defining my activities as they came, in small chunks, then worrying about other stuff in the future. I'm shocked my team survived my first Ragnar.

Lesson 8: Estimate Activity Resources
What do you need to make that list above happen? This one is too self explanatory, but PMPers have made this ridiculously intricate. I do a lot of budgeting in this phase. I recommend bottom-up estimating (assign time/money to each activity, then add it all up)

The real world calls this an Resource Breakdown Structure. I call it "the first Ragnar heart attack."

Lesson 9: Sequence Activities
It seems like this would make sense, and that it would all come intuitively, but it doesn't. Remember these key words: 11 other people, 200 miles, 2 vans, 30+ hours. There is NO intuition in that. While you are months out, make this list for yourself. It will look stupid, but trust me, it isn't. For example:
1) Confirm someone wants to be on team
2) Get paid via PayPal
3) Send Ragnar Team invite through Ragnar
4) Send access to Google Doc
5) Confirm that teammate has signed waiver
6) Confirm teammate has put in appropriate pace estimation
7) Confirm teammate has filled out info on google doc

Seriously. You'll find yourself weeks later, trying to make sure they paid or figure out why their invite isn't working.

If I could make a process flow, I would. Maybe I will and publish it later. But let's talk about process flows (Project Network Logic Diagram if we're being official) while we're at it. There are 4 types of interactivity relationships.

Once you've built this, take the longest route from start to finish and that is your "critical path" - this is the shortest amount of time that it takes to get through your project. I know that's odd, but work with me here.

You can build this chart two ways:
- Arrow diagramming method (ADM) also called Activity on Arrow
- Precedence Diagramming method (PDM)

ADM only show Finish to Start interdependencies while PDM shows all four.
- Finish to Start - You can't invite people to the team until you've registered
- Start to Finish  - This one is tricky, but think about it like this: I can start sending out "you owe x for x" emails once shirts have been ordered. I never do this, but it's the best example I have.
- Finish to Finish - I won't send a bill to the entire team (finishing finances) until I've received all of the expenses from everyone
- Start to Start - We can start decorating the van when the sun starts to set

Leads and Lags:
- Leads show the time saved when you can overlap tasks: i.e. for "fun stuff" completion, I can order glowing stuff and t-shirts at the same time. Instead of each taking 3 days to ship back to back, they will ship at the same time, thus saving 3 days. 
- Lags show waiting time. If the team doesn't pay me until 2 weeks after the race, I can't repay people's expenses until I have that money. 

Think about it in terms of Ragnar Showers:
If there are only three stalls at the high school, you cannot have more than 3 people showering at once (well, you could, but we're not going there). If you have a prison shower situation, you can have multiple people showering at once (let's go with 9), there you go - lead time. 

Major Exchanges:
Force the group to do group activities right when you get to major exchanges (night decorations, photos, etc.) instead of dispersing. When the group disperses, you immediately introduce lag time because you fracture dependent activities into F-S activities. Yes? Yes. 

This is the latest finish time minus the earliest finish time. Here's my best example. You saw your runner at the halfway point in their leg. At the fastest they can go, they'll be at the exchange in 30 minutes. At the slowest, it'll take them 50 minutes. Your slack time (to go pee at the nearest gas station) is 20 minutes.

Lesson 10: Estimate Activity Duration
All you need to know is that it's better to have a range of times for expecting your runner, rather than a set point. No one runs precise 9 minute miles on 0 sleep. No one.

Let's calculate a 3 point estimate on a runner's time. Best case, runner 1 will do their leg in 28 minutes. Most probable is 33, but if there's a mountain in there, it'll take 40 minutes. Our formula is this: (40+4*33+28)/6 = 33.3 minutes. I haven't gotten this anal yet, don't worry.

Moving on.

Lesson 11: Estimate Costs
This is the most important thing EVER. Seriously. I'm spending the most amount of time in my off season working on this process for my team.

The final bill for Ragnar has direct and indirect costs. Direct costs = the cost of glowing shit Indirect = we don't really have these. But if we had a secretary that we were paying to organize all this, her salary would be indirect.

I use analogous estimating the most for this (historical costs). Parametric estimating is also a good bet - this is historical costs (vans cost 400 bucks a piece in 2010) plus other variables (but now taxes have gone up, so I bet it's closer to 415).

Lesson 12: Plan Risk Management
MY TEAM IS PERFECT TRA-LA-LA NOTHING WILL GO WRONG. You're an idiot. My team is perfect and shit goes wrong ALL the time. Wait, I'm sorry, your plane is HOW MANY HOURS DELAYED? Hold on...the shirts didn't ship? What do you mean our volunteer has the stomach flu? Hold up. I have to do an ULTRA because you have a job interview??

Fortunately, risks can be positive and negative. We just generally call them negative. Good risks are surprise fun things. Like...hey! I get to do an ultra because our team member had to drop out at the last minute! (Or is that the mental illness talking?)

Here is your process:
- Figure out what risks might happen (your teammate gets a job interview and can't make the trip)
- Characteristics (you are now at 11 people on a team)
- Indicators that the risk has occurred (you, as captain, are running 34 miles instead of 20)

Seriously, though. I use this system all the time to determine if we need to begin leap frogging our runners/vans so we can get to the finish line in time. 

Lesson 13: Identify Risks
Determine what is likely to happen (my team will need to leap frog) and what that looks like (we're getting dangerously close to finishing after the finish line shuts down).

You can chart this stuff out, but I don't have time for that on the road and usually, I can't even find a pen by leg 20. Regardless, here are some risk types:

Kinds of Risk!
- Technical (our van breaks down)
- Project management (our captain is an idiot and didn't get insurance on the vans)
- Organization (two people broke up right before the race and are now stuck in a van together for 30 hours)
- External (it's pouring and our van is stuck in mud)

Not kidding, I have witnessed these things happen (thank god, not on my team). Risky business, this Ragnar stuff!

Ok. Wine break. We'll finish up Ragnaring the PMP Process: Planning Part 2 next.

No comments:

Post a Comment