This document discusses project management roles and scope management. It begins by outlining the roles and responsibilities of a project manager, including scope planning, definition, verification and control. It then discusses the need for construction project management due to potential conflicts between objectives and constraints. The key functions of project management for construction are specified, including directing resources to achieve objectives, specifying plans, efficient resource use, implementation, and conflict resolution. Principles of project management are also outlined, such as having a clear project structure and goals. The document concludes by discussing verification and control project management stages.

1. PROJECT MANAGENT –I
MODULE-3
AR M.B. MULLA

2. MODULE-3
ROLES OF PROJECT MANAGER:
• Roles & Responsibilities of Project/ Construction Managers,
• Scope Management
• Construction: Scope Planning, Definition,
• Verification and Control Project Management Stages:
• Project planning, project scheduling and project controlling.

3. NEED FOR MANAGEMENT OF CONSTRUCTION PROJECTS
THERE ARE POTENTIAL CONFLICTS BETWEEN THE STATED OBJECTIVES WITH REGARD TO SCOPE, COST, TIME AND QUALITY,
AND THE CONSTRAINTS IMPOSED ON HUMAN MATERIAL AND FINANCIAL RESOURCES.
THE FUNCTIONS OF PROJECT MANAGEMENT FOR CONSTRUCTION GENERALLY INCLUDE THE FOLLOWING:
• PROJECT MANAGEMENT IS THE ART OF DIRECTING AND COORDINATING HUMAN AND MATERIAL RESOURCES
THROUGHOUT THE LIFE OF A PROJECT BY USING MODERN MANAGEMENT TECHNIQUES TO ACHIEVE PREDETERMINED
OBJECTIVES OF SCOPE, COST, TIME, QUALITY AND PARTICIPATION SATISFACTION.
• SPECIFICATION OF PROJECT OBJECTIVES AND PLANS INCLUDING DELINEATION OF SCOPE, BUDGETING, SCHEDULING,
SETTING PERFORMANCE REQUIREMENTS, AND SELECTING PROJECT PARTICIPANTS.
• MAXIMIZATION OF EFFICIENT RESOURCE UTILIZATION THROUGH PROCUREMENT OF LABOR, MATERIALS AND
EQUIPMENT ACCORDING TO THE PRESCRIBED SCHEDULE AND PLAN.
• IMPLEMENTATION OF VARIOUS OPERATIONS THROUGH PROPER COORDINATION AND CONTROL OF PLANNING, DESIGN,
ESTIMATING, CONTRACTING AND CONSTRUCTION IN THE ENTIRE PROCESS.
• DEVELOPMENT OF EFFECTIVE COMMUNICATIONS AND MECHANISMS FOR RESOLVING CONFLICTS AMONG THE VARIOUS
PARTICIPANTS.

4. Principles of Project Management- The principles of project management are the fundamental rules that should be followed
• Project structure
• Definition phase
• Clear goals
• Transparency about project status
• Risk recognition
• Managing project disturbances
• Responsibility of the project manager
• Project success
• Project Structure - Project management typically revolves around three parameters – Quality, Resources, and Time.
A project structure can usually be successfully created by considering:
1. Project Goal -- An answer to the question “What has to be done” is usually a good starting point when setting a project
goal. This question leads to the project structure plan.
2. Project Timeline and Order- A flowchart is a powerful tool to visualize the starting point, the endpoint, and the order of
work packages in a single chart.
3. Project Milestones -- Milestones define certain phases of your project and the corresponding costs and results. Milestones
represent decisive steps during the project. They are set after a certain number of work packages that belong together.

5. • Definition Phase
The definition phase is where many projects go wrong. This can happen when no clear definition, or when the definition is
muddled due to the involvement of too many stakeholders. A successful definition must involve the entire team at every step
to facilitate acceptance and commitment to the project.
• Clear Goals
The project manager is responsible for the achievement of all project goals. These goals should always be defined using the
SMART paradigm (specific, measurable, ambitious, realistic, time-bound). With nebulous goals, a project manager can be
faced with a daily grind of keeping everything organized. It will work decidedly to your advantage to clearly define goals
before the project begins.
• Transparency About the Project Status
Your flowcharts, structure plan, and milestone plan are useful tools to help you stay on track. As a project manager, you
should be able to present a brief report about the status of the project to your principal or stakeholders at each stage of the
project. At such meetings, you should be able to give overviews about the costs, the timeline, and the achieved milestones.
• Risk Recognition
It’s the duty of the project manager to evaluate risks regularly. You should come into every project with the knowledge that all
projects come with a variety of risks. This is normal. Always keep in mind that your project is a unique endeavor with strict
goals concerning costs, appointments, and performance. The sooner you identify these risks, the sooner you can address
negative developments
• Managing Project Disturbances
It’s not very likely that you have enough personal capacity to identify every single risk that may occur. Instead, work to identify
the big risks and develop specific strategies to avoid them. Even if you’re no visionary, you should rely on your skill set,
knowledge, and instincts in order to react quickly and productively when something goes wrong.

