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.

The ASPE Project Management Professional Boot Camp

Okay, I’ve decided to do it!  I’m attending the ASPE Project Management Professional (PMP)® Certification Exam Boot Camp in Denver, Colorado!  It is part of a twelve-city tour by ASPE, Inc. to educate and prepare would-be project managers for the PMP Exam.  Cool!

Wouldn’t it be neat to read the unbiased personal experiences of somebody who had been through the course before taking the plunge yourself?  That’s exactly what I’m offering in this series of blog posts.  You’ll get my unvarnished daily experiences of the entire PMP Prep seminar.  After reading them, you can decide if this is for you.  I expect to enjoy myself, so you probably will too.

I’ll be posting my personal experiences every day I attend.  You’ll get a firsthand look at the whole process: the course materials, the homework, the hardships, and the excitement along the way – everything one might expect when taking such a course to prepare for sitting the PMP exam hosted by PMI.  See links below to check out the ASPE course I’ll be taking.

Honestly at this point, I just have a sketchy view of the week ahead.  I sort-of know what to expect, but not exactly.  I’ve been doing project management for longer than I care to divulge, but have never taken the PMP exam, and never formally studied the disciplines of project management.  Of course, having worked in engineering shops since college, I know much of the terminology and probably apply the principles on a daily basis.  So I’m coming from a different perspective than those who may just be starting their careers.  Honestly, I wish I’d done this a long time ago, but it’s never too late to improve your career with training like this.

To prepare, I read through the ASPE PMP Boot Camp overview and course outline (see link below).  I learned that there are four very full days of coursework – from 8 AM to 6 PM.  (I’m expecting to drink from a fire hose.)  The course outline lists 68 topics grouped into 8 areas.  We’ll cover such lofty subjects as Project Management Overview, The Project Management Life Cycle, The Knowledge Areas, The Elements of Project Management, The PMP Exam, The PMP Certification, and The Credentials.

After finishing the course, they say 97% of ASPE students pass the PMP examination.  That’s reassuring.  It probably means I could too!

The cost is $2,395.  Honestly, I think that’s a small price to pay to advance your career.  I mean really… if you plan to spend any time around projects for next forty years, this is probably a good idea – it doesn’t matter what your role is.  You’ll certainly earn it all back, especially since it launches you on a fast-track to higher management positions.  And PMI claims a PMP certification it directly impacts your salary.  Who doesn’t want that?  This little-understood fact is a big deal for career advancement:  Get all the training you can handle.  And get it early in your career!

Helpful links:

http://www.aspe-sdlc.com/courses/pmp-boot-camp/

http://www.pmi.org/certification/project-management-professional-pmp.aspx

http://www.projectteamblog.com/?p=239

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.

Engineering Begins with Prototypes

I was talking with a senior software developer last week about the importance of early prototypes to define products. We concluded that it is pointless to begin developing any real architecture or engineering until the prototypes are finished and signed off. You must put your ideas into tangible form before you can trust them to the discipline of engineering. And customers must see examples of the finished product before you can move forward with deep development. Here’s why:

Under-the-hood engineering depends entirely on what you plan to sell. Notice I did not say what the developers thing might be cool or trendy. It’s what you plan to sell. Period. It doesn’t matter if you are selling transmissions or skyscrapers or operating systems; you have to know what the customer wants before you can build the most efficient version of that. Just try to dream it all up alone on a deserted island – without any input – without customers telling you what they will pay for and what they will not. That’s a lot like what you’d get if the developers in their Tommy Bahamas island shirts said, Oh, yeah! That’s so cool. Let’s make that!

Prototype Prototype

Take the automobile transmission for example. If you designed it on a deserted island, and sent the designs straight into production, the risks would be enormous. The finished product would likely have extra gears, “cool” new ideas, and “special” modes that the customer never asked for. And won’t pay for. All those extras make the product less efficient, more costly to manufacture, and more costly to maintain. You probably can’t afford that. Only the most efficient and cost effect designs survive. In other words, only what the customer asked for – nothing more.

