Posted on

Improve Task Estimates, Multiply by Pi

Trouble with poor task estimation?  Introducing the three-point estimating technique.  This might help.

Te = (To + 4Tm + Tp) / 6

Here’s the problem: engineers are never good at estimating task durations.  Not even close.  When asked how long their tasks will take, they usually just say, “They’ll be done when they’re done!”  As a project manager, you have to coerce an estimate out of them.  And then multiple by Pi for the real number.  But there may be a better way.  Read on for a possible solution.

Example:

                It’ll take about two and a half months.

                Multiple by Pi

                Result: eight months

First off, Engineers just don’t like estimating time.  They have technical issues to deal with, and are not practiced in the arts of time estimation.  They feel uncomfortable in fuzzy areas like this because they don’t spend any time thinking about such things.  The traffic in mathematical and logical conundrums, not project scheduling.  You might just as well ask them how much their tasks will cost, or how much the company will make from the product, once marketed.  It’s just not something they spend any time considering.  That means you have to take their task estimates with a grain of salt, or perhaps with a more scientific calculation.

What could be more scientific than multiplying them by Pi?  🙂

The three-point estimate technique below first appeared with PERT (Program Evaluation and Review Technique).  It has some merit when dealing with task durations, and might be more accurate than multiplying engineer estimates by some arbitrary number.

Start by taking this three-point estimate below from the engineer for each task.  You must get them to tell you the most likely duration for each task, which they will understate by a longshot… then you must try for an optimistic estimate, which they will assert is the same as the first estimate… then finally you have to get them to spit out a pessimistic duration, at which point they will argue is also the same as the first two, and that you are stupid for asking… now go away!  But if you can get these three numbers, you can plug them into the three-point estimate calculation below.

  • 1. Tm – Most Likely estimate (example: 6 months)
  • 2. To – Optimistic estimate (example: 4 months)
  • 3. Tp – Pessimistic estimate (example: 12 months)

With these three estimates, you can run a calculation to find the mean estimate.  (Find this calculation on page 150 of the PMBOK.)

                Te = (To + 4Tm + Tp) / 6

                Example: (4 + 4(6) + 12) / 6 = 8 months

The results are a good prediction of human estimations, assuming that most people under-judge the duration of most tasks.  They simply forget or don’t consider all the possible details in executing their assigned tasks.  This calculation makes up for that lack of detail.

Hope it works for you!

Posted on

Define: Resource Breakdown Structure (RBS)

Resource Breakdown Structure (RBS): A hierarchical listing of resources necessary to complete a project.

Project resources are commonly thought of human resources only.  In other words, only the people that will actually work on the project tasks.  But that is not necessarily the only type of resource list that can be compiled.  In fact, the RBS can include both human resources and physical resources, like computers, software programs, timesheets, tools, instruments, automobiles, or even special clothing.

As seen below, the hierarchy is entirely project defined.  Any leveling applicable to the project can be used.  Examples might be organizational chart, or tool type, or physical location, or even sequencing by use.  Any useful project breakdown is appropriate.

Traditionally, only non-expendable resources are included.  Expendable items such as water and gasoline would not be listed.  These would fall into the category of supplies rather than resources.

Example of hierarchies of resources:

1. Engineering
  1.1 Rob
                2.2 Ted
                1.3 Software
                                1.3.1 Bill
                                1.3.2 Joe
                                1.3.3 Standard Time® Timesheet (timesheet and project tracking software)
                                1.3.4 Microsoft Project (project scheduling)
                                1.3.5 SQL Server (database)
                1.4 Hardware
                                1.4.1 Alice
                                1.4.2 Jill
                                1.4.3 Test Stand A
                                                1.4.3.1 Computer
                                                1.4.3.2 Wiring harness
                                1.4.4 Test Stand B
                                                1.4.4.1 Computer
                                                1.4.4.2 Wiring harness
 

The example above includes both human and inanimate physical resources, like software and test instruments.

Notice the numbering nomenclature.  The hierarchical list is numbered, with each indented layer adding another level to the numerical label.  Examples: 1.3, 1.3.1.  This makes each resource uniquely identifiable by numerical label.

Posted on

How Buggy is your Product?

