Page 10 of 16

December 20, 2006

Taking the PMP Exam - Part 13 - How the PMP Exam is constructed

Like any project, the PMP examination required that some sort of scope be set. The document which set the scope for the project is the Project Management Profession Examination Specification. I covered this in Part 12 if you need the full reference or want to know how to obtain it. In most cases the thing which is being produced has at least a passable resemblence to what was specified. In this case, one which is supposed to be exemplary of project management, it is reasonable to expect that the results were pretty close to what was asked for. Therefore, knowing the blueprint of the PMP examination is very helpful in navigating your way through it. With that out of the way I'm just going to dive in and start stating the most important parts of the spec.

What the test consists of: The PMP exam consists of questions from six different areas in differing percentages. For the current exam they are:

  • Initiation, 11 percent
  • Planning, 23 percent
  • Executing, 27 percent
  • Monitoring and Controlling, 21 percent
  • Closing, 9 percent
  • Professional and Social Responsibility, 9 percent

These percentages should guide your study. The high weighting given to Planning and Executing for example mean that you can not neglect these areas. You should focus on them for at least half of your time - unless you are already quite familiar with them, It also means that if you feel weak in one of the lesser areas, you should not fall into panic. In fact, you could miss all the questions on Professional and Social Responsibility and still pass the exam.

The PMP examination specification goes further than this though. Each of these "Performance Domains" are broken down further into a number of tasks. For example, Initiating is broken down into project selection, scope definition, development and documentation of risks, assumptions and constraints, stakeholder requirements analysis, development of project charter, and obtaining approvals. Each of these tasks requires a certain knowledge and the application of a set of defined skills. An example of knowledge required for risk documentation would be knowing what risk identification tools and techniques are available and suitable for the project. An example of a skill required would be "identifying risk".

With these examples you can see how the spec has moved from being ... um ... non-exisitent? to being based on the performance of project management, or at least tying the performance of Project Management to the knowledge and processes defined (as mentioned previously, the PMBOK has morphed from being a taxonomy to a prescriptive document) in the PMBOK Guide.

What effect this has on preparing for the exam and passing the exam I am not quite sure, but I'm starting to think that moving from the old braindump of process areas towards a new braindump of "Performance Domains" and their tasks would be a good idea. That will be a topic for upcoming articles.

Things to remember:

  • Initiation, 11 percent
  • Planning, 23 percent
  • Executing, 27 percent
  • Monitoring and Controlling, 21 percent
  • Closing, 9 percent
  • Professional and Social Responsibility, 9 percent

December 19, 2006

Glen's Book List

In the small world of Project Management Bloggers, the thing which most passes for a year-end tradition is Glen Alleman's book list. You can find it here:

Books of 2006

It is definitely worth taking a look at. My reading is a bit more eclectic. If I get around to it I'll post a few things, but don't wait up.

Taking the PMP Exam - Part 12 - The PMP Examination Specification

No sooner do I mention that the references available on PMI's eReads and Reference section are dated than they publish a notice stating they will be removed and replaced with two references. The first is the ALL IMPORTANT PMP Examination Specification. According to a helpful comment from Oliver Lehmann, a PMP Trainer in Germany, this new book lays out the bones of the PMP Examination much better than I have been doing. This makes sense since it is the blueprint for the new exam. I will dig into it in depth as soon as it is available. But have no fear that what we have covered so far is useless. No, the definition of a project has not changed a bit.

The second is a publication titled Q & A's for the PMBOK Guide. I'm not sure what exactly it covers, but it also sounds interesting.

Both of these references will be available for PMI members on January 4, 2007. For the benefit of those interested, here is the text of the announcement:

**Important news about eReads & Reference content**
The eReads & Reference collection currently still includes study guides for the old Project Management Professional (PMP®) certification exams (i.e., study books published before 2005). These study guides are located on the Certification Study Bookshelf of the eReads site. On 4 January 2007 the 4 outdated books listed below will be removed from the collection:

* PMP: Project Management Professional Study Guide
by Kim Heldman. Sybex, ©2002, ISBN:0782141064

* PMP: Project Management Professional Workbook
by Claudia Baca and Patti Jansen. Sybex, ©2003, ISBN:0782142400

* Preparing for the Project Management Professional (PMP) Certification Exam, Second Edition
by Michael W. Newell. AMACOM ©2002, ISBN:0814471722

