Posted on

The ASPE Project Management Professional Boot Camp

Okay, I’ve decided to do it!  I’m attending the ASPE Project Management Professional (PMP)® Certification Exam Boot Camp in Denver, Colorado!  It is part of a twelve-city tour by ASPE, Inc. to educate and prepare would-be project managers for the PMP Exam.  Cool!

Wouldn’t it be neat to read the unbiased personal experiences of somebody who had been through the course before taking the plunge yourself?  That’s exactly what I’m offering in this series of blog posts.  You’ll get my unvarnished daily experiences of the entire PMP Prep seminar.  After reading them, you can decide if this is for you.  I expect to enjoy myself, so you probably will too.

I’ll be posting my personal experiences every day I attend.  You’ll get a firsthand look at the whole process: the course materials, the homework, the hardships, and the excitement along the way – everything one might expect when taking such a course to prepare for sitting the PMP exam hosted by PMI.  See links below to check out the ASPE course I’ll be taking.

Honestly at this point, I just have a sketchy view of the week ahead.  I sort-of know what to expect, but not exactly.  I’ve been doing project management for longer than I care to divulge, but have never taken the PMP exam, and never formally studied the disciplines of project management.  Of course, having worked in engineering shops since college, I know much of the terminology and probably apply the principles on a daily basis.  So I’m coming from a different perspective than those who may just be starting their careers.  Honestly, I wish I’d done this a long time ago, but it’s never too late to improve your career with training like this.

To prepare, I read through the ASPE PMP Boot Camp overview and course outline (see link below).  I learned that there are four very full days of coursework – from 8 AM to 6 PM.  (I’m expecting to drink from a fire hose.)  The course outline lists 68 topics grouped into 8 areas.  We’ll cover such lofty subjects as Project Management Overview, The Project Management Life Cycle, The Knowledge Areas, The Elements of Project Management, The PMP Exam, The PMP Certification, and The Credentials.

After finishing the course, they say 97% of ASPE students pass the PMP examination.  That’s reassuring.  It probably means I could too!

The cost is $2,395.  Honestly, I think that’s a small price to pay to advance your career.  I mean really… if you plan to spend any time around projects for next forty years, this is probably a good idea – it doesn’t matter what your role is.  You’ll certainly earn it all back, especially since it launches you on a fast-track to higher management positions.  And PMI claims a PMP certification it directly impacts your salary.  Who doesn’t want that?  This little-understood fact is a big deal for career advancement:  Get all the training you can handle.  And get it early in your career!

Helpful links:

http://www.aspe-sdlc.com/courses/pmp-boot-camp/

http://www.pmi.org/certification/project-management-professional-pmp.aspx

http://www.projectteamblog.com/?p=239

Links to previous ASPE PMP Boot Camp posts

 

Disclaimer: The thoughts and feedback for the ASPE PMP Certification Exam Boot Camp associated with this series of posts are my own.  In exchange for providing my feedback on this community forum, ASPE has provided benefits related to my course attendance.

Posted on

Engineering Begins with Prototypes

I was talking with a senior software developer last week about the importance of early prototypes to define products. We concluded that it is pointless to begin developing any real architecture or engineering until the prototypes are finished and signed off. You must put your ideas into tangible form before you can trust them to the discipline of engineering. And customers must see examples of the finished product before you can move forward with deep development. Here’s why:

Under-the-hood engineering depends entirely on what you plan to sell. Notice I did not say what the developers thing might be cool or trendy. It’s what you plan to sell. Period. It doesn’t matter if you are selling transmissions or skyscrapers or operating systems; you have to know what the customer wants before you can build the most efficient version of that. Just try to dream it all up alone on a deserted island – without any input – without customers telling you what they will pay for and what they will not. That’s a lot like what you’d get if the developers in their Tommy Bahamas island shirts said, Oh, yeah! That’s so cool. Let’s make that!

Prototype Prototype

Take the automobile transmission for example. If you designed it on a deserted island, and sent the designs straight into production, the risks would be enormous. The finished product would likely have extra gears, “cool” new ideas, and “special” modes that the customer never asked for. And won’t pay for. All those extras make the product less efficient, more costly to manufacture, and more costly to maintain. You probably can’t afford that. Only the most efficient and cost effect designs survive. In other words, only what the customer asked for – nothing more.

Sure, you can get creative and throw in some extras. I call that “programmer candy.” The product doesn’t have to be a total bore. But make sure your core competencies are taken care of first.

 

Prototype

 