Want a really slick way to find out how buggy and nasty your product is? Buggy? Who wants to know that? We want good products, not buggy ones. Well, this method will help you get there. It’s a way to find out how many bugs there are still in your software when you release it.
Let’s face it, all products have bugs. Even fully released and supported ones. But managing the number of bugs at launch time is a good thing. Release too many, and you’re dead. Tech Support will hate you; your CFO will hate you, and worst of all, your customers will hate you. So clean things up, buster!

Here’s how you do it:

Let’s first start by supposing that you have a QA department testing your product prior to release. They test the documented and “undocumented” features of the product, record and report the bugs, then retest when engineers fix them. Hopefully, the product becomes more robust as the release date approaches. Less and less bugs are found. But we all know the product will ship with some known and unknown bugs. You just can find them all, and you can’t always fix the ones you find. But the process is good, and it’s working fine.

So, what if you intentionally slipped some known bugs into the product, hoping the QA department would find them? If you did, you’d know they were doing their jobs. After all, that’s what they are paid to do. So for instance, if you were receiving 1,000 bugs per week from the QA department, and you slipped 100 new bugs into it, you would hope to get 1,100 bugs the next week. You would know the Quality Assurance department was catching 100% of the bugs in the product.

But what if the QA department only found 70 of your artificially injected bugs? I.e. the ones you inserted just to test the percentage of bug found. If only 70 of the inserted bugs came out, that would tell you that their efficiency rate is about 70%. Given that they find 1,000 bugs per month, you might suspect there are actually 1,428 in the system. Why? Because they only found 70% of your artificial bugs, so what makes you think they are finding 100% of the others? Probably not, but that’s okay; nobody’s perfect. If they are 70% efficient, then 1,428 x 70% = 1,000.

Using this method, as your bug rate approaches zero, you’ll know about how many uncaught bugs remain.
Posted on

Closer to the Source

The sooner employees record actual hours worked, the more accurate they will be.  Some companies require team members to record their project hours.  Sometimes this is for client billing, other times for engineering or manufacturing projects.  Whatever the reason, I’ve seen firsthand that recoding hours soon after the actual event ensures accuracy.

Most people cannot remember what they did last week.  So if asked to fill in their timesheet for last week, they will not be able to pick out individual tasks.  Sure, they remember which projects they worked on, unless there are more than two.  But they cannot reliably remember which tasks.  It gets impossible when asked to assign actual hours to those tasks.  That is the primary reason DCAA (Defense Contract Audit Agency) requires timekeeping every day.  Even filling out timesheets at the end of the week is against the rules.  I don’t normally like government agencies, but in this case there is truth to their overbearing policies.

Standard Time® is an example of a professional timesheet with a built-in timer.  The image below illustrates the Quick Task window.  A link to a video is also included.

Prototype

Standard Time® Quick Tasks

In the Standard Time Quick Task window, you simple click project tasks to start and stop the timer.  Time log records are automatically entered into the timesheet.  That solves the problem of entering hours after the work is finished.  Actual work is sent directly to the timesheet; there is no delay.  And since you are clicking the checkbox to start and stop a timer, the actual work is as accurate as it could possibly be.

Most companies do not require minute-by-minute accuracy, unless you are charging them for time worked.  Only consulting companies really need this level of granularity.  For them, it’s much easier to justify invoices when the time accounting accuracy is beyond impeachment.  Simply print out the actual time log report (with records down to the second) and there is no disputing the accuracy.  Of course you can still milk the clock, but consultants are rarely accused of that.  But still most manufacturing companies that track projects for earned value purposes don’t need timer accuracy.

Whether your company needs timer accuracy, daily accuracy, weekly, or monthly, tracking time is almost always a good thing.  There is so much value in knowing how much time projects take.  Consider a few good reasons: comparing estimates to actuals, estimating future projects, assigning cost and estimates to new activities, or even know what employees are up to – all good things!

�

Posted on

When to Re-baseline Your Project

Baselining is the act of recording your original project estimates so you can compare them to actual results at a later time.  It is also the platform from which the project is conducted.  In other words, the baseline contains schedule and cost numbers used by the project team throughout the entire process.  By baselining the project, you are laying the foundation on which the project will rise.  That’s a nice thing to have.  Employees want a good solid plan that doesn’t wander from whim to social whim.  They want a visible goal that isn’t ducking and weaving out of sight every week.  Such a goal offers reassurance and confidence for success.  A moving target is the worst motivation killer known to man.

