Please login or join to subscribe to this thread
How do you define "cross project interference"? Does it have to do with competition for resources, or that changes created by a project need to be picked up the another project?
The pressures on resources to work on a bunch of things (project tasks) at once is, IMHO, the biggest issue facing project-based organizations.
Most projects are planned and promised with their own uncertainty in mind, and then are subjected to the uncertainty and interference of other projects as well -- through the resources.
Why the 'Anonymous post'?
I think that this is an excellent question, to which there is no easy answer.
I run a Program Office, where we are addressing this problem, and our approach is as follows:
1. The organisation that wishes to avoid 'Project Interference' is at a level where they are ready for formal resource management. The organisational management must recognize 'Project Interference' to be a problem which if left unattended will limit the affectivity of Project Management, and must be committed to solving it.
2. The organisation must be prepared to sell/enforce the idea that resources belong to the organisation, and not to individual managers / line structures.
3. The organisation must be prepared to sell/enforce the idea that Projects are not being run in a vacuum, and that the Project is being run for the benefit of the organisation, and not for the benefit of the Project Managers in question.
4. Once the above milestones have been achieved, the organisation must put in place a mechanism for prioritisation of work (not only project related, but 'production' oriented work also).
5. Given that the above have been achieved, and that the systems for effective communication, planning and control (especially schedule baseline change control) are in place, the organisation can begin to implement the tedious process of resource management.
6. The organisation may select one of a number of methods to actually implement resource levelling (the nitty-gritty work), such as Critical Chain scheduling, Knapsack scheduling, Simulated annealing, etc.
Some comments on the above message - The pressures facing the people working in a multiple project / matrix environment are immense, and lead to numerous (well documented) organisational pathologies.
These pressures are present, even in an environment where a formal resource management process is in operation, and are primarily ascribed to 'Political Pressures' within the organisation. This is especially prevalent in the transition period between the 'Free for all' and 'Organisationally managed resource' environments.
One might actually find that the transition period stresses are strong enough to cause serious organisational damage (at mid-management level), due to a strong impression of disempowerment, ultimately leading to the failure of the resource management mechanism itself.
I am in the final stages of implementing a Program Management Office. We are in the business of designing, manufacturing and installing communication towers and associated equipment. Approximately 35 Project Managers/Coordinator compete for engineering, drafting and fabrication resources located at one central location and to a lesser extent the installation labour that is located locally. Historically, the local field resource conflicts are settled by the local branch manager. Central resource conflicts have been the source of numerous problems resulting in we/they situation. One of the goals of the PMO is to lessen the gap between the field and the main plant.
In the new paradigm the field project manager will be responsible for his/her project from cradle to grave. Task owners will be identified for all tasks including the tasks that are carried out in the plant. Task owners are responsible to the project manager for schedule, quality and budget. The idea is to create a team environment where everybody will work together to solve disputes. Realizing the difficulties that might arise, considering the PM is located 4,000 miles from the plant, I have appointed a senior planner to be the liason between the project managers and the task owners. This senior planner will have intimate up-to-date knowledge of the status of all project activities at the plant and will be in a position to help negotiate solutions to conflicts whenever possible. Once this avenue has been exhausted, the conflict will be elevated to a senior "steering committee" meeting chaired by myself as an impartial facilitator and attended by the General Manager (Tie Breaker), Director of Field Operations, Director of Fabrication and the V.P. of Engineering.
Part of the project initiation process will force the project manager to identify the importance of the project from both the local branch and the customer's point of view. They are also required to identify the project priorities. This information will be available to the Project Review Committee. Using the above mentioned information and the corperate goals and strategies as a guide, a decision will be made by this committee.
We think that these strategies will go a long way to helping mend the gap between the field and the plant and that in most cases the resource conflict will be resolved using team synergy and creativity and the project team level. However, when this becomes impossible we have a formal, impartial decision making process that will ensure that whatever the decision, it will be what is best for the organization as a whole.
This one almost slipped by me. Back in October, Stuart wrote . . . The organisation may select one of a number of methods to actually implement resource levelling (the nitty-gritty work), such as Critical Chain scheduling . . .
I'd like to add a bit of clarification on resource levelling and Critical Chain as it applies to multi-project environments.
Within individual projects, it is absolutely necessary to account for resource dependencies if you are going to make rational promises, hence the need for resource leveling in the Critical Chain approach. As a matter of fact, that levelling occurs prior to the determination of what is "critical."
However, when we move to the system that is a multi-project environment, it becomes an onerous (and usless) effort to try to level resources across projects. Onerous, because everytime you add a new project into the mix, there is the possibility of having to revisit previous schedules and commitments. Useless, because after you spend all that time and effort levelling everything and everyone, the moment we move to execution, and reality deviates from the schedule, all the nicely lined up resources will be unlevelled.
The application of Critical Chain to multi-project systems involves identifying one or two heavily used, commonly used resources, and launching the projects based on levelling only them. If they are commonly used across projects and heavily used relative to other resources, then the other resources will have ample time (over the long haul) to get what they need to do done.
If, as a result, there contention across projects for the use of a resource a a particular point of time, that's what buffers are for. Project and feeding buffers will absorb the possible delay of attention. And Buffer Management will provide guidance on which of those contending tasks is the best use of the resource's time.
So yes, there's a bit of [prudent] "nitty-gritty" work in leveling resources within projects, but not across projects when using Critical Chain-based multi-project management.
Please login or join to reply