Ragnaring the PMP Exam: Controlling Costs AND I PASSED

So I totally skipped ahead a couple of lessons and wrote this right before the exam, but in case you don't want to read it, here's the bottom line: I PASSED!

Lesson 38: Control Costs

Generally, I'm pretty good at controlling Ragnar costs. But if you made me go through a formula to prove to you that we're behind/on target/ahead of cost/schedule/scope, I'd probably kick you off the team.

That being said, the EVA process (or earned value management) tells you where you are with respect to cost/schedule/scope. Basically - are you on track with how much something should cost, have you done enough things on the check list, and is it all where it should be with this many weeks til the race?

The Planned Value (PV) or Budgeted Cost of Work Schedule (BCWS) - baseline of money planned for spending to date at any particular time. Essentially: if 30 days out, I should have gotten all the decorations for 200. My PV is 200.

Earned Value (EV) or Budgeted Cost of Work Performed (BCWP) - baseline of money planned for spending on actual work performed to date. Example: if we're 30 days out, the cost of what I've actually accomplished (it may be that I've only spent 10 dollars on glow sticks). My EV is 10.

Actual Cost (AV) or Actual Cost of Work Performed (ACWP) - the amount of money spent on the actual work performed to date. Example: at 30 days out, I got our decorations, but because of a coupon, I got them for $150. My AC is 150. 

Budget At Completion (BAC) - this is the amount of money planned for spending on the entire project. Generally, for Ragnar, if we're not traveling, and including registration fee, you're looking between $250-$350 a person.

Schedule Variance (SV) - take your Earned Value and subtract your Planned Value (EV- PV). If your SV is greater than 0, you are ahead of schedule. If your SV is less than 0, you're behind schedule. Example: If I have done 300 dollars of work (shirts and decorations!) when I was only having to get 200 dollars of work done (decorations), my SV is -100 and I am ahead of schedule.

Cost Variance (CV) - Earned Value minus Actual Cost. I got $10 of glowsticks, but they actually cost me $15 with shipping. CV > 0 = under budget, CV < 0 = over budget. Here, I'm over budget. 

Variance at Completion (VAC) - BAC (budget at completion) - EAC (cost estimate at completion). 

Schedule Performance Index (SPI) - SPI = Earned Value/Planned Value  SPI  > 1 = ahead SPI < 1 = behind; I did $300 dollars of work (shirts and decorations) when I said I'd have $200 done (decorations). Ahead of schedule!

Cost Performance Index (CPI) = EV/AC How much the cost of work should have been over how much I actually spent. Again, 10/15 (glowstick example) would equal less than 1. Over budget.

To Complete Performance Index (TCPI) = (BAC-EV)/(EAC-AC) thus - Team Budget of 1000-200(decorations)/1200-1100 = 8

Let's have a quick chat about EAC. There are three kinds and I hate them all. 

Time EAC = Planned Duration/SPI (EV/PV)

Cost EAC = BAC/CPI (EV/AC)

Estimate to Complete ETC = EAC-AC

Here are my fun ways to memorize this stuff:

SV = EV - PV (rain seeps into the van and can make a schedule variance)

CV = EV - AC (if there's a problem with a vendor, say "see ya" to extra cash because of cost variance)

VAC = BAC - EAC (Very Big Expectations for having 0 variances of cost or schedule)

SPI = EV/PV (spies are EVer Present to see if we're on schedule)

CPI = EV/AC I got nothin, once I remember SPI, I remember that it's just CEA with division instead of subtraction

Ragnaring the PMP Exam - Executing

Execution. Let's run this bitch.

In case you missed it, I'm studying for my PMP exam (tomorrow at 1!) by outlining the PMP process and applying it to captaining a Ragnar team.

This is where the project management really speeds up and you will thank/curse yourself for the time and effort that you put into the planning phase.

Lesson 24: Direct and Manage Project Execution
We've all met at the van rental desk. We're ready to get to the start line hotel. Thus begins project execution. These first 4-8 hours are the hardest for me as a captain. If you talk to me during this time period, I will probably respond in grunts, giggles, inappropriate or random phrases, because I am so busy checking that everything is ready, that people are getting along, and that everyone has an understanding of what's next (checking in on project scope!) Those who have run with me a lot know that this is usually the best time to smile and nod and keep me well fed. Type A's gotta go nutty sometimes.

Please note, the PMP backs me up on this crazy behavior: "the project manager must constantly monitor and measure performance against baselines, so that timely corrective action can be taken."

I know the instant that two people aren't going to get along and dive head first into pre-meditated conflict negotiation (this step is coming up a bit later).

The one place where this process deviates from the PMP process is in spending. It says the most money is usually spend in this phase; if we pre-pay for everything, then that is inaccurate, but the point being - usually the majority of money is spent here in project execution. Vans are expensive.

CONFLICT. I mentioned conflict. Here are reasons for conflict:
1) Schedules: We're sharing a hotel room and I want to go to bed, but you're talking our roommate's ear off and won't shut up. Our bed time schedules are causing conflicts.
2) Budgets: I thought we were keeping costs on the low end - we can't go to ruth's chris steakhouse for dinner.
3) Priorities: decorating is the most important thing to one runner, sleeping is the most important thing to another. I have seen serious blow out fights on this one. 
4) Human Resources: dear god, if I am the only person awake and driving the van at 3 am while everyone else is asleep, I will slowly turn into a burning pile of rage
5) Technical tradeoffs: Our van will be cheaper, but it won't have that awesome assisted back-up camera. And we may have to roll down the windows by hand.
6) Personalities: enough said.
7) Admin Procedures: You will get out of the van to cheer on your teammates even if you don't want to.

