I my previous blogs I have been focusing purely on the planning, control and closure of single project management.
Let's take a step from individual project management and move to programme management.
One project might be very small or rather big. One project might be for external or internal customers. However, there is some strong differences between internal and external projects:
External projects are designed to generate profits.
Internal projects do not generate profits directly, but intended to increase profitability. These are often regarded as enabling projects and enable the business to operate more efficiently.
How both internal and external projects might relate to each other is presented in figure below.
the figure presents a scenario of a business who has many commercial projects with the aim of gaining profits. Sometimes, however, they need to refuse internal projects originating from managers who think those might or will bring benefits.
Many organisations run external projects and internal ones concurrently, some of which might be very expensive.
Business Change and IT projects
IT projects might be conducted with considerable expense and bring true disruption to the organisation. The consequences can be quite damaging. From terminated operations to lost reputation. It is therefore important that new projects are reviewed by senior manager, risks are assessed and benefits are established.
Majority of IT project fail with considerable costs.
To reduce the risks of failures, it would be beneficial to establish a procedure that any changes should be submitted in a form of business plan. The plan should be submitted in the same format for everyone. Initial screening process should also be put into place to ensure it can bring a benefit to organisation.
Some managers make suggestions to boost their own ego, but there is no benefit to organisation. Sometimes projects are rejected due to lack of resources in cash or skilled people and competency required.
Portfolio management, on another side, is a process to ensure that:
Priorities are based on the timing of the benefits, including risks, the resources required and its availability.
No investment is promised until the project is authorised by senior management as funds might be used which belong to customers or shareholders.
Only the most expert people are assigned so that the risk of mistakes through competence is minimised.
Every project is closely monitored so that it can be stopped or terminated before sinking more than necessary.
A business could be investing millions to inappropriate projects. This is visible in some UK NHS projects. Each project should be able to show the value to the investment.
Multi-project scheduling
In many organisations only primary methods of project scheduling are adopted. When organisations employ their own permanent direct labour to number of project the scheduling is more relevant. Sometimes the only challenge would be to know how to marry the projects within the resources available.
If appropriate Work Breakdown structures are prepared, resource scheduling is done well for each project, critical path networks are being drawn and relevant project management is chosen there are still difficulties.
The entire system need to account for a vast amount of data, priority conflicts must be resolved and tasks interdependencies should be observed. The system needs to be dynamic and responsive to changes. There can be design changes, technical problems, cancellations, new projects and fluctuation of manpower and resources.
There are difference in scheduling multi-projects as opposed to single projects. The total workload can be regarded as "the project" and sub-projects". The same task identifiers might crop up in different projects. Therefore the same numbers may never occur in all sub-projects. It might be solved by prefixing all of the task ID codes within each sub-project with unique numbers of characters. Some software can add such prefixes automatically for sub-tasks. We should avoid very long numbers for individual codes as it is increasing human error.
Each sub-project to be given its sub-tasks special code.
Multi-project management
The multi-project environment generally has ever changing existence. Each sub-project will have its own life cycle. New projects are added, completed projects removed and changes reflected for projects in-progress.
Attention should be paid to data preparation, system security and updates. Access level to the system must be closely controlled through passwords. Only those with necessary skill and training should access the data. Access might also be jealousy guarded.
The above system presented is in favour of maintaining integrity of the multi-project model.
Data preparation
Data preparation is very similar for multi-projects as for single projects scheduling. Separate network must be built for each separate sub-project. Estimation for duration, costs and resources are made in a normal way. Calendars and holiday files the same and set correctly.
The resource definition will need to be structured for the whole model rather than for individual sub-project. This means that the total availability of the resource will be the total amount of that resource which is available for allocation to all sub-project. This will be easier option than allocating resources for each individual project.
We should also account for use of resources for non-projects. This might involve manufacturing spare materials.
We can approach this in two ways:
The total level of each resource in the organisation that is declared are being available for projects is reduced to the amount equivalent for miscellaneous work and staff absences using the "sludge factor".
Sludge factor
If there are 50 people of one resource in a department generally it might seem reasonable to declare 100 units available. But, there are complications. The people might be needed for other projects. No department of work ever achieves 100% efficacy. People take time off due to illness, holidays, dentists, time waiting, machine failures etc. Some of these people will also work on unscheduled work like modifications and corrections.
Therefore, we must estimate the level of efficacy for every department and assign the amount of that resource available for the project. If in doubt, we need to start assuming 80% and amend as experience builds up. That leaves 20% sludge factor to cover unplanned absences and down time and schedule for work that is impossible to schedule. People use 85% successfully for general availability levels, the 15% disappear over the activities which are impractical to schedule.
2. The non-project work can be introduced into the scheduling calculations as it it was on a continuous project. This would require a "network" having a duration spanning not less than the life of the of the whole multi-project schedule, thus carrying out the forecast of non-project usage level for each category of resource in the model. This option, however, can be over-complicated and not satisfactory, but likely to be more accurate if used for recruitment or downsizing.
Priorities among sub-projects
Planners should always be able to choose priorities from priority rules for allocating resources to tasks within the sub-projects. But in multi-project case there is a further level of priorities decided by allocation of resources between different sub-projects.
The ideal solution is very simple.
Firstly, we need to specify target start and completion dates for every sub-project. These dates should be the contractual dates committed and agreed with various customers. The computer will carry on time analysis for all sub-projects independently and calculate float from this imposed target dates. After that, priority claims for scare resources during multi-project processing can be decided automatically according to the amount of float possessed by each task.
Different stakeholders (senior management, sales management and managers) will have different views on the priorities. Sometimes one customer might be regarded as more important than another. If the project planner cannot overcome these conflicts, the priority should be given by artificial means. This can be done by placing artificially early target completion date on the relevant subproject.
Some software will allow specific priority levels and the system implemented might be able to deal with it. If the system is designed well, it will gain the trust of management. Allocation resources only to available float is an elegant solution and easy to apply.
Interface tasks
There might be a situation in the multi-project model when one or more sub-project networks share the same tasks. Therefore, the task should share the same identifier and be designated as interface tasks.
In the network diagrams these are generally marked by double line boarder on the task box. These incidents, however, should be rare. They should not be used to force priorities. The reliance on the remaining float is the more sensible option.
There might be an exemption in the allocation of final factory assembly space for large items of plants or machinery, where one item cannot be assembled when the other one has been completed. Operations management should be involved in such allocations. These can be resolved by adding interface tasks or adding constraints to the tasks.
It might be safer to create special interface tasks (with zero duration) rather then designate existing tasks representing real world as interfaces. Two or more interfaces must be given the same ID number.
Updating intervals
Regular updates in multi-project models are imperative. We need to declare current situation, re-analyse time, re-schedule resources and costs. The frequency truly depends but updates in large projects should be done every 2 to 4 weeks.
The data needs to give each department manager reports that are relevant to them. Each manager should be able to filter their own information and task progress. This only applies to programmes with many project managers.
To facilitate the filtering allocating relevant codes (departmental, resource, task). When there is a joint responsibility tasks could use two or more resource codes. Artificial resource can also be created to allow filtering.
Summary
Project scheduled along with sale forecasts and other possible tasks to come provide information from which manpower, financial and other strategic plans can be generated. Organisations can predict manpower needs, competency needs, cashflows, to name the few.
One important part is ensuring that work-to-do lists exist where each manager can complete their activities in the planned sequence. We plan to ensure we do not cause overloads.
Bibliography:
Lock D., 2013, Project Management, Gower Publishing
Comments