But sometimes you just need to start over.

Yes, a moving target is a sure killer.  But there are times when the baseline is just crap.  The schedule has become irrelevant, costs are laughable, and the project team is floundering in a sea of mud.  Nothing is going as planned.  Designers are throwing in new requirements that were heretofore unheard of.  Executives are MIA.  And managers have you working 80 hour weeks to hit a target they have no clue of the purpose of.  Nobody’s admitting they’re stupid, but it’s obvious everybody is.  It’s only years later that everyone can look back and shake their heads at the calamity.  But while you’re in the midst of it, you just keep buggering on.

It is those times that executives, or maybe a strong-willed project manager needs to step in and call a hiatus.  But who’s got the guts for that.  Again, you’ve got to be a strong person to blow the whistle and wave your arms.  But if you can recognize the signals, a re-baselining during a mess like this may be your only option.

I was on a two-year software death-march like this.  It was a disaster.  Nobody knew the warning signs.  Nobody blew the whistle.  Nobody re-baselined.  The product failed six months after release, which was at that time a year overdue and marketplace irrelevant.  It was the worst project I was ever on.

Here is a good rule of thumb for knowing when to rebaseline:

Baseline the project if you have missed over half your scheduled targets in the last six months.

Have you missed a few end-to-end tests?  Missed a customer drop or two?  How about a major milestone?  Missed a target feature?  These are the warning signs.  Again, if you have missed over half your targets in the last six months, rebaseline.  Don’t try to figure it out, just baseline the project again.

In fact, in cases like that above I would suggest cutting the scope in half.  Cut the project into smaller phases.  Get the schedule down to visible goals.  And if anybody disputes them, cut them again.  And then again.  You must have realistic goals or you will fail every time.

�

Posted on

Earned Value: 50% Fiction and 50% Fact

In project management, there is a term named “Earned Value.”  It prevents the value your project has actually earned based on its current state of completion.  The graphics below help describe this.

A close relative to Earned Value is Planned Value.  It is the monetary value the project should have generated at any point in its state of completion.  Ideally, Earned Value and Planned Value should be identical.

And another close relative is Actual Cost.  It is the cost the project has incurred at its current state of completion.  When Earned Value and Planned Value and Actual Cost are all equal, the planets have aligned!  But when they are not, we have discrepancies which we’ll explore below.  That may help explain the post title: “Earned Value: 50% Fiction and 50% Fact”.

The 50% fiction is Planned Value.  The 50% fact is Actual Cost.  Earned Value is somewhere in the middle.

Prototype

 

Here is an example of a discrepancy between Earned Value, Planned Value, and Actual Cost.  The Earned Value is much less than we expected, and the Actual Cost is much more.

Prototype

 

In this example, we see Earned Value at $30,000, but it should be $40,000.  We also see the actual costs on the project to be $45,000.  It turns out there are calculations to help normalize and judge the value of these numbers.  This let you compare the numbers with other projects to see how close you have come to historical numbers.  If you miss the Planned Value mark, the difference is called a variance.  Variance simply means you varied from your target by some amount.  There is a schedule variance and cost variance.  Of course ideally, we want these to be zero.

Schedule Variance (SV) is Earned Value minus Planed Value.  Cost Variance is Earned Value minus Actual Cost.  The equation is below.

SV = EV – PV  ($30,000 – $40,000 = -$10,000)

CV = EV – AC  ($30,000 – $45,000 = -$15,000)

In addition to variance, you can view the discrepancies in terms of ratios.  They are actually more helpful to compare with other projects because they normalize all the numbers to a single comparable performance value.

The Cost Performance Index is the ratio of Earned Value to Actual Cost.  The Schedule Performance Index is the ratio of Earned Value to Planned Value.

CPI = EV / AC  ($30,000 / $45,000 = .67)

SPI = EV / PV  ($30,000 / $40,000 = .75)

Any Cost Performance Index number over 1 is over budget.  Any Schedule Performance Index over 1 is “over schedule.”  See how these performance numbers could be helpful?

In this case, the Cost Performance Index is 67% efficient.  In other words, the project made 67 cents for every dollar expected.  That’s not good.  But maybe the next project will be better!

 

 

�

Posted on

ASPE PMP Boot Camp Day 4 (Last Day)

