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

One or Two Day Tasks

Posted by mikeberry | Agile Executives, Product Owner, ScrumMaster, PMI-ACP, Agile Development | Monday 10 December 2012 10:44 pm

Recently while coaching Agile to a large client in the Salt Lake City area one of the developers on one of the teams asked me why an Agile team should decompose features into one or two day units of work.  It seems, he said, the particular unit of work he was considering could not be broken down into anything smaller than 4 days.

This is a common question for groups first exposed to Agile.   Decomposing features into one or two day tasks can be challenging at first.  Here are several reasons why it is a good practice:

1. Breaking down features and large tasks into one or two day units of work forces the Agile team member to really understand the nature of the tasks.  Ambiguity is the enemy of success and large units of work really are ambiguous.

2. Smaller units of work limit the amount of risk that a particular task can adversely impact a schedule that was estimated incorrectly.

3. Decomposing work into many one or two day tasks gives the team member a win every one or two days.   They and their teammates will njoy a sense of accomplishment more frequently, helping team morale.

4. Decomposing work in to one or two day tasks creates more transparency and precision so the team can account for completed work more accurately.  This many not be noticeable for one single work item but imagine the effect if the entire team kept work items at a non-decomposed level…too much ambiguity.

5.  Some teams I encounter hold standup meeting less frequently than daily.  This is a mistake.  Standup meetings should be held daily.  When I drill down and ask why, I typically hear that the team is reporting on the same work item the whole week.  Further questioning reveals they are not decomposing work into one or two day tasks.  When they start decomposing work into one or two day tasks then they have something new to report each day, and the standup meetings become more helpful.

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

Red Rock Research

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

CBAP and Agile Development

I attended an excellent presentation hosted by the Northern Utah PMI Chapter, featuring Mike Sandberg, Novell’s Chief Business Analysts.  Mike spoke to a room of well over 200 folks about the CBAP certification.  This is the Certified Business Analysis Professional credential that us now coming of age.Mike talked about his own experience discovering the CBAP community and about the successes and issues involved with adopting the framework.Specifically, Mike spoke about how the PMP and CBAP roles work together.  He talked about some challenges regarding turf and terminology that sometimes befall newer groups.Someone in the audience asked Mike about how CBAP fits in with Agile.  Mike explained that this is a common question and that the business analyst would be most suited for the Agile Product Owner role.This seemed to make the most sense to me, and to the others present.Mike J. Berry, PMP, CSM, CSP, ITIL

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

Agile Development and Requirements Documentation

I keep hearing horror stories from managers about how their teams that have adopted Agile Development insist there are no documented requirements necessary when using the Scrum framework.This is wrong.  Scrum is intentionally quiet about software requirements so that groups can use what works best for them.At Red Rock Research,  we show groups practicing Agile how they can benefit from a high-level “strategic” use case model.  This strategic model, or High Level Analysis, is used to flush out the users, the needs of the users, and to expose any data flow requirements that were missed in the inception phase.This technique has proved quick and effective.Mike J. Berry, PMP, ITILv3, SCM, SCPOwww.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

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

Need a tech job: www.twitter.com/RedRockJobs

Posted by mikeberry | Uncategorized | Friday 21 August 2009 7:29 pm

This economy needs help.

Follow www.twitter.com/RedRockJobs and be the first to know about immediate tech job openings, contract work, side jobs, or special requests.

You never know when that friend in need could be you!

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: Crossing the CHASM

I’ve heard people make references to Geoffrey A. Moore’s Crossing the CHASM book for several years now but had’t read it until this past week.

Moore’s book is a must-read for any IT company trying to launch a new product.  Although the concepts in the book are not novel (so admit’s Moore) the book brings a vocabulary and metaphoric dictionary to the readers allowing marketing groups, investors, and techies alike to communicate about the playing field in a proactive manner.

Moore discusses the importance of delivering continuous innovation, instead if discontinuous innovation.  Our new innovations need to help people do what they are already doing better, and not force them to abruptly change something that kinda works for something that they are not sure about that may possibly work better.

Moore introduces the Technology Adoption LifeCycle, complete with five categories of market segments.  He discusses how to market in succession to each group:

  1. Innovators
  2. Early Adopters
  3. Early Majority
  4. Late Majority
  5. Laggards

Finally, Moore introduces some business concepts you may have heard of by now, like the bowling alley, the tornado, and the fault line.

If you haven’t heard of these, then you need to get reading!

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

Publishing My First Book: Software Quality Systems Management

Posted by mikeberry | Leadership, Book Reviews | Tuesday 21 July 2009 1:59 pm

I’m publishing my first book next month.  It’s about software quality management.

Quality management, that is, in the sense of improving software processes and production support methods, not about ‘how to test software.’

I include overviews of the four formal quality models: CMMI, Six Sigma, and ISO 90003, and ITIL.  I outline how to create a quality system within an organization and I discuss common fixtures it should have.

I talk about checklists, measurements, purpose, accountability, and continuous improvement.

So now I want your help.  Tell me what else I should include in a book about managing quality in an IT/Software Development/Production Support environment.

Also, suggest some titles.  Thanks in advance!

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
Next Page »