6. • Responsibility of the Project Manager
The Project Manager develops the Project Plan with the team and manages the team’s performance of project tasks. The
Project Manager is also responsible for securing acceptance and approval of deliverables from the Project Sponsor and
Stakeholders. The Project Manager is responsible for communication, including status reporting, risk management, and
escalation of issues that cannot be resolved in the team—and generally ensuring the project is delivered within budget,
on schedule, and within scope.
Project managers of all projects must possess the following attributes along with the other project-related responsibilities:
Knowledge of technology in relation to project products
Understanding Management concepts
Interpersonal skills for clear communications that help get things done
Ability to see the project as an open system and understand the external-internal interactions
• Project Success
Project success is a multi-dimensional construct that can mean different things to different people. It is best expressed at
the beginning of a project in terms of key and measurable criteria upon which the relative success or failure of the project
may be judged. For example, some generally used success criteria include:
Meeting key project objectives such as the business objectives of the sponsoring organization, owner or user
Eliciting satisfaction with the project management process, i.e., the deliverable is complete, up to standard, is on time and
within budget
Reflecting general acceptance and satisfaction with the project’s deliverable on the part of the project’s customer and the
majority of the project’s community at some time in the future.

7. What is Project Scope Management?
Scope refers to all the work involved in creating the products of the project and the processes used to create them.
A deliverable is a product produced as part of a project, such as hardware or software, planning documents.
Project scope management includes the processes involved in defining and controlling what is or is not included in a
project
Objectives Understand the importance of good project scope management.
• Discuss methods for collecting and documenting requirements in order to meet stakeholder needs and expectations.
• Explain the scope definition process and describe the contents of a project scope statement.
• Discuss the process for creating a work breakdown structure using the analogy, top-down, bottom-up, and mind-
mapping approaches.
Defining Scope
• Key inputs for preparing the project scope statement include the project charter, requirements documentation, and
organizational process assets such as policies and procedures related to scope statements as well as project files and
lessons learned from previous, similar projects.
• As time progresses, the scope of a project should become more clear and specific.

8. Construction: Scope Planning, Definition
It is a deliverable-oriented decomposition of a project into smaller components. It defines and groups a
project's discrete work elements in a way that helps organize and define the total work scope of the project.
What is the definition of project scope planning
Getting key parties to agree upon what is the scope of the project's work is known as project scope planning. The
practice of project scope planning is a key management practice for planning and delivering projects successfully.
What is scope creep?
Scope creep occurs when your project exceeds your initial scope statement. For example, scope creep may occur if a
stakeholder adds an additional project deliverable after the project has begun
Unexpected project changes can lead to increased project risks like missed timelines, increased budgets, overwork, or a
low-quality end product. There are various reasons why scope creep can occur. Some reasons include:
• Unclear project scope
• Unrealistic project objectives
• Too many stakeholders
• Poor scope management
• Poor communication with stakeholders
• To avoid scope creep, you need to plan against it, which is where a strong scope
management plan comes into play.

9. Steps of Scope Management

10. Project Scope Management Processes
• Collecting requirements: defining and
documenting the features and functions of
the products produced during the project as
well as the processes used for creating them.
• Defining scope: reviewing the project
charter, requirements documents, and
organizational process assets to create a
scope statement.
• Creating the WBS: subdividing the major
project deliverables into smaller, more
manageable components.
• Verifying scope: formalizing acceptance of
the project deliverables.
• Controlling scope: controlling changes to
project scope throughout the life of the
project.

13. Collecting Requirements
• A Requirement is “a condition or capability that must be met or possessed by a system, product, service, result, or
component to satisfy a contract, standard, specification, or other formal document”. (PMBOK® Guide, 2008)
• It is helpful to divide requirements development into categories called elicitation, analysis, specification, and validation.
• It is important to use an iterative approach to defining requirements since they are often unclear early in a project.
Methods for Collecting Requirements
• Interviewing stakeholder one-on-one: Effective but expensive and time-consuming.
• Focus groups and facilitated workshops: Faster and less expensive than one-on-one interviews. Using group creativity and
decision-making techniques.
• Questionnaires and surveys: Efficient as long as key stakeholders provide honest and thorough information.
• Observation: Good for projects that involve improving working processes and procedures
• A requirements management plan
This describes how project requirements will be analyzed, documented, and managed.
• A requirements traceability matrix (RTM) is a table that lists requirements, various attributes of each requirement, and
the status of the requirements to ensure that all requirements are addressed.
Sample Requirements Traceability Matrix

