We are currently going through some operational efficiency programs as well as still trying to do some transformational initiatives. What we're finding is that lots of "projects" are kicking off, urgent (under 30 days), along with longer term projects (90 to 300 days), and when they go to implement they're "banging into each other". It's actually our release management process that is catching these things. I'm looking for a way to get the PM's to think and identify dependencies proactively. I need something that will help trigger their mind to think through what should be identified. Does anyone have any tools, questionnaires, checklists, that they use to assist in this kind of area? Our architecture team raised this as an issue because they don't have the resources to put an architect on every single project yet need to have some kind of "trigger" that will raise potential impacts in advance of implementation. I've looked through a bunch of the templates here but didn't see anything at first glance that might help me. Saving Changes...
Checklists etc can help. Perhaps the architecture team can provide an initial list.
As well review of lessons learned from previous projects (I banged into another project "here"). Hopefully these are being collected.
My favorite would be perhaps a program manager. Seems your projects are related at least at a techncial level. A person overseeing related projects, even if they only act as the gatekeeper. Taking some info from release management and getting it into the planning cycle might be a start. If they are "catching" the problems already the may be able to identify some of the triggers.
I would suggest you think about implementing more of a project office/portfolio management approach to managing these initiatives, see attached chectlist as a starting point. Saving Changes...
With all due respect to PMOs (which I've chaired on rather large projects), your environment sounds that it needs a mechanism to track a lot of smaller projects. The weakness of a PMO in your situation (Tom: I'd love to debate in another thread :) ) is that "someone or something" needs to know the operational environment very well in order to detect the collisions. If it can be detected on a "manager of manager level" the projects would not collide.
OK, some impromptu practical steps. (read: conceptually works, the details may need some tweaking)
1. Create a master resources project plan. That is, create a project plan where you define your technical resources (be they applications, application modules, network componets, programming or support group processes, etc.)
2. Divide each of your 30-90 day projects into major components (by resources used or impacted).
3. Schedule them on a project plan (MS project will do). Assign the resources to the appropriate tasks.
4. Look for over committed resources.
Now, standard PM reports such as 30 Day Look Aheads, over committed resources, etc. should give fair warning. You will have to play with the level of detail. It will also provide a good tool to publish milestones as well as determine priorities. Saving Changes...
