Project management planning scheduling and controlling projects pdf

Developing Project Resources Plans? Planning and Budgeting Construction Costs? Author : Saleh A. Author : David R. Pierce, Jr. This is a comprehensive, yet easy-to-follow guide to construction project planning and control, from vital project management principles to the latest scheduling, tracking, and controlling techniques.

Author : Gerald McKee Jr. Lewis—one of the top experts and best-known authors in the timely project management The monitoring and control process provides the basis for asking the right questions, and perhaps the basis for answering them. The chapter on baselines Chapter 21 could be a section in its own right, as it is the pivot between the planning and scheduling effort and the processes of monitoring and control.

It is, however, a useful introduction to performance management, and touches on issues of change and other forms of control that are dealt with later in this part of the book. Performance reporting Chapter 22 covers the collection of progress and cost information and how this is turned into useful management data.

However, this guide does cover the basic principles of earned value. Cost control is given its own chapter Chapter 23 , and, although it is covered with some brevity, the fundamental principles are discussed. After the project has started, the project needs to react to progress made and re-plan as necessary.

In Chapter 24, we outline this process. Chapters 25 and 26 discuss two processes that will actually be active throughout the whole life of the project. The former discusses change management, and the latter gives an overview of risk management. This chapter provides details of the QSRA and QCRA processes, which are the quantitative analyses of schedule and cost, respectively hence the acronyms.

These are tools that check the initial and ongoing robustness of the project plans. The last chapter in Part Four Chapter 27 discusses forensic analysis and delay and disruption analysis. It forms both the basis of updating the schedules and plans for perform- ance reporting, and to enable forensic analysis should it be necessary.

It provides the basis of much of the learning from the project that can be used to improve future projects. Document management Chapter 29 ensures that this and all other relevant project information is available to those who need it.

The closely allied but separate processes of handover and closeout of the project are dealt with in Chapter The handover process ensures that the project and its obligations are complete and signed off; closeout essentially closes down all the support structures and commercial settlement of the project.

The inal chapter of the book deals with another process that exists throughout the life of the project: lessons learned Chapter An example of the former would be productivity outputs achieved; an example of the latter might be an analysis of why the outputs were at the levels achieved.

This is in keeping with the belief that this is a guide to dip into rather than read cover to cover although the reader is welcome to try! Cross referencing in the book is kept to a minimum, and as a result there is a small amount of repetition, but in general a familiarity with the structure of the book will aid navigation through it. As stated in the preface, we have tried to only use plain English in this guide.

However, when writing about technical subjects, there are always going to be words used that the reader is not familiar with. In these instances we have highlighted the word in blue, and added a deinition in the glossary. As with all processes, making sure that planning and control processes are audited to check for appropriate implementation is important.

Some research and effort are required to ensure that the tools used and their coniguration are suitable for the organisation or project and the team who will be using them. In some industry sectors a big consideration will be client expecta- tions, and this cannot be ignored.

Any action or process that is established must be appropriate and must show a beneit that outweighs the cost of its imple- mentation. This cost is not just in inancial terms, but also in the use of the available time of the team. Projects of differing complexity will require different imple- mentations: the highly complex and risky project will require something close to everything in this guide!

A simple project will only need to apply the principles, often in a very informal way. Its purpose is to obtain management commitment and approval for investment in the project. This is to test the ongoing viability of a project before proceeding into the next phase of work.

Alternatively, the business case may determine that the project is not viable and should not proceed. The business case is owned by the project sponsor.

In some cases the outcome of the business case may be that the proposed project does not proceed. A key part of the business case is the communication of the resources, commercial strategy and capital investment necessary to realise the business beneits that the project is due to deliver. It covers the details of the issues to be addressed, or the opportunity that has arisen.

Each of the economic options must be appraised in terms of costs, beneits, risks and opportunities. Making the beneits SMART speciic, measurable, achievable, relevant, time- bound will facilitate decision making and, in time, assist with the beneits realisa- tion analysis.

Dis-beneits should be analysed as part of the investment appraisal to ensure that they do not outweigh the expected beneits of the project. As with the beneits, the compromises that the organisation will have to make will need to be translated into SMART objectives to aid the decision-making process. Have the deined beneits of the project been achieved, or are they going to be achieved?

However, the two key stages are the time over which the project will be run and the period over which the beneits will be realised. The former is required to understand cash-low forecasting, periods of disruption etc.