14. Creating the Work Breakdown Structure (WBS)
• A WBS is a deliverable-oriented grouping of the work involved in a project that defines the total scope of the project
• WBS is a foundation document that provides the basis for planning and managing project schedules, costs, resources, and
changes.
• Decomposition is subdividing project deliverables into smaller pieces.
• A work package is a task at the lowest level of the WBS.
Approaches to Developing WBSs
• Using guidelines: some organizations, like the DOD, provide guidelines for preparing WBSs.
• The analogy approach: review WBSs of similar projects and tailor to your project.
• The top-down approach: start with the largest items of the project and break them down.
• The bottom-up approach: start with the specific tasks and roll them up.
• Mind-mapping approach: mind mapping is a technique that uses branches radiating out from a core idea to structure
thoughts and ideas.

15. Control scope
The last step in your scope management plan is scope control. As your project continues into the execution phase, monitor
the status of the project and manage changes to the scope. The best way to streamline scope control is to use project
management software. These tools can share feedback, files, and status updates on your project so you’re aware of any scope
changes in real time.
Tips to control scope:
• Analyze variance: In this part of the scope management plan, assess how much variance in scope occurs. Analyzing the
actual performance of your scope versus the planned performance will give you insight for future projects.
• Refer to change control document: You created a change control process earlier in the planning phase. Remember to refer
to this document so you can track the flow of information when it comes to project changes.
• Validate scope
• Validating your scope simply means getting sign-off from all stakeholders involved in the project. Make sure stakeholders
clearly understand your project deliverables to avoid future scope creep. If possible, get feedback or advice on any changes
and improvements.
Tips to validate scope:
• Inspect your plan: Because validation is the final sign-off for your scope management plan, you’ll want to review and
inspect it thoroughly. Team members can help you inspect the plan before sending it off to stakeholders, but stakeholders
should also participate in a final inspection so that the plan gets as many eyes on it as possible.

16. The WBS Dictionary and Scope Baseline
• Many WBS tasks are vague and must be explained more so people know what to do and can estimate how long it will
take and what it will cost to do the work.
• A WBS dictionary is a document that describes detailed information about each WBS item.
• The approved project scope statement and its WBS and WBS dictionary form the scope baseline, which is used to
measure performance in meeting project scope goals.
Verifying Scope
• It is very difficult to create a good scope statement and WBS for a project.
• It is even more difficult to verify project scope and minimize scope changes.
• Scope verification involves formal acceptance of the completed project scope by the stakeholders.
• Acceptance is often achieved by a customer inspection and then sign-off on key deliverables.
Controlling Scope
• Scope control involves controlling changes to the project scope.
• Goals of scope control are to:
• Influence the factors that cause scope changes.
• Assure changes are processed according to procedures developed as part of integrated change control.
• Manage changes when they occur.
• Variance is the difference between planned and actual performance

17. CONCLUSION
Project scope management includes the processes required to ensure that the project addresses all the work required, and
only the work required, to complete the project successfully
Main processes include:
• Collect requirements
• Define scope
• Create WBS
• Verify scope
• Control scope
Verification and Control Project Management Stages:
Verification project management
Verification project management is a set of process and principles to achieve high quality verification results. These
process and principles are anchored around six essential generic parameters. Six essential generic parameters are Clarity,
People, Metrics, Tracking, Review and Closure. Verification project consists of primarily three phases. They are planning,
development and regressions. All six essential generic parameters are applicable to all three phases of verification

18. Six essential generic parameters :
• Clarity: Identifying the aspects that should be clear. It can be clarity of goals, tasks, timelines and process. Clarity is not
absence of ambiguity but a constant battle against the ambiguity. This is a single most important factor that keeps team
motivation levels up and translates to results.
• People: Right person for right job is half the job done. Bad engineers are rare. Most are just mismatches in assignments.
• Metrics: Management guru Peter Drucker quoted “If you can’t measure it, you can’t manage it”. Metrics provide
indication of how the project execution is progressing. Right metrics provide insights to improve the execution.
• Tracking: Tracking is a process of collecting metrics and using metrics to tune the processes to achieve the desired
results. Tracking provides the push required for closure.
• Review: One of the popular Russian proverb says “Trust, but verify”. Review is a process to guard the quality in each of
the tasks to achieve overall quality goals.
• Closure: ABC of verification project management is “Always be closing”. Functional Verification is never ending process.
Unless you close it, it will go on.