Here is how I deal with those conflicts:
1) Withdrawing: I'm going to ignore that person A is irritated because it's minor and they just need food (Justin does this to me all the time)
2) Forcing: "why?" "Because I'm the team captain and I said so." I don't think I have ever used this one during a race, thank God.
3) Smoothing: "She's just tired, she doesn't hate you" (LIES. ALL LIES, BUT PLEASE, LEAVE IT ALONE.)
4) Confronting: "Ok. I know this isn't the best situation, but here are our three options, tell me what you would most like to do."
5) Collaborating: "We're not going to make the finish line in time, here is my suggestion - what is yours?"
6) Compromising: "I hate leap frogging too, but we can either carry on as normal and maybe finish the race without beer or pizza, or we can leap frog and make it to a finish line party." 

Lesson 25: Acquire Project Team
This is out of sequence for our team since our team is formed waaaaay back in the planning phase, but in the real PMP world, you'd be assigning resources now.

Lesson 26: Develop Project Team
Sometimes, this happens by itself. Sometimes, I have to know random shit about each of my teammates so I can get conversations going. Generally speaking, here are the ways to develop a team. I actually do use each of them.

1) Training - every time someone does a Ragnar with me, they learn something new (usually because I learn something new, too). The more confident my team is with the process, the better the next race (generally) goes. I spend a lot of time with new Ragnarians, too, teaching them about Ragnar.
2) Team-Building Activities: Cards Against Humanity, team dinner, mixing up the vans on the drive up to the start line hotel, all good ways to get people chatting. One day, when I have less going on in my life, I'll get a pre-event team happy hour planned.
3) Reward and Recognition: have you followed our twitter feed? I try to tweet congrats to all of my runners on their progress
4) Co-location: easy. You're stuck in a van with each other for 30 hours

Need more? Here are reasons for motivation:
Maslow's Hierarchy of Needs: the pyramid effect. If your base needs are satisfied, then you can focus on levels over that. If you have gotten rest before the race, you can be stoked about wearing a safety vest, if you're good there, then you can spend time with your team, etc.

Alderfer's ERG: Existence Needs: Food, Relatedness: Relationships, Growth: development. That is your definition of Ragnar

Herzberg's Motivational Theory: advancement, recognition, and responsibility encourage motivation (give someone a task and give them recognition and boom, people will be motivated!)

McGregor's Theory X - people hate work (let's sleep in the back of the van all the time!)
McGregor's Theory Y - people love to work when appropriately motivated (I love decorating the van because we might win batons!)