Financial commitment across the whole project life cycle needs to be analysed. Anything that delivers more savings than it costs will produce a positive net inancial effect, and this should be quoted with the relevant back-up data. Where there are insuficient internal resources to deliver the project, proposals must be made to either recruit additional, or acquire external, resources to complete the work.

This aspect can clearly have a major impact on the viability of a project. Risks and opportunities considered in this section should include risks to cost, time, health and safety, the environment, reputational damage, the effects on third parties and so on, as is relevant to the particular sector or organisation.

If the project is considered too risky, then the project sponsor may decide to not proceed. This will highlight potential relationships with other projects, programmes or portfolios within the business or externally. Visibility of the bigger picture could identify constraints or issues associated with resource availability, materials or funds. In addition, information for inclusion in the business case, such as resource histograms or high-level schedules, should be provided.

The spend proile of the capital costs may need to be generated from the strategic schedule. This would enable the project cash-low to be determined in line with the key phases or milestones of the project. In most organisations, annual spend proiles are important for managing the business.

This will be used as part of the inancial planning of the organisation. The capacity to undertake the project internally or the procurement of external resources must be determined and appropriate options highlighted in the business case. All project outputs must be delivered it for purpose, to the standards and speciication outlined in the requirements. However, it is possible to have a successfully delivered project that fails to deliver expected beneits, or a project that delivers signiicant beneits but is considered a failure.

Achievement of project requirements and end-user beneits needs to be considered together, because it is the creation and use of deliverables that produces beneits. For this reason, beneit realisation measures should be identiied and baseline data should be collected before implementation begins. This should be presented alongside the project outcomes.

The post-implementation survey is simple and proves whether the beneits predicted by the model have been realised. If not, there may be various reasons for this, and these need to be analysed and interpreted in a beneit realisation review. If so, cash-low forecasting may be required, as will the introduction of spending caps. Security around intellectual property rights may be a concern. The business case should deine how the scope of the project will be procured.

For example, if the business need is for a rapid delivery of the project it may be appropriate to select the shortest procurement route, single source procurement, existing supply chain framework, as opposed to competitive tender.

The commercial project manager or project procurement professional should both have input into the business case and understand it.

Much of the activity associated with developing the business case will typically be undertaken as part of the wider project management process. Project managers must understand the development of the project procurement strategy in terms of how to break a project down into packages of work, and what factors to consider when giving direction on how individual providers will be selected, paid and rewarded, risks allocated, etc.

Investing time in developing the strategy both increases the likelihood of the individual packages being successful and, more importantly, allows the business to review how the packages it together to deliver the overall beneits.

These reviews will take place throughout the project life cycle, and additional reviews will take place following handover and closeout to ensure that the beneits are being realised by the organisation. They deine the structures that enable the planning, scheduling and budgeting exercises to be undertaken in a structured manner. This will facilitate the control of the project as it enters its execution phases.

These processes control how the project scope is developed and veriied. It is also important to clearly establish what is excluded from the project scope. The business plan will deine the breadth of the project scope. This will include discussion with a range of stakeholders, such as potential suppliers, to determine what is possible, research and development areas, policy, legal and more.

The project manager is responsible for carrying out reinement and agreement of the scope with the project executive, sponsor, programme manager, end-user and other key stakeholders to ensure that the project delivers a relevant and appropriate solution. It is essential that these key individuals sign up to their agreement of scope and that this is recorded in the project management plan. Once the scope has been agreed it should be put under a formal change control process, as scope creep and uncontrolled change are common causes of project failure.

It is developed at the start of the project when the product or outcomes have been scoped and agreed. The PBS breaks down all necessary outcomes of a project. A WBS can be further broken down into work packages and planning packages. Roles are usually used in the OBS rather than names e. The CBS often highlights any inancial coding used for the business accounting system and any booking codes associated with each element of the project.

The structure is not usually identical to the CBS, but there will be a relationship between them. Breakdown structures are dealt with in greater detail in Chapter 8. To summarise: a PBS tells you what the product is; the WBS tells you about not only the product but the supporting services and how you deliver them; the OBS tells you who has project accountability for elements of the WBS; the RAM shows you the control points for management; the CBS records the costs; and the RBS deines the type of resource and resources on the project.