19. Three phases of the verification project:
The three major phases of the verification project are planning, development and regressions.
• Planning phase primarily focuses on creating verification plan and test bench architecture. Verification plan consists of
test plan, checks plan and coverage plan. Based on verification plan and test bench architecture detailed task lists are
created.
• Development phase focuses on building the bus functional model(BFM), test benches and tests. HVLs and Verification
methodologies play a major role in building these.
• Regression phase is about executing all tests and its variants to catch the issues and meet the coverage goals.

20. 1. Planning phase: Clarity
Following four elements should be clear during planning phase. Overall work scope clarity needs to be established during
this phase.
• Scope understanding: Scope of the verification is based on the specifications. Key prerequisite for planning phase is
specifications. Specifications mean both the standard requirement specifications and implementation specifications.
Most of the today’s designs deal with multiple specifications. It’s very important to identify the list of all the
specifications applicable.
• Specifications understanding: Clear understanding of the specifications both the requirement specifications and micro-
architecture specifications
• Verification strategy understanding: A clear verification strategy needs to be established based on the specification
scope and understanding. This forms the basis for the verification plan and test bench architecture creation
• Team understanding: Clear list of the contact persons in architecture, design and verification team at one place

21. 2. Planning phase: Metrics
Metrics during planning phase are meant to provide the idea about the completeness of the verification plan, test bench
architecture and development task lists creation.
Total number of features
Verification plan completeness percentage
Number of tests identified
Number of checks identified
Number of the functional cover points identified
Test bench architecture completeness percentage
Overall architecture completeness
Major blocks of test bench
Total number of major blocks identified
Total number of major blocks for which interface and functionality is defined
Abstract classes
Total number of classes identified
Total number of abstract classes coded and compiling
Development tasks lists
Total number of blocks for which task list is identified
Total development tasks

22. 3. Planning phase: People
• Best of your experienced engineers should be working on verification plan and test bench architecture development.
• Technical leader of the project should be involved in this activity very actively. He should be one of the key contributor
to verification plan and test bench architecture
• Engineers with natural attraction for the engineering depth are well suited for this activity.
• Engineers working on plan should be allowed to think theoretically enumerating all the verification scenarios without
worrying about the resource and schedule content.
4. Planning phase: Tracking
• Planning phase involves one of the highest levels of creative work. Out of box thought process may be required to set
the verification strategy. Make sure it’s not rushed through. It’s easy to rush and create half-baked plans as it’s difficult
to judge if it’s complete in early stages of the project
• Premature closing of planning phase will result in costly reworks later. Its pay now or later with huge interest rates

23. 5. Planning phase: Review
• Verification strategy should be carefully reviewed. It sets the basis for the verification plan and test bench architecture
Verification plan structure review has to be conducted periodically. This ensures no big ticket items are missed
• Review of the verification strategy, verification plan and test bench architecture should be conducted with the architecture
and design teams
• Verification plan should be executable. It should not be limited to a very high level plan.
• Verification managers should pick a feature and question it for its consistency in thought process across all three test plan,
checks plan and coverage plan
6. Planning phase: Closure
• All the specifications applicable are identified and made accessible in a global shared location for verification team
• Code repositories for development, email aliases for the communication and discussions, Task tracking system for project
and bug database are setup
• All three plans test plan, checks plan and coverage plan constituting the verification plan in executable form should be
checked-in under code repository
• Reviews of the verification strategy, verification plans and test bench architecture completed. Major review items
addressed and open items documented and put in a task tracking system for closure

24. 1. Development phase: Metrics
Full development
Total milestones
Completed milestones
Percentage completion in current milestone
Total development man days pending
Tasks
Total tasks
Completed tasks
Pending tasks
Current milestone
Total tasks of this milestone
Completed tasks of this milestone
Total tasks per engineer this milestone
Total completed tasks per engineer this milestone
New tasks added to milestone
2. Development phase: People
• An enthusiastic engineer should be encouraged to ensure productive development environment for everyone. This role
can be played by the technical lead as well partly along with junior engineer.
• It involves hooking everything and getting simulations up and running, keeping check-in regressions healthy, setting up
flows for compile, simulation, full regression ownership and any productivity enhancements. This is a key role and
tough one. It should be well supported and appreciated by everyone in team

25. Development phase: Tracking
• Development is also creative work. Some of the blocks need time to build them well. To make the code reusable. Use
the medium level of follow up for best results
• A good task tracking system is key to development management. Task management system should be able to generate
most of the metrics listed automatically
• It’s not just sufficient to set up the tasks. Periodic scrub of the tasks is equally essential. Scrub to discover if tasks are
blocked for information or dependencies. Keep clearing obstacles to ensure continued progress
• Tasks lists are mainly owned by the verification manager or verification lead. Encourage team to add new tasks
discovered to task management list. Task lists are also assets. Task lists provides good understanding of work to be
completed and load on engineers. Tasks worked without being on tasks management system can mislead the total
project work and individual engineer’s workload
• Weekly meetings should be utilized as opportunity to assess how the closure on the current milestone is coming up.
This should be used as opportunity to bring up the surprises and to identify the areas that need more attention
Not every development task or engineer requires equal attention. Identify critical tasks and complex tasks that need
attention. Verification lead should pay more attention to those tasks

