Hydra White Paper. Scheduling technologies: Resource centric versus Task centric

Transcription

1 Hydra White Paper Scheduling technologies: Resource centric versus Task centric Introduction Historically all project management products have revolved around a common set of techniques to determine the time, effort and dependencies that are involved in any project. This methodology is called the task centric approach and relies on supporting techniques of critical path analysis and then for more complex projects, a consolidation process, where all sub projects are combined to one master project. For complex projects there are a number of limitations to these techniques which can result in gross errors, large amounts of manual intervention and unrealistic plans and schedules. A new set of techniques emerged in the last few years based upon a relatively simple but radically different approach to handling complex projects; this is the technique of resource centric scheduling and is allied to an integrated or holistic approach to managing a complex set of projects with interdependencies. This methodology has a number of fundamental advantages when compared to task centric schedulers and planners; accuracy is assured, highly realistic plans are created and linked with their dependent projects automatically, manual intervention is no longer required, through automation users are encouraged to experiment and flex plans rather than simply construct and then reconcile errors and inconsistencies. Empirically it has been shown that a project that has been scheduled in Hydra is at least 5-10% more efficient than one scheduled using task based scheduling tools, i.e. 100 resources tend to perform as if there were resources. Administration overheads (from a project support office perspective) are reduced typically by a factor of 6-8 times. The point at which a resource centric approach becomes compelling is as low as 5 managers working with 20 people on 5 associated projects or subprojects. Hydra is the manifestation and implementation of a resource centric approach to project management. Detailed White Paper Scheduling and Critical Path with Hydra page 1 of 9.

2 Management Effort vs Complexity of Projects Effor Resource Centric Task Centric Complexity Detailed White Paper Scheduling and Critical Path with Hydra page 2 of 9.

3 Task centric project planning. In the traditional model, tasks, with estimated durations in units of time (days, weeks), are connected by links or dependencies. A diagram showing tasks and their dependencies is often called a critical path diagram or a critical path but is correctly known as a Precedence Diagram. When combined with external restraints ( not before dates ) the critical path analysis, commonly known as the PERT, provides a mathematical process to calculate when each task may begin the earliest possible start date. This is called the forward pass and gives an overall duration for the project the earliest finish date of the whole group of tasks. Having calculated an earliest finish date for the overall project the technique next provides for a backward pass calculating the latest possible finish dates. For each task the difference between early and late start (and early and late finish) is known as float. Tasks with zero float are defined as critical. Two types of float are recognised free float and total float but they may be treated in the same way for this purpose. Float was conceived partly to help with the allocation of resources. This process described in the British Standard makes three assumptions: a) There will be a unique start and a unique finish point in each plan. b) Those resources can be initially ignored for the purposes of scheduling. c) That once scheduling is achieved tasks may be delayed until resources are available to perform them. There are a number of intrinsic weaknesses with this approach when applied to a more complex environment. 1) There is no direct and explicit association between the specific resource to perform a task and the task itself. This means that a separate process has to be undertaken to allocate resources to task, as task durations change manual calculations and allocations have to be performed each time there is a variation in task duration. Implicitly the theoretical critical path that was established may become obsolete and a new critical path needs to be recalculated. a. Either people then ignore this revised critical path in which case the plan is now fundamentally compromised. b. Or significant manual work needs to be expended in resolving the conflict. 2) In more sophisticated plans the resources that are involved in one plan may also be separately planned for in a non associated plan. At consolidation time valuable time is expended manually reconciling the inconsistency and involves either project support office staff and/or project managers manually revisiting their plans to reconcile the fact that one person cannot be in two different places at the same time! 3) The scope for error, and the level of human intervention levels of sub projects increase, and/or the number of associated projects increase and/or the number of people (resources) increase. a. Empirical research shows that the failure point is reached when the 20:5:5 rule is broken, i.e. more than 20 resources (people) working on more than 5 projects with more than 5 project managers (or other line mangers). Historically people have used a mixture of spreadsheets and databases to attempt to manage and reconcile these fundamental issues. As a result significant time and effort has been expended in attempting to create support and debug such systems. Detailed White Paper Scheduling and Critical Path with Hydra page 3 of 9.

