(UPDATED: 09/2019) PMP Application - How to Make it Not Suck!
Aspiring PM’s are blown away when I share these two unknown tips with them

You excitedly submit your application for the PMP.  Then…you are chosen for an audit.

Damn it.

I was one of the “lucky” ones who didn’t get audited. I’d like to think it had a bit to do with luck, research and some preparation.

While I cant help with the luck part (no winner – winner chicken dinner here), I can bestow upon you the research, tips and tricks that helped me get the approval to sit for the exam.

Aside from meeting the experience and timing requirements (which I won’t get into here, but you can read about here and here), aspiring PM’s are blown away when I share these two unknown tips with them.

Ready for it?

In an effort to document my experience and the experience of others, I have talked to quite a few folks and stumbled across online forums where PMP aspirants have discussed their experience with the application audit.

What did I discover?  There was a clear pattern. These applications lacked good project descriptions and did not align to the PMI/PMBOK way.

Take for instance this redditor:
Or this one:

They both talk about their experiences and how they come up short when it came to writing good project descriptions. Since this was a topic I had researched thoroughly before completing my application, I didn’t make those same mistakes and I’m here to help you avoid making them too.

Disclaimer: Since I took the exam in November 2017, some of the application requirements have been updated. What I did notice is that  PMI gives better tips for completing the application.  The two minor differences I read, is that PMI wants the description to include an outcome of the project and accepts abbreviations such as Initiation, “IN.”   This will save on character count for the description. More on that shortly.

Lets jump in!

Project Description
Length, Structure & Content

The description has to be clear and concise, and be 550 characters, NOT words, to hit the nail on the head. If you have a tendency to be a detailed writer, or are…well, verbose… now isn’t the time. The application will not allow you to submit until you can write a project description that is <550 characters for all eligible projects.

But that’s not it.

PMI does not understand your project lingo at work, so avoid it. Write PMI/PMBOK using the guide below:

  • A brief, one-sentence project objective
  • Project deliverables summarized by process areas (Initiating, Planning, Executing, Monitoring and Controlling, and Closing – abbreviations are acceptable IN, PL, EX, MC & CL)
  • A brief, one-sentence project outcome

So about 6-7ish sentences.

How about some examples?

I have compiled three examples of answers that I have used successfully through PMI’s application screening. Take a look below:

Example 1:

Objectives: Move business functions to a SaaS platform, which included setup & implementation of data integrations and modules.

IN: A project assessment was completed

PL: Developed comprehensive project, risks, communication and training plans 

EX: Delivery of tasks in per the approved plans 

MC: Changes to scope, schedule or budget were addressed with the project leaders in progress meetings 

CL: Final acceptance of deliverables than lessons learned were discussed.     

Outcome: Project schedule was re baselined and delivered on time.  

Example 2:

Objectives: Transition customer to an online certification process system

IN: A meeting was held to identify key stakeholders for the roll out 

PL: Project plans were created to outline high level and detailed work packages 

EX: Progress meetings were held weekly with the project team and as needed with stakeholders 

MC: The performance was monitored daily to ensure all aspects of the plan were on track 

CL: Following completion of the system, acceptable of deliverables were obtained.   

Outcome: Project was delivered on time 

Example 3:

Objectives: Implement electronic compliance system using the hired subcontractor.

IN: Assigned to lead customer transition to an electronic contract monitoring system 

PL: Outlined the scope and work assignments in a meeting with the team and subcontractor 

EX: Work performed based on deliverables/ work packages in the plan. 

MC: Time sheets were monitored and checked weekly to keep the resource budget on track. 

CL: A closeout meeting was held with all stakeholders.     

Outcome: Project was placed on hold by client 

Now it's your turn!
Use my templated terms below for your application to align best with the examples above. Here’s a list to get you started:

Initiating:

  • Develop project charter
  • Identify risks, assumptions and constraints
  • Identify stakeholders
  • Define high-level scope
  • Perform project assessment

Planning:

  • Present project plan to stakeholders
  • Develop WBS
  • Collect requirements
  • Define scope
  • Prepare project schedule, budget, and other management plans

