Help?

That said, to ease your local pain, the first thing that needs to be done is to determine the real availability of resources -- you can't plan individual projects, much less synchronize a pipeline of them, without getting a handle on what you have to work with. If expanding the project universe to include customer efforts is out of the question (for now), then analyze, by resource skill type, how many person-days are available, offset by those that historically have fallen prey to (what seem to be, but really aren't) unplannable efforts.

The other first thing that needs to be done is to develop clear priorities of your current pile of projects.

Then, using the results of these two efforts, develop plans for the first project on the list, then the second, then the third... as if they were standalone efforts, but with leveled resources based on the staff available.

Now, if you were using the Critical Chain approach to planning the individual projects, this next step would be relatively easy, but since you are probably not, you'll have to slowly add the individually projects to a synchronized pipeline schedule. Take the plan of the first priority project, set it in the calendar, and lock it down with a promise. (If it has a required due date, put it there, as long as the start of the remaining work doesn't require a time machine.)

Add each subsequent prioritized project, but for each one, push it's promise out to avoid overextending resource capacity. (There is no greater cause of multi-project chaos than trying to shove 10 pounds of sh.., I mean projects, through a 5 pound pipe. If you try, you'll be lucky to get 3 pounds out.) You can do this by keying on what we in the CC world sometimes refer to as "drum" resources -- those that are most common and most heavily used across projects. If you stagger project launches so that these bottleneck resources aren't forced to multi-task, then odds are most of the other resources won't be overly loaded as well. (If you had buffered CC schedules, you could rely on the buffers to absorb occasional resource contention of non-drum resources. If not, you'll just have to make your best analysis to determine the best use of a resource that's torn between two tasks.)

Oh -- If your organization refuses to deal with the unplanned (not unplannable -- just consciously unplanned) work, when staggering the project launches, you'll have to add some additional time between lauches to allow for it. If it's not needed, there's nothing stopping you from pulling the next project up in time. If it is needed, you'll be glad it's there.

I fear I've gone a little too far in my response. Given your quandary of "where to start," it's with understanding the system, in terms of its resource capacity and of the prioritized demand on it.
Saving Changes...

Thank you for your response, Frank. I've spent a solid two days banging on doors to try and gain a more defined sense of what's expected from me, as a PM.

The result of those conversations is this:
They (people with authority) don't believe that we can implement any type of project management. When they use the term "project management" they really mean project TRACKING. They're wanting metrics... that will show them where they're allocating their time. They're not wanting to change what their reality is, just be able to define it and paint an accurate picture. *sigh*

Unfortunately, one of the managers believes that he's got all the answers when it comes to project management, just none of the time. Soo... this is what he wants done:

They don't even mean project tracking -- it sounds like they mean resource tracking. It sounds like the powers that be have succumbed to their belief that they can't implement any type of project management. As a result, they don't. Someone once said something along the lines of "whether you think that you can do something or that you can't, you're probably right." I suspect that, as a result, they fell that if they can prove that everyone's been kept busy, they're doing what they can to "manage" the situation.

The problem is that I'm sure that the goal of your organization is not to keep everyone busy, but to actually accomplish something -- with 120 projects per year, probably a whole lot of somethings.

* Work with the designated team leaders, of the given project, to create a "plan" in MS Project. * Assign resources using that theory that they can all apply 100% effort, 25% of their available time. Of course, this is the gov't... so their available time changes with each breath taken. * Baseline the project. * Have *each* team member fill out a time card and submit it to me (on paper, because most of them won't touch Project Central or anything of that nature) and have me keep track of why projects derail.

I really don't have a problem with the first three, although 25% of available time bothers me a bit, along with the concern of how they will actually apply that time. If the do your tasks start to finish, and then go off and do other stuff for 75% of their time, it could be an acceptable situation. But, if, as I suspect from the apparent focus on keeping people busy, the more common situation will be one of bouncing-back-and-forth multi-tasking, full of sound and fury, signifying not much more than nothing. At least their time-cards will be full, but full with a lot of non-value-adding "now where was I on this?" restart activity.

As yes -- timecards...

That fourth bullet accomplishes what management wants to see -- documented use of time of busy resources. And you're right -- this is not even anywhere near something that is associated with project management. Project management is all about looking to the future, figuring out what needs to be done -- and in execution, what remains to be done. Timecards and hour accounting tell you about the past, but nothing about the future. They give a false sense of accomplishment and tells you nothing about the health of the project.

I wouldn't blame resources for "underappreciating" you if you were to be the keeper of the timecards.

If you could manage to slip in at least on piece of data into the reporting, you could probably add some real value to the process. That piece of data is the only one needed to look forward and manage projects -- the duration time remaining until completion of the current task being worked by the reporting resource. In your environment, it might be interesting to also ask for effort time remaining as well, to point out the debilitating effects of multi-tasking. As management recognizes these effects, the two numbers should get closer and closer, and at the same time, more and more projects will be completed faster and faster.

...the customer has little choice in who does their development work, so they just have to accept whatever the pace may be.

At least you're lucky in terms of there being a low level of expectations. ;-)

I looked at the Critical Chain Scheduling and Buffer Management article... Is there a way to do this without having a final delivery date to begin with? It doesn't seem so.

Wow...

Most of my clients would give their eyeteeth AND their firstborn to have projects with no required final delivery date imposed on them. I wonder...without due dates, do you really have "projects?" Geez...I would love to have a chat with your management to get a handle on what they think they are managing?

That said, of course you can use CC without predetermined due dates. This is not to say that after building a schedule, you won't have one, but it can only be an internal date, used as a baseline end of the buffer that provides you with the health of progress for the project. If you're customers aren't expecting promises, to manage, you at least have to make promises to yourself.

Saving Changes...