It’s Thursday afternoon, and I’ve finished the Project Management Professional (PMP)® Certification Exam Boot Camp hosted by Dave Caccamo at ASPE and I’ve decided that it’s not a real Boot Camp because we didn’t fire any guns.  I blame ASPE for the misleading title.  🙂 

So aside from that little misunderstanding, I’d definitely go with the Boot Camp title – this is hardcore!  If you like hardcore, get in on this course.  If you don’t, maybe you can pass the PMI PMP Certification Exam on your own.  Good luck with that!

Actually, I thought of doing that very thing about two years ago.  I researched the PMI PMP exam, and strongly considered signing up for it.  I figured I knew enough about project management to pass.  Heck, it was probably just a bunch of terminology and best practices, right?  I knew that stuff and figured I could pass.  Now after taking this course, that idea seems so laughable.  I probably would have had about a 1% chance of having my application accepted, let alone passing the exam.  There is so much I didn’t realize about PMI and their PMP exam and their expectations of project managers.

This course enlightened me considerably.

We spent the last day finishing up the 42 PMI project management processes.  That included those from the Executing, Monitor and Control, and Closing process groups.  This is where the Initiating and Planning processes are performed.  After finishing those, we took a final test quiz and finished out the course.  Anyone with a low 70’s grade on the final quiz should feel comfortable moving forward with the PMP exam after a reasonable study period.  So I guess I’m good.

I have to say, even though we stuck closely to the PMI processes, this classroom offered a perfect setting for a wide range of project management topics.  It wasn’t all PMI Process Heaven.  All the methodologies  came out eventually, with comparisons to PMI – the good, the bad, and the ugly – and how real-world PM’s get things done.  So felt I grew a little outside the sanctioned course material.

One thing to stress is that you cannot come riding into this course on your high horse.  Don’t think you are going teach everyone how wise you are in the world of project management.  Get ready to submit yourself to the PMI method, even if you disagree with it.  There just isn’t time to argue platitudes.  You’ll miss the whole point, and likely ruin your chances of passing the exam.  Stick to the subject matter and you’ll be farther ahead.

I hope you have enjoyed the series.  I offer my sincere apologies to those in the PMI world for oversimplifying, misunderstanding, and perhaps misrepresenting the material.  Again, this was my personal experience of going through the PMP Certification Exam Boot Camp.  You’re seeing it through my limited experience level – a complete novice to PMI and the PMP exam.  Your mileage may vary.

 

 

My Notes on Day 4 of PMP Boot Camp:

Focus on being able to write out PMBOK matrix in its entirety.

Practice PMP cert exam write-ups.  Make sure you have some experience for every process group, even if it’s light or it may not be accepted.  Must use some PMI buzzwords, but not an obvious list from page 43 of PMBOK.  Go into some detail in one or more areas, a success.  No technical details, no technical lead.  All details should be PM related.  Connect PMI processes to show project success.  If you were a team member without a formal PM title, you’ll have to come up with something related – descriptive rather than formal titles.  How you integrated processes, management deliverables.  You can still get away with a “Project Task Manager” title.

Send your PMI write-up to Dave Caccamo at ASPE before submitting.  He can tell whether it will be accepted.

Use the patterns for learning process inputs and outputs.  At this point, I know I should be doing this, but haven’t memorized the patterns, so I forget them.  I suppose I didn’t know the significance of the patterns early enough.  Pretty important, or else you have to memorize all inputs and outputs without a framework of logic.  PMI doesn’t like simplified pattern style of learning.

A spaghetti factory is what you get if you try to show flowcharted rubber band connections between all the inputs and outputs.  It’s just too complex to draw out.

Turn brain cells over to PMI.

Read PMBOK for Monitoring and Controlling (and Closing) Process Group.  Closing Process Group questions may be tricky and picky.

PMP cert pass rate is about 70%, and the average score is 72%, but PMI doesn’t publish this info.

Get the “Random Thoughts on the PMI Exam” document from Dave Caccamo.  Answers a lot of questions.

After drawing the matrix every day (before exam), name one major output to help key you during the test.

 

Links to previous ASPE PMP Boot Camp posts

 

Disclaimer: The thoughts and feedback for the ASPE PMP Certification Exam Boot Camp associated with this series of posts are my own. In exchange for providing my feedback on this community forum, ASPE has provided benefits related to my course attendance.