26. Development phase: Review
• Code reviews for every code check-in is great but may be an overkill. Of course nuclear weapon can also kill mosquito if
you have that luxury. Code reviews at certain milestone points are very productive. Invest in the code when it has
proven to be useful by meeting functionality of the milestones. Premature code reviews are waste of precious energy.
• Code reviews are best done as a code walkthroughs between developer and reviewers. This provides opportunity to
developer to provide the context behind the functionality of the code. This ensures the time is optimally utilized for
everyone and best from the code reviews can be extracted
• Code reviews are also opportunities for providing short customized feedback to the developers on the areas for the
improvements and learning.
• Code review actions should not be left floating in email or code review system. Code review actions which require
more than couple of hours of time for fixing should go in the task tracking system
• Alignment with the architectural intent, functional correctness, adherence to standard coding practices and ease of
understanding and maintainability should be accessed as part of review
One of the ignored parts of verification planning is verification of checks itself. This should be questioned as part of the
review

27. Development phase: Closure
• All the developed code should pass the sanity tests. It’s understandable that the detailed verification will be carried
out in regression phase.
• All code developed should be compiling and sanitized with the basic tests. All critical code review actions should be
addressed. If its not completed the same should be added to the task tracking system
• Compile warnings and run time warnings should be periodically reviewed and should be fixed unless its an approved
as exception. These lead to failures to be painfully debugged as programming errors
• Any code limitations or parts of the features planned but not implemented should be documented. Tasks to fix these
later should be added to the task tracking system
Some times even when milestone approaches not all the tasks planned may be completed. Make an evaluation if the
milestone needs to be extended or remaining tasks be moved to next milestone. Some times, it may make sense to move
remaining tasks to next milestone and adjust the schedule accordingly rather than squeezing it and doing a poor quality
job in rush. This provides the closure and provides sense of progress

28. Regression phase:
This is the final phase and climax of the verification. It’s a highly intense phase of verification. Regression phase duration
cannot be controlled. It’s extremely difficult to plan for it and make this schedule bound. Regression is highly reactive
phase. Only quick response with the dynamic adaption is the way to closure.
Key objectives of this phase:
Minimize the passing tests turning in to failure
Maximize the bugs discovered
Get all planned tests executed and passing
Get the code coverage and functional coverage goals met
Regression phase: Clarity
Tests to be executed. The variants of tests to be exercised
The functional coverage and code coverage goals to be met
Set of the new tests to be written
Targets for clearing the backlog failures from previous milestones
Pool of engineers available for the debug and their areas of expertise
Process of running regression, regression failure triaging, failure assignments and reporting of the debug status
Process of filing bugs and guidelines for interacting with the designers to achieve the closure
Process of the debug utilizing the log files, waveforms, interactive debuggers and any additional tools available
Process for repeatability of the falling tests especially for the seeded constrained random tests
Periodic clarity on regression and bugs status with priorities

29. Regression phase: Metrics
Test status
Total tests
Development
Total tests to be written
Total tests under development
Regression status
Total tests enabled in regression
Total passing tests
Total failing tests
Unique failures among failures which need debugging
Breakup of open debugs per engineer
These may have to be generated on different criterias
Bug status
Total bugs files
Total bugs open
RTL Bugs open (can be grouped by priority)
Test bench bugs open (can be grouped by priority)
Number of test bench bugs per RTL bugs (test bench quality
indicator)
Coverage status
Code coverage status
Functional coverage status

30. Regression phase: People
•An enthusiastic engineer to hold front on regressions. He should have good understanding of linux operating
system, LSFs and flows of the regression process. He should also be automation expert ensuring productive
experience for the full regression management
•It may be tempting to push the new engineers into regression debug. It should be avoided. Instead attach them
with the experienced engineers to help them ramp up. If its possible it’s best to start them with writing of the tests
to help them get the awareness of the verification environment and then they can participate in the regression
debug activity
•Developers from both the design and test bench team should be part of the debug pool
•Extroverts, analytical, go getter engineers who can interact with the various engineers from design, verification to
close the debug are best suited for this activity. This activity involves bringing in many hands in to activity to get it to
closure
•Verification lead should set the appropriate debug strategy before the failures are rolled out to team. In case of
large failures whether comparative debug approach vs. regular debug flow decisions needs to be made. When
failure numbers are more than the engineers available in debug pool appropriate prioritization must be done

