Categories
PMI PMP Certification Project Management

What is the PMBOK?

A Guide to the Project Management Body of Knowledge (PMBOK Guide)The PMBOK (or PMBOK Guide) is the Guide to the Project Management Body of Knowledge, one of the key sources of PMI (Project Management Institute) standards and guidelines. This comprehensive project management document describes the norms, methods, processes and practices involved in professional project management. As described in the PMBOK Guide itself, these standards and guidelines are developed through a consensus standards development process through consultation with volunteers and project management experts. PMI is the administrator of the process but does not write the PMBOK nor does it test or evaluate its accuracy; the information contained in the PMBOK is a culmination of the information put together by these experts and volunteers.

The PMBOK was first put together over 25 years ago, in 1983, and there are currently over 2 million copies of the PMBOK in circulation. As of this post, the latest version of the PMBOK is the 4th edition, published in late 2008. The fourth edition of the PMBOK replaced the 3rd edition as the version tested on the PMP (Project Management Professional) exam in July of 2009; that is to say that in June of 2009, PMP certification candidates were tested on the 3rd edition of the PMBOK, and in July of 2009, the 4th. As of January, 2013, PMI has released the fifth edition of the PMBOK.

The contents of the PMBOK include an introduction to project management (including a definition of what constitutes a project), a vision of the project life cycle, and a detailed overview of the project management processes that take place during PMI-based project management. The five Project Management Process Groups are covered:

  1. Initiating
  2. Planning
  3. Executing
  4. Monitoring & Controlling
  5. Closing

As well as the nine Knowledge Areas, where the skills and techniques of project management are applied:

  1. Project Integration Management
  2. Project Scope Management
  3. Project Time Management
  4. Project Cost Management
  5. Project Quality Management
  6. Project Human Resource Management
  7. Project Communications Management
  8. Project Risk Management
  9. Project Procurement Management

Although I’ve listed these Knowledge Areas from 1 to 9, in the PMBOK they are listed from 4 to 12; this is because these numbers correspond to the chapters within the PMBOK where you can learn about these knowledge areas.

The PMBOK is a thorough document; the 4th edition copy I hold in my hand (I don’t have a 5th edition version handy), including the Index, comprises a hefty 467 pages. Nevertheless, in order to pass the PMP exam you will need to understand this document. It can be a little dry (each input, tool or technique and output is described in rigorous detail for each project management process), but only by understanding each process intimately can the PMP exam be passed. I should also note that some things that you need to know in order to pass the PMP exam are not featured in the PMBOK; for example, PMI’s Code of Ethics and Professional Conduct. The examination itself includes questions about the proper ethical behavior of project management professionals that you will need resources above and beyond the PMBOK to understand, and though you may think that questions on such a topic would take simple common sense to figure out, for the PMP exam this is not the case.

When studying for the PMP exam I would personally read the PMBOK second in your reading list; it focuses on minute details of project management that might make it difficult to obtain a proper high-level understanding of project management if it is the first document you’re reading about the discipline. I personally read Andy Crowe’s book “The PMP Exam: How to Pass on your First Try” first; then the PMBOK; and finally, Rita Mulcahy’s “PMP Exam Prep”. This progression worked well for me.

If you’re interested in learning more about preparing for the PMP exam and about how I myself studied for it, I have documented the method that I personally used to pass the PMP exam in this post.

Categories
Agile Development Project Management

The final sprint before release in Scrum

A rugby scrum with the teams from Clermont Auvergne and BathScrum as a product development methodology is certainly growing in popularity. Having managed projects using several different project management frameworks I can attest to the flexibility and scalability of Scrum, especially when compared to the waterfall method.

