Advice for passing the PMP Exam

Posted by mikeberry | CAPM, PMP, Project Management | Monday 10 December 2012 11:02 pm

The PMP, or Project Management Professional certification, indicates a person possesses years of industry experience participating in projects, and they understand the PMBOK framework.

The PMBOK, or Project Management Body of Knowledge, is a framework comprising 42 processes useful to managing formal projects.

Legendary in the industry, the PMP exam is one of the toughest professional exams out there.  It consists of 200 questions and takes most people the entire 4 hour allotment of time to complete.

The test is put together using Blooms Taxonomy, a learning framework that describes different ways people process learned information.   Recalling lists versus selecting the best option from a set of viable options are examples of categories in Blooms Taxonomy.

One major tip for passing the PMP exam is to expect to be reading questions in street lingo.  For example, the question may be a short story about a manager asking for something from her project manager.  The question will contain no terminology…you will be expected to translate the street lingo into the particular framework component being described and select the correct answer from the choices given.

I teach a PMP Exam Prep class and have many students who pass, and a few who don’t.  What’s the difference?  Quality study time.  Be sure you take this exam seriously so that you can benefit from the PMBOK framework concepts.

Mike J. Berry, PMP, CAPM, CBAP, ITIL, ACP, CSP, CSM, CSPO
John C. Maxwell Leadership Coach

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Fark
  • Netscape
  • StumbleUpon
  • Technorati
  • YahooMyWeb

Project Management Institute Announces New PMI-ACP Agile Certification Credential

Agile Certified Practioner (PMI-ACP) will be the designation of the new PMI Agile credential.  PMI has decided to recognize the prevelance and effectiveness of Agile practices within the project management community and has constructed a tangible foundation of requirements and guidelines for establishing what constitutes an Agile framework.  Perhaps we’ll soon finally see an Aglie BOK.Key dates for the PMI-ACP are as follows:(May 2011) PMI is now accepting and reviewing applications for the PMI-ACP(Sep 2011) The PMI-ACP examination will be available(Oct-Dec 2011) The first PMI-ACP certifications will be awarded to successful pilot candidatesSign up for the PMI-ACP pilot program here:http://www.staging.pmi.org/en/Certification/New-PMI-Agile-Certification/PMI-Agile-Certification-Pilot-Program.aspx

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Fark
  • Netscape
  • StumbleUpon
  • Technorati
  • YahooMyWeb

Whiteboards for Everyone!

Do you like designing on whiteboards?  I do.   Colorful markers against a clean, white surface inspire all kinds of creativity and fun.

Recently David Crossett of Ready Receipts gave me a great tip.  He told me that instead of going to your local OfficeBOX superstore and paying $200 for a 4×8 whiteboard, just hit HomeDepot instead and get a $12 piece of showerboard.  It works just as good and if you need a smaller size they will cut it for you on site for no additional charge!  At that price, you can line your walls with thinking space.  Power to the Consumer–thanks David!

Mike J. Berry
www.RedRockResearch.com

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Fark
  • Netscape
  • StumbleUpon
  • Technorati
  • YahooMyWeb

Software Development Best Practices - Software Requirements Management

