Language and Terminology of PMI

Planning to take the Project Management Professional (PMP) exam from Project Management Institute? Excellent move! That’s just the right medicine for today’s tight economy. You might even find that your position depends upon it. I hope that’s not true, but I’ve seen it happen.

I found an interesting way to prep for the PMP exam plus get a working knowledge of the language and terminology used in the PMP exam. There’s a North Carolina-based company with PMP and Agile instructors that set up classroom sessions around the country: ASPE-SDLC training. Of course, they also have online classes. You can contact them at http://www.aspe-sdlc.com/ and see the PMP Boot Camp class at http://www.aspe-sdlc.com/courses/pmp-boot-camp/.

I’m considering taking the class to sharpen up my own seat-of-the-pants PM skills. If I do, I’ll blog the daily experience here on Project Team Blog. You hear all the ‘torture’ I’ve been subject to.  But you’ll also get an honest day-by-day account of the course. After all that, you might consider taking the course yourself.

Stay tuned!

Define: Project Baseline

Project Baseline: A copy of the project tasks as they were at some point in time, which you can refer to at a later date.

Here is an example of two project tasks immediately after setting the project baseline.  Notice that the ‘Baseline 1 Work’ field has been copied from the ‘Work’ field.  As the ‘Work’ field changes throughout the project, the baseline is still available for comparison.  How did we do this?  Easy.  Just choose Tools, Tracking, Set Baseline within Microsoft Project.

Here we see the ‘Work’ field changed and the ‘Baseline’ unchanged.

 

Want an easier solution?
Baselining can be complicated and confusing, so “Sir Ganttalot” (a YouTube celebrity) has come up with an easy alternative.  Click here to see the YouTube video:

 

 

 

http://www.youtube.com/watch?v=c7BJ6%5F1pcgc

Essentially, Ganttalot creates a customized field named “Finish Date Changed” to identify tasks that have changed.  Graphical arrow indicators tell whether a finish date has slipped in the future or has tightened up.  These graphical indicators are easier to spot than comparing textual finish dates to baseline finish dates.  It shows you at-a-glance what’s changed from week to week.  Slick, I’d say!

Define: Timephased

Timephased: Total project task hours distributed over a period of time.

An example from Microsoft Project of this is shown below.  The hours for each project task are distributed over the duration of each task.  The hours per day is the ‘Work’ field divided by ‘Duration’ field.  In other words, the total work is spread evenly over the duration.  Choose the Microsoft Project views below to see these task layouts.

 

Tracking Gantt View:
 

 

Task Usage View:
 

You can see that the 100 hours are timephased over 10 days for the first task, and over 1 day on the second task.

MS Project Overallocation

Assigning a project resource to a task by percentage alleviates the problem of overallocation.  Below are two project tasks assigned to the same time period.  If they both must be completed, you have an over-allocation problem.  Over-allocation simply means that the person has been assigned too much work to perform in a given time period.  In all likelihood, they will not be able to complete the work.

 

 

Choose View, Resource Graph in MS Project to see the problem  Red bars mean the resource is overallocated for that time period.  In this case, there is double the work that is reasonably expected from the project team member.  So how do you fix that?

 

 

Here’s how to solve it:  Assign the resource to work only 50% of their hours on each task.  Assigning project team members a certain percentage of their hours reflects the likely situation on the ground.  Hald their time goes to one task and half to the other.  Let the resource figure out when to actually perform the work.

 

 

This is the new resulting project resource allocation graph.  It shows that the resource is fully allocated to 100%.

Seven Days in Utopia

The movie Seven Days in Utopia is clearly not up to Robert Duvall’s standards.  The story points were awkward and difficult to decipher.  One-shot git-er-done scenes and Karate Kid theme didn’t help.  But I managed to scrape out the movie’s arc and purpose.  It’s about faith and trust in God… and a little golf thrown in.

Buried in the poor directing was a principle that resonated with me.  Duvall’s character says, “The game of golf is about conviction.”  He continues with, “Watch out for that random idea that comes at you, that will throw you right out of your game.  Without conviction, it will make you question your game and shake your confidence.  Without confidence, you cannot win.”

It occurred to me that project management is exactly like that.  Without a clear strategy that rests on bedrock conviction, random ideas from so-called experts will shake your confidence.  You’ll chase a dozen “great ideas” from outsiders and never execute your strategy.  Although while that’s true, you must still remain open to new input.  It’s a touchy game.

Moral of the story: Develop a solid project strategy and hold your confidence.  Follow through with confidence.

Why Foundational Features Matter

Let’s say you know customers need a really complex feature, but your project team only has time for a basic implementation.  Do you wait until you have team resources to build the full implementation?  Or do you just build a basic foundational product that doesn’t actually meet any current customer requiments?

My answer: Start with the basics.  Add later.

Foundational product features are usually enough to sell the full implementation.  Customers can see that you have a percentage of what they need.  That helps them have faith in a full implementation at a later time.  They know it’s just a derivative of your current implementation.  But without something tangible to demonstrate, they won’t believe you’ll do the feature at all.

U.S. Losing Competitive Edge in Technology

The recent eWeek story regarding U.S. decline in science and technology (see below) is nothing new.  We’ve heard this same story for twenty years.  But is anyone listening?

http://www.eweek.com/c/a/IT-Infrastructure/US-Losing-Competitive-Edge-in-Technology-Science-National-Science-Board-610257/

Over the Christmas break, I did my bit to encourage passion in software development, engineering, and project management.  I mentored a college student with an Arduio board.  (See http://www.arduino.cc/)  The Arduino is a microcontroller with inputs and outputs for controlling external devices.  It’s big in university engineering departments.  Awesome, dude!

We stayed up past midnight wiring circuits and slinging C++ code to exercise the Arduino I/O ports.  In a rat’s nest of wires, LED’s flashed, speakers squealed, and relays clattered.  Cool!  When it was over, the kid had a new passion for product development and engineering principles.

Code ‘til you drop, and then do it again tomorrow!  That’s my answer to declining technology in the U.S.  And I suppose it’s also my preferred project management style.

Earned Value Increases As It Travels

Earned value (or the value you receive on your intellectual property) increases as it travels through the supply chain.  In other words, the farther an item travels from the manufacturer to the consumer, the more value it brings the manufacturer.  Consumer items change hands many times before they end up in consumer’s hands.  Each time they change hands, more money is invested, and therefore the value goes up.

Consider the illustration below.  A single egg isn’t worth much until it is developed.  Its value rises 100 times from nest to table.

Have you ever considered that software does the same thing?  It earns value as it passes from idea to developer, to QA, to packaging, to reseller, and finally to consumer.  So, the true Earned Value of a product is dependent upon its position in the supply chain, not just at the coder’s keyboard.  You account for such value by quantifying your products on their route to the consumer.

What’s the difference between ‘Duration’ and ‘Work’?

What’s the difference between MS Project ‘Duration’ and ‘Work’ fields?  The image below probably explains it all.  It’s a simple task from Microsoft Project that shows both the ‘Duration’ and ‘Work’ columns.

 

Task Duration

 

As you can see ‘Duration’ defines the calendar time that the task will be worked on, while ‘Work’ defines the number of man-hours.  In this case, Frank is scheduled to work only 40 hours over the next four weeks.  That’s only 25% of his scheduled hours.