Also, it should be understood that prototypes can rarely be morphed into shipping products. (Managers don’t get that.) They are usually throw-away models, so expect to add that extra time to your overall project schedule. For instance, take the old clay automobile models as an extreme example. Remember them from the 1950’s? Even after sanded and painted, they still couldn’t serve as production automobiles. It’s almost humorous to imagine. But still, it has always been a strong desire in engineering circles to go from prototype to shipping product with the stroke of the pen. After all, the prototype looks so real, why not just clean it up and ship it! That’s what the manager usually ask for. Actually, that goal is not far off in computer-aided design, like software development, because editing is so easy. Not so with clay models.

Posted on

YouTube Video: Consulting Software

This YouTube video for consulting software is pretty neat. It covers a lot of ground in five minutes, and is worth taking a look at. Amateur, but neat. The premise starts with a timesheet and closely related time log view where consulting hours are displayed. Of course, the timesheet is a typical Monday thru Friday grid with client projects on the left. Things got cooler with the time log ivew. The time log displays the same records as the time sheet, but in a top-to-bottom view.

Consultants will drool over this. Trust me.

For every time log record (which is also displayed in the timesheet) you get a client field, project, category, start and end times, actual work field, client rate, client cost, billable, and billed columns. There are other columns not shown that can be added to this view. Plus, you can filter that time log view to show only the work you did for a certain client or project, or only the work for a selected consultant. Or only work for a selected date range. That’s slick! You can also filter out the non-billable records and only see what is billable to the client.

But this is only where the app just begins…

The video goes on to show a glimpse of the billing rates window. (Wish it showed more.) It seems that you can set the billing rates for each consultant, and for each project they work on. So every consultant has his own rates for every project. And they only see the project they work on. Nice. But again, the video is brief, so you have to check this out for yourself – it’s just a five minute overview.

If time tracking is not enough, there is a menu item to show project revenue over a 12-month timeframe. This lets you see trends for the coming months and identify bad months that require attention. If only it also showed historical results for the last 12 months… That would be cool, but probably not as useful. Every project has its own win/loss percentage projections so it acts like a sales funnel. But all that’s a side issue that consulting companies get for free. Sure, you’ll use it, but the real stuff is logging billable hours.

The video sticks right to the point: client receivables and consultant utilization rates. That’s is the heart and soul of consulting. Get those wrong and you fail. So those reports let you see where your money is coming from, and what your effective billing rate really is. In other words, how much is your organization is billing for the work it does. Reports like this naturally raise the question, “How to increase your effective billing rate?” Edging out small increases is what consulting is all about. If you spend too much time on non-billable or in-house jobs, you die. If your effective billing rate is too low, you die. If you don’t book gigs, you die. If you don’t invoice billable hours, you die. This program seems to get that.

What is not mentioned in this video is equally valuable: expense tracking, client invoicing and QuickBooks integration. Yes, the product has those things, but the video fails to highlight them. Why? Not enough time, I suppose… I’m not sure. But it’s nice to know that there’s more to this product than the basics that can fit in a 5-minute video. Definitely worth a look.

Check it out: Consulting Software

Posted on

That’s Where Experience Comes In

Recently, I overheard a senior project team member reminding a junior software developer to make sure his code built and could be checked in every day. He reminded the junior coder that we now have more coders on the project, and that leaving files checked out for multiple days put others in a difficult position. They could not get his changes until he checked it in, and long delays held up forward progress of the project.

That conversation got me thinking about all the little things you learn throughout the years. Here are some more to consider.
A few things experience has taught me:
• Check your code in often
• Don’t go dark for long periods of time
• Make yourself accessible
• Research everything you don’t know the meaning of
• Try new things
• Don’t get locked into legacy products
• Upgrade your development environment often
• Get a new development machine every three years
• Network with team members
• Answer every email you get, and in timely manner
• Get on Skype
• Blog often
• Re-read your emails before sending
• Let no bug survive
• Don’t be an obstruction to others
• Clear obstructions for those who work with you
• Take a vocabulary class
• Use good grammar and punctuation, not IM slang
• Decline unproductive meetings
• Produce a lot of code
• Design before you code
• Get peer feedback
• Learn to spell
• Work on communication skills
• Make a lot of friends

Got something to add? Become a contributor and add your comments below. I’d love to hear them!

Posted on

Define: Fixed Duration, Fixed Units, Fixed Work

Fixed Duration: The task calendar ‘Duration’ will not change when you change the ‘Work’ or add resources.

