The Hard-Nosed Project Manager

Manage Projects using SharePoint and Microsoft Project webinar on 9/14

I just finished listening to this webinar.  It was less about project management than project management tools so I got less than I expected being a long time SharePoint and Project user.  Obviously the speaker knows these tools very well and her demos where almost flawless.  I think you should listen to this if you are interested in tools or if you are a newer project manager.  Kind of as a stepping stone to Project Server and SharePoint workspaces.

One thing that we were sadly reminded of is that the tool most used for scheduling is Excel… Personally I suffer a mental block if I try using Excel for schedules.  You can open a can of beans with a screwdriver but why would you if you have a can opener? 

By the way, sound quality was very bad with lots of hissing.

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.

 

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.

A believable plan

As I was catching up on my reading I landed on The Late Finish Strategy by Glen Alleman.  I find that reading his posts usually make me think, sometimes make me smile, and that linking to them make people believe that I’m not that dumb after all…  Often times Glen’s post are about those common sense things that, for some reason, end up being neglected.  Things like knowing what you are trying to deliver or having a believable plan.

In this post he talks about the need for budget and schedule margins.  Most of the time you are not given margins; your team has to fight hard to build them up.  Most of the time you look at your schedule and there is a sea of red tasks; the critical path extends from project beginning to project end with no break.  To state the obvious; if your schedule does not have any slack, it’s not that you MAY get in trouble, you ARE in trouble.

Now, if you are blessed with some slack in your project schedule you are not out of the woods yet.  As the old saying goes: ”How does a project end up late? One day at a time…”  So, however you got that slack, you have to fight tooth and nail to avoid seeing it disappear.  You likely won’t be able to end with all the slack you started with or all the slack you managed to build up but you just can’t give it away or you’ll end up being the meat in a “rock and a hard place” sandwich.  This situation can happen real fast or creep up on you but the result is the same; pain.

I’ll add to Glen’s post that on top of a budget margin and of a schedule margin you also need a personnel margin.  What good are schedule and budget margins if you don’t have the personnel to do the work?  I contend that like for budget and schedule you need a personnel margin.  Why?  Here are a few scenarios were that margin would be useful:

• Your resources are “potentially overcommitted” due to their name or skills being linked to numerous proposals or future projects.  Don’t you love “do not substitute” clauses in contracts?
• You work in a matrix environment, your resources are on “loan”, and the loan is being called.
• Your resources are committed to more than one project and the other project manager (not you of course) dropped the ball, his project is in trouble and he is sucking all available resources.
• Your resources are committed to more than one project, business priorities change and your resources end up overcommitted.  Multitasking and overtime are taking their toll.

Once again, if your schedule does not have any slack, it’s not that you MAY get in trouble, you ARE in trouble.  You must have slack in your schedule, budget, and resources or you plan is not believable and you have to stop lying to yourself and others.

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. 

Agile? Me too or 2?

Craig Brown (Better Project) commented on my previous “Agile? Me?” post.  My main take away from the points he makes are that Agile, although not entirely new, packages software project management in such a way as to make it appealing to teams.

Other important points are:

• The command and control approach to software project management does not really work.
• A fool with a tool (or methodology) is still a fool or, in his words, “Smart people get it right. People that struggle with common sense will fail at this management system as much as any other”.

As previously stated, I see Agile as a different language or dialect of project management; I do understand that some (many?) project stakeholders do not “get” traditional project management.  I lost count of how many times I’ve been asked for a schedule only to have the person asking go totally blank when receiving it and then asking very basic questions about Gantt charts. 

However, talking with someone experienced in scheduling, EV, etc. you don’t get the blank stares.  This goes to say that speaking a language that all stakeholders understand gets you a long way down the path to success.

The aspect that is still evading me is, assuming that the Agile practitioner is not a fool or a micro manager, what is the economic benefit to the project organization that takes the Agile path?  Can I expect 15% shorter schedule, 17% lower cost, 8% lower rework, 21% fewer bugs, etc.?  The numbers are not that important but they would help me make a decision while investing my time and money training myself.

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.

Agile? Me?

I try to continually improve myself.  I know, it’s hard to believe, but it is still possible for me to do so…

So, I’ve been thinking of expanding my project management skills some more but, what do I pick?  I already have the piece of paper that proves that I know something (the PMP) and I work in Manufacturing IT so I could go ITIL, I could go PRINCE2, I could go IPMA.  All of those are PMP look alike certifications with various strong points.  For a comparative review lookup this post from the How to Manage a Camel blog.

I also trained on RUP a few years ago so I could go Agile/Scrum or some other approach.  In my current work environment Agile methods are not really in fashion; my clients typically insist on gate reviews and a waterfall approach. 