I recently hosted Red Rock Research’s second weekly software development best practices seminar for the general public.  Our topic was Software Requirements Management.Requirements Management is perhaps the most controversial topic in software development.  Everyone seems to have their own technque.  It is also the most important skill-set–statistically more important than development skills–to the overall success of a software project (Standish CHAOS Report, 2009).Let me say that another way because this principle is not intuitive…if you want to improve the performance of your development projects, improve the skill-sets of your business analysts who generate requirements.  Statistically, this has more of a performance boost on a projects outcome than any other skill-based area.Many published requirements management techniques exists, and yet in a $220 Billion industury with a project failure/delay rate of 64%, it appears that most of these published techniques are not embraced.Our seminar covered Eliciting, Prioritizing, Validating, and Documenting a requirements baseline.  We discussed the progression of system context diagrams, UML actors, use cases, data-flow diagrams, High-Level Overview diagrams, High-Level Design diagrams and finally the Software Requirements Specification document.   We talked briefly about  a Concept of Operations document and a System Design Description document.We discussed the difference between a plan-based documentation stack, and a minimized Agile-development documentation stack–which would be generated during a Sprint-Zero.  (Yes BTW, you DO create documentation for Agile projects!)We discussed techniques to control scope creep after the requirements baseline, and then discussed techniques for dealing with what I call ‘approval noise.’What puzzles me the most about this topic is an entrenchment I encounter occasionally, as expressed by one of the seminar participants.   He stated, after the seminar, that all of this was interesting in a textbook-like manner, but that he felt none of it was pratically applicable.I asked him to explain how his company performs requirements practices and he said “Well, we have nothing written.  We have everything in our head and we just talk across the cubicles.”  He then told me he was frustrated at some additional items he was asked to add to his project that morning because it was supposed to be completed two weeks ago.  He also told me that the owner of his organization wished they had a structured approach to software project management, and that–oh, by they way–many of the programmers were given layoff notices at the beginning of the week because the company is failing.Hmm, it’s almost as if the problem is not properly in focus.  Downstream problems are caused by upstream actions or omissions.  I mean no disrespect, I just wish to point out the obvious that if companies like this would adopt upstream structure they would benefit from downstream success.You see, the problem proper requirements practices solves is not at the development effort level, it is at the project management, estimation, budget, and strategy planning–or business level.Software centric business level practices become predictable and executives can be proactive if their projects properly consume the time estimated.Projects will consume the time estimated if they include all of the functionality needed for a desired level of business value, and those functions are identified in whole, at the beginning of the project.  This way the software project time-frames and feature-sets can be included accurately in the estimation, budgeting, resource planning, and strategic planning of a company.  This way, scope creep will be minimal, and the whole company will benefit from a predictable project delivery process.Without proper requirements skills, entire feature-sets get missed upstream and need to be added ‘at the last moment’ downstream,  the risk of re-work increases drastically, and recurring cycles of this erode project managers and the development team’s credibility in the eyes of the executive team and the waiting customers.  In worst case scenarios, this can lead to layoffs and finally company failures.If you haven’t been trained on proper requirement management techniques, you are holding your organization at risk.  Attend our next three-day Software Requirements Management training course held September 7-9 in SLC.Mike J. Berry, PMP, CSM, CSPMwww.RedRockResearch.com

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Fark
  • Netscape
  • StumbleUpon
  • Technorati
  • YahooMyWeb

Don’t miss these Software Development Best Practice Workshops…

I’m hosting weekly Software Development Best Practice workshops each Thursday during the next four weeks.  These are held during work hours so ask your manager/VP/CIO and perhaps they would like to come along.  The topics are different each week.

This is basically a summary of my three day courses that I am now offering.  I’m giving the info away to get some attention in the valley.  Each workshop is from 3:00 - 5:00pm Thursday afternoon at the Miller Campus - Professional Development Center  This represents a tremendous value as I have put over 3000 hours of research into the material and consumed over 100 industry books.

Topics

Software Estimation - July 9th

Software Requirements Management - July 16th

Software Quality Systems Management - July 23rd

Software Development Life Cycle (SDLC) Management - July 30th

Event Calendar and Info

http://www.utahtechcouncil.org/Events/Community-Events/Community-Calendar.aspx

Hope to see you there!

Mike J. Berry
www.RedRockResearch.com

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Fark
  • Netscape
  • StumbleUpon
  • Technorati
  • YahooMyWeb

How to compute % defects removed from release candidate code

Recently someone on StackOverflow.com asked me to explain how to compute the defect removal rate for release candidate software.  There are two methods for producing this number and I teach both in several of my seminars, but I’ll explain the simpler method in this post…

Lawrence Putnam presented this model in his 1992 Book titled Measures for Excellence.  His book reads more like a math text than a software development guide, and suffers from an unfortunate formula typo which has lead to widespread confusion about his models in the industry, but I will  explain his defect removal rate calculation process.  (I hired a math wizard to examine his data and correct the formula!)

