Online Learning: Project Management Archives

March 13, 2005

PROJECT MANAGEMENT: Clients Behaving Badly

Whether developing courses in-house or out, all of us have clients to satisfy - managers, deans, SMEs, faculty, learners, etc. - and a lot of time and energy in project management is spent on coming up with paradigms for avoiding problems and increasing client satisfaction ... as well as smoothing the inevitable bumps that occur when a client makes seemingly irrational demands or otherwise appears to be somewhat less than cooperative.

Of course, these paradigms can be very useful. And in many cases, following advice like "treat in-house clients like customers," "manage your client expectations," "clearly specify deliverables," and "focus on process, not personality" is essential in ensuring that you meet your targets for time, budget, scope, and course quality with a maximum of client satisfaction and a minimum of bloodshed.

But all of these paradigms and most of this advice have one thing in common: they assume that your client is, at bottom, a reasonable person with a vested interest in getting the work done.

Unfortunately, this isn't always the case.

Don't get me wrong, the vast majority of clients are rational and cooperative when the project manager does a good job of communicating expectations and status and of specifying deliverables, requirements, and conditions. A few are even a dream to work with. And there are plenty of occasions when, if you diagnose the reason behind a client's seemingly bad behavior, you find that the problem boils down to mistakes on your side - the most common being faulty communication on the part of the project manager or others on the course development team.

But there are also clients who are nearly impossible to work with.

There are staff who, annoyed that management has decided to outsource an important project, will do anything they can to undermine and subvert a vendor's work. Something similar can happen to in-house staff where internal politics or rival departments are involved. There are SMEs and managers who see development staff as convenient scapegoats or slave labor. There are managers who refuse to honor their obligations in a contract - adopting a "go ahead and sue me" attitude. There are managers who initiate a project, get staff and/or vendors working on it, and then lose interest, leaving the development team twisting in the wind.

And there are people who are just plain rude.

While it might seem that vendors, contractors, and freelancers are most vulnerable, there are actually a few things they can do to keep from being terrorized by these clients behaving badly, since they can usually design a contract that has a built-in "exit strategy" ... get some money up front, tie payments to deliverables, have a termination clause, avoid "scope creep," and be sure to hold some assets back until payment is received. And, most important, they can decide never to work with that client again.

These luxuries are generally not available to in-house staff, who can become totally demoralized by repeated exposure to these types of internal clients if they don't have decent management support as a backstop. If the anecdotal evidence of students and colleagues is any indication, staff in this position generally adopt the same strategy: stay out of the line of fire, do as little real work as possible, get really good at playing Minesweeper, and check the want ads every day.

Of course, these types of clients can be found in any type of endeavor - not just online course development - and learning to deal with unreasonable people could be seen as just another sadly important life skill. And, luckily, for most of us, this type of client is the exception and not the rule.

While it's hard not to be cynical after encountering such a client, your best bet at the end of the day is probably just to treat it as you would any other bad relationship: Get out as soon as possible and without too many scars, lick your wounds, move on, and try not to let the experience sour your future relationships.

Posted by Joanne Tzanis at 10:20 PM | Comments (0)

January 05, 2005

PROJECT MANAGEMENT: Is Your Project Doomed to Fail?

You can find out using this simple "one-minute" risk assessment worksheet . The worksheet is based on the findings of a research project to analyze risks in software development (using data from senior IT managers).

Not surprisingly, the key software project risk drivers were found to be:

Use of an inappropriate methodology
Lack of customer involvement
Lack of formal project management practices
Dissimilarity to previous projects
Project complexity
Requirements volatility

(Link via Slashdot)

Posted by Joanne Tzanis at 03:06 PM | Comments (0)

October 22, 2004

PROJECT MANAGEMENT: Contingency Planning

I'm back online after dealing with a death in the family, which also happened to occur at the same time as the second week of two of my online courses, the first week of two classroom-based courses, and some F2F seminars. At the moment, I'm still trying to sort things out... I'm hardly focused on blog posting - and I refuse to even look at my aggregator, which is surely exploding with several weeks of unread posts.

Since I like to look at everything as a learning opportunity, I'll say that it's interesting to note once again how less well-formed contingency planning often is in the online world as opposed to the traditional classroom.

Part of the problem is that there are so many more choices that can be left up to the online instructor ... for on-site classes, it's simple - if you aren't in town you can't teach, and it's up to the administration to decide whether to cancel, find a substitute, or delay.

But for online instructors called out-of-town on a sudden emergency, there's always the question of whether or not the facilitator will be able to log in from wherever he/she is (and how soon he/she will be able to do this). If there is no designated administrative liaison monitoring the class, the instructor may well be the only person communicating with students and the only one who has any clear picture of the class status, structure, scheduling, and time zone issues for synchronous elements. If the class is asynchronous, there's a question of whether or not any delay will be needed to be announced at all. And, of course, the facilitator may be dealing with these questions at a difficult time when he/she isn't thinking clearly and focused on the class.

Administrative systems are rarely set up and staffed well enough to handle any amount of ambiguity in SOPs, so there's a huge opportunity for communications failure when administrators must suddenly act as the liaison between the facilitator and class participants in these types of situations. While some might say that a standard, inflexible cancellation policy is the only thing that makes sense in these situations, I can't help but think that this goes too far in the opposite direction.

As for myself, I am definitely planning to re-evaluate the contingency plans for my own classes to see if I can't suggest a more workable approach for everybody involved...

Posted by Joanne Tzanis at 01:35 PM | Comments (0)

July 18, 2004

RESOURCES: Project Management Tools

This "tool box" from e-LearningGuru.com contains a variety of downloadable worksheets and calculators in Word and Excel for tasks related to project management, evaluation, and cost-benefit analysis.

The site also links to a Flash-based calculator from Ernst & Young designed to help calculate the potential cost savings for large companies of moving some portion of classroom-based training online. While the reliability of the calculation achieved is definitely questionable, this is an interesting exercise for those trying to make a "bottom line" case for online learning.

Posted by Joanne Tzanis at 09:47 AM | Comments (0)