That being said I can appreciate that understanding Agile could be useful to me it is like speaking more than one language or knowing more than one culture.  On that level, it appeals to me because, after all, you’d have to be an idiot (I was going to say [20100712 - PR - expletive deleted] but it is not polite to do so…) to think that there is only one good, fits everything approach/language/culture.

So assuming I decide to go Agile, can anyone out there engage in a conversation with me on benefits they have realized from going Agile?  I am not looking for dogma (e.g. waterfall is crap), for preaching on the Agile Manifesto (I hate motherhood statements), for how Agile is better that sliced bread/the 4-hole button/the wheel.  What I am looking for numbers on hard benefits (consistently cheaper, consistently shorter schedule, etc.) or soft benefits (easier to lead the current generation, higher customer satisfaction, etc).

Go ahead, convince me to go Agile.  I’m open-minded about it; I’m just looking for good arguments before I invest my time.  Thanks in advance to those who chime in.

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.

Risk management is a day 0 activity

This morning I was participating in a Mentisor seminar/roundtable activity on Risk Management and Scope Management.  Both subjects are basic project management topics that often don’t receive the attention they deserve given the mayhem that neglect may cause.  This got me to reflect on a conversation I had a few months ago with a client that got badly burned.

In my line of work system validation is mandatory and very expensive compared with hardware/software/programming costs.  The numbers vary and each of my clients has its own pet number but it is typical to add 170%, 200%, or even 220% to the purchase cost just to account for validation.  In hard numbers this means that a $1M system will cost $2.7M to $3.2M by the time it is validated and rolled out.  If the system is more expensive; you do the math.  It can get scary pretty fast

A side effect of this multiplier is that clients understandably fight scope change tooth and nail.  We do the same; no one wants to be the donkey in a game this pricey.  The title of this post being “Risk management is a day 0 activity”, you are probably wondering where I am going with this?  Well, the wait is over; some best practices related to Risk Management and Scope Management should avoid a lot of wasted money:

• Risks are built in the project approach; a project or product is not a repeat activity and some of this innovation is likely to have unrecognized risks. Recognize this from day 0.

• Avoid Swiss army knife software; there is no software package that does everything well and all those marginal features will still need to be tested and validated ($$$). What is the likelihood that some of these features are putting you project budget or schedule at risk?

• Avoid stakeholder’s pet feature for the same reason as above. I’ve had requests for reports that have the same content but packaged differently; keep only one variant and let the people adapt. There has to be a positive aspect to that Evolution thing.

• If you can’t avoid the two previous points, identify those features that are risky, track their triggers diligently, and the minute those triggers engage let the project sponsor know. You may be able to jettison them before they really hurt the project or at least to minimize their impact.

• Remind your stakeholders that featuritis is costly to implement, to validate, and to live with over the live of the product or system. Remember COBOL, FORTRAN, etc? Systems written in those languages still need to be “fed” years after rollout by old guy like me who will retire eventually.

Don’t tell me that these points don’t ring true and that they don’t represent situation that repeat themselves, with predictable outcomes.  Recognizing and managing risks from day 0 will save you a lot of aggravation and costs.

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.

3 Point Estimates

I was catching up on my reading after coming back from vacation and I hit on Glen Alleman’s Herding Cats blog particularly this post.  Be sure to read the comments too.  If this content doesn’t get you to subscribe I don’t know what will.

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.

Bracketing the target

I like appropriating expressions of my past lives and reusing them in project management.  Bracketing the target is something an artillery observation post crew does; you start shooting for a target and then try to find its actual location by overshooting it, undershooting it, and shooting right and left of it.  Then you deal with it…

In project management the equivalent would be finding the true scope of a project which may be hidden within a large number of fuzzy requirements.  That fuzziness comes from a lack of context, the use of jargon, the piggy backing of requirements left behind from other projects, pet requirements, etc.

As I mentioned in my CHAOS theory post I believe that applying a Pareto law to the set or requirements would remove the 20% that really hurts the schedule and cost of a project and increase risk.  My experience is that when you leave those 20% behind you hardly ever get to include them in future releases; they just weren’t that “required”. 

Looking at it from a slightly different perspective Glen Alleman replied in a comment that at the US DoD, under Secretary Gates, 60% of the needed capabilities "now" are considered much better than 100% (or something near that) later.  This is a very good, very pragmatic approach to projects.

The best practice we’ve been using to get everyone on the same page is to do a prototype, demo it, and then make the necessary adjustments.  This prototype is not a throwaway; it is a rough draft of the end project.  This approach works with software projects as well as “consulting” assignments such as strategic planning.

Using such an approach as always allowed us to identify and then remove fuzziness from requirements.  It is also a great way of working around communication issues brought on by jargon.  The end result our clients and for us is less pain and typically a lower cost, a more accurate schedule, and less risk.

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.

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.