31. Regression phase: Tracking
• This is one of the highly tracking intensive phases of verification. Good tracking and coordination can give good boost to
the overall activity
• Based on overall project phase sometimes hourly to daily tracking may be required. This frequency of updates provides the
clarity to team involved in the debugging and also helps avoid duplicate debug efforts
• Since frequency of tracking can go to crazy rates the automation for generation of the metrics desired and failure debug
tracking is a must. This can significantly boost the regression triage cycle efficiency
• Subset of the critical debugs should be explicitly identified and should be tracked differently. Anything that needs quicker
closure due to release or any such reason should be put on different track and tracked separately
• Bug filing may look like an additional overhead but it’s an important step. There may be certain level of hesitation from
engineers to follow it. Verification lead and manager should emphasize it. It provides history. Historic data about the bugs
is very helpful in making final tape out decisions
Regression cycle:
• Without follow up link between steps may break and bugs may become zombies
• Regression debugs generate lot of information. Large information can hide small issues. Care should be taken such that any
additional related tasks emerging out of the bugs should be added to the task tracking system immediately. If needed the
tasks can be tagged with the bug filed to keep the context alive
• Regression triaging and debug is activity that can turn stinky very quick. Frequent quick meetings or phone calls may be
more useful than email or bug report based interactions
• Regression run duration, compute and memory requirement statistics should also be tracked periodically. This helps in
release planning as well as future compute infrastructure upgrade planning

32. Regression phase: Review
• Check-in regression should be periodically reviewed and refreshed with the new tests enabled in full regression to keep
it relevant
• Code coverage and functional coverage reviews should be conducted periodically. Actions such as increase seeds of
certain constrained random tests, constraint tuning, writing more tests and test bench upgrades required should be
identified and fed back into task tracking system for fixing
• Very long running tests should be identified which are bottleneck in regression turnaround time. They should be broken
into smaller tests wherever possible to improve regression cycle efficiency
Even with all measures failures rates during critical milestones can go out of control. To recover back from such conditions
a call for code freezes on development may be required. Verification lead and manager should look out for such situations
and make those hard calls to get things back in control
Regression phase: Closure
• Regression is of the most challenging activities to close. It can be compared to building the bridge in the river flowing
full force. Bridge will often be washed away. It’s highly iterative process. It takes grind and patience to get handle on
the closure
• True closure on regression is not possible unless the activity of the development tapers down and closes for most
practical purposes. Step by step various threads of activity that can lead to code changes should be closed down one by
one. Certain level of calculated risk is called for here to achieve closure

33. Project planning, project scheduling and project controlling.
PROJECT PLANNING
In planning phase, plan is made and strategies are set, taking into consideration the company policies, procedures and
rules Planning provides direction, unifying frame work, performance standards, and helps to reveal future opportunities
and threats In Planning, the following steps are followed.
The Objectives of the projects in definite words
Goals and stages intermediate to attain the final target
Forecast and means of achieving goals i.e., activities.
Organization resources-financial, managerial and operational-to carry out activities and to determine what is feasible
and what is not.
Alternatives-individual courses of action that will allow accomplishing goals.
For consistency with company’s policies
An alternative which is not only consistent with its goals and concept but also one that can be accomplished with the
evaluated resources.
Decision on a Plan

34. Forward Planning
Planner starts from the initial event and builds up the events and activities
logically and sequentially until the end event is reached.
What event comes next?
What are dependent events?
What events can take place concurrently?
Backward Planning
The planner starts with the end event, and arranges the events and activities
until
the initial event is reached.
The planner asks himself “if we want to achieve this, what events or activities
should have taken place?
Combined Planning
Combination of both forward planning and backward planning.
At any stage the planner may need to traverse the network back and forth several
times
until it is found to be satisfactory.
Questions of the Planner
What event or events must be completed before the particular event can start?
What event or events follow this?
What activities can be accomplished simultaneously
Resource Classification
Manpower
Material
Machine
Time
Money

35. PROJECT SCHEDULING
Scheduling is the allocation of resources
Resources in conceptual sense are time & energy but in practical sense are the time, manpower, equipment applied to
material.
Scheduling is the process of formalizing the planned functions, assigning the starting and completion dates to each activity
which proceeds in a logical sequence and in an orderly and systematic manner
In Scheduling, the following steps are followed.
Detailed control information is to be calculated.
Timings to events & activities are assigned
Consideration must be given to resources generally concerned with those resources whose availability is limited and which
there by impose a constraint on the project. Important ones are skilled, technical and supervisory manpower and capital
investment
Resource Allocation

