This chapter covers fundamentals of project management. It introduces project management concepts and provides a system view of project management plan and processes with which they are implemented. The knowledge areas include scope, time, cost, quality, and risk. The chapter will also emphasize on the interrelated nature of these knowledge areas. In addition to introducing these knowledge areas, the chapter will attempt to develop an understanding of these concepts and the important role of project teams in managing projects successfully. This chapter will also discuss similarities and differences between the plan-driven and change-driven (Agile) project methods.
- project management
- risk management
- schedule network
- project plan
- project teams
- agile projects
It is common that every business faces a situation that compels a change. Some of these changes usually are starting a new office, launching a new product or service, improving an existing work process, installing a new computer system, merging with another company, moving to a new location, entering a new market, meeting a social need and so on. These changes are necessary to meet operational or strategic goals of an organization. And these goals are accomplished using projects. Further, the primary objective of an organization is to create value for its stockholders and it is achieved when the organization creates a healthy profit through the achievement of its strategic objectives . And projects are the instruments by which an enterprise accomplishes its strategic objectives .
Organizations design and execute projects that can be classified as internally and externally funded projects based on the nature of their business. In organizations that conduct externally funded projects for a fee (of sorts) on behalf of external clients, efficiency in the conduct of projects is the means by which the amount of real profit is enhanced . If the primary line of business of the organization is service, manufacturing, or research; the projects in the organization are probably internally funded, and the missions of project teams are to create increased operational efficiency, new products, or new markets. Internally funded projects also play an important role in the profit margin, albeit indirectly. In the case of a nonprofit organization, the projects are executed either internally or externally and are conceived to serve its main purpose, which is a social cause and not profit. However, the underlying project management principles of effective and efficient use of resources are still valid and important to expand their services for social cause without increase in their resources .
1.1 So, what is a project?
PMBOK® defines project as a temporary endeavor to create a unique product, service, or result . It uses the word, temporary, which sometimes implies negative connotation and low importance. One must remember that “temporary” does not influence the length of the project duration. Also, PMBOK definition does not introduce the concept of value and its contribution to organization’s strategic goals. Value can be tangible (e.g., cost savings) or intangible (e.g., increased brand equity). However, value is always associated with benefit. A project must provide value to all its stakeholders; if not, project will not receive adequate support .
A project can be seen as a new time-bound effort with several related and/or interdependent tasks to create a unique product or service that adds value. As it is a new effort, often, we do not have complete knowledge or experience about planning and executing the project. Needless to say, projects are characterized with unknown factors and ambiguity, which delay the development of detailed scope and specifications to later stages of project planning. Further, any project requires resources such as materials, tools, equipment, and people to execute it. Considering these additional facets of a project and to extend the definition of a project further, project can be considered as a complex, non-routine, one-time effort limited by time, budget, resources, and performance specifications designed to meet customer needs and add value to all key stakeholders.
1.2 Distinction between project and process
It is important understand the distinction between a project and process. Process is repetitive in nature with clearly defined procedures and outcomes. A process will yield the same result be it a product or a service. Project, on the other hand, is unique and new by definition. So, outcome of a project would always be new and unique. However, project is executed through project management processes and project deliverable-oriented processes.
Projects are conceived, created, and managed because an individual or organization other than the project manager or project team identifies a need . As stated earlier, projects are always aimed at fulfilling organizational objectives and/or strategic needs such as market demand, customer request, technological advance, legal requirements, a social need (for non-profit organizations), crisis situation, and obsolete technology or equipment.
1.3 Project characteristics
A project is time-bound, i.e. it has definite beginning and definite ending. However, it does not mean that project is of a short duration, which may vary from 10 days to 10years. However, “temporary” does not apply for the project deliverable. It is interesting to note that project team is certainly temporary (Table 1).
- Defined start and end
- Transient teams
- Little precedence
|- Revolutionary improvements|
- Level of difficulty is high
Project outcome can be a product, service, or result.
product: iPhone, power plant
service: online banking, Google search
result: decision to pursue Tokyo airport expansion
unique: something or some aspect that is not repetitive
Progressive elaboration is another characteristic of a project. As requirements are not clear at the initiation stage. Developing the project scope in steps and continuing by increments is a common aspect of a project and it goes through stages such as: scope – scope definition – project plan – detailed WBS. All these project characteristics present a challenge to manage projects successfully.
2. Project management
Managing a project includes identifying requirements, establishing clear and achievable objectives, balancing competing demands of quality, scope, cost, and time, adapting specifications, plans, and approach to meet expectations of all key stakeholders including the client and the end-user. We define project management as the art and science of using experience, knowledge, skills, tools, and techniques efficiently and effectively to meet stakeholder expectations.
Current trends in the project suggest that organizations manage several projects simultaneously.
Long-term success in managing projects requires proven and established project management practices and processes and several successful projects to emulate . Therefore, organization-wide resource allocation becomes necessary to succeed, which may not always be possible. Also, required skills and expertise are always not available locally. Consequently, virtual teams are becoming common for project execution. PM tools increasing in complexity and usefulness. Managing project involves:
establishing clear and achievable objectives
balancing the demands of time, cost, scope, and quality
adapting to expectations of all stakeholders
Thus, project management is an approach to accomplish project objectives within organizational structural and resource constraints for internal projects. For external projects, political, social, legal and environmental constraints may also have to be considered.
Project is an organization-level effort associated with complexity, uncertainties, and unknowns. Consequently, it requires continual involvement of several functions. Obviously, integration, coordination, and accountability assume greater importance. Project Management tools and techniques will help to accomplish these integration and management functions. Uncertainties and unknowns affect requirements to change dynamically and the project manager has to meet these requirements while meeting the expectations of all the project stakeholders.
2.1 Necessity for project management
Managing project is fast becoming a standard way of executing business strategies. Some of the reasons for deploying project management practices are:
increased competition due to free market philosophy
constraints of cost, time, and scope (quality)
Nature and frequency of projects determine whether an organization requires an informal or formal project management practices. Some of the following questions will help determine the requirement of a formal project management in organizations.
Is the effort associated with complexity and uncertainty?
Are external and technical environments dynamic to compel changes in the organization?
Is it governed by constraints such as time, budget, scope, and quality?
Are there multiple functions involved?
Affirmative responses to some or all of these questions will determine the extent to which project management is required to be formalized. However, project Management (PM) needs investment in resources and consequently demands results. Also, organizations are required to train people at all levels. On the positive side, PM facilitates effective and efficient use of resources. PM also provides an opportunity for senior management to realize strengths and weaknesses of an organization.
In many organizations, PM demands changes in policies, practices, and procedures. Further, PM will also influence the function of finance because project-based financial control systems are routinely implemented. PM tools and techniques aid productivity and help us deal with complexity .
2.2 Key drivers of project performance
Projects, by definition are new and learning new is associated with change in behavior. Thus, working in teams, integrating, learning, and collaborating are essential characteristics of the project teams. Consequently, effective communication assumes great importance for its success. As a general rule, with the increase in project size, the number of people involved in the project will also increase. Consequently, effective communication becomes complex with the increase in project size. Based on extensive research, the following are identified as the key drivers of project performance and they are also considered success factors . It is the primarily the responsibility of the project manager to:
define project processes and roles
implement consistent processes
communicate expectations and outcomes to all stakeholders
create clarity in communications
facilitate organizational support
manage outcomes be developing performance measures
PM Maturity and success
Project management maturity is a state determined by fully developed standards and processes, which lead to repeatable success in managing projects. PM maturity ultimately should lead to developing best PM practices. However, you should remember that project success factors are different for different stakeholders. For example, a project, in spite of experiencing time and cost overruns, may still be considered successful by the client.
The distinction between project success and project management success must be understood. Project success is measured against the overall project objectives whereas project management success is a measure of managing project within time, cost, and meeting the scope requirements . Success of a project should be measured by considering three different areas: project meeting its own cost-duration targets, the deliverable meeting enterprise strategic objectives, and the deliverable meeting the enterprise financial objectives.
3. Strategic alignment
Projects are means to accomplish strategic objectives and goals of organizations. Project Management (PM) is an integration of several academic disciplines such as accountancy, decision sciences, economics, finance, and management. It uses systems approach in integrating these disciplines. PM will continue to grow in its importance because it is how business is done, in the present global economy.
Project selection should be based on the corporate strategic plan and investment strategies . Thus, each project must have a business objective that is aligned with the strategic plan; it will serve as the foundation for the project investment proposal. In addition, a project must conform to a broader purpose than a set of internally derived objectives. It must support overarching strategies of their parent company or its clients. To be successful, the project manager and the team should clearly understand the vision and mission of their clients; such understanding is more likely to deliver products and services that meet demanding customer requirements, which eventually results in customer satisfaction.
4. Scope management
Project Scope must include all the work required, and only the work required by the client . Scope management is concerned with defining and controlling the scope. It assumes greater importance than all other knowledge areas of project management. The scope should define the project by what should and should not be planned, budgeted, staffed and executed. Project scope also identifies the boundaries separating excluded activities or resources from those, which must be included for the project execution.
As stated earlier, projects are characterized by unknown factors and ambiguity, which delay the detailed development of scope and specifications to later stage of the project. Consequently, the scope of the project continually changes throughout the project. Sometimes, the original objective of the project may also change as the project progresses and we learn more about what is needed, what is possible, and what the costs are going to be. All these changes will impact on the project scope and its management.
Despite these changes, a clearly defined scope is crucial to developing a project plan, which provides a baseline for managing the schedule, the budget, and the detailed work of the project. Without a clearly defined scope, we have no basis for tracking progress on the project as defined or for altering schedule and cost criteria should the client request changes in the original project plan.
Once a project has been initiated, the project manager and an early-stage project team begin scope management by creating a preliminary scope statement based on the project charter. The preliminary scope statement formalizes between the project and its customer an agreement regarding quantifying project/product objectives and clarifying specific deliverables.
While the preliminary scope statement sets objectives at a higher level of abstraction, these objectives must be defined in as much detail as possible before explicit schedules, budgets, and work plans can be developed during the planning phase of the project management life cycle . At this point, historical information and expert opinion are applied within the constraints and assumptions of the present project to create a body of requirements necessary for guiding project execution. This body of requirements is the foundation of scope definition, which subdivides the major project deliverables into smaller, more manageable components. It is important to translate requirements of the client into specifications, which denote finality and clear definition of project outcomes with specific quality parameters and measures.
This preliminary scope statement document sets various product performance criteria, delineates the initial project organization, boundaries, assumptions and constraints, while providing a high-level WBS and order of magnitude cost estimates [2, 6]. Below is an example of deliverable-oriented WBS (Figure 1).
This preliminary will be refined into the formal scope statement as the project moves into its planning phase. This refinement comes in the form of WBS. It provides a cornerstone of the scope management plan, which lays out how objectives and deliverables will be administered and how scope changes will be integrated into the project.
5. Cost management
WBS identifies all project activities to be executed but it does not include estimates of time, resources, or project costs. WBS should be initially developed at a higher level and expanded to include more specifications as you incorporate additional requirements of the project. As a next step, you will develop first two or three levels of the WBS, which essentially contain deliverables. These higher-level work elements are broken down into smaller and smaller work packages so that you can have manageable tasks to complete at any given point in the project . The work package list is both inclusive and exhaustive. Preferably, these tasks should be at level 3 or lower. Remember that a good WBS encourages a systematic planning process, reduces the possibility of omission of key project work elements, and simplifies the project by dividing it into manageable units.
5.1 Cost estimating
To estimate cost for a work element, we need the following information:
Resources required (people, equipment, tools, materials)
Duration of usage (time unit)
Cost rate for time unit
Duration may not be relevant for materials, which are absorbed for completing the work. Number of resources for each resource multiplied by its duration and the rate will provide an estimate of that resource cost. Adding all the resource costs will give you an estimate of the activity cost. We sum up all these activity costs of the project to determine the total estimated project cost. These costs must then be managed and controlled along with the schedule throughout the project execution phase.
The most accurate and most reliable estimate for a project can be developed when all of the elements of the WBS have been identified with a reasonable degree of reliability and when the resource breakdown structure (RBS) has been defined with the desired degree of certainty . This estimate is referred to as the bottom-up estimate and it is derived from detailed information that is contained in the WBS and RBS at the time of the estimate. Resource Breakdown Structure (RBS) is similar to WBS. By resources we mean everything that will cost money to obtain and are necessary for the completion of the project (labor, materials, equipment, licenses, taxes). RBS follows the WBS structure of hierarchy and we can classify resources into major categories such as:
Materials and installed equipment
To be useful, RBS should be accurate and reliable, so it needs to be updated periodically. An example of RBS is provided below (Figure 2).
Detailed and accurate estimates require substantial definitive information about the project. Further, they require a relatively large block of time and effort for the estimating task. Therefore, one needs to strike a balance between the time spent on estimating, the accuracy of the results, and the degree of accuracy required by the stakeholders at the point in the project life. Project management methodologies recognize various tools and strategies to support project cost estimating.
Analogous estimating is a top-down approach where managers create estimates based on expert judgment, data from similar projects, industry benchmarks, published or interpersonal research sources. This approach is typically less accurate than bottoms-up estimates, but it may be quicker and less costly to develop.
Parametric estimating uses mathematical models to predict costs. These methods may include specialized computerized estimating tools. Specific metrics may applicable to particular industry sector such as cost per line of code, and square footage construction cost.
Bottoms-up estimating is a method in which the people and other resources assigned to the activity create the cost and schedule estimates. This approach creates optimal commitment from the performing team, and is effective when the team contains appropriate subject matter expertise (domain specific knowledge) and adequate experience to accurately forecast duration estimates. Of all the estimates, this approach tends to be more accurate. An example of bottom-up estimate is shown below (Figure 3).
Once the costs of all work packages have been estimated, supplementary information documented, and cost accounts assigned, then these costs are rolled up to highest level of the WBS to determine project cost. This is a process of progressively totaling the work package estimates to their higher levels of detail.
6. Time management
Time Management is required to accomplish timely completion of the project and organizes it into six components, five of which occur during the planning phase of project lifecycles:
Activity Definition: identify and document activities to produce the WBS elements
Activity Sequencing: identify and document interactive logical WBS relationships
Activity Resource Estimating: determine what and when resources quantities are needed
Activity Duration Estimating: develop activity durations from scope and resource information
Schedule Development: determine start and finish dates for activities
Schedule Control: manage and control changes to the schedule
In general, scheduling tools include:
Bar (Gantt) Charts
Of these, the network diagram shows interdependencies of all tasks and illustrate the workflow of the project and assumes greater importance.
6.1 Network diagram
Network diagrams have evolved as a de facto standard for building project schedules because of their emphasis is on activity dependencies. They depict entire projects, or subprojects, as visual maps that portray activities in their required order of execution. These diagrams can be developed in one of the following two forms:
Activity-on-Arrow (AOA), also called Activity-on-Line (AOL) or Arrow Diagramming Method (ADM)
Activity-on-Node (AON) also called Precedence Diagram Method (PDM)
AOA diagramming is almost never seen today in popular software programs due to the fact that additional memory is needed to program the dummy activities.
6.2 Activity on the node (AON) diagramming
AON or precedent diagramming was developed in the late 1960’s specifically to “do away” with the dummy activity. In this form of diagramming, the arrow represents “precedence;” it simply identifies what activity must be completed before the next can begin, with the arrowhead representing direction of flow through the network. In precedent diagramming the arrow does not represent work accomplished. Instead, work is represented on the node of the network – and in this case the node is represented by a rectangle with the name of the activity within the rectangle. Other information may also be entered into the rectangular node, including early start, early finish, late start, late finish, duration, cost, etc. The IT industry has adopted precedent diagramming as its predominant form of network diagramming.
6.3 Rules and accepted practices
Network diagramming is a scheduling technique fundamental to the skills of any project manager. There are a few basic rules, or accepted practices, that apply to all network diagrams:
An arrow is a straight line and the arrows showing precedence may have right angles built into them. Good practice requires that all such bent arrows be bent at right angles, and only at right angles, so that we can clearly identify that the bend was intended.
An arrow is always directional, with the arrowhead demonstrating the direction. There must be an arrowhead on each arrow to indicate its direction.
The arrows cross each other frequently – but when good practice is used these arrows will cross each other at right angles. The purpose of this is to help us follow the arrows without getting sidetracked onto another arrow.
In well-formatted network diagrams, arrows may proceed from the left to the right, they can proceed up, or they can proceed down on the paper. In the absence of arrows, one can assume that the activities proceed from left to right.
Every project has one, and only one, starting point; and one, and only one, ending point. This is easily accomplished in the AOA format, but it is an accepted practice that is frequently violated in AON networks. The way to correct this error in AON formats is to add two additional nodes, one labeled “start” and the other labeled end. Then, all of your initial activities are initiated from the start node and all of your hanging activities will be tied in to the end node. Of course, the duration of both the start and end nodes will be zero.
6.4 Activity duration estimating
PERT (Program Evaluation Review Technique) has an emphasis on meeting schedules with flexibility on costs and it can be drawn only on an AOA diagram, and therefore, can have dummies.
Has 3 estimates per activity: Optimistic (O), Pessimistic (P), and Most likely (M)
PERT calculates an estimated time using the following equation: ((P + 4 M + O)/6)
These estimates can be used to describe a Beta Distribution. You are probably familiar with a Normal Distribution (similar to the shape of a Bell and used in Six Sigma Quality Management). A Beta Distribution has a different shape as shown in Figure 4.
Notice how there is a long tail to this distribution making different than a normal distribution where the m would be an equal distance between the a and the b and would represent the 50/50 mark of a distribution (50% of sample times falls to the left of m and 50% of sample times falls to the right of m).
6.5 Critical path method (CPM)
Although this technique may use the words critical path, it does not refer to finding the critical path. It refers to estimating based on one time estimate per activity.
The critical path is the longest path in the network diagram.
There may be more than one critical path.
Allows you to identify potential points where project can go “off schedule” and slack or “float time” that allows you to delay some tasks that are not on the critical path.
6.6 Monte Carlo simulation
This method will create a project duration that is closer to reality than CPM or PERT. This method uses computers to simulate the outcome of a project based on PERT estimates and the network diagram, but does not use the PERT formula. Simulation can tell you the probability of completing the project on any specific day, probability of completing the project for any specific amount of cost, probability of any task actually being on the critical path, and overall project risk.
The network diagram shows the sequence of work elements required to reach project completion. Note that the initial stage of the network diagramming does not require time or cost estimates. We simply determine the most logical and technically viable approach to completing the project and use the network format to visualize this scenario. You must remember that initial network diagram logic is dictated by work-related constraints only; you should not introduce resource and time constraints at that time.
Once the network illustrating a logical flow of work elements in the project is developed, you can assign (or assume) resources to each activity and develop initial task time estimates. These estimates are then aggregated across the network to calculate its critical path, and the slack times associated with each activity. These calculations are based on a forward pass to compute the earliest start and finish times for each activity, and then a backward pass to determine the latest start and finish times of the activity. Then the difference between the earliest and latest times for any activity gives us its slack time. All activities with slack times of zero duration constitute the critical path(s) for the project.
7. Quality management
Quality management refers to the processes required to ensure that projects satisfy the needs for which they are undertaken. These processes should make certain that a project does not deviate from agreed-upon specifications. Quality management requires accurate assessment of stakeholder needs and requirements during both project planning and implementation. It is important to remember that quality must be planned in as opposed to inspected in. Without adequate quality management, projects may face the risk of increased costs while compromising the project team morale and customer satisfaction.
Quality planning makes use of some quality management tools and techniques project outcomes (products and tangible deliverables) and project management processes. This is an important distinction to understand.
Quality related to project outcomes (deliverables or services) is determined during the planning phase when requirements and specifications are defined. Quality assurance and control processes are implemented as we develop these project deliverables during the project execution phase. This aspect of quality is primarily the responsibility of the project manager and the project team.
Quality related to project management processes is influenced by the organization’s knowledge and maturity in managing projects. However, proper implementation of quality assurance remains the responsibility of the project manager and the project team.
One of the most important tasks a project manager must focus on when planning quality is to define quality and how it will be measured (i.e., What defines Project Success?). When developing these metrics, Project Managers should remember to include both quantitative (benchmark specifications, experiments, and financial/cost metrics) and qualitative (subjective assessment) metrics. Cost of Quality includes consideration of conformance costs (both prevention and appraisal) and non-conformance or failure costs (both internal and external). Non-conformance costs tend to be higher.
Quality Assurance is about evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant system of quality standards.
Quality Control is monitoring specific project results to determine their conformance to specific quality metrics and identifying ways to eliminate the causes of unsatisfactory performance. During Quality Control quantitative analysis is applied to specific processes and project protocols. When processes operate beyond predetermined limits, adjustments will have to be swiftly implemented to bring the operations back into conformance with project-defined quality standards. Quality Control tools include:
Control charts: Determines process stability.
Cause and Effect Diagrams: Illustrates how various factors might cause problems or effects.
Pareto diagrams: Identifies quantity of defects assigned by category and cause.
Statistical sampling: Narrows a population of study to a representative sample.
Run Charts: Show the history and pattern of variation.
Trend analysis: Assesses non-conformance over time.
It is important that you understand how these tools operate. Most of these tools are not specific to project environments. They have been developed and utilized to enhance better products and processes in continuous manufacturing environments.
8. Risk management
Risk is an exposure to a situation that is usually associated with unfavorable outcome . Project risk is an uncertain event or conditions that, if occurs, has a positive or a negative effect on at least on one of the project objectives. The possible result of a risk is either loss or gain. If left unaddressed or ignored, specifically, the negative risk, it could potentially interfere with the successful completion of the project and may result in time and cost overruns, or diminished quality of the product or service. Risk is integral to a project as it is a new effort that is associated with unknowns and uncertainties. In general, when you try something new, risk is inevitable.
It is important to make a distinction between a risk and a problem. A problem is identified and known in a current time-frame and it is a certain event. Therefore, it demands an immediate solution. A risk is a probable and a potential event that may occur in future. Even when a risk event takes place, its consequences are uncertain . A risk is also known or unknown event. Risks are problems that have not occurred yet. A risk can become a problem if it is not planned or managed. Occurrence and assessment of a project risk is a combination of an event which is unanticipated or unwanted, likelihood of its occurrence and its impact on project execution. So, identifying, analyzing, and responding are the essential elements of risk planning.
Managing project risk is inevitable and important to project performance. Risk management is the art and science of identifying, analyzing, and responding to risk factors throughout the life of a project and in the best interest of project objectives and metrics for project success. The purpose of risk management is to address risks associated with projects in a systematic manner. If not addressed comprehensively and completely, risks can lead to failure of projects in terms of cost, scope, and project deliverables . The goal of risk management is to maximize the results of positive events and minimize the consequences of negative events. Sources of a risk in a project can be understood from the risk breakdown structure (Figure 5).
A formal or informal approach to planning and managing risks within a project depends on the impact of risks on project objectives such as financial targets, timely and successful completion of the project. However, it is critical that we understand the formalized approach to risk management. In taking a more formal approach to this process, the PMBOK defines risk management as consisting of (1) Plan risk management (2) Identify risks, (3) Perform qualitative risk analysis, (4) Perform quantitative risk analysis, (5) Plan risk responses, and (6) Control risks. In this learning module, we will focus on the first five of these processes, leaving (6) control risk to be covered later in the program. Various strategies for managing risk are:
Accept: absorb the potential damages
Mitigate: develop protective measures
Transfer: re-route the risk to someone else
Avoid: use an entirely different approach
The risk management plan is a complex process, influenced significantly by organizational and project context, the cultural and operational styles of the performing organizations, as well as the individual perceptions and risk tolerances of management and of the other project stakeholders. Understanding management and stakeholder risk tolerances is critical: customers, sponsors and senior management are expected to have different perceptions of what constitute acceptable risks. Risk management plan should address each of the above considerations in a manner, which is relevant to the individual project and its unique environment.
9. Importance of project teams
Projects are executed in teams. In general, projects are managed using teams in a work environment that is complex for two reasons: first, each project is unique, and second, conditions for team selection and motivation are often far from ideal . In addition to uniqueness and complexity, unfamiliarity is often described as one of the characteristics of projects and as a result, projects are often associated with change. Consequently, successful project performance requires strong leadership, which provides vision and ability to cope with change.
Projects, by definition, are unique and are often associated with uncertainties and unknowns. It is reasonable to assume that in project management, it is not if the plans will change, it is when, what will change, and by how much. If anything is constant in a project, it is the change. When changes are significant in a project, which is often the case, leadership role assumes greater importance. Leadership has its efforts directed towards convincing people about the need to change, aligning them to a new direction, and motivating people to work together to achieve project objectives under difficult and demanding work environments .
Motivating the project team involves getting the team members to do the tasks that need to be done, not because they have to do them but because they understand the value of their work to the overall success of the project and they want to do them. If people want to do what we need to have them do, their commitment is bound to be greater, and the job is likely to be accomplished much better than if they were being forced to do the work.
Project managers must understand the personal aspirations of project team members and support them. The project manager’s leadership skills play an important role in motivating and guiding the project team to grow as professionals while accomplishing project goals at the same time. In essence, project managers should ensure that both personal and project goals are accomplished and that the conflict between these two goals is minimized .
The project manager’s job is to get others to do what the project manager needs them to do, not because they have to but because they want to. Empowerment means providing freedom to people (not control) so that they can successfully do what they want to do. This is very different from making them do what you want them to do. Empowerment makes sense on projects. Projects typically employ a multidisciplinary approach, requiring subject matter experts from different functional areas. Each person brings unique expertise, and experience to the project team. By letting project team members make decisions and set goals pertaining to their roles and functions, the project manager can empower the team.
10. Plan-driven vs. change-driven projects
Plan-driven or traditional project management presents a transformation view of production. It is based on principles of: managing the project as planned, using the plan for execution, monitoring and for control. The plan includes measures for monitoring progress and completion. The plan-driven or traditional approach is suitable when we can define the scope and specify deliverables precisely. In this approach, uncertainties and unknowns may still exist but they may not be challenging or disruptive to the project deliverable . However, the traditional or plan-driven project management approach may be challenged if a project is complex and changes are major.
When a project lacks complete understanding of the project deliverables or outcomes, or when a project is associated with fast-paced technological changes, or needs of the client are unclear, change-driven or Agile method is preferred. These projects are associated with uncertainties and change. The client may reveal functional outcomes incrementally as the project makes progress and results are assessed. The project adapts change-driven approach and project team’s immediate focus is on generating value to the client.
The main difference between the plan-driven and change-driven approaches is that instead of freezing specifications early and developing a fixed plan, the Agile approach adapts flexibility to modify and alter project plans to address critical and changing business needs .