Posted on

ASPE PMP Boot Camp Day 3

At what point during an intense technical seminar do people start to weary and tune out?  For me, that point almost came at the last hour of Day 3.  As you know from my previous posts, I’m taking the Project Management Professional (PMP)® Certification Exam Boot Camp offered by ASPE SDLC Training.  I got a direct mail piece one day, and just signed up.  So here I am in Denver, taking the class.  These are my personal experiences.

Okay… so I’ve lasted one hour shy of three days.  All is well… I’m challenged… I’m getting it… I’m filling the notepad… but I’m starting to notice a peculiar feeling not hitherto experienced… exhaustion.  Probably from burning the candle at both ends and sitting a pretty intense course.  So I guess I’ll tune out, right?  Slack off on the notes, let a few minutes of lecture gently ease over my head while I fake the Active Listening feedback.  Sure, I could have done that.

But then came along Earned Value Analysis!

Bing!  I woke right up!  The next hour (and last one of the day) flew by like the very first ones had on Monday morning.  Discussions of Earned Value and Planned Value and Actual Cost drove cobwebs from my weary brain.  Then there were formulas for Cost Variance and Schedule Variance, and then Cost Performance Index and Schedule Performance Index, and further discussions of how SPI is only a defining value when taken from the Critical Path killed off the hour.  (You gotta be a geek.)

Lesson learned: you have got to come into this class with some real interest in the project management process.  Pick a topic: Scope?  Time and Cost?  QA or QC?  How about Human Resources or Communications?  Procurement?  Pick one.  Because without some natural interest, and some serious geekology (the study of geeks), you might not survive this Boot Camp.  That’s what I realized today.  I really like some of this stuff!  Although I’m not sure why.  But when certain topics come up, my heart leaps and I drill in extra hard for all the good stuff.  I can honestly say, this course did not disappoint the geek within.  Even on the last hour of the third day (there’s one more Day to go), Dave Caccamo did not slack up.  Earned Value came forth with the same enthusiasm as Developing Project Charters and Identifying Stakeholders had on Day 1.  That was a surprise.  You would think he’d run out of steam like I had.  Nope, not Dave.

Okay, changing subjects… I really get the feeling that PMI wants to weed out the deadbeats.  A good portion of this course was raising the awareness of the heights to which PMI will go to trick exam-takers and would-be PMP’ers.  If you don’t live for this stuff, they want you gone.  The novice who has never taken a course like this would never know that… until they bombed the exam four times.  I now know about twenty ways PMI could trip me up.  Maybe that will help when sitting the exam.  Hope so.

One more thing: I would have liked one improvement.  I would somehow like to see special significance given to process inputs and outputs.  After Day 3, I realized that from the dozens of processes, lists, phrases, formulas, and methods you read through, the process inputs and outputs seem to all blend in.  You have to manually pick them out of the soup.  I found it difficult to elevate them to a higher status that would help me instantly identify even though they were clearly listed on the slides.  In other words, they didn’t stand out from the minutia.  I know that sounds dumb, because there they were on the slides and flash cards.  But it seemed like as we zoomed through the material, one list had equal standing with the next, and only by applied effort was I able to elevate the process inputs and outputs to the level they deserved for memorization.  After all, you can’t memorize everything.  You have to prioritize, and process inputs, outputs, tools, and techniques were the likely choice for me.  I don’t have any suggestions for improvement; I’m just griping.  I can do that, right?

So, there’s one more day left…  I’m excited to complete this, but I’m also weary.  Will I survive?  Yeah, I think so.  Will I tune out?  Probably not, but you never know.  But I know this will certainly stand out as a career highlight for me.  I’ve gotten more knowledge in these few days than several years’ worth.

Check out ASPE.  Great organization.

 

My Notes Taken on Day 3:

There are some useful “PMI thinks” rules that dictate input and outputs.  Remember these rules and you can predict the inputs to any process.  Dave Caccamo has developed these rules.  Get from him.

There are so many trick questions that you can’t list them.  Very numerous.  Plus, all the wrong answers will be common things people think of based on the trick terminology.  The subject material is hard enough without these shenanigans; tricks just put it over the top.

There are 50 “pretest” questions mixed into the test.  You won’t know which questions count toward the results and which don’t.  Pretest questions don’t count.  They are used by PMI to decide if the question will eventually be put into the real questions.