Sure, you can get creative and throw in some extras. I call that “programmer candy.” The product doesn’t have to be a total bore. But make sure your core competencies are taken care of first.

 

Prototype

 

Also, it should be understood that prototypes can rarely be morphed into shipping products. (Managers don’t get that.) They are usually throw-away models, so expect to add that extra time to your overall project schedule. For instance, take the old clay automobile models as an extreme example. Remember them from the 1950’s? Even after sanded and painted, they still couldn’t serve as production automobiles. It’s almost humorous to imagine. But still, it has always been a strong desire in engineering circles to go from prototype to shipping product with the stroke of the pen. After all, the prototype looks so real, why not just clean it up and ship it! That’s what the manager usually ask for. Actually, that goal is not far off in computer-aided design, like software development, because editing is so easy. Not so with clay models.

YouTube Video: Consulting Software

This YouTube video for consulting software is pretty neat. It covers a lot of ground in five minutes, and is worth taking a look at. Amateur, but neat. The premise starts with a timesheet and closely related time log view where consulting hours are displayed. Of course, the timesheet is a typical Monday thru Friday grid with client projects on the left. Things got cooler with the time log ivew. The time log displays the same records as the time sheet, but in a top-to-bottom view.

Consultants will drool over this. Trust me.

For every time log record (which is also displayed in the timesheet) you get a client field, project, category, start and end times, actual work field, client rate, client cost, billable, and billed columns. There are other columns not shown that can be added to this view. Plus, you can filter that time log view to show only the work you did for a certain client or project, or only the work for a selected consultant. Or only work for a selected date range. That’s slick! You can also filter out the non-billable records and only see what is billable to the client.

But this is only where the app just begins…

The video goes on to show a glimpse of the billing rates window. (Wish it showed more.) It seems that you can set the billing rates for each consultant, and for each project they work on. So every consultant has his own rates for every project. And they only see the project they work on. Nice. But again, the video is brief, so you have to check this out for yourself – it’s just a five minute overview.

If time tracking is not enough, there is a menu item to show project revenue over a 12-month timeframe. This lets you see trends for the coming months and identify bad months that require attention. If only it also showed historical results for the last 12 months… That would be cool, but probably not as useful. Every project has its own win/loss percentage projections so it acts like a sales funnel. But all that’s a side issue that consulting companies get for free. Sure, you’ll use it, but the real stuff is logging billable hours.

The video sticks right to the point: client receivables and consultant utilization rates. That’s is the heart and soul of consulting. Get those wrong and you fail. So those reports let you see where your money is coming from, and what your effective billing rate really is. In other words, how much is your organization is billing for the work it does. Reports like this naturally raise the question, “How to increase your effective billing rate?” Edging out small increases is what consulting is all about. If you spend too much time on non-billable or in-house jobs, you die. If your effective billing rate is too low, you die. If you don’t book gigs, you die. If you don’t invoice billable hours, you die. This program seems to get that.

What is not mentioned in this video is equally valuable: expense tracking, client invoicing and QuickBooks integration. Yes, the product has those things, but the video fails to highlight them. Why? Not enough time, I suppose… I’m not sure. But it’s nice to know that there’s more to this product than the basics that can fit in a 5-minute video. Definitely worth a look.

Check it out: Consulting Software

That’s Where Experience Comes In

Recently, I overheard a senior project team member reminding a junior software developer to make sure his code built and could be checked in every day. He reminded the junior coder that we now have more coders on the project, and that leaving files checked out for multiple days put others in a difficult position. They could not get his changes until he checked it in, and long delays held up forward progress of the project.