It requires the capture of requirements via a structured process. This process should incrementally break down the requirements in a hierarchical manner, considering different conditions and scenarios. Requirements management is an ongoing process that is maintained throughout the project life cycle. Thus, it helps to deine the project scope.

This allows the project team to understand the exact deliverables of the project and how the work will be structured to meet the requirements and deliver the scope. Ideally, each phase would be completed prior to the next starting, but in reality this process is often iterative and cyclical, with requirements being continually analysed and evaluated whilst the design is being inalised and build has commenced.

Satisfying all project requirements equates to the completion of the project. It may be useful to examine requirements and acceptance criteria used for previous projects of a similar nature.

It is important to take standards, legal acts and regulations to be complied with into account when requirements are deined. The documentation should list all assumptions, exclusions and constraints and the acceptance, handover and closeout criteria.

When deining the requirements, it is important to distin- guish wants from needs. One requirement may have multiple sources, but it is important to identify the owner s of each requirement. Once requirements are deined, the acceptance criteria for each requirement should be approved by the customer. This could include analysis, inspection, demonstra- tion or test, or simulation.

A clearly deined requirement increases the chances of the project sponsor being able to make a clear decision regarding acceptance after completion. Requirements may be traded where appropriate, to balance time, cost, quality and safety parameters within the scope of work, using an approved change control process. Once requirements have been clearly deined and agreed, they should be clearly documented, and the strategy for the delivery of the requirements should be detailed within the PEP and the schedule.

The requirements should be baselined before commencing the design and delivery process. There are a number of design approaches, but for the majority of projects a validation and veriication requirements matrix VVRM is a useful model to map the user requirements and system design, in order to facilitate the project assurance process; compliance with requirements may be achieved by linking the VVRM to tests, trials, demonstration, analysis and inspections within the relevant plan and then to the project schedule.

Key review points should be identiied for example preliminary design review, critical design review , where certain requirements must be met before the project proceeds further. At these reviews, requirements and acceptance criteria should be validated prior to testing to ensure that they are still appropriate. If not, they can be amended through the relevant change process. The VVRM should be updated as requirements are met through their acceptance criteria.

Handover and closeout of all requirements and assumptions should be captured in a formal acceptance process 4. Each works information item must be linked to the formal requirement that generates it. This is to ensure that scope creep is not generated by the creation of the works information or, indeed, that scope gaps do not appear.

The schedule must contain all the works identiied in the works information. It is often developed in line with the business case, and the SOW will then form the basis of contractor selection and contract administration. The SOW deines all the work that is required to be undertaken in order to develop or produce the outputs of the project, along with work performance requirements for the project e.

It includes qualitative and quantitative design and performance requirements that can be measured to determine project success.

Once a contract has been awarded to a supplier and a project commences, the project team often breaks the top-level SOW into individual or work package SOWs, creating a more detailed and lower-level WBS structure than that which was submitted at bid stage. This facilitates clearer deinition of the work packages, as the SOW requirements can be traced throughout the WBS structure, and ownership can be clearly assigned to the work packages.

Relevant parts of the SOWs which are referenced in a WBS dictionary are then considered alongside the constraints, risks, assumptions, interfaces, dependencies and opportunities. This produces the scope baseline for the project team to estimate work schedules and costs. As schedules are worked up, the basis of estimates for duration of activities and cost estimates is recorded for both project audit purposes, and schedule and cost risk assessment activities.

Stakeholder management is the formal management of these interests, including the management of the relationships and monitoring the delivery of commitments made to the stakeholders. Managing stake- holders can make the difference between success and failure of a project, and as such should feature highly on the list of priorities and be treated with appropriate gravity. Whilst the planner assists with this process, the main responsibility for managing the stakeholders lies with the project manager.

It is essential that these key individuals sign up to their agreement of scope and that this is retained for record purposes. Stakeholders must be identiied, their level of interest and power to inluence the project analysed, and plans devised for their management.

Stakeholder management is an iterative process which starts during project concept. Stakeholders should be managed to ensure that a positive relationship with the project is built and maintained.

It may include who the stakeholders are and their communication needs, and who is responsible for their management and planned responses. Stakeholder management needs to consider interfaces with third parties or outside inluences. Although a planner will not be expected to know the inite technical detail of the project, planners should have an appreciation of each element of the project.

Areas where the project team typically may need to gain a high level of understanding are listed in Table 6. Table 6. How does this inluence the plans? Find out what approval stages are required, e. Planning is the activity of determining how raw materials and other resources are delivered into a desired outcome. It is also the process that will deliver a compet- itive edge to organisations competing to win contracts to deliver work.

