The Hard-Nosed Project Manager

KISS

I have tons of amazing ideas for software products.  The only problem is that most amazing ideas violate the KISS principle.  When I was is the army, KISS stood for Keep It Simple Stupid (or Sir).  Basically non-KISS ideas are those that only an engineer or project manager would like.  You know the type.

I was reminded of the KISS principle while listening to episode 197 of The Project Management Podcast.  In that episode a product called Eppora is discussed.  Listening to the guy behind Eppora was like listening to me when I have an amazing idea; he was actually describing project management software I had thought of years ago but thankfully dropped.  The problem?  Grandiosity… 

Some features that rubbed me wrong:

• Most project managers and the companies that employ them don’t have the time and money to keep statistics about every person working on projects.  If only some project managers use it, the return on investment disappears.
• Those statistics are wrong anyway.  For example, easy task plus great programmer equals great productivity, hard task plus great programmer equal normal productivity, normal task and so-so programmer equal normal (maybe) productivity, and hard task plus so-so programmer equals… So match the wrong person to the wrong task and your statistics mean nothing.
• You can’t pay people on productivity statistics. Hard task plus great programmer equals normal productivity and normal task and so-so programmer equal normal productivity.  The two guys are worth the same?  Like hell they are.
• Many clients will not let their schedules live on or be accessed via “the cloud”.  Schedule information can be highly sensitive.
• Selling a critical chain approach is hard.  Most people are threatened by that kind of approach as they think it may cause them to sit on their hands if they are too productive.

I understand that the guy was kind of selling his salad but if you are going to make extraordinary claims you’d better have extra ordinary proof.  He has not given me the proverbial warm and fuzzy feeling.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request

Run, don’t walk (or crawl)!

Yeah, I know, it should be the other way around; but often it is not.  Why people or companies try to start any endeavour directly at the top instead of progressing from their current level evades me.  In project management you often see this with PMOs or Enterprise Project Management (EPM).

Enterprises get into a mad rush to create one or many PMOs when, up to that moment, they had never thought of actually managing projects or of having any type of processes however simple.  Suddenly an Encyclopaedia Britannica sized manual lands on your desk and every newly christened PM must abide by all of its teachings.  The reality is that typically these new processes are ill formed, ill fitting, and bypassed as much as possible.  Of course processes evolve on a weekly basis. 

The PMO craze has been going on for years now and in many organizations is in its Nth incarnation.  PMOs are not useless unless you design them to be that way.

EPM is the newer craze but in many regards follow the same path as PMOs.  I know of an organization where, up to very recently, no schedules where ever prepared yet they have gone whole hog on EPM.  You have to prepare a schedule, upload it, and maintain it.  Simple, no?  Maybe, maybe not:

• You are told not to put too many tasks in your schedule (nothing below deliverables).  When you contradict that edict with a whopping 700 tasks for a 6 month, 10 person project you find out why; the poor server can barely load, save, and publish something that size.  Forget resource levelling; my laptop is more powerful.
• In total contradiction with the prior directive, schedules are treated like a collection of post it notes.  Everything that comes to mind is now required to go into the schedule.
• In total contradiction with the prior directive everything that your sponsor does not want to explain must be taken out of the schedule even if doing so deletes predecessors or successors.  You can always add them later!
• You must stick to the original end date regardless of delays, scope changes, resource shortages, or whatever else happens.
• When you ask for the WBS field to be part of the enterprise template you are asked by the EPM administrator if you mean Work Breakdown Structure.  What else the freaking hell could I mean?  You are then told that you have to wait for a meeting of the steering committee to find out if adding your field will be allowed.  Something tells me that no one on that committee has ever run a project.
• You are told that you need to update a traffic light status based on earned value metrics but promptly find out that none of the EV related fields are visible.  I guess I’m supposed to go to that steering committee for that too.  By the way I found out that the traffic lights are not linked to EV anyway; they are set by hands and there are no guidelines for setting them.  All green anyone?

I guess that, if you insist on jumping off a plainly visible cliff, you may as well run and be out of your misery sooner instead of inching up to it.

What do you think?  As always comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Interesting video on resource leveling

Many PMs struggle with schedule resource leveling.  Most of the time, the schedule is not dynamic enough and resists leveling. 

The Ask a Project PM: Resource Leveling video (14 min, 37 sec) discusses a number of best practices around resource levelling.  The demo uses MS Project but the same best practices can be applied to other software packages.  Some of the best practices reference an Enterprise Project Management (EPM) system and portfolio management.

My take away ordered punch list:

• Use an up to date company calendar.

• Use individual calendars for each resource, based on the company calendar and on their specific availability constraints.

• Remove all constraints that are not essential. You may have set fixed start dates or other constraints for tasks that do not require them.

• Remove all dependencies that are not essential. You may have set dependencies between tasks that are not logically related. I’ve been guilty of that.

• Assign resources or resource groups to tasks.

• Set task priorities; higher priorities get scheduled first. I’ll start doing this; never knew about this.

• Set the leveling options for your software package.

• Start leveling and level periodically.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.