36. PROJECT CONTROLLING
• This phase is carried during the execution of the project.
• The difference between the scheduled performance and actual performance are reviewed once the project
starts.
• Project control is established to determine deviations from the basic plan, to determine the precise effect of
these deviations on the plan, and to replan and reschedule to compensate for the deviations.
Controlling, the following steps are followed.
• The Standards and targets are established and targets are generally exposed in terms of time.
• Performance is measured against the standards set down in the first step.
• The Deviations from the standard are identified

37. EXAMPLES ON PROJECT SCHEDULING
Steps are
Define Activities
Sequence activities
Estimate time and
Develop schedule
Techniques are
All the Techniques comes with some limitations and can be used based on the requirements for project scheduling –
Gantt chart- This is represented by the graph or bar chart with a specific bar for activities in the project that shows the
passage of time. Gantt chart limits a clear indication of interrelation between the activities.
CPM- Critical path method was developed for industrial projects where activity times are generally known.
PERT- Program evaluation and review technique were developed for R&D projects where activity times are generally
uncertain. Its prime objective is taking the shortest possible time.
Microsoft projects- All the work is performed on the computer memory and changes can be saved only when the program
is asked to operate.

42. Problem 1 -- The following details are
Determine the critical path, the critical
activities and the project completion time.
• Compare the times for the two paths.
Maximum of {22,19} = 22. We see that
path I has the maximum time of 22
weeks. Therefore, path I is the critical
path. The critical activities are A, B, D
and F. The project completion time is 22
weeks.
• We notice that C and E are non- critical
activities.
Time for path I - Time for path II = 22- 19 = 3 weeks.
Therefore, together the non- critical activities can be delayed
upto a maximum of 3 weeks, without delaying the completion
of the whole project.

43. Problem 2
Find out the completion time and the critical
activities for the following project
Compare the times for the
four paths. Maximum of
{42, 43, 45, 47} = 47. We
see that the following path
has the maximum time
and so it is the critical path
The critical activities are C, F, J and L. The non-critical activities
are A, B, D, E, G, H, I and K. The project completion time is 47
units of time

48. Determine a crashing scheme for the above project so that the total project time is
reduced by 3 weeks
• Therefore Path II is the critical path and the critical activities are A, C, E, G and H. The non-critical activities are B, D and F.
• Given that the normal time of activity A is 4 weeks while its crash time is 3 weeks. Hence the time of this activity can be
reduced by one week if the management is prepared to spend an additional amount.
• However, the time cannot be reduced by more than one week even if the management may be prepared to spend more
money. The normal cost of this activity is Rs. 8,000 whereas the crash cost is Rs. 9,000.
• From this, we see that crashing of activity A by one week will cost the management an extra amount of Rs. 1,000. In a
similar fashion, we can work out the crash cost per unit time for the other activities also. The results are provided in the
following table

49. A non-critical activity can be delayed without delaying the
execution of the whole project. But, if a critical activity is delayed, it
will delay the whole project. Because of this reason, we have to
select a critical activity for crashing. Here we have to choose one of
the activities A, C, E, G and H The crash cost per unit time works out
as follows:
Rs. 1,000 for A; Rs. 1,000 for C; Rs. 1,000 for E; Rs. 6,000 for G; Rs.
3,000 for H.
The maximum among them is Rs. 1,000. So we have to choose an
activity with Rs.1,000 as the crash cost per unit time. However, there
is a tie among A, C and E. The tie can be resolved arbitrarily. Let us
select A for crashing. We reduce the time of A by one week by
spending an extra amount of Rs. 1,000
The revised time for Path I = 3 + 5 + 6 + 5 = 19 weeks.
The time for Path II = 3 + 4 + 6 + 7 + 4 = 24 weeks.
Maximum of {19, 24} = 24.
Therefore Path II is the critical path and the critical
activities are A, C, E, G and H. However, the time for A
cannot be reduced further. Therefore, we have to
consider C, E, G and H for crashing. Among them, C
and E have the least crash cost per unit time. The tie
between C and E can be resolved arbitrarily. Suppose
we reduce the time of C by one week with an extra
cost of Rs. 1,000.
After this step, we have the following network with
the revised times for the activities

50. The time for Path I = 3 + 5 + 6 + 5 = 19 weeks.
The time for Path II = 3 + 3 + 6 + 7 + 4 = 23 weeks.
Maximum of {19, 23} = 23.
Therefore Path II is the critical path and the critical activities are
A, C, E, G and H. Now the time for A or C cannot be reduced
further. Therefore, we have to consider E, G and H for crashing.
Among them, E has the least crash cost per unit time. Hence
we reduce the time of E by one week with an extra cost of Rs.
1,000.
By the given condition, we have to reduce the project time by
3 weeks. Since this has been accomplished, we stop with this
step
Result: We have arrived at the following crashing scheme for
the given project:
Reduce the time of A, C and E by one week each.
Project time after crashing is 22 weeks.
Extra amount required = 1,000 + 1,000 + 1,000 = Rs. 3,000