That conversation got me thinking about all the little things you learn throughout the years. Here are some more to consider.
A few things experience has taught me:
• Check your code in often
• Don’t go dark for long periods of time
• Make yourself accessible
• Research everything you don’t know the meaning of
• Try new things
• Don’t get locked into legacy products
• Upgrade your development environment often
• Get a new development machine every three years
• Network with team members
• Answer every email you get, and in timely manner
• Get on Skype
• Blog often
• Re-read your emails before sending
• Let no bug survive
• Don’t be an obstruction to others
• Clear obstructions for those who work with you
• Take a vocabulary class
• Use good grammar and punctuation, not IM slang
• Decline unproductive meetings
• Produce a lot of code
• Design before you code
• Get peer feedback
• Learn to spell
• Work on communication skills
• Make a lot of friends

Got something to add? Become a contributor and add your comments below. I’d love to hear them!

Define: Fixed Duration, Fixed Units, Fixed Work

Fixed Duration: The task calendar ‘Duration’ will not change when you change the ‘Work’ or add resources.

Fixed Units: The resource percentage of work will not change when you change the task ‘Duration’ or ‘Work’ hours.
Fixed Work: The ‘Work’ hours will not change when you change the ‘Duration’ or percentage of resource work.

Double-click on a Microsoft Project task to display the dialog box below. The field we’re describing is highlighted below: ‘Task type’.

Task Properties

The default setting for ‘Task type’ is Fixed Units. That means the percentage of resource work (Example: “Buzz[50%]”) doesn’t change when you enter a new number for the work hours. For instance, if Buzz is set to work 50% of his time, changing the amount of work won’t change that. He will still work 50% of his time.

Changing the ‘Task type’ to Fixed Duration causes the Duration field to not change when you enter ‘Work’ hours.

Changing the ‘Task type’ to Fixed Work means that the Work field won’t change when you update the other two fields.

False Front Prototypes

When you watch the old Westerns like ‘3-10 To Yuma’ you are usually treated to a Main Street with old-time businesses and homes on it. Horse drawn wagons lumber by. Victorian dress is on full display. A child taps an iron barrel ring down the dusty street with a stick. There’s the obligatory livery station, bank, gunsmith and hardware store, and cobbler. They all sport a nice tall false front, as the turn of the Century buildings often did. It’s exactly like “real life” in 1880.

But what you don’t see is the backs of those buildings. The Hollywood cameraman never goes back there. Guess what? There’s nothing back there! The buildings are literally just false fronts. You couldn’t actually live in one of those houses or do business in one of those stores. Sure, there are a few sets where you see characters going into and out of those businesses, but those movie sets may be in a completely different sound stage. Nothing is as it seems; it’s all staged for the camera.

Got your attention? Now consider how this happens in engineering…

In engineering, we build prototypes to help people see what a finished product will look like. What people? Customers, potential investors, buyers, company executives, project stakeholders. Everyone needs an idea what a product will look like when the engineering is complete. It gets everyone on the same page, and dispels misunderstandings. Sure, the prototypes have a few warts. It can have reduced functionality, but it must *look* like the finished product, and must allow the sales force to tell the story and make the sale.

The problem with these prototypes is that they have almost none of the proper engineering – much like a Western movie set. Sure, they look good, and may even appear to work. For the purposes of a First Look, they satisfy everyone curiosity and need to see something tangible, and they get everyone thinking in the same vein. But they may not have any of the correct functionality! That fact alone leads to a false sense of completion.

Project managers, engineers, project stakeholders, and everyone alike can be lulled into a false belief that these systems are just a step away from completion. In actuality, they are like false front Western movie sets. You could never consider actually using them for everyday purposes. But after looking at them for an extended period of time, you come to a false belief that you could. You forget how far they are from reality.