Fixed Units: The resource percentage of work will not change when you change the task ‘Duration’ or ‘Work’ hours.
Fixed Work: The ‘Work’ hours will not change when you change the ‘Duration’ or percentage of resource work.

Double-click on a Microsoft Project task to display the dialog box below. The field we’re describing is highlighted below: ‘Task type’.

Task Properties

The default setting for ‘Task type’ is Fixed Units. That means the percentage of resource work (Example: “Buzz[50%]”) doesn’t change when you enter a new number for the work hours. For instance, if Buzz is set to work 50% of his time, changing the amount of work won’t change that. He will still work 50% of his time.

Changing the ‘Task type’ to Fixed Duration causes the Duration field to not change when you enter ‘Work’ hours.

Changing the ‘Task type’ to Fixed Work means that the Work field won’t change when you update the other two fields.

Posted on

False Front Prototypes

When you watch the old Westerns like ‘3-10 To Yuma’ you are usually treated to a Main Street with old-time businesses and homes on it. Horse drawn wagons lumber by. Victorian dress is on full display. A child taps an iron barrel ring down the dusty street with a stick. There’s the obligatory livery station, bank, gunsmith and hardware store, and cobbler. They all sport a nice tall false front, as the turn of the Century buildings often did. It’s exactly like “real life” in 1880.

But what you don’t see is the backs of those buildings. The Hollywood cameraman never goes back there. Guess what? There’s nothing back there! The buildings are literally just false fronts. You couldn’t actually live in one of those houses or do business in one of those stores. Sure, there are a few sets where you see characters going into and out of those businesses, but those movie sets may be in a completely different sound stage. Nothing is as it seems; it’s all staged for the camera.

Got your attention? Now consider how this happens in engineering…

In engineering, we build prototypes to help people see what a finished product will look like. What people? Customers, potential investors, buyers, company executives, project stakeholders. Everyone needs an idea what a product will look like when the engineering is complete. It gets everyone on the same page, and dispels misunderstandings. Sure, the prototypes have a few warts. It can have reduced functionality, but it must *look* like the finished product, and must allow the sales force to tell the story and make the sale.

The problem with these prototypes is that they have almost none of the proper engineering – much like a Western movie set. Sure, they look good, and may even appear to work. For the purposes of a First Look, they satisfy everyone curiosity and need to see something tangible, and they get everyone thinking in the same vein. But they may not have any of the correct functionality! That fact alone leads to a false sense of completion.

Project managers, engineers, project stakeholders, and everyone alike can be lulled into a false belief that these systems are just a step away from completion. In actuality, they are like false front Western movie sets. You could never consider actually using them for everyday purposes. But after looking at them for an extended period of time, you come to a false belief that you could. You forget how far they are from reality.

It’s that “one step to final product” illusion that gets everyone into trouble — especially the engineers. They are the ones tasked with readying the product for release. Everyone around them believes the product is almost there – almost finished. But it’s not. The stakeholders have big money riding on a swift move from prototype to production. Customer expectations have been set, and they are waiting – sometimes not so patiently. Problem is, there is no swift move. The prototype must be thrown away and the “real” engineering begins. It’s like throwing away the Hollywood false front hardware store and building a real one. You can’t just build onto the false cardboard buildings. They have none of the real factors that go into a real building. Real hardware stores are expensive! And they take a long time to build! They are nothing like the quickie cardboard movie sets.

�

Posted on

Overtime: The Devil’s In The Details

I keep running into the same old product development story: All the developers meet for a status update to compare with the project schedule (and this isn’t just a fault of project schedules… it happens with scrum stories as well) but the engineers are just a little behind schedule. Gee, what’s new? They all have just a few more tasks to complete their stories, just a few more details… And that goes on and on and on… It’s enough to shake my faith in project management methodologies. Not enough to shake my faith in the project team, just the narrow ruts we find ourselves channeled into. It’s the same old story. The program manger doesn’t have a full grasp of the detail that team members must face to complete their tasks. In fact, you can’t know that level of detail until you are the one doing the tasks. And sure enough, every one has 50 – 100% more detail than initially scheduled for. So… the schedule blown, and everybody is in trouble. And working overtime. Who made that up? Okay, I complete get that companies have to fight hard for an advantage. Overtime is a necessity just to survive sometimes. If you don’t do it, you shrink back into oblivion. So yes, overtime is good. But I’m not sure I like how it’s arrived upon. It’s always “our” fault because we haven’t completed our tasks, so there’s a mad scramble to complete the project on time. Overtime is never pitched as something good for the species. Or necessary for survival. Instead, it’s simply because we haven’t competed our tasks in a timely manner. Ooo, gosh.  I guess I’ve been complaining, huh?  🙂