According to the Scrum methodology you should not change your processes while sprinting; the first sprint in your development cycle should be planned and executed the very same way as the last sprint. After every sprint you should have releasable code; whether or not you want to release such code to your clients is up to you. This sounds good in theory, but I have found that you need to pay special attention to how you address the final sprint before you release your product to your clients. Here is why:

  1. After your final sprint, mistakes can’t be thrown away. One of the great things about Scrum is the fact that you will end up with releasable code after every sprint. An in-process product can be demonstrated to stakeholders right after the very first iteration, and design issues that could render a waterfall-developed product worthless can be found early in the development cycle – if you find a mistake after a three-week sprint, the most development time you’ll have wasted is three weeks. During the final sprint, however, you can’t throw away what you’ve created – if it’s destined for the release, it’s going out the door. So more care to design and develop proper product needs to be given during this final sprint.
  2. What you put into the sprint backlog likely needs to stay in the sprint backlog. It’s not good practice to pull functionality (in the form of user stories) from sprints while they’re in process, but it gets done. Sometimes stories that you think are a size of 8, end up being a size of 20; other times integration or technical issues arise with certain stories that you can’t take care of during your sprint. The problem here is that during the final sprint before release it’s likely that you’ve committed to getting out what you’ve put into your sprint backlog, and removing items may not be a viable option.
  3. The final iteration is riskier than the others. Some stories involve cleaning up functionality created in earlier sprints, or enhancing what was already coded. This means that development during a mid-development sprint is not very risky; if you need to, you can go back and clean up what you’ve done in a later sprint – that’s how Scrum works. During the final sprint, however, this can’t happen – what you’ve created is going out the door. So you need to pay special attention to risk management, and very closely monitor the product that is being created during this time.
  4. It is crucial that the product be properly integrated after the last sprint. It’s true that every piece of functionality developed during each sprint needs to integrate with what’s already in the product, so you should always integrate your product properly before the end of each sprint. However, the final sprint is the one where you will need to ensure that all new product is tied together – everything will need to work with everything else before it’s shipped to clients. Extra care should be taken during the final sprint to make sure that this is so.

There is no need to panic about your final sprint before release… with proper risk management and an understanding of expectations you can deliver quality releasable product when the iteration is done. But without giving the final release the proper respect it deserves, you could run into significant problems – and at this stage of the game, they’ll be problems you won’t have the time or resources to fix.

Categories
Project Management

IT Project Management one of America’s best jobs

Today Focus published the following graphic that displays, based on salary, flexibility, job security and other factors, the best jobs in America:

Best Jobs in America

IT Project Management scored as the 5th best job in America, out of 7,000 jobs – a great success for the profession. Professional project management is a well-paying job with great opportunities for growth and career satisfaction. Software Product Management also scored well, at 16th on the list.

In general, the Information Technology field did really well in Focus’ survey – in the top 30 jobs, 7 of them were in IT (including the top spot, Systems Engineer). Not only that, but many of the other jobs in the top spots can also be commonly found within the realm of IT and software – Product Management Director, Sales Director, Financial Analyst, Certified Public Accountant and Human Resources Manager, to name five.

Categories
PMI Project Management

Attending PMI meetings

PMI meetingAttending PMI meetings is not mandatory for PMI members and PMP certificate holders, but I’ve found it to be a useful way to spend a lunch hour. PMI meetings normally take an hour and a half (ours have run from 11:30 AM to 1:00 PM on weekdays) and feature a speaker who presents some topic relevant to project management. And, contrary to what you might believe, the topics are not always particularly relevant to Project Management Institute (PMI) processes and practices, but normally feature real-world stories and scenarios, and I’ve found generally pretty interesting.

I’ve attended PMI meetings in both San Antonio, Texas and Charleston, South Carolina, and notice that in each city the meetings have followed a certain progression, which is this:

  1. PMI members arrive at the meeting room, mingle, grab some lunch (normally catered), and take a seat
  2. The president of the chapter speaks, discusses PMI chapter business, and asks for two groups of people to stand up; first, those who are attending their first PMI chapter meeting, and second, those people who have recently passed their PMP exam
  3. The president introduces the speaker, who gets up and speaks on his or her topic for an hour, normally accompanied by a PowerPoint presentation
  4. The speaker conducts a Q&A session on his or her topic while members gradually start trickling out to head back to work.

Your chapter may have a different way of conducting their PMI chapter meetings, but this method seems to work quite well! One thing I have noticed, is that the Charleston chapter meetings don’t have as much mingling as do the San Antonio chapter meetings – that’s something I’d like to see change, as I really appreciate the time spent meeting other project managers in the area and making contacts.

The presentations I’ve been to have covered a variety of topics – in one, a registered nurse explained how she incorporated project management into her operation of a hospital department, and in another a good friend of mine talked about his projects involving fluid dynamics graphics work at Digital Domain, which eventually led to his winning a Scientific & Technical Academy Award. This month a fellow presented an introduction to Scrum, an Agile Development framework that we use where I work as a program manager.

Attending a PMI chapter meeting grants you one PDU (Professional Development Unit), which is good for those members who are PMP certified and need to amass 60 PDUs every 3 years. If you attend every chapter meeting your chapter puts on every month, that’s 24 PDUs toward that total. So while you’ll have to do some extra work to get those additional 36 PDUs, what you can earn from attending PMI chapter meetings certainly doesn’t hurt.