Planning is the activity of a team working together to determine the strategy for delivering the project. To achieve this, the project team determines the method or methods that will be used to deliver the project as well as how the project is to be procured. Specialist planners may guide and facilitate the process.

In principle, planning is an activity that precedes scheduling. During the planning process, the main interfaces will be identiied. It is important that during this process the assumptions made, the risks, opportunities and issues are identiied and recorded.

At the planning stage of the project, it is important that the project control and reporting methodologies that will be used are deined so that decisions around the methods of planning effort and toolsets adopted will be adequate. This includes recording any organisational or management approaches and processes that will be used.

The planning discipline assesses how and when activities need to take place and deines the acceptable standard required for completion, as well as balancing standards and targets within agreed time, cost and quality parameters.

Planning enables the project manager and their team to determine what methods and techniques they intend to use to deliver the required outputs, products and activities. Adding the activities to a schedule helps to understand the logical relationships between activities, the impact on resource distribution, the expenditure proile and reporting implications. Planning and scheduling are essential to the authorisation of the project delivery stages.

Without a robust and realistic PMP and schedule, advancement through the project stages should not be approved. The approval at each stage will look closely at the plan and schedule and consider whether the project is on course to deliver its intended business beneits in accordance with the business case. Once agreed and authorised, plans and schedules are an essential mechanism for communicating the project strategy and the deployment and tasking of staff, contractors and other resources.

Well-planned projects, where the tasks that need to be undertaken, how and when have been carefully considered, are much more likely to successfully deliver desired outcomes. Early identiication of deviation will allow the maximum time for corrective action and assessment of impact on other planned activities. This should assist in achieving buy-in of the project team. Planning should never be an isolated exercise.

In practice, no one technique will likely give a deinitive answer in terms of both planning and control. Good practices are set up by careful selection of the right tools for the project. This will include logistics planning, stakeholder management and the availability of suitably trained and numerous resources.

Planners may have both skill sets, but it is important to be aware of, and for this guide to deine, the difference between the two roles. Whereas planning has to be done well in order to deine the best solution to deliver the project, scheduling needs to be done well to determine the project parameters: how long the project will take to complete, for example.

Furthermore, it must be done well to communicate the project clearly and precisely. It can then form a sound foundation for project control. Scheduling is more of a science compared with the art of planning; it usually involves the input of planning information into scheduling software.

Scheduling uses the WBS as the framework on which to build all the project activities. It also deines the logical sequence of activities and calculates the critical path the path or chain of activities which, if delayed, will cause a corres- ponding delay to the overall project completion date. In this process it computes the start and inish dates and identiies the loat on all the activities. The inal outcome of this process is to determine the feasibility of delivering the project to the required completion dates.

At the outset of a project, planning is the art of deciding the best strategy for designing a project, implementing a project and bringing a project into use.

The key to good planning is effective communication of the strategy and method s that are decided upon as the most eficient way to deliver the project. A key part of planning is creating the project schedule.

The schedule should have enough information in it to manage the project and accurately model the impact of change and progress. Information that can be held in a separate tracker should not be included in the schedule. It is not useful to manage all this in the specialist scheduling software, because it increases the size of the schedule to less manageable proportions it is likely to be a high-density level of detail.

It would also make it harder for the project manager to access the data, thus detracting from the main purpose of the schedule. It should give a clear understanding to both project and non-project team members of the way the work has been planned and scheduled, with associated assumptions. Typically, this top-down approach will deine the overall project life cycle along with key events that will need to happen in order to achieve each gate review.

As the top-down plan is more requirements driven and needs driven, it tends not to be date focused, and works instead on establishing the essential logic lows and sequences required for the successful completion of the project. Bottom-up planning then complements this approach by validating the effort and duration required to deliver the requirements on the project, and should result in a resource-driven schedule showing the project dates by which key events can be met.

Often, there is then a rationalisation period whereby the bottom-up and the top-down plans are aligned and trades in time, cost or quality are made to ensure that the project can be delivered to the timescales, cost or quality standards outlined by the customer. See Figure 7. This is typically a high-density schedule, and would be one of the more detailed planning outputs.