Team phases are also important:
Forming: we've all just met - no one is upset! everyone is excited! much Ragnificance all around
Storming: omg are you serious? you don't sleep the night before a race?! RAGE RAGE RAGE
Norming: no more storming. we're talking like adults again.
Performing: that beautiful point where people have randomly picked up roles, like flag bearer or water refiller. You fall in love with your teammates.
Adjourining: end of the race. beer me.

Lesson 27: Manage Project Team
Teammates fighting? Time to cut someone manage them.

This process tracks and appraises team members. Frankly, by this point, unless there is a serious issue, I just hope everyone acts like teenagers (I won't hope for adulthood since I can't usually muster this kind of responsibility at 3am)

Lesson 28: Perform Quality Assurance
This is basically auditing the quality requirement. Example: is everyone wearing their safety vests during night time hours? 

It's also a bit larger than the specific race - I try to do some QA activities between teams, as well. Continuous improvement - PMP likes that a lot. They also call this KAIZEN (whatevs). It's the process of achieving improvements through small, incremental steps.

Lesson 29: Manage Stakeholder Expectations
This is another one of those processes that is really start to finish. If you come in thinking our vans are going to shoot off fireworks, we need to have a chat. 

Lesson 30: Conduct Procurements
This also happens earlier for us. But this is the time where I'm looking at Custom Ink versus Cafe Press for shirts; or someone is looking over the best place to rent vans, or which airport we should fly out of (we have three to choose from in DC and it's really annoying at times)

Lesson 31: Distribute Information
Again with the earlier process bit (note that a lot of processes don't happen in a preferred order!)

It's easiest to distribute information when you've been keeping good records. Remember your google doc? When everyone needs to have everyone else's phone numbers - boom. If you need to keep track of expenses - it's all done!

In the real world, you need to consider:
- Sender/receiver models (feedback loops/barriers to communication) - did you get my email? did it make sense? 
- Choice of media - don't send your team massive amounts of info in text; likewise, only text your team during the race when they may be sleeping if the info is menial
- Writing style - be sensitive when communicating with teammates at 3am
- Meeting management - Cards Against Humanity
- Presentation techniques - have you seen me lead a team meeting? Start mean, get weird, end happy
- Facilitation techniques - talk amongst ye selves

And that is our execution set of processes. Next up - Monitoring and Controlling the Project, which may need to happen first thing tomorrow morning!

Ragnaring the PMP Process: Planning (Part 2)

Ok. Wine procured (take notes, that word will come up again!)

Lesson 14: Qualitative Risk Analysis
How likely is it that your team will have to leap frog? How likely is it that you will have to split three legs across your van because your teammate has to drop due to job interview/angry spouse/broken leg?

Now is the time to figure out which identified risks (see last blog entry!) are likely to occur and how totally screwed you are if it does occur. Low on the P-I scale (probability impact) would be if a bee stings someone and they are uncomfortable on their run (i.e. I experienced my first bee sting ever in Great River and ran an uncomfortable several miles). High on the P-I scale would be that a major storm is destroying Chicago and your teammate's flight gets in the evening of the race. 

Lesson 15: Quantitative Risk Analysis
Assign numbers to those qualitative risks. You can do this a few different ways.

1) Expected Monetary Value (EVM): multiply the value of each possible outcome by the probability of occurrence, then add them all together. i.e. Am I willing to spend an extra $100 to get extra insurance on our big white vans? (Value x Probability)
2) Sensitivity Analysis: How risk averse are you? I'll spend that extra $100 if I'm really worried about the vans
3) Decision Tree Analysis: Decision and the possible outcomes. If I don't get the insurance...I could save our team money, or be up shit creek and owning a couple grand to the insurance company if we get hit in the parking lot...

Lesson 16: Plan Risk Response
1) Develop options to enhance positive risks (opportunities): we're down a runner - if we find someone fast, we can potentially have less risk about getting to the finish line in time
2) Develop options to reduce negative risks (threats): Promise to check your email twice a day to prevent an angry boss

There are a few ways to deal with risks. This risk being an angry boss:
- Avoid it: Bring laptop and work through connectivity to best substitute that you're at the office
- Accept risk: Well. He'll be angry.
- Contingency Plan: If he's angry, I'll have my laptop and I can work through my phone.
- Transfer Risk: set up someone to work in your stead at the office
- Mitigate Risk: promise to work the day after Thanksgiving if you can take off this day