1. For a typical project, code is produced at a rate which resembles a Rayleigh curve.  A Rayleigh curve looks like a bell curve with a long-tail.  See my ASCII graphics below:

||||
|||||||||||
|||||||||||||||||
|||||||||||||||||||||||

2. Error ‘creation’ typically happens in parallel and proportional to code creation.  So, you can think of errors created (or injected) into code as a smaller Rayleigh curve:

||||
|||+++|||||
||||+++++|||||
||||+++++++||||||||

where ‘|’ represents code, and ‘+’ represents errors

3. Therefore, as defects are found, their ‘detection rate’ will also follow a Rayleigh curve.  At some point your defect discovery rate will peak and then start to lesson.  This peak, or apex, is about 40% of the volume of a Rayleigh curve.

4. So, when your defect rate peaks and starts to diminish, factor the peak as 40% of all defects found, then use regression analysis to calculate how many defects are still in the code and not found yet.

By regression analysis I mean if you found 37 defects at the apex after three weeks of testing, you know two things:  37 = 40% of defects in code, so code contains ~ (37 * 100/40) = ~ 93 errors total, and your finding about 10.2 defects per week, so total testing time will be about 9 weeks.

Of course, this assumes complete code coverage and a constant rate of testing.

Hope this is clear.

Mike J. Berry
www.RedRockResearch.com

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Fark
  • Netscape
  • StumbleUpon
  • Technorati
  • YahooMyWeb

25 Most Dangerous Information Security Programming Errors

Want to visit ground-zero for data security?  Experts from SANS, MITRE, SAFECode, EMC, Juniper, Microsoft, Nokia, SAP, Symantec, and the U.S. Department of Homeland Security’s National Cyber Security Division last week presented a listing of The Top 25 Most Dangerous (Information Security) Programming Errors.  Expect to see future government and big-money RFP’s mandate these items be addressed.

Mike J. Berry
www.RedRockResearch.com

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Fark
  • Netscape
  • StumbleUpon
  • Technorati
  • YahooMyWeb

Anatomy of an Execution Plan

Have you been challenged with performing a high-risk task like upgrading a prominent server, for example?

Here’s an execution plan template that you can use to guide you.

I. Executive Summary
Brief overview of intended event.

II. Review of Discovery
Details of what efforts were made to research what is listed in the following sections.  Meetings, Vendor consultations,  OnLine Resources, and Conventional Wisdom can be included.

III. Pre-Upgrade Procedures
Steps identified to be taken before the event.

IV. Upgrade Procedures
Steps identified to be taken during the event.

V. Post-Upgrade Procedures
Steps identified to be taken after the event.

VI. Test Plan
Verification procedures to confirm the event was a success.  This section should define the success criteria.

VII. Rollback Plan
In case the worst happens, what to do.

IIX. Situational Awareness Plan
After-the-event steps to validate the success of the event with the system’s business users.  This would include a two-way communication between your group and the business users, announcing the success, and providing contact information for them to contact you in case there is still a problem.

IX. Risk-Management plan
A plan listing risks associated with the steps above and recommendations as to how to lower those risks.

X. Schedule
If the event spans many hours or days, you may want to draft a schedule for the benefit of all involved.  Include on the schedule the ‘rollback point,’ which would be the latest time a rollback could be successfully performed.  Your success criteria whould have to be met by this point to avoid a rollback.

Be sure the Execution Plan is in a checklist format, not a bullet-list format.  Require participants in the event to ’check’ completed checklist items and sign-off sections they are responsible for.

For critical areas of high-risk, (ie: setting up replication), for example, you may want to require two individuals to perform the checklist steps and sign their names when that section is complete.

If you like, add a ‘lessons learned’ section to be completed later, and keep a copy of the execution plan for historical purposes.

Mike J. Berry
www.RedRockResearch.com

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Fark
  • Netscape
  • StumbleUpon
  • Technorati
  • YahooMyWeb