It’s that “one step to final product” illusion that gets everyone into trouble — especially the engineers. They are the ones tasked with readying the product for release. Everyone around them believes the product is almost there – almost finished. But it’s not. The stakeholders have big money riding on a swift move from prototype to production. Customer expectations have been set, and they are waiting – sometimes not so patiently. Problem is, there is no swift move. The prototype must be thrown away and the “real” engineering begins. It’s like throwing away the Hollywood false front hardware store and building a real one. You can’t just build onto the false cardboard buildings. They have none of the real factors that go into a real building. Real hardware stores are expensive! And they take a long time to build! They are nothing like the quickie cardboard movie sets.

Overtime: The Devil’s In The Details

I keep running into the same old product development story: All the developers meet for a status update to compare with the project schedule (and this isn’t just a fault of project schedules… it happens with scrum stories as well) but the engineers are just a little behind schedule. Gee, what’s new? They all have just a few more tasks to complete their stories, just a few more details… And that goes on and on and on… It’s enough to shake my faith in project management methodologies. Not enough to shake my faith in the project team, just the narrow ruts we find ourselves channeled into. It’s the same old story. The program manger doesn’t have a full grasp of the detail that team members must face to complete their tasks. In fact, you can’t know that level of detail until you are the one doing the tasks. And sure enough, every one has 50 – 100% more detail than initially scheduled for. So… the schedule blown, and everybody is in trouble. And working overtime. Who made that up? Okay, I complete get that companies have to fight hard for an advantage. Overtime is a necessity just to survive sometimes. If you don’t do it, you shrink back into oblivion. So yes, overtime is good. But I’m not sure I like how it’s arrived upon. It’s always “our” fault because we haven’t completed our tasks, so there’s a mad scramble to complete the project on time. Overtime is never pitched as something good for the species. Or necessary for survival. Instead, it’s simply because we haven’t competed our tasks in a timely manner. Ooo, gosh.  I guess I’ve been complaining, huh?  🙂

Failure, ouch…

Failure is simply the opportunity to begin again, this time more intelligently.
    — Henry Ford

 

These are not from Henry:

Project failure is a luxury few can afford.  Multiple failures can bankrupt you.  See that they don’t…

It really is true that project failure is an opportunity to redesign and restart.  If you think about it… why do projects fail in the first place?  They fail because of some huge flaw that nobody recognized at the outset (or that the stakeholders ignored).

So starting over with those flaws corrected is what Henry is talking about.

There were 13 years of development leading up to the Model T.  (1896 – 1909)  There was another 18 years of development that lead up to the Model A.  (1909 – 1927)  That’s a lot of failure!

But think about it… it’s also a lot of success!

Task Lingering: Employees Avoid the Unfamiliar

Actually, not just employees… Everybody avoids the unfamiliar. But this post is about employees, and specifically project team members that engineer or develop new technologies. It’s about how employees sometimes try to settle into familiar tasks and avoid new and unfamiliar ones. And it’s about how to prevent that.

But wait… why prevent it? Isn’t efficiency gained by perfecting the familiar? By polishing your craft so you can perform it virtually without thought?

Yes, but this isn’t really about that. It’s about the propensity of employees to spend too much time on project tasks they have become familiar and comfortable with, to the exclusion of those upcoming tasks they dread the thought of.

I’ve heard reports of engineers racking up 200 – 500% extra time on tasks that could have been completed at the estimated time. Here’s the reason: people become comfortable with tasks they’ve spent significant time on and don’t want to leave them. The next task on their list may be unfamiliar and scary, so they stay on the one that doesn’t give off those vibes. The justification is that the current task could use some more polish.
Problem is, you’ve got to keep marching on. Your projects must be completed and delivered. You can’t afford to dally on project tasks you’ve already completed.

Here’s a technique you can use to discourage task lingerers. Set your timesheet “percent warning” to 75%. At that time, the task will begin reminding the employee that it’s time to move on. Of course, they may resist, but it’s a good reminder. Then set the “percent error” to go off at 125%. That stops team members from entering any more time. You can extend it with an administrator override, but at least you have some controls to monitor and manage task lingering.

Here’s a YouTube video that describes task lingering.