Drink the Kool-Aid.

I found it difficult to remember where each process input was produced.  Which process produced it?  Sometimes they abstracted by other process outputs.  Outputs do not always go directly to inputs.  I would like to see a computer rubber band model that traced inputs to the processes that created them.

By now memorization should be giving way to logic.  Inputs should be predictable.  Problem is, there’s so much information that needle-sized outputs are hard to pick out of the haystack.  Actually, I’m not even sure if all inputs are outputs of other processes.  Maybe some are from external sources.

Fog of war.

I admire people who hold forth well beyond my comfort level.  How do they do that?

Links to previous ASPE PMP Boot Camp posts

 

Disclaimer: The thoughts and feedback for the ASPE PMP Certification Exam Boot Camp associated with this series of posts are my own. In exchange for providing my feedback on this community forum, ASPE has provided benefits related to my course attendance.

Posted on

ASPE PMP Boot Camp Day 2

It became clear on Day2 of the ASPE PMP Boot Camp that the PMI world revolves around page 43 of the PMBOK.  Just as I suspected.

If you’re still reading, you may be following my personal experiences of the ASPE PMP Boot Camp class in Denver, Colorado.  I’m taking the training course for the purposes of sitting the PMI PMP exam, but I’m also sharing my thoughts along the way.  Hopefully, this will help others who journey down this road.  Just exactly what does this course cover?  How much does it cost?  What requirements does it expect of the students?  And how will you personally feel when going through it?  Those are the topics explored in this series.  This is Day 2, so scroll down for earlier posts to catch the dialogue.

So… back to my premise… PMBOK page 43 is King!  What’s on page 43 again?  Page 43 of the PMBOK is the grid of Project Management Process Groups and Knowledge Areas.  In other words, the processes that PMI project managers use to initiate, plan, execute, monitor, control, and close a project.  When taking this PMP Boot Camp seminar, you will spend all four days examining page 43 from a hundred different angles, yeah a thousand angles.  Everything you study comes back to it, so make sure you study it well.  Memorize it early.  Forward and backward.  Be able to write it out upon demand.  In fact, you are allowed to do just that within the first ten minutes of the PMP exam to use as a cheat sheet.

The ASPE instructor handed out 50 flash cards, which I found very handy for quick study.  You’ll use them to name the 42 PMI processes, each having inputs, outputs, tools, and techniques.  You must memorize every word of this or risk exam failure.  And don’t try to write these out during class because you’ll miss too much of the lecture.  Do it the night before.  Unfortunately, understanding the general flow of processes is not enough for success.  There are simply too many unfamiliar terms to mentally juggle.  You’ll have to memorize too.

Make no mistake about it, this class is a Boot Camp just like its name says.  Marine Corps Boot Camp.  As I stated in my Day 1 post, this is very, very intense.  The 42 PMI processes are just the beginning.  As I said earlier, each one has inputs, outputs, tools, and techniques you must understand and memorize.  But it doesn’t end there!  Each one of those has a tidy list of 2 – 10 items encapsulated within: project documents, breakdowns, formulas, methods, theories, plans, etc.  Want to count the cost?  Multiply processes times your list of inputs, outputs, tools, and techniques, and again times those encapsulated lists and you’ve got thousands of pieces of information at your fingertips.  You’ll literally be hit with scores each day.  And you’ll be expected to recall them from memory for the exam.

This course will tax every resource you can muster, most notably: time.  Don’t expect to have any kind of real life for these four days.  Remember, this is Boot Camp not play time!

Okay, that’s probably enough about the hardships.  Further posts likely won’t even mention that aspect unless I suffer a complete nervous breakdown and am dying to tell you about it.  Instead, I’ll focus on other aspects of the course.  But I wanted you to get the full picture of what you might experience in taking this course.  It’s a doozie!

Are the hardships worth it?  Of course!  Gosh, it’s only four days.  Anyone can survive that.  So don’t let this discourage you.  Sure it’s hard but survivable.  Just remember, anything worthwhile is hard, or at least seems that way when you’re in the middle of it.  Later, you’ll look back and realize it wasn’t all that bad.  So stick with it and you’ll be glad you did!

You should also know that the Boot Camp course it not the end of your journey to the PMP exam.  After this four days of classroom instruction, you should expect to 2-3 weeks in the ASPE Study Guide and PMBOK.  Make sure to factor that into your near-term plans.