Fully logic-linked and usually held in a scheduling software tool, this approach can be effectively utilised through collaborative planning techniques. It is usually undertaken via a facil- itated workshop, whereby the facilitator will help to guide the team to create a bottom-up schedule of activities required to successfully reach an agreed end-point.

There are multiple ways of facilitating planning workshops — one effective approach is for all of the team to create task names on sticky notes, which are then categorised and reviewed. Logic, durations, resources and any constraints are then discussed and agreed until a fully logic-linked schedule has been created. This approach takes a number of iterations; however, it should foster a collaborative approach and help to ensure that all team members are fully engaged in the planning process. These items cover weeks or months.

If, however, some or all of these are not in place, some form of rolling wave planning is required. Rolling wave planning describes the scheduling density that is achieved at different moments in time. Figure 7. The project then uses the top-down plan and systematically plans each wave to an increasing level of granularity, starting with a high-density schedule upfront in the irst wave, and gradually reducing the level of density and hence the requirement to fully deine details which may not be fully available to the project until a later date.

In large-scale, long-duration projects, it may not be feasible to structure the rolling waves according to gate reviews, as these may be many years apart. Where this is the case, the project may choose interim milestones or deliverables by which the rolling waves should be completed, or, alternatively, may choose a set number of periods of time e.

As the project moves nearer to the end of the irst phase, the second phase will be planned to a higher level of density and detail, as the project team will have more information available than at project inception. The waves may relate to phases of the project as shown in the illustration above. An agile approach integrates planning with execution almost concurrently, allowing early and continuous delivery.

For a full deinition and purpose statement, see Chapter These are typically 2 to 4 weeks in duration. Releases that are planned in the near term are shown in more detail than later ones. Not all activities are constrained to sprints; for example, procurement activities or activities involving external stakeholders.

There is a common misconception that is it not possible to reliably develop and use a baseline for an agile project, but this is not the case. Welcoming change does not mean undisciplined or ad hoc delivery. The project still has a vision, a timescale in which the vision needs to be achieved, and a budget. The planning of the sprints is guided by the project vision. A baseline provides the basis for specifying expected outcomes of each iteration. As a result, customers have the ability to hold the team accountable to the project vision at the end of each iteration and version release.

Being agile means that there is less resistance to changing the schedule; the highest priority is to satisfy the customer by early and continuous delivery of valuable software. Wherever possible, these are the requirements that are developed irst, to gain customer trust and conidence in the system, providing early functionality. Without them, the project solution will still deliver; however, there is value to adding these requirements for a more complete system.

These are the requirements which, if time or cost becomes tight, are the irst to be cut out of the scope. This is not to say, however, that if the project is awarded an extension, or if there is a delay elsewhere, some of these non-essential requirements cannot be added in at a later date if they do not detract from the main project priorities.

Once the strategy has been decided upon, it will direct the rest of the planning, estimating and scheduling efforts of the project, potentially imposing constraints and other limitations on the schedule and methods to be adopted. Different strategies can be described with differing planned value curves. The basic possibilities are based on the critical path method CPM , which calculates two sets of dates based on the same schedule logic an early completion and a late completion for each activity.

The combination of these forms an envelope in which the works can logically be completed without delaying the desired project completion date see Figure 7. This never happens. This curve is often referred to as the P0 plan, P0 referring to zero percent probability of achievement.

If a delay to an activity were to occur, delivery on time or to budget with the existing logic and assumptions would be impossible. Attempting to work to this curve would be to assume that no risk will be realised. It is not, therefore, appropriate to rely on these sorts of planned values without further reinement, and the use of resource-levelled schedules is therefore recommended in this guide Chapter It is part of the planning strategy to decide what resources can be applied and what limitations on them are sensible to account for in the project schedule.

This is based on constraints around the availability of funds — caps on spending at particular points, for example. A commercial beneit can be achieved from reducing inancing costs, but if delivery on time is a priority it will have the effect of adding risk into the project, as it will be harder to recover from unforeseen delays.

Late curve Work Early curve Time Figure 7. It is necessary to allow for the unknown when planning for the future. The former will be applicable at later stages of the project life cycle, such as at the point of going into contract.

Chapter 26 will discuss the assessment and management of risk in general, and speciically in relation to time, under the process of quantitative schedule risk analysis QSRA.

