Managing multiple projects 1

[A0C61ZZ]

Hello all,
Our company has secured a Maintenance contract for the client applications (around 10) across different technologies, platforms. I have been asked to manage it.
The architecture is complex. In addition we are also busy with the daily support receiving calls from our users/clients.

Usually we handle 2-3 different workorders at a given time distributed amongst team members.

My problem is if we start working on say 3 different application/ workorders at the same time some new issue crops up and the priorities keep on changing.
This issue could be due to
1. An user demand with a new urgent request
2. Limitations uncovered during the maintenance of the technology/architecture/environment (dev, prod)

This results in schedule slippage. Are there any best practices/ideas for managing a complex project with a high turnover of requests affecting the schedules of the current project?
Anybody worked on a project of similar complexity??

Thanks,

 

[PDQBach]

The really quick answer is: a change management process. It's difficult to tell from your description where you are in the corporate "food chain" but it seems that you're not really in a position to push back by insisting on a signed off document by the project sponsors of all the affected projects.

If you were then you'd get the request, acknowledge it, do an assessment of the projects that are being affected and then send out a change management document to the project sponsor of the new project as well as to the project sponsors of the affected projects. Your assessment would show, for each project, the impact (delayed delivery, cost adjustments, etc.) and you would get the project sponsors to sign off on the change. Failure to get a complete set of signatures means that you change only the "signed off" projects (and that probably includes the new one) and the other(s) continue on their previously developed schedules.

Since you don't appear to be at that level, you are probably left with "the memo trail" solution: document for your boss (cc to the project sponsors - but I'd be politically careful about the distribution) about the impact. Yeah, I know: takes time and you don't have it. Make it. It's the only way you'll have to manage the stress you are currently experiencing.

You're likely going to get "compress the other schedules so everything gets done on time" memos. You handle those by confirming with the resources doing the delivery that the time estimates are accurate. After that, it's your own accumen that will help you negotiate the final results.

Incidentally, if you do get signatures approving changes then your position is significantly strengthened: when you get requests you can easily say "But Mary and Bob have already agreed to the existing schedule. Your change is going to have an impact on that. Perhaps you should discuss it with them first and have them tell me what changes they are prepared to accept in their schedules.

 

[A0C61ZZ]

We are working for a financial institution and the business area/function/prod we are supporting is out of market these days. (it was a hot product initially). There's still a sizeable market for it so its been retained as a "Strategic advantage".
So we are at the bottom of the "food chain", with less funds,resources.
You are right, we are swamped with requests so there's no time to follow the formal methodology in detail including sign-off docs. Every sign-off is in an email.

The only stuff that gets documented in detail is when something blows up and eyebrows are raised by the top mgmt in which case we have to file a postmortem report.
However I do make an effort to highlight stuff in weekly & monthly status reports.

 

[PDQBach]

Some additional random thoughts.

Even though you are swamped, there is still an opportunity to employ a formal methodology. It does *not* have to be all-encompassing -- you can restrict it to a single cover page with a bunch of items that need check marks and you can staple/paperclip appropriate documents to it.

Here are the "check mark" things I would have on it. Basically, each item below is a line on the cover page and never more than a page max of supporting info that you paperclip to the cover page.

"Charter" (deliberately in quotes): you don't want a fully fledged one, just one that names the principals (sponsor name, PMs name), budget, estimated work effort, internal priority (*your* priority, not the sponsor's), objective. You need this to keep track of scope changes. Scope creep rarely kills projects, but it does "kill" people because they keep getting asked to do more and more without any formal review/acknowledgement of the changes.

Schedule: Excel printout

Risk list: you need a focus on risk events that affect this project only. You don't need the traditional "staffing risk - might not have the right skillset at the right time", but you do need "Bob is going to get it started but then he's taking two weeks vacation" or "Customer facing app -- may need two or three recycles to get UI working smoothly". If this goes more than two paras, you may be looking for too many generic risks.

Purchasing: you might not need in most cases to buy stuff, but keep it in just in case.

Staffing: "round up the usual suspects"; names and days of work only. You should also have a pre-determined "loaded cost" for your resource types so you can give a rough-and-ready cost.

Costing: now that you have a pre-determined cost rate for each resource type and a schedule you can quickly tell the sponsor what the project will cost the company. They'll still tell you to do it anyway (and you will) but it's a useful reality check.

Meeting Schedule: schedule for internal project progress (or lack of same!) meetings (you and the lead); schedule for external project review meetings (you and the sponsor -- and maybe some others). You're doing this to formalize the reviews so that they aren't ad hoc.

The info from these cover pages will help you develop your own metrics. These are for you to bring up during your annual salary discussions: number of projects you started, number finished, number still processing, total cost of all projects, total work days of all projects, ... anything that makes your workload look high and makes you look good. Anybody can quote numbers, with your cover pages you've got support.

Change management: one line per change to the project and each line has a page (or more, if necessary) describing the changes (mods to program specs, for example). Each line should show the change date, change id, change description (5 words), cost delta, time delta.

Note the low level of admin required on your part. One other thing I'd consider doing: getting a large whiteboard where you show current project status. You update it during the internal review meetings. It won't help you do your job but it will be a visible indicator to visitors about the work you and your staff are doing.

At the end of the day, the issue isn't a discussion of formal methodology (that game is finished and the teams have left the field -- you *need* the rigor and discipline that a methodology brings). The discussion is "how elaborate an implementation do you need". You need something you can put on a Palm Pilot -- just what I discussed above.

 

[johnherman]

As usual PDQ is on-target. I have detected a new star in his constellation.

-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright

 

[A0C61ZZ]

Now that was insightful from PDQBach.
Ours is a fixed bid project, so Costing is not required. However I do keep some docs as mentioned but not the Risk list (Risk list eluded me). Will include it.

Ours is something like a cross between projects and operations. We have fixed time frame workorders (which could classify as projects) but then some stuff is purely repetitive on a day-to-day basis stretching into infinity.
Thanks