Plan to love the PMI methodology, at least for the duration of this undertaking.  I mean love it!  Dig in like a toothless redneck at a pie eating contest.  Focus all your attentions on the PMI way of doing things.  There’s a reason I say this; it’s a subtle but important one…  If you get the notion in your head that this methodology doesn’t work for you, or can’t be justified in real life, or won’t work for your company, or any other reason to hate it, you will not have the fortitude to continue.  You must (at least temporarily) set aside your personal beliefs and love this PMI approach like it’s you own.  Imagine yourself as a highly paid PMI project manager at the top of a Fortune 100 company, or whatever it takes.  Just love this stuff for a season.

During all this, I have gotten a renewed respect I got for the ASPE instructor, Dave Caccamo.  Not only did he write the 850 page Participant Manual and Slide Guide, but delivers it with flawless execution.  That’s no trivial occupation.  Pray you get this guy.  Seriously.  He’s good.

Okay, that’s it for today.  I’ve got 20 flash cards to write up, 43 processes to memorize, and five formulas to refresh my memory on.  I hope you’re enjoying the series.  Click the “About” page link to let me know what you think!

 

My Notes From Day 2:

Start right out writing out the Project Management Process Groups and Knowledge Areas Mapping matrix on page 43 of PMBOK.  Write out matrix in shorthand and put X’s where there is a process.  9 x 5 grid, 26 processes.

Flash cards came in real handy because we went over all the planning processes.  Inputs and outputs were on the cards, and very handy to refer to in class.  Write these out the night before!  If you don’t, you can get lost in the pace.  There are 42 processes.  Must know all inputs and outputs.  Instructor spends most time on Day 2 explaining inputs and outputs.

But flash cards only cover some of what you’ll cover.  There are deep discussions of tools and techniques that are not on the cards.  Much of that has to be studied and memorized as well.

Inputs and outputs of processes are so numerous and unfamiliar that memorization seems like the only way to get them.  They are natural and logical, but just too numerous to mentally juggle.  That means a huge amount of study.

Memorization is destroyed by adrenalin

There were a fair number of descriptions of the sneaky ways PMP questions can be posed.  PMI will sneak in adjacent inputs or tools and techniques to trick you into a wrong answer.

There were several discussions amongst students about when they could take the PMP exam.  Wait too long and forget everything.  Try to take it too soon and risk not studying enough.  Plus, there’s work  and personal schedules to account for.  Bottom line: this is a big commitment with a fair amount of risk.

Quick recall is the premium skill for this course.

Links to previous ASPE PMP Boot Camp posts

 

Disclaimer: The thoughts and feedback for the ASPE PMP Certification Exam Boot Camp associated with this series of posts are my own. In exchange for providing my feedback on this community forum, ASPE has provided benefits related to my course attendance.

Posted on

ASPE PMP Boot Camp Day 1

“Intense” is the operative word for the ASPE PMP Boot Camp Day 1.  Or maybe “panic!”  Actually, I never reached a full state of panic.  Maybe “bracing concern” is a more accurate description.

Remember in yesterday’s post here, I agreed to share my experiences in the 4-day ASPE PMP Boot Camp.  So here it is!  Day 1.  Don’t get scared!

The first thing you should know  about this course, which I gradually discovered about 1 – 2 hours into it, is that it is not a general purpose project management course.  It is not a Cliff Notes of the Project Management Body of Knowledge (PMBOK)® guide.  You are not coming here to learn all the latest theories on how to make successful projects, on how to manage a project team, on the correct way to manage projects.  You are here to learn PMI’s way to do things.  You are here to learn the PMI terminology and process.  And more specifically, here to learn how to pass the PMP exam.

Throw away everything you think you know about project management.  It will not help for the next four days.  In fact, it may hurt you.  Again, you are here to do it the PMI way.  Anything else will only hinder that singular goal: learn PMBOK so you can pass the PMP exam.

As you may have read from my first post, I was unsure what to expect when I signed up for this.  Would I get a foundational course in project management including all the terms and philosophies?  Would it be a crash course in all the techniques for successful project execution?  I wasn’t entirely sure.  But that all became clear within the first few hours.  No!  This course is focused almost entirely on getting a person up to speed with PMI’s PMBOK, which is the basis for the PMP exam.