Excellence over Heroics

I value Excellence over Heroics.

‘Excellence’ can be defined as “the crisp execution of established procedures.”  Think about that for a minute.

Do you know of a software development shop where several prominent developers often stay up late into the night, or come in regularly over the weekend to solve high-profile problems, or put out urgent mission-critical fires?

The thrill of delivering when the whole company’s reputation is at stake can be addictive.  I remember once staying up 37 hours in-a-row to deliver an EDI package for a bankers convention.  I was successful, delivering the application just before it was to be demo’d.  I went home and slept for 24 hours straight afterwards.

The problem with ‘Heriocs’ is that the hero is compensating for the effects of a broken process.  Think about that for a minute.

If heroes are needed to make a software development project successful, then really something upstream is broken.

Most problems requiring heroics at the end of a project stem from improper effort estimations, inability to control scope, inadequate project tracking transparency, mismanaged Q/A scheduling, unnecessary gold-plating, or inadequate communication between the development team and the project users/stakeholders.

A well-organized development group humms along like a well-oiled machine.  Proper project scoping, analysis, design deconstruction, estimating, tracking, and healthy communication between development and the users/stakeholders will bring that excellence that trumps heroics.

Hey, I hear that Microsoft is looking for some Heroes.

Mike J. Berry
www.RedRockResearch.com

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Fark
  • Netscape
  • StumbleUpon
  • Technorati
  • YahooMyWeb

Book Review: Motivating Employees

Employee motivation is an ever-present concern for most proactive managers.  Interestingly enough, motivation can come from both functional and dysfunctional sources.

I’ve seen employees motivated for many different reasons: recognition, financial incentive, empowerment, personal growth, tension release, fear, and finally there’s that weird Lord of the Flies thing where employees get motivated together against another employee.

In their book, Motivating Employees, Anne Bruce and James S. Pepitone describe the most effective ways to motivate a team.  They describe the three C’s which are vital to functionally motivating employees:

1. Collaboration: Be sure to involve employees in decisions and discussions where their efforts are involved.

2. Content: As they produce suggestions, act on those suggestions immediately.

3. Choice: Be sure to offer choices to your employees–even if you can predict what they will decide.

These three techniques actually empower your employees.   Involving employees in decisions that affect them, or the outcome of what they are working on produces a level of buy-in that is hard to match any other way.

Bruce and Pepitone continue with an examination of Theory-X and Theory-Y motivation and management styles.  These styles were originally presented in the 1960’s by Douglas McGregor.

McGregor states that Theory-X managers proceed from the assumption that their employees are uninformed, lazy, and needy of high-structure.

Theory-Y managers, however, proceed from the assumption that their employees are qualified, intelligent, and capable of making proper decisions provided they are given proper goals, accountability, authority, and resources to accomplish their tasks.

Although Theory-X is the most effective approach during some situations, if you consider the amount of college-educated employees in the workforce today, it’s easy to see how Theory-Y, if applied properly, yields much higher performance.

The authors continue with a formula for encouraging Entrepreneurial Thinking.   Their five-step formula is:

1. Explain the organization
2. Demonstrate how the organization operates and generates income
3. Help your employees understand the competition
4. Encourage intelligent risk-taking
5. Inspire innovative thinking

Another great idea the authors present is to link motivation to performance.  They suggest you develop a written-list of performance standards for meeting and exceeding the expectations you’ve agreed upon during collaborative sessions with them.

The authors talk about how important it is to weave fun into everything your organization does.   This may sound like a unusual suggestion at first, but the authors point out that there is a direct correlation between fun on the job and employee productivity, moral, creativity, satisfaction, and most importantly–retention.

The final few chapters in the book discuss de-motivating factors (or individuals), and how to deal with them.  There is also a good chapter on conducting effective employee-reviews.

Overall I recommend this book to any manager.   It’s a great book to re-read every so often.

Mike J. Berry
www.RedRockResearch.com

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Fark
  • Netscape
  • StumbleUpon
  • Technorati
  • YahooMyWeb
Next Page »