4 Resource centric project planning There are a number of simple but fundamental differences between Hydra and virtually all other products. Hydra uses resource centric scheduling to manage the relationship between tasks, projects and their need for resources, i.e. what resource can accomplish the task quickest as opposed to task centric, i.e. how many resources do I need to accomplish the task in the stated time period. Hydra uses a single holistic integrated database to hold all data appertaining to resources, their availability, their commitments and their capabilities. Hydra uses a subtractive process (rather than an additive process used in task centric consolidation) to allocate resources to ensure that no resource is over committed, i.e. given that people are already allocated who is left who can perform the task. All resources are uniquely identified in perpetuity, unlike other systems it is forbidden to allow substitutes in time, i.e. when a person leaves their work must be taken over by a new person with a different identity, in this way again no inadvertent duplication or confusion can exist about each resource. Hydra uses the concept of delegation to create a permanent and dynamic link between a master project and its sub projects. Delegation need not be hierarchical i.e. delegations can be either across projects or even up projects. Referential integrity and logical consistency are automatically and continually checked. Hydra also recognises that there may be many independent tasks and many independent groups of tasks with many start and finish points, i.e. the precise scheduling of these tasks is irrelevant to the overall project and can be started and stopped whenever convenient. Hydra has a number of concepts that are common or similar to traditional project management toolsets. Hydra allows all British Standard forms of link (dependency) and a full precedence diagram (critical path model) is held in memory. The precedence diagram is shown through a logic linked barchart, where tasks are drawn as bars and links connect the bars. Links maybe displayed or suppressed from view. Additionally Hydra has adapted this model to acknowledge the availability of resources to perform the work. Hydra uses the concept of a Gantt chart type layout and a consistent Microsoft Windows / Windows XP look and feel to retain user familiarity and orientation. Detailed White Paper Scheduling and Critical Path with Hydra page 4 of 9.

5 Detailed explanation of the Hydra Resource Centric scheduler Tasks are scheduled by resource availability and by preceding logic. The following describes the mechanics Hydra uses when scheduling tasks. Tasks are defined by their work content or effort in terms of work-time, usually expressed in terms like mandays, resource-weeks, Full Time Equivalents (FTEs) or engineer-days. The start date of a task is controlled by reference to any preceding links and not before dates. These will always be recognised and respected to help Hydra calculate the earliest start date of the task. This is the forward pass of the critical path model. The elapsed time for the task is controlled by the availability of the selected or suggested resource and it is this that provides the task s end time. Hydra tasks may be scheduled by resource or by skill. A resource is commonly an individual person. A skill is an attribute that many people may share designer, engineer, programmer etc If a resource is named the following calculation is executed for that person. If a skill is named, the calculation is carried out for everyone with that skill. Working from the start date of the task Hydra searches for available time of the selected resource considering that resource s: Availability for work Availability remaining after any loans Non-project commitments Allocation on a full time or part time basis to higher priority tasks In the following example a task estimated to take 2 work days may be scheduled to take 6 elapsed weeks if the resource is already scheduled to work on other higher priority tasks leaving free time as follows: Day 1 no free time Day 2 2 hours free time Day hours free time Day 4 no free time Day 5 free Day 6 4 hours free time And so on. Hydra therefore fits each task into each person s schedule using available time. At this end of this process the task is scheduled within the individual s capacity to do work. If a resource is planned to devote only part time to a task, this is acknowledged and the rest of the remaining time is made available to other tasks requiring the resource i.e. the resource availability is not lost. It would be unhelpful if Hydra found odd seconds and minutes to use for a task so the minimum period for work allocation is controlled by the user. Where a skill has been selected Hydra repeats this process for everyone with the desired skill. Hydra first modifies the estimated effort in light of the individual s ability to deliver that skill and then calculates the date on which that person would complete that task. Hydra then recommends the person who will complete the task earlier than all others. Detailed White Paper Scheduling and Critical Path with Hydra page 5 of 9.