There are a few ways to deal with opportunities:
Exploit: I found a fast runner for our team. They now have the most miles!
Share: I found a fast runner for our team. Let's put them in the van that has the slowest combined time.
Enhance: I found a fast runner for our team. Let's give them short miles so they can run faster!

Lesson 17: Develop Human Resources Plan
Develop, document, assign project roles.

Remember that team google doc we had? Add a column in there that has a responsibility column. This will harken back to your WBS spreadsheet. If I were to get weird, I'd make an org chart here, but I'm not that weird, just yet. Once you add that column, that document actually becomes a "Responsibility Assignment Matrix" - or matching resources with tasks.

Yes, you are now in charge of ordering t-shirts. Yes, since you live closest to the start line, we are shipping our glowing stuff to your house.

Let's talk about different types of team structures.

Functional organizations: Project managers don't have a lot of authority - i.e. you just order the glowing stuff, you don't control how much is ordered or how the van is decorated
Matrix organizations: Project managers and execs share responsibility - i.e.  the person in charge of decorating the van and the captain make the decisions together on how much to order and how to decorate
Projectized Organization: each project lead has authority over their area - i.e. There is a van decoration lead, a team t-shirt lead, etc. 

In the real world, it's preferable to be a projectized organization. Don't do this for Ragnar. Your best bet is, honest to god, functional. At the most, have a very week matrix. This may also be my Type A talking.

Lesson 18: Plan Quality
What does good look like? While we're at it, let's talk about high-grade versus low-grade.

You can have a high or low grade team and still have high quality. High-grade is our vans - ridiculously complicated and seriously awesome. Low-grade are our cheering routines - I've seen teams with choreographed dances. That is seriously high-grade. We just scream and ring cowbells.

There are a bunch of ways to plan quality...cost-benefit analysis, statistical sampling, flow charting, all that. But frankly, the PMP exam doesn't spend enough time on this for me to care and I can't come up with a good analogy in Ragnar terms.

Lesson 19: Plan Communications
THIS IS THE MOST IMPORTANT THING EVER.

In cold, hard PMP language: communication provides the vital connections between people, concepts, and information through the project environment.

Time to determine:
1) What information is needed (how much does it costs to rent a van?)
2) When is it needed (3 months before - we need to rent those vans early and budget for them)
3) How will it be delivered (spreadsheet? email? phone call?)

Communication is a two-way street. My job as captain is NOT done if I send an email. I have to send an email and make sure that my team understands what I said in the email. 

Keep in mind that there isn't just 1 two way street, no no, we have a lot of communication channels. That formula looks like this: N(N-1)/2. So, if there are 12 people on a team, that is 12(11)/2 = 66. That's a lot of channels. 

Here are some communication types:
1) Informal Verbal: talking to prospective teammate during a race "hey *breath breath* I heard you want to run ragnar *breath*
2) Formal Verbal: team meeting (happening Dec. 1!)
3) Non-Verbal communications: All I will say is that I know when my teammates are in a bad mood
4) Informal Written: bantering emails
5) Formal Written: Invitation from Ragnar to join team

Lesson 20: Plan Procurements
Simply put: what do you need to buy? Here is your decision tree for what you need to acquire:

1) Make or buy - should I make posters of our team logo or have them made for me?
2) Select Procurement Documents - what kind of contracts do we need? Should I pay up front for the hotels or pay when we arrive?
3) Create procurement management plan  - what does our cashflow look like?
4) Create the procurement SOW - how to submit expenses/get reimbursed and when to pull the trigger
5) Source selection - who should we pick to make our magnets?

For our team, we always go with Firm Fixed Price for our vans. We pay 1 flat fee, no extras (like per mile charge). A per mile charge would fall under a Time & Material contract. If you choose to have the rental company fill up the tank when you drop off the van - that's a cost reimbursable contract (avoid at all costs). 

Lesson 21: Determine Budget
Add up all our of WBS cost estimations and then divide by 12. Does everyone cringe? Time to work on that budget again. I strongly suggest padding the budget by $50 a person. Gas is hella expensive.