* Project Management Professional (PMP®) Role Delineation Study
Project Management Institute. ©2000, ISBN:188041029X

The Certification Study Bookself will be updated with these two PMI publications relating to current PMP® and CAPM® certification:

* Q & As for the PMBOK® Guide - Third Edition
Project Management Institute. ©2005 ISBN:1930699395

* Project Management Professional (PMP®) Examination Specification Project Management Institute. ©2005 ISBN: 1930699883

Here are links to the two references if you want hard copies:


December 18, 2006

Taking the PMP Exam - Part 11 - PMO's Programs and Portfolios

I think that passing the PMP exam requires attention towards the context that the PMI believes Project Managers exist in. That context is a hierarchy of strategic plans (at the top), portfolios of programs or projects, projects and subprojects. Other than the clear break between strategy and project, one can imagine that the stones at the top of the pyramid are the same as the stones at the bottom, but since PMI takes the time to call them separate and different you had better know why. Let's start at the top:

Portfolios A portfolio is a collection of projects and/or programs which serve some strategic business objective. If your company makes hats, shovels, pitchforks and plastic flowerpots and sees some strategic value in adopting some new digging technology, they may put the shovels and pitchforks together in a portfolio and assign someone to look after it. The thinking is that they are pretty much the same line of business. However, the grouping is not limited to business lines. It could be types of projects or even along other categories (placing all "High-Risk" projects together and managing them as a group. Treating the projects as a generic class and measuring them against each other or a common metric is a hallmark of Portfolio Management.

The word portfolio is derived from the financial markets and in a way the objectives are similar - managing the portfolio to maximize value, balance risk and reward, optimize investments. The objectives are fundamentally different from project management which for the most part consists of meeting the requirements. As a result Portfolio management is usually the job of senior managers.

The next step down from the top is a Program. PMBOK's definition of a Program is:

"A program is a group of related project managed in a coordinated way to obtain benefits and control not available from managing them individually"

Let's look at how that is different from Program management. Program management deals with the temporary and unique. A program is generally heterogeneous. There may be multiple simultaneous projects which must be coordinated to meet a larger goal or there may be multiple iterations of a series of similar projects. This differs from a portfolio in that the program manager is still responsible for "getting it done". Program management centralizes and coordinates the management of projects. There is not much more to it than that. PMI is developing a Program Management Certification, so perhaps I'll tackle that one day, but not now.

Subprojects We already covered projects so move on to the next leve, the subproject. A subproject is typically very much like a project, but is broken out (or divided) off to ease management. This is commonly done when the control of an element of work exists in a different sphere of control such as a sub-contractor or external vendor or perhaps a different functional unit of an organization. As such, subprojects can be divided again and again until you run out of project and subproject managers. They are managed in the same way as projects except that some care needs to be taken in some of the process areas, most notably developing clear requirements and defining relationships and dependencies. It is at the interfaces where troubles can build up. Good communication will help to minimize the issues.

The Project Management Office (PMO) I have my questions about the effectiveness of many "project management offices" but surely if project managers are professionals they need a place where they can drink coffee don't they? In line with PMI's goals for the industry of project management, the PMO is a separate organizational unit meant to centralize and coordinate management of projects. It is a broad definition and ranges in practice from a group of project management professionals who provide project management support to being a group of "real" project managers who are actively managing the projects. In my mind it is promoted simply to allow differentiation of some specific sub-set of managment skills and reward and recognition thereof. That said, when done right it has some essential goodness. Here is a short list of things it CAN provide (if done right):

  • Development and implementation of standardized project management methodologies and metrics.
  • Training, development and mentoring of project managers
  • Archiving of historical data and a librarian function
  • Extended analysis of project management success factors
  • Tool selection and support
  • Resolution of issues and assisting in alignment between different individual projects
  • Digesting and packaging project level information for executive consumption
  • Resource allocation and reporting

That wraps up the PMBOK Guide Introduction. Next we move on to the Project Life Cycle. No, it is not something you pedal.

Things to remember:

  • Hierarchy of Strategy:Portfolio:Program:Project:Subproject
  • Different goals and different methods of management at different levels of hierarchy
  • PMO is a centralization of common skills and resources aimed at optimizing the management of a number of projects.

December 12, 2006

Taking the PMP Exam - Appendix A -Exam Guides

I've mentioned that I'm planning on taking the PMP exam by reading nothing but the PMBOK, but there are a number of exam guides and prep course books out there so I'm going to list them here for the use of anyone who thinks they need them. One thing to be very careful about is to get a version which targets the current exam. It should state that it is for the PMBOK Guide 3rd. Edition. With that out of the way, here are the books I've glanced through and some background on them.

PMP Exam Prep, Fifth Edition: Rita's Course in a Book for Passing the PMP Exam, Rita Mulcahy
This book is put out by Rita Mulcahy, one of the more established PMP exam trainers. Her company RMC (derived from her initials I believe) conducts exam prep courses, has online courses, and publishes a number of different PMP exam materials.

Rita's writing is either the kind you love or hate. Looking on Amazon you find that people find her approach motivational or condescending. I have to admit I'm not motivated by her approach, but you may be. Rita focuses on how to pass the test and her books have a number of tips and techniques for dealing with the idiosyncratic ways of the PMP exam. As I've been mentioning through this series, the way to pass the test is to think like the PMBOK.

Arrangement of the materials is a bit odd. I think that mirroring the PMBOK organization is probably a better approach. The book contains a number of practice exams. The general opinion is that the practice exams are tough (which is a good thing in some regards) and the answers are explained. I note that a few people who used this book considered the tests to be unrealistically hard - and they thought they were intended to scare people into more expensive prep classes. There is a bit of a hard sell.

Results of people using this book as reported in Amazon are pretty good. In one way this is not surprising. 80% of people pass the exam and those that don't probably aren't talking. The book apparently is used as part of her prep classes so people who are investing that much time and effort are probably pretty serious about it and would pass no matter what text they used. But the book is widely used and is probably a good choice for someone without much project management background.

PMP: Project Management Professional Study Guide, Kim Heldman
I've only taken a brief look at this book. I like the organization, but when I got to the point where I looked at the answers to one of the practice exams and the Triple constraint was described as Time, Cost and Quality I had to shake my head. Where is scope Kim? PMI members can access an online version of this book, but the one that is available is from 2002 and should probably NOT be used for studying for the current exam. Using an old book may cause you to memorize things you do not have to, and completely miss the things which are new or changed.

The basic errors scare me. Rita's book is said to have some too, so it is not specific to this book, but they are good reasons to go to the source first.

The PMP Exam: How to Pass On Your First Try, Andy Crowe
This book is widely regarded as "easy to read" and helps make sense of the PMI. On the other hand, a criticism is that perhaps it is too easy. The practice exams are not up to the same level of difficulty as the one's in Rita's books. I'd contend that the right difficulty is somewhere between the two.

This book is also firmly targetted at passing the PMP exam. Most readers report that he does a good job of highlighting what is important and what is not. This is very helpful if you have limited time to study.

PMP In Depth: Project Management Professional Study Guide for PMP and CAPM Exams, Paul Sanghera
This book is organized, like the PMBOK around the different process areas. I have not read it or even seen it yet so I don't have much to say except that many people are recommending it over the three books I've listed above. On top of that, it appears to be the most reasonably priced. Definitely worth considering if you are choosing a book to study from.

Well if it is not Google in bed with the terrorists, then it is those damn artists in bed with the CIA

From Momus we find discussion of a documentary by Hans-Rüdiger Minow regarding the CIA sponsorship of the Avante-garde in Post-war Europe as a stand against the Soviets. Blame the CIA for Abstract Expressionism. As Gunter Grass put it "The ideology of the CIA was that the West had to be the most modern of the modern". Interesting to say the least. I'm hoping we can see an English language version sometime.

An interview with the director is here (in German)

December 11, 2006

How to Change Cell Background color in MS Project

Changing the background color for a task cell in Microsoft Project is now a two-step process:

  • Step 1 - Upgrade to Microsoft Project 2007 - you just can not do this in Project 2003 or earlier.
  • Step 2 - Rightclick on the cell, choose "font" and set background color and pattern.

Sadly there are still only 16 colors to choose from, but they are getting there.

Taking the PMP Exam - Part 9 - Areas of Expertise

The PMBOK claims that effective project management requires drawing upon 5 areas of expertise.:

  • The Project Management Body of Knowledge
  • Knowledge of the application area, standards and regulations
  • Understanding the project environment
  • General management knowledge and skills
  • Interpersonal skills

These are not intended to be discrete - they overlap substantially. In fact I think they overlap to the point where there are really only three... but that is just my opinion. In an act of grace and kindness the PMBOK grants that no single person have all of this knowledge and skills. But then the whip comes down and it becomes "important that the project management team has full knowlede of the PMBOK(tm) Guide." If you were going to ask me I'd say that you can do fine without ever reading the PMBOK Guide. In fact, what did people do for thousands of years prior to the first version in 1986? And are projects managed prior to the 3rd Edition somehow LESS well managed? But anyway, when I see a list I figure it is important enough to remember. Do you remember the project management processes from last time? IPEM/CC...

So what does this important knowledge of the PMBOK guide consist of? Precisely three things:

  • The definition of project life cycle
  • The 5 Project Management Process Groups (I,P, E,M/C,C)
  • Nine Knowledge Areas

This is great news for those hoping to get a PMP cert. Seems simple doesn't it? By the way the 9 knowledge areas are:

  • Project Integration Management
  • Project Scope Management
  • Project Time Management
  • Project Cost Management
  • Project Quality Management
  • Project Human Resource Management
  • Project Communications Management
  • Project Risk Management
  • Project Procurement Management

Throwing out the reduntant terms we get an acronym of ISTCQHRCRP. Repetition is key to remembering. And multiple choice tests require that you remember rather than derive the answer so look for these items to show up to jog your memory from now until you pass the exam.

OK, that covers the PMBOK. Let's see what else they expect you to know. Starting up with application areas. An application area is a way of categorizing projects. For example an engineering project or new product development could be application areas as they have some common skill or understanding required. The PMBOK tacks on Standards and Regulations surrounding those application areas. Standards are voluntary guidelines, often developed by participants in those areas while regulations are government imposed. To make it a bit messy, sometimes a regulation will mandate adherence to a standard... but it is the compliance which is the regulation, not the standard itself.

The project environment is boiled down into three basic contexts:

  • Cultural and Social Environment
  • International and Political Environment
  • Physical Environment

All I can say about the environment is ignore it at your own peril. The examples the PMBOK gives for these things are fairly muddled citing timezones as an international and political factor rather than the clear physical factor that they are. But ignore that. I'm sure that the category is the only thing that is important here and anyone can come up with examples of each quite handily.

Three down, two to go. Next: General Managemenk Knowledge and Skills. Here my mind gets twisted by the insistance that Project Management is somehow different or is a superset of this. But that is what the PMBOK claims: "General management provides the foundation for building project management skills and is often essential for the project manager". I view it the other way around. Project Mangement is just another page in the book of General Management Knowledge and until the PMI accepts this PM's are going to be kept in a pen of their own making. This self-limiting is a problem I think. To give a flavor of what General Management is built from here are some keywords: financial, accounting, purchasing, procurement, sales, marketing, contracts, law, manufacturing, distribution, logistics, suppy chain, planninng, organization, the whole of HR it seems, Safety, IT... Enough said

The final piece: Interpersonal Skills. The PMBOK ideal would be a PM who communicates effectively, influences the organization. A leader, who motivates his/her team and who manages conflict and solves problems.. Sounds good. Where do I find one? But further thought makes me wonder why trust and respect are not important enough to rank.

Things to remember from this section:

    The five areas of expertise:
  • The Project Management Body of Knowledge
  • Knowledge of the application area, standards and regulations
  • Understanding the project environment
  • General management knowledge and skills
  • Interpersonal skills

December 9, 2006

No longer N*k*d

Sorry if you see my series of articles about taking the PMP exam show up again. I renamed and republished them after I did a google search and got this result:

The word "n*k*d" has been filtered from the search because Google SafeSearch is active. (I even censored this to keep it from being censored by safesearch)

The word had to go or no one would ever find the articles, well except the intrepid folks who seem to preface almost any noun with that word. Plenty of them showed up. Maybe they will go away now.

December 7, 2006

Taking the PMP Exam - Part 8 - What is Project Management

Time to suspend disbelief again or more correctly prepare your mind for acceptance of the gospel...

What is Project Management? The PMBOK tells us that the goal is to meet project requirements through the execution of project activities and project management is applying knowledge, skills, tools and techniques to those activities. I'd argue that the there is a component which is not strictly related to "activities" but let's discard that idea for now..

With this definition in place what is important? First of course, the project requirements are essential. PMI claims that Project Managers are responsible for identifying requirements. This has not been my experience in some organizations, but know that PMI believes that this is the case. (As an aside, apparently senior management doesn't always agree. I've written about this before here).

Let's step back a little bit here though as some key concepts are creeping in. The PMBOK is organized around a number of processes. They are:

  • Initiating
  • Planning
  • Executing
  • Monitoring
  • Controlling
  • Closing

It is this framework which forms the bulk of the PMBOK so start getting familar. I think that the exam will require you know these backwards and forward. IPEMCC. Think up your own mnemonic. These processes are "applied" to the work and are "integrated" by the project manager. The PMBOK places a heavy load on the PM. The PM is responsible for accomplishing the project objectives. In my experience much of the accomplishment is due to the efforts of the project team, but not in this book, and likely not on the exam.

This section also introduces the concept of the "Iron Triangle" or "Triple Constraint" which is the idea that every project faces balancing time, cost and scope against each other. These three requirements compete against each other and exist in an "unbreakable" relationship. To give two concrete examples: decreasing the time needed by adding more resources will increase cost, or, adding to the scope will increase time and cost. The PMBOK claim is that quality is the product of all of these. (I'd argue slightly different about the meaning of quality. ) The triangle comes in handy when arguing for more time or more resources or more money or against inclusion of someone's pet feature. By gaining agreement that there is a triangle and it is iron, you force the other to agree to making the trade-off. A sort of "my hands are tied here. I'd love to, but..." argument. In the PMI view of the world, the PM is the one who holds the triangle and makes adjustments as needed to satisfy stakeholders.

Managing risk is perhaps the heart of project management and the PMBOK states that PM's do that too. I'd add that the definition of risk is an "uncertain event or condition" which if it occurs will affect the project. The line between risk and issue is often difficult for some to discern. My personal definition is that if it MIGHT happen it is a risk. If it HAS happened it is an issue. I'm certain I'll have a post all about risk sometime soon.

Here we get onto sketchy ground. PMI claims that the PM team has a professional responsibility to stakeholders - including the public. I'm cynical here and think that this is part of PMI's goals to "professionalize" the act of managing a project. PM's should certainly be responsible. Everyone should be. (hey, how did the "public" get involved in my project?) But PMI insists that members adhere to PMI's "Code of Ethics" and "Code of Professional Conduct". Further, team members who are PMI members are obligated to adhere to those same codes. I'm of two minds about this. On one hand I think, hey why not? Doing the right thing is a good thing right? But then I think, why should PMI be telling me what the right thing is? Am I not righteous enough in my own right? Righteous has its own rewards so I'd rather be righteous for myself than for PMI. For now I'll drop it and pick it up later when we read more specifics on what the codes say.

Next a warning of how processes are iterative because of "progressive elaboration". Saw that phrase already so you know you better know it. "Progressive Elaboration" is the idea that you don't know everything at first but you are getting there. I'm in favor of this concept, but the term is a bit clunky... Say it ten times fast. Or get a tattoo.

This section closes with a note that sometimes people say "project management" when they mean turning everything (well, almost everything) into projects in an approach called "management by project". In a telling sentence, the PMBOK states that detailed discussion is outside the scope of the standard. Remember what this "standard" is? A compilation of practices "generally recognized as good practice". So either there is not general recognition of management by projects or it is not good practice. Why bring it up at all then? Hm?

So that is it for today. A bit of scathing commentary and a few facts. Next time we will get into areas of expertise or die trying.

Things to remember:

  • Triple constraint of Time, Scope and Cost with quality being the result.
  • A PM who goes from soup to nuts holding the Iron triangle in hand.
  • 6 Process areas - IPEMCC (to be covered in more detail later)
  • Professional responsibility and adherence to both "Code of Ethics" and "Code of Professional Conduct"
  • Risk - it is a risk until it happens. (don't get crazy ideas about asteroids hitting the earth though)
  • The PM owns establishing project objectives and accomplishing them. Make them CLEAR and ACHIEVABLE (see the part about PM accomplishing them).

December 6, 2006

Taking the PMP Exam - Part 7 - PMBOK Introduction and What is a Project

We finished the Preface and now it is on to the introduction. Usually this sort of stuff is unimportant, but remember, we are reading the PMBOK for clues on how to pass the PMP exam. Understanding the Project Management "Bible" will help give the necessary context for study, notes and answering exam questions. As with any test, you have to understand the test from the point of view of the test giver. THe better you understand their ideals and how they think, the easier it will be to recognize what they consider the correct answer. In this sort of exam it is not so important what you think as it is what they think.

The Purpose of the PMBOK Guide. Hmmm... it used to be called Guide to the PMBOK (PMBOK stands for Project Management Body of Knowledge). Here we see that the PMBOK is meant to identify a "subset" of all that is known about project management, specifically that which is "generally recognized" as good practice. Sorry to take issue with this PMI, but knowledge and practice are two different things. If I am an architect I have knowledge of say Borromini's baroque "San Carlo alle Quattro Fontana" and may be able to apply some of that knowledge to a current design, but knowledge is by definition a different thing than practice. I would suggest that indeed, the PMBOK guide is becoming more of a practice guide than the taxonomy which it began as. It is becoming more prescriptive than descriptive. Despite the disclaimer (in BOLD) that "the project management team is responsible for determining what is appropriate for any given project" it would appear that the PMBOK is specifying a lowest common denominator for project management. But let's leave that alone now. It won't help in taking the test - except the part in bold.

Here are some other things that the PMBOK does:

  • Provides and promotes a common lexicon
  • Serves as a reference for professional development

OK, but then they call it a "standard". Stretching PMI, stretching... Is it a guide to a body of knowledge or is it a standard? It really can't be both. For the purposes of the exam I'm going with their view that it IS a standard, a standard way to do things, a standard way to name or describe things. Forget about it being a guide.

What is a Project? Good question. Looks almost certain that some questions will be based on this so get memorizing:

A project is a temporary endeavor undertaken to create a unique product, service or result.

Key words are Temporary, Unique,. Temporary in this sense refers to the effort involved in creation, not the end result. Building a permanent base on the South Pole of the Moon is a temporary endeavor and is a project. Unique is a difficult term too. Fortunately, almost everything is unique if you define it widely enough. Different teams, different places, different clients all make something unique. I'm expecting thie "unique" part of the definition to wither and die one of these days, but know it for now.

Bundled up in the definition of what a project is, is a section on "progressinve elaboration. I'm not sure if this is a cut and paste error or what. I think it is perhaps trying to stretch the definition somehow for some purpose. My best guess is that there are projects which do not initially have complete definitions at the start. Fine. expand the definition to things where the general outcome is sort of defined, but the means to get there are not completely known. The two examples they give are both sorts of efforts in a general direction, a chemical plant and economic development. To me this appears to be some sort of quibble about what level scope needs to be decided on prior to calling something a project. For this exam, know the term means "developing in steps, and continuing by increments." It is a bit like playing pool. Name the ball and the pocket and take the shot. Do this often enough and the game is eventually over.

Project or operations? PMI considers operations to be ongoing and repetitive. We already know that a project is... temporary... yes... and... Unique! Very good! The project is over when it is over. Operations are never over. This is not to say an operations group can not undertake specific projects, they can. But such projects must be temporary (they must end sometime) and they must generally create something (product, service or capability) that was not there before. Implementing a new cost accounting system is a project. Maintaining that system is operations. So sayeth the PMBOK.

The last section on what a project is concerns how and why organizations perform projects. I disagree with the assumptions here, but my opinions dont count on the exam. Just remember that a project is meant to address a need that can't be addressed within the "organizations normal operational limits". They go on to contend that they are often part of an organization's strategic plan. I can think of counter-examples... no. I better not. Project are authorized to meet one or more of these considerations:

  • Market Demands
  • Organizational Needs
  • Customer Requests (how is this different from market demand?)
  • Technological Advances (getting foggy here. How is this different from market demand or organization needs?)
  • Legal or regulatory requirements (RoHS - regulation of hazardous substances, or corporate governance laws for example) - Once again I'm not sure this is strategic, but not to quibble. Just know these five.

That was a pretty good batch of stuff. I'll try and get around to making some cheat notes from this to boil down the concepts to a couple of key phrases.

Next time: What is Project Management?

December 2, 2006

It does it every December - Ginkgo Biloba Tree

Click to see larger sizes

The Ginkgo tree dates back about 270 Million years, before the age of the dinosaurs. So for 270 million Decembers the trees have been turning a buttery yellow (yes, long long before there even was butter, or December for that matter...). In a couple of weeks the leaves will all fall and make a yellow carpet on the ground, most likely in a single rainstorm.

December 1, 2006

Taking the PMP Exam - Part 6 - Downloading the PMBOK

Switching to a Windows-based computer cleared up my edit problem. Now let's start from the start. It is my hypothesis that you can pass the PMP exam with only experience and a careful reading of the Guide to the PMBOK. So, throwing experience out of the window for a moment, let's take a look at the Guide to the PMBOK. I'll be going through it chapter by chapter and hopefully compiling study guides along the way, but knowing what the PMBOK is and what it isn't is a good first step.

The current version of the Guide to the PMBOK is the "third edition". This supercedes the 2000 version. I'm not sure in practice whether the differences are anything but semantic, but since the PMBOK is nothing if not a taxonomy, it is very important that for a test on this taxonomy that you are looking at the right version. Let's look at what the Preface says to get an idea of what is new and different:

Thirteen changes are called out. Several are not particularly relevant, but some items give clues about what to look for:

4. The number of processes increased from 39 to 44. Seven processes were added, two processes were deleted, and 13 processes were renamed for a net gain of five new processes.

Translation: Throw out any study guide based on the 2000 PMBOK if it has you memorizing the processes. Whatever mnemonic it has you babbling will be wrong.

8. The project management processes were mapped to show process integration. and:
12. Process flow diagrams have been aded to Chaters 4 through 12 to provide added support to the integration of processes.

Translation: Pay attention to integration, or at least know what they mean by it. Flow and integration are the order of the day. This sets the stage for moving to the introduction which I'll post next time.

Taking the PMP Exam - Part 5 - PMI Standards or the lack thereof

OK, PMI got back to me with hours to spare on their 5 business day service level. Now I take the information I got and plug it into their website. Hooray! I'm in. But the data is old. Let me edit to show my current address. Please let me edit to show my current address. Please please let me edit to show my current address...

Hmmm... Maybe Firefox is just too wacky for them. Let's try Safari... no... not that either. But of course IE will work! Won't it? Oh dear. No. Click click click. Nothing. Guess a late model Mac just doesn't meet the PMI Standards.

Fired off another note to the customer service folks. Looks like it will be next week until the ball gets rolling. In the meantime I'm gonna cheat a bit and see if a Windows-based PC has better luck navigating their site. Silly PMI!

November 30, 2006

MS Project 2007 - Changing Working Time

For the past few versions of Microsoft Project (Project 2000, Project 2002, Project 2003) the changes to the desktop application have been fairly minor. But Project 2007 shows that some attention is again being paid to the desktop user. One of the more subtle changes that has been made is to add more functionality to the "Change Working Time" feature. This is the way that a user sets and modifies calendars. Go to the tools menu, select "change working time" and the new dialog looks like this:


In this example I'm setting the first day of January to be non-working time. What is new about this is that you get to name the exceptions. See the list below? Type in a name for it and you can more easily keep track of it. I am guessing that the name of the exception is retrievable with some code so you could conceivably extract all the exceptions from a project using a bit of VBA and check them against some master list.

The other exciting thing about this is that you can set an exception to recur. Since Jan 1 comes once a year, I'm setting it to be an exception on a yearly basis in the following screenshot:


The options are pretty self-explanatory. You can set it to be the same calendar date or if you want it can be the first Monday of a month or the third Tuesday or whatever vacation vagaries your clever company decides to inflict upon you. These options are also available for monthly recurrences. Just knowing that you won't have to scroll through months and months just to set up standard holidays is a great help So is the ability to label the exceptions so you know that 5 days in December of next year are blocked out because the office is being painted rather than having to guess why no work is going on at that time.

I recommend you work through this as you start any new project. Official holidays and vacation time can easily eat up a month of time. If you haven't accounted for this in advance you will find yourself postponiing that vacation or eating Turkey and Pumpkin pie at work.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16


Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.34