6 It follows then that Hydra plans are always levelled and always represent the quickest way work can be done within the limitations of the workforce. Resources are only overloaded where the planner deliberately chooses to do so. They are never overloaded by accident. By automatically scheduling the plan Hydra negates the need to display the critical path as now, the critical path is determined by the critical resources. The examples below show how the critical path disappears in a traditional scheduling tool just by changing the duration from 6 to 9 days and pressing the reschedule button. Figure 1 - Before Figure 2 - After In Hydra s example below blue bars represent actual work done and hatched green represent part time activities. The planner has allocated specific tasks to Joan. Other tasks have been allocated a required skill and Hydra has recommended Joan (those tasks in brackets). Joan has a background task, technical support workload that typically takes 2 hours per day and this is her highest priority work. She also has some minor fixes to existing applications to look after which is estimated to take 20 days but this is a low priority. She is working on a project developing a functional spec, detailed spec, helping with a project board review and some investigation work. This project has a higher priority than the minor fixes but has to fit in with her technical support work. The project work cannot start until the second week of September. Hydra has allocated 2 hours of her time to the support activity and therefore uses the rest of her day to schedule the minor fixes until the project work is due to start. After this project work is ready for her input Hydra breaks the minor fixes task to schedule in the project task using all the time left over from the technical support workload. Once the project work is done, Hydra uses her time apart from the nontechnical support work to finish off the minor fixes task. The result of this is that the task for the minor fixes, estimated to take 20 days spreads over 4 months and that Joan is 100% utilised as long as there is work for her to do. All that has been necessary in this simple example is to allocate either Joan by name or skill (BusAn and SnCo) to each task, estimate the amount of work that has to be done, set the technical support work daily limit and indicate the priorities of the work. Hydra has found the most efficient schedule for every resource including Joan. Detailed White Paper Scheduling and Critical Path with Hydra page 6 of 9.

7 Figure 3 - Hydra's optimised plan It would be virtually impossible to represent this with some traditional planning software and it could only be achieved with any tool other than Hydra with a great deal of configuration and manual manipulation. Where is the Critical Path? Critical path has no meaning in any resource levelled plan and Hydra plans are always resource levelled. We conclude that the traditional highlighted critical path has no meaning in a schedule derived at in this way as we can see in Figure 2 above. The critical path is traditionally defined as a path through a network connecting tasks that, if delayed, would delay the overall project. We have adapted this definition to be: The critical path is defined as a path through a network connecting resources that, if delayed, would delay the overall schedule. For this reason Hydra highlights the periods of time where each resource is fully loaded (100% utilised) as a delay to these resources in those periods of time would delay the overall schedule. Another way of stating this is to say that: In a resource constrained plan, the critical path has no meaning and has been replaced by the concept of critical resources. It is also true to say that Hydra schedules work within the capacity of the team and therefore avoids accidental resource overloads. Accelerating the Plan A common task for project planners and managers is to find ways of achieving a project in a shorter timescale. This section compares the traditional and Hydra processes for doing this in an attempt to stress the advantages of the latest, resource-centric, Hydra technology. Detailed White Paper Scheduling and Critical Path with Hydra page 7 of 9.