There's a bit about s-curves in here, but all it means is that there's a line you shouldn't cross or that you shouldn't cross too soon (s-curve measures where you are in your project with how much money you've spent based on projections. If you're 50% done and should be through 40% of your budget, but you're already through 60% of your budget, send up the emergency flares)

Lesson 22: Develop Schedule
This is another important one and it seems to be the one that gets totally FUBAR if you model your team like a projectized organization. I swear by having a dictator.

One day, I will put our schedule into microsoft Project. Today, however, is not that day.

This is the best time to sit down and look at your critical path from when we worked on activities sequencing. Take into account the critical path (the minimum amount of days it takes to accomplish a task added up according to the sequence of activities).

If you find you're f'ed in the a, you have two options:
1) Crashing - assign more resources to the task (or pay rush shipping!)
2) Fast Tracking - have resources performed in parallel (decorate the vans while supporting runners)

Fun fact: Heuristic means "thumb rule" useless at Ragnar as it is probably not among Cards Against Humanity.

Lesson 23: Develop Project Management Plan
Put it alllllllll together.

This is your google docs (now called google drive, apparently. I won't tell you how many profanities I uttered while searching for "documents" on my gmail launch pad)

So. We've initiated, we've planned. Let's do this thing. On to Ragnaring the PMP Process - Executing

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 follow all race rules (ESPECIALLY NIGHT SAFETY OR I RISK CAPTAIN NIGERIA STAPLING MY SAFETY VEST TO MY BACK)
- 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: namely...win)
- 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 (glowuniverse.com)
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. 

Slack:
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.

Ragnaring the PMP Exam: Initiating

Tonight, I am breaking my blogging avoidance (hi! I lived through the 70.3!) by studying for my PMP (project management professional) and applying it to captaining a Ragnar team!

So, all you current or future PMPs out there, you can totally captain a Ragnar team. Ragnar Captains - you can totally pass a PMP Exam!

Let's begin. You will find PMP concepts in black, Ragnar concepts in orange.

Lesson 1: Mastering the PMBOK (How to Captain a Team)

A project is a temporary endeavor undertaken to create a unique product, service or result. It has a beginning and an end. Captaining a team for one race! 

A stakeholder is anyone or group actively involved in a project. Teammates, race officials, volunteers.

The PMBOK guide identifies best practices, etc. Hello, this is your Ragnar Race Bible.

The level of the project management effort should be proportional to the size/scope of the project. Don't spend 10k and 6 months of full time planning on your team. Also: don't spend $10 and put it together in a week.

Initiating and Planning are the most important phases. Don't show up to a race (executing!) without proper planning. Bad bad bad things happen when you do that.

Lesson 2: Develop Project Charter Process

A formal project charter documents:
1) Preliminary characteristics of the project (team name! race date! race location!)
2) Authorizes the project (confirms team registration)
3) Identifies the project manager (team captain)

Your project charter is your first email to the team. It's a high level email with the preliminary, high level points of your team and race expectations. This is your wall of truth (you MUST be ready to go at 2pm on Thursday - do NOT make Saturday afternoon plans.) Now is the time to tell your team you expect a 7 minute mile. It shouldn't be too long - if you have to scroll too long on your phone to read the email, make it shorter.

Lesson 3: Identify the Stakeholders Process

Now is the time to identify your stakeholders: teammates, your volunteers (if you're within 100 miles of the course), the race director, and anyone else involved - yes, this includes spouses (the good and bad kind). 

Analyze each of your teammate's roles, interest, knowledge, expectation and influence.
For example:
Creative Person who has never done Ragnar, but has high expectations because they've been wanting to do Ragnar for years. They're bringing two other people to the team.
Role: Team designer! Make the shirts!
Interest: High
Knowledge: Low
Expectation: Figure this out fast - good time? Fast time? Something else?
Influence: High - you have a fourth of the team riding in their sphere of influence

Classify your stakeholders by level of authority, concern, involvement, and ability to affect change, salience, need for immediate attention, etc. Trust me. I've made the mistake of not doing this and it was disastrous. 11 other people is a LOT of cat herding.

In the PMP world, you'd make a Stakeholder register and a stakeholder management strategy. In Ragnar world - make a google doc with everyone's info and take the time to talk to each of your teammates individually about the above. 

Next up, we have the PLANNING Process Group!