In the example, the product is now broken down into phases. At this point there is no need to break out the structure any further. There are a number of different breakdown structures that a project may employ Figure 8. A product is an output which meets the scope or requirement, sometimes referred to as a deliverable s. It provides a hierarchical tree representation of the relationship between the products and sub-products such as assemblies, sub-assemblies and parts, which contribute to delivering the scope and objectives of a project or programme.

It provides the outline framework for planning, contracting, budgeting and reporting. An example is shown in Figure 8. Some examples of products required to manage the project are reports, test documentation, requirement speciications and safety certiications. This makes it easier to ensure that all the outputs have been identiied before going into the detail of identifying the work packages or activities within a work breakdown structure WBS.

Additionally, the PBS helps create a common understanding of the deliverables in a project, and aids objective progress capture by deining a physical output. The PBS provides a breakdown of all the necessary products outputs of a project, whereas a WBS provides a breakdown of the all work packages or areas of the project.

The PBS should be included as part of the project plan and stage plans, with progressively more detail at each level. A useful approach is to gather stakeholders together to brainstorm the products needed. A PBS is drawn in a hierarchical structure from the top down. The irst box summarises the overall product, with the subsequent branches showing intermediate products such as assemblies, sub-assemblies and components or parts.

It may be useful to break down products into specialist products, which are those products required to meet the scope or requirement, and management products, such as reports and plans.

Once a project has been broken into small packages of work, there is a better chance of understanding what needs to be done. It divides work into deinable work packages from which a statement of work can be developed and technical, schedule, cost and resource reporting can be established.

Individual work packages or areas of the WBS may be broken down further to give better schedule segregation. A WBS code must be applied in order to identify the work packages within the project in a logical manner. This then forms the basis for accurate reporting and mapping of time, cost and resources.

A WBS can be combined with an organisational breakdown structure OBS to produce a responsibility assignment matrix RAM showing the responsibility for each work package. It is good practice to use a WBS when developing any project schedule.

If a product breakdown structure has already been produced, this provides a good breakdown of all necessary products and outputs of a project, and can form the primary input to the WBS. Note: in the construction sector the WBS is more usually used to identify geographical areas where work will be carried out.

However, the hierarchy principle still applies. The individual work packages may themselves be further sub-divided down to individual activities. The key thing about the WBS is the ability to break down the project into work packages that can be assigned to a resource.

This helps to ensure a consistent and coherent approach to the project and clearly deines the key deliverables for each WBS node. In other words, it is a tool to identify scope gaps or overlaps and assist in their elimination. When a project is up and running, change control of the WBS and associated dictionaries should be applied. An example of a WBS dictionary is shown in Figure 8.

In addition to the ields illustrated, additional information may be contained in a WBS dictionary, such as clariication to suppliers or sub-contractors of services or free issue materials to be provided or not to the supplier by the contractor or client. See Figure 8. WBS number: 1. Dent Figure 8. It is used to convey the communication routes and reporting lines within the project.

It is used to show the project organisation structured in a hierarchical manner. Organisational breakdown structure Project manager Senior Senior Business Engineering Financial production commercial support manager controller manager manager manager Production Commercial Avionics Deputy business Finance manager manager engineer support manager manager Production Commercial Structures Approvals manager manager engineer manager Test engineer Figure 8.

Larger projects may deine RAMs at multiple levels. Lower-level RAMs can be used within teams to assign roles and responsibilities for speciic activities to individuals. It is used within the project to communicate the required work to stakeholders. The RAM can form the basis for scheduling activities and is a key input when developing the network diagram or Gantt chart.

Generally, it is shown as a grid with the WBS elements on the left-hand side and the OBS resources across the top, marked at the appropriate intersections to indicate who is doing what. A WBS is a project planning tool used to break a project down into smaller, more manageable pieces of work, called work packages.

Work packages can then be broken down further into individual activities and their associated deliverables. An OBS maps the resources available. Share This Paper. Figures and Tables from this paper. Citation Type. Has PDF. Publication Type. More Filters. International Journal of Engineering and Advanced Technology.

Project management is a strategy implemented in service and manufacturing sector organisations to manage the effective completion of a project. The successful running of an organization, i. View 1 excerpt, cites background. The main purpose of the study was to establish the factors affecting warehouse … Expand. BIM-tool development enhancing collaborative scheduling for pre-construction.

Design quality in pre-project planning: applications of the Project Definition Rating Index. The development of the project scope definition package is one of the major tasks in the pre-project planning process.

It is where risks associated with the project are analysed, early designs are … Expand.