Posted on

Failure, ouch…

Failure is simply the opportunity to begin again, this time more intelligently.
    — Henry Ford

 

These are not from Henry:

Project failure is a luxury few can afford.  Multiple failures can bankrupt you.  See that they don’t…

It really is true that project failure is an opportunity to redesign and restart.  If you think about it… why do projects fail in the first place?  They fail because of some huge flaw that nobody recognized at the outset (or that the stakeholders ignored).

So starting over with those flaws corrected is what Henry is talking about.

There were 13 years of development leading up to the Model T.  (1896 – 1909)  There was another 18 years of development that lead up to the Model A.  (1909 – 1927)  That’s a lot of failure!

But think about it… it’s also a lot of success!

Posted on

Task Lingering: Employees Avoid the Unfamiliar

Actually, not just employees… Everybody avoids the unfamiliar. But this post is about employees, and specifically project team members that engineer or develop new technologies. It’s about how employees sometimes try to settle into familiar tasks and avoid new and unfamiliar ones. And it’s about how to prevent that.

But wait… why prevent it? Isn’t efficiency gained by perfecting the familiar? By polishing your craft so you can perform it virtually without thought?

Yes, but this isn’t really about that. It’s about the propensity of employees to spend too much time on project tasks they have become familiar and comfortable with, to the exclusion of those upcoming tasks they dread the thought of.

I’ve heard reports of engineers racking up 200 – 500% extra time on tasks that could have been completed at the estimated time. Here’s the reason: people become comfortable with tasks they’ve spent significant time on and don’t want to leave them. The next task on their list may be unfamiliar and scary, so they stay on the one that doesn’t give off those vibes. The justification is that the current task could use some more polish.
Problem is, you’ve got to keep marching on. Your projects must be completed and delivered. You can’t afford to dally on project tasks you’ve already completed.

Here’s a technique you can use to discourage task lingerers. Set your timesheet “percent warning” to 75%. At that time, the task will begin reminding the employee that it’s time to move on. Of course, they may resist, but it’s a good reminder. Then set the “percent error” to go off at 125%. That stops team members from entering any more time. You can extend it with an administrator override, but at least you have some controls to monitor and manage task lingering.

Here’s a YouTube video that describes task lingering.

Posted on

Timesheet Administrators: Lock Your Timesheets Quick!

Have you ever locked your company timesheet when the week or pay period is over? If not, you’re probably wondering what for? Why lock an employee timesheet? Or you might be wondering how to do it at all.
Locking employee timesheets is done for two primary reasons: payroll and client billing.

First, payroll: If you use your timesheet hours to pay employees, those hours must be verified and deemed correct before entering them into payroll. Nobody wants to be shorted just because they missed a few daily entries, but it happens. You also don’t want to pay crafty employees twice what they should get, just because they entered 80 hours in for the week. Again, you’ve got to verify and certify before timesheet hours go to payroll.

But what happens if an employee makes a change after the hours have gone to payroll? For instance, they realize later that they actually worked a few hours overtime. Understandably, they want to be paid for those hours. But they may not know you have already cut the check. So they innocently enter the extra overtime hours, and nobody notices! The check was already cut before they entered them. Yikes!

Locking all the employee timesheets before you cut checks is the only safe solution.

In the example above, the employee would not be able to enter his overtime hours for the previous pay period because it was already being processed. Lock it down and they can’t enter any additional hours. Of course, they’ll come back screaming, but at least you won’t miss the hours. Just tell them to enter the hours for next week and they’ll get paid for them in the next check.

Second, client billing: It’s the same issue as payroll above. Employees who enter time for the purposes of billing clients may not know the exact time you cut an invoice. The scenario is the same: The Accounts Receivables department cuts an invoice for the previous month’s work… and then a day later one of the employees working on that project enters some additional hours – AFTER the invoice was already cut!

That’s a bad situation!

The Accounts Receivables department doesn’t realize that more time was added to this invoice date range, and, the employee doesn’t realize that the invoice has already been cut. So the billable hours he entered are effectively lost. Sure, they are in the system, but nobody knows they should be included on an invoice.

Oops!

Again, the safest solution is to lock the invoice date range before cutting an invoice. This prevents any new hours from being entered. Employees will get an error and realize they should put the hours into the next pay period instead.

Try locking your timesheets, if you deal with payroll or client billing!