8 Step Traditional Hydra 1 Examine project time scale and define acceleration required Examine project time scale and define acceleration required 2 Check to ensure that no resource is overloaded 3 Select one task on the critical path Locate first period of critical resource (longest/first) 4 Reduce timescale of the selected task 5 Increase resource allocation on selected task Increase availability of the critical resource(s) in the critical period 6 Analyse plan and level resources manually Analyse plan and pre-emptively level resources or by scheduler 7 Check resources not overloaded 8 Examine resulting overall timescale evaluate if any reduction has resulted. Evaluate if critical path has now relocated 9 If useful improvements have been delivered move to next longest critical task Improvements are always delivered. Move to next period of critical resource Return to step If improvements have not been delivered, undo changes and select another critical task. Return to step 3 Delegated tasks Hydra has introduced a new class of task called delegated tasks. These are timed by agreement between two parties and therefore are beyond the scope of the critical path model. Delegated tasks perform three roles. They record the agreement, and any changes to that agreement, between two managers to do work. They connect two plans so that both managers can compare current plans with the agreed timing. They provide managed inter-dependencies between plans. As a plan typically contains both delegated tasks controlled by agreement and normal tasks scheduled as described above. This situation is beyond the scope of the British Standard and has been created to address the common problem in program management where plans depend on other plans. Delegated tasks may be timed according to the agreement or in line with one of the two connected plans. Modifications to the critical path model have been made to allow for delegated tasks. Resource Loaning When introduced, the Critical Path Model assumed all resources would work on the same project full time until completed. In today s environment many people work on many projects in addition to non project work. As the traditional software tools that use the critical path model moved out of the engineering and construction market place and into high technology, a method of consolidating multiple projects was introduced. Consolidating projects highlighted any resource conflicts. When conflicts arise, unrealistic plans are then realised leaving an arduous task for a senior manager to sort out. Multiple project priorities may Detailed White Paper Scheduling and Critical Path with Hydra page 8 of 9.

9 exist and priorities within each project makes only complicates the matter. All too often, resources are just left overloaded and projects delivered late and over budget. From the outset, Hydra was designed to resolve the consolidation problem. In addition to delegation Hydra introduces the concept of Resource Owners. Resource Owners could be, for example, project managers, program managers, functional managers, team leaders, resource managers and so on. If a project manager has insufficient capacity, they may request a particular individual or skill from a Resource Owner. The Resource Owner may then loan a specific resource to the requestor on a full or part time basis for a specified period. As the resource is loaned, their availability in the Resource Owners plan reduces and increases in the project manager s plan. The project manager is then free to give work to the resource until the loan expires. Hydra ensures that work can only be allocated within the loan period and for the specified capacity. E.g. Joan maybe loaned 50% of her time to project 1 and 50% to project 2. Any work scheduled in either plan will take at least twice as long to do. Publishing the Plan Many traditional tools fail to communicate to the resources what work is actually being planned for them to do, and why would they? Why would you give a plan to a bricklayer to tell him he is laying bricks for the next 6 months? Often, just a rarely updated Gantt chart printout is provided. Hydra brings these people doing the work into the planning process by providing them with their own Personal Plans. Hydra s unique Publishing functionality builds individual work plans for all tasks they are scheduled to do. Where resources are loaned across multiple projects, their own Personal Plans represent an achievable workload they see all work from all plans. As work is done, the resources are able to record actual work and any remaining efforts. Who better to supply estimates to complete? As the actual work and remaining effort is fed back to the relevant project managers via a timesheet, they immediately see any impact this has on the overall project. Another part of the publishing mechanism is updating any Delegation agreements. Therefore timesheets automatically update project plans, project plans automatically update higher level plans and so on until ultimately there is one single view at the enterprise level. Summary In most high technology projects it is the availability of resources that constrains the speed of the project. Hydra has superseded the display of a series of critical tasks with a display of a series of tasks to be done by critical resources by uniquely and pre-emptively optimising resources and skills and following a resourcecentric philosophy. In the research and development phases of Hydra, the traditional concepts of critical path analysis were analysed and extended in two ways to address the needs of what has now become known as program management. Having previously written project management software, the authors quickly realised these new concepts would require a total re-write of any software tool to achieve this. This is why Hydra is the only solution on the market to offer resource centric scheduling This makes the human task of finding ways to accelerate a plan and balancing time against team size much more intuitive, quicker and easier. Automation allows the planner to focus on the key issues ahead and not the key issues of yesterday. Detailed White Paper Scheduling and Critical Path with Hydra page 9 of 9.