Executing:

  • Communicate with stakeholders
  • Implement approved changes
  • Manage project team
  • Execute tasks defined in the project plan
  • Obtain and manage resources

Monitoring & Controlling:

  • Assess results of corrective action
  • Monitor & control risks
  • Ensure quality standards are met
  • Manage changes to scope, schedule, and budget
  • Measure project performance

Closing:

  • Archive documents
  • Close project or phase
  • Obtain administrative closure
  • Document lessons learned
  • Obtain final acceptance of deliverables
Calculating Hours

While calculating and documenting project hours isn’t the #1 reason for rejected applications based on PMP interviewees I chatted with, these next few remained on the list as red flags if not documented correctly. 

When it comes to calculating hours, here are a few things to be cautious about.

40 hours/week rule

While it is more common than any project manager would like to admit, it’s not unusual to be faced with a 40+ hour work week. When it comes to logging hours on a single project, or on multiple projects during the same time-frame, PMI doesn’t want to see that you’ve exceeded a normal 40 hour work week. Nor do they want you lying on the application.

Best advice – log the 40 hours and document another project to get the remaining hours to meet the “years of PM’ing” duration requirement. Better to be safe and front-load the work, than get audited.

Align hours the PMI way

Another tip is to make sure the breakdown of your hours aligns with, you guessed it, the PMI way, as shown below. To accomplish this you need to have the total number of hours worked for each project and then perform a little math to breakdown your hours based on process group.

  • Initiation: (5-10%) 
  • Planning: (20-30%)
  • Executing: (20-30%)
  • Controlling and Monitoring: (20-30%)
  • Closing: (5-10%) 

For instance, I had a project that went on from 3/6/2015 to 3/25/2016. There were 660 hours spent on the project. I chose a number between 5-10% and did some math. For initiation, 660×10% = 66 hours. I ended up going with 64 (still within 5-10% range). Some of the values will have to be adjusted to make sure the percentages vary and that the total number of hours match the 660 in this example.

Here is an example of a breakdown I used.  You’ll notice the actual math vs the hours that I actually used.  As I mentioned, you’ll have to tinker with the numbers to hit the correct TOTAL hours.

Total Hours – 660

  • Initiation (5-10%)
    • 660 x 0.10 = 66
    • Used: 64 hours
  • Planning: (20-30%)
    • 660 x 0.25 = 165
    • Used: 165.5 hours
  • Executing (20-30%)
    • 660 x 0.29 = 191.4
    • Used: 191 hours
  • Controlling and Monitoring (20-30%)
    • 660 x 0.28 = 184.8
    • Used: 184.5 hours
  • Closing (5-10%)
    • 660 x 0.08 = 52.8
    • Used: 55 hours
  • 64 + 165.5 + 191 + 184.5 + 55 = 660.  Yay!

The key thing here is to make sure your hours are broken up my process group and the hours are allocated accordingly. 

Do this and you can reduce your chances of getting your application flagged.

Putting it all together

So I have been babbling on awhile now. Are you pickin’ up what I’m puttin’ down? (Love those dad jokes/puns by the way)

Let’s recap!

  • Be sure you have enough hours and project experience
  • Project descriptions should be 550 characters or less, not 550 words or less
  • Project descriptions should use the PMI/PMBOK lingo and be written with a sentence or so for each process group of what you did to manage the project
  • Descriptions should also be written describing how you lead and managed projects
  • Log project hours the PMI/PMBOK way my process group percentages 
  • Make sure project hours on a single project, or on multiple projects during the same time-frame don’t exceed a normal 40 hour work week.

While PMI states that audits occur randomly (and I’m not saying they don’t) these are they key areas of the application that those who have been audited said they didn’t do, and those who have said they weren’t.

Also, we put together this great template to help you with your application.  You can download it here!

Good luck!

P.S. – We’re all friends here. Share your experience from the audit so others can learn from your mistakes and not make them.

Or better yet, share your best dad joke/pun. That is more for me.

Related Posts

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.