Another thing became clear within the first few hours of the ASPE course; you cannot cram the entire PMBOK in to 35 hours of instruction.  Even if you turn it sideways!  On Day 1, I’m left wondering if you can even survey it in that amount of time.  So what is your best use of four days in the classroom?  I guess, hit the highlights, and point students to the places where they can study for the test.  Sure, there’s more to it than that, but that is certainly a major component of this class.  You get that right away.  The ASPE instructor’s number one goal is your success in sitting the PMP exam.  I certainly give the instructor high marks for a good mix of humor, depth of personal knowledge, and the ability to deliver a large amount of information in short bursts.  Kudos to ASPE!  These guys are good.

After the first day, you sort-of feel it’s possible to pass the PMP exam.  But only after dozens more hours of study.  I expect to get a good start for that in the classroom, but don’t expect to be able to run right out and sit the exam the next week.  There’s just too much information to absorb.  After all, the PMBOK is almost 500 pages!

It has become acutely obvious that a huge amount of memorization is necessary to pass this test.  The class professor understands this and points that out on Day 1, which brings on a strong feeling of panic, which they say gives way to resign on Day 2, and then to confidence on Day 3 and 4.  The full scope of memorization just isn’t clear on Day 1, and you look at that huge PMBOK that could choke a horse, and you’re not sure if you can pass or not.  It just requires dedication, they say.

So after posting this tonight, I’ll hit the books.  I’ve got to fill out a series of flash cards and then memorize the “Project Management Process Groups and Knowledge Areas Mapping” grid on page 43 of the PMBOK.  After that, I’ll read through the 190 pages of the “ASPE Participant Manual/Slide Guide that we covered today.”  Of course, I’ll do most of that during the boring 2-hour meeting I have to attend tonight.  Then maybe I can sleep!

 

My Notes for Day 1 of ASPE PMP Boot Camp Seminar:

Course Instructor: Dave Caccamo, M.Econ, PMP, CSM, Network+
35 hours of instruction

PMP Exam: 175 questions, 4 hours, passing grade: 61% or 106 correct answers, before exam 20% of applicants will be audited for further certification

20% of questions will not be in PMBOK.  Look at 1,000 questions before taking test.  ASPE goes over about 500 questions.

While studying: keep a sheet of paper that you fill out for every question you miss that contains “the one piece of knowledge” that would have helped you get the questions right.

Don’t expect to cram during the prep course and then pass the exam immediately after.  Take it as soon as possible, but you must study.  15 – 25 hours of extra study and memorization are necessary.  Don’t read the PMBOK before exam.  Much of it won’t apply.  You must already be a good project manager to pass the PMP exam.  Memorization is not enough.

PMI asks questions like no one else.  Evil questions.  Think like PMI, not necessarily how things work for you in practice.  Questions are always according to PMI lists, not personal experience.  Trick questions will include fake answers from real-world.  Use PMBOK answers instead. Don’t get into the mindset teaching PMI the “right way” to do project management.  Tricky and picky.

There is a ten-minute period just before the exam where you can write down anything you want.  You can use that as a cheap sheet.  You cannot bring in anything.  They will give you pencil and paper.

PMBOK pg. 43: Table of Process Groups verses Knowledge Areas, memorize this page!

Study following the class:
First 3 days after 4-day class: Daily warm-up: write out matrix, study cards
For 10 days: read study guide chapters for ten days
Last 3-4 days: Online assessment, 2 closing processes, read appendix G to see buzzwords, read domain tasks directives

Memorize:

  • PMBOK Page 43
  • 16 Formulas
  • Inputs and outputs

 

Course materials:

  • 1. The Project Management Professional (PMP)® Certification Exam Boot Camp 3-ring binder, 846 pages
  • 2. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Fourth Edition, 467 pages
  • 3. Flash cards, part of study guide, quick reference
  • 4. The Complete Project management Professional (PMP 4.0)® Study Guide, 332 pages (for use after the class is finished for study and memorization for the exam)

Links to previous ASPE PMP Boot Camp posts

 

Disclaimer: The thoughts and feedback for the ASPE PMP Certification Exam Boot Camp associated with this series of posts are my own. In exchange for providing my feedback on this community forum, ASPE has provided benefits related to my course attendance.