51. Problem 2
The management of a company is interested in crashing of
the following project by spending an additional amount
not exceeding Rs. 2,000. Suggest how this can be
accomplished
Therefore Path I is the critical path and the critical activities are
A, B, D and E. The non-critical activity is C.
The crash cost per unit time for the activities in the project are
provided in the following table

52. We have to choose one of the activities A, B, D
and E for crashing. The crash cost per unit time
is as follows:
Rs. 3,000 for A; Rs. 1,000 for B; Rs. 1,000 for D;
Rs. 500 for E.
The least among them is Rs. 500. So we have
to choose the activity E for crashing. We reduce
the time of E by one week by spending an extra
amount of Rs. 500.
After this step, we have the following network
with the revised times for the activities
The revised time for Path I = 7 + 12 + 11 + 5 = 35 weeks.
The time for Path II = 7 + 22 + 5 = 34 weeks.
Maximum of {35, 34} = 35.
Therefore Path I is the critical path and the critical activities are A, B, D
and E. The non-critical activity is C.
The time of E cannot be reduced further. So we cannot select it for
crashing. Next B and have the smallest crash cost per unit time. Let us
select B for crashing. Let us reduce the time of E by one week at an
extra cost of Rs. 1,000.
After this step, we have the following network with the revised times for
the activities:

53. The revised time for Path I = 7 + 11 + 11 + 5 = 34 weeks.
The time for Path II = 7 + 22 + 5 = 34 weeks.
Maximum of {34, 34} = 34.
Since both paths have equal times, both are critical paths. So, we can choose an activity for crashing from either of them
depending on the least crash cost per unit time. In path I, the activities are A, B, D and E. In path II, the activities are A, C and E.
The crash cost per unit time is the least for activity C. So we select C for crashing. Reduce the time of C by one week at an extra
cost of Rs. 500.
By the given condition, the extra amount cannot exceed Rs. 2,000.
Since this state has been met, we stop with this step.
Result: The following crashing scheme is suggested for the given project:
Reduce the time of E, B and C by one week each.
Project time after crashing is 33 weeks.
Extra amount required = 500 + 1,000 + 500 = Rs. 2,000

54. Problem 3
The manager of a company wants to apply crashing for the
following project by spending an additional amount not
exceeding Rs. 2,000. Offer your suggestion to the manager.
The time for the path = 15+19 +25 = 69 weeks.
Maximum of {70, 62, 69} = 70.
Therefore Path I is the critical path and the critical activities are
A, C and F. The non-critical activities are B, D, E and G.
The crash cost per unit time for the activities in the project are
provided in the following table

55. We have to choose one of the activities A, C and F for crashing. The crash cost
per unit time is as follows:
Rs. 2,000 for A; Rs. 500 for C; Rs. 1,000 for F.
The least among them is Rs. 500. So we have to choose the activity C for
crashing. We reduce the time of C by one week by spending an extra amount of
Rs. 500.
After this step, we have the following network with the revised times for the
activities
The revised time for Path I = 20 + 21 + 28= 69 weeks.
The time for Path II = 20 + 17 + 25= 62 weeks.
The time for Path III = 15+19 +25 = 69 weeks.
Maximum of {69, 62, 69} = 69.
Since paths I and III have equal times, both are critical paths. So, we can choose an activity for crashing
from either of them depending on the least crash cost per unit time.
In path I, the activities are A, C and F. In path III, the activities are B, E and G.
The crash cost per unit time is the least for activity C. So we select C for crashing. Reduce the time of C by
one week at an extra cost of Rs. 500

56. After this step, we have the following network with
the revised times for the activities The revised time for Path I = 20 + 20 + 28= 68 weeks.
The time for Path II = 20 + 17 + 25= 62 weeks.
The time for Path III = 15+19 +25 = 69 weeks.
Maximum of {68, 62, 69} = 69
Therefore path III is the critical activities. Hence we have to select an
activity from Path III for crashing. We see that the crash cost per unit
time is as follows:
Rs. 3,000 for B; Rs. 1,000 for E; Rs. 1,000 for G.
The least among them is Rs. 1,000. So we can select either E or G for
crashing. Let us select E for crashing. We reduce the time of E by one
week by spending an extra amount of Rs. 1,000.
By the given condition, the extra amount cannot exceed Rs. 2,000.
Since this condition has been reached, we stop with this step.
Result: The following crashing scheme is suggested for the given
project: Reduce the time of C by 2 weeks and that of E by one week.
Project time after crashing is 67 weeks.
Extra amount required = 2 x 500 + 1,000 = Rs. 2,000