Upgrade to remove ads
Complete IT Project Management Set
All IT Project Management Sets
Terms in this set (260)
A project is a unique venture with a beginning and an end.
Projects are goal oriented.
"a temporary endeavor undertaken to create a unique product or service".
Elements of Projects
• Complex, one-time processes
• Limited by budget, schedule, and resources
• Developed to resolve a clear goal or set of goals
Why projects are important
• product life-cycles have shortened
• product launch windows are becoming increasingly narrow
• increasingly complex and technical products
• emergence of global markets
• an economic period marked by low inflation
5 components of project
a. Client interest
b. Project stake
Project management maturity models
Used to allow organizations to benchmark the best practices of successful project management firms.
Purpose of benchmarking is to systematically manage the process improvements of project delivery by a single organization over a period of time.
Use of maturity models
Development of better project management practices is an evolutionary process, involving systematic commitment to continuous improvement, maturity models offer the template for defining and then achieving such progressive improvement.
Generic PM maturity model
Low maturity - Ad hoc, no common language, little support
Moderate maturity - Defined practices, training programs, organizational support
High maturity - Institutionalized, seeks continuous improvement
Project manager's responsibilities
1. Selecting a team
2. Developing project objectives and a plan for execution
3. Performing risk management activities
4. Cost estimating and budgeting
6. Managing resources
Six criteria for project screening/selection method
1. Realism; model must reflect organizational objectives.
2. Capability; model should be flexible enough to respond to changes in the conditions under which the project are carried out.
3. Flexibility; model should be easily modified should trial applications require changes.
4. Ease of use; model must be simple enough to be used by people in all areas of the organization.
5. Cost; the screening model must be cost-effective.
6. Comparability; model must be broad enough to be applied to multiple projects.
Issues in project screening and selection
Internal operating issues
Additional factors, including:
- Patent protection
- Impact on company's image
- Strategic fit
True for any decision model
- Only partially reflect reality
- Include both objective and subjective factors
- Fails to resolve trade-off issues
Simplified scoring models
1. Assign importance weights to each criterion.
2. Assign scores to each criterion in term of its rating.
3. Multiply importance weight with score.
4. Add the weighted score to arrive at an overall project score.
Analytical hierarchy process
1. Structuring the hierarchy of criteria
2. Allocating weights to criteria
3. Assigning numerical values to evaluation dimensions
4. Evaluating project proposals
Limitations of AHP
- Negative utility
- Requires all criteria to be openly available.
Profile models disadvantages
- Limit decision criteria to 2
- Some value must be attached to risk which is not always logical
- Discounted cash flow analysis
- Net present value
- Internal rate of return
- IRR is not ROI. Only if project-generated cash flows can be reinvested in new projects at similar rates of return does this hold true.
- IRR and NPV typically agree only when projects are independent of each other. If projects are not mutually exclusive IRR and NPV may disagree. NPV is then leading.
- If cash flows are not normal IRR may arrive at multiple solutions, only one of which is correct.
Choosing a project selection approach
- Focus on the method
- Right method for the right situation
Portfolio management process
- Decision making
- Review alternatives
Keys to successful PPM
- Flexible structure and freedom of communication (fostering the right environment for innovation)
- Low-cost environmental scanning (launching many low-cost pilots to gauge commercial viability of projects)
- Time-paced transition (planning the introduction of new products).
Common problems in PPM
- Conservative technical communities that are not willing to give up projects that do not align with business goals.
- Out of sync projects and portfolios
- Unpromising projects
- Scarce resources
Everything about a project - work content as well as expected outcomes. Including:
- Project's goals
The function of controlling a project in terms of its goals and objectives through the processes of conceptual development, full definition, execution and termination.
Scope management activities
1. Conceptual development
2. Scope statement
3. Work authorization
4. Scope reporting
5. Control system
6. Project closeout
Goal of scope management
Maximum efficiency through the formation and execution of plans or systems that leave as little as possible to chance.
The process that addresses project objectives by finding the best ways to meet them.
Elements of conceptual development
- problem statement
- information gathering
- alternative analysis
- project objectives
- statement of work
Statement of work
A detailed narrative describing the required work for a project.
Reflects the project team's best efforts at creating the documentation and approval of all important project parameters prior to proceeding to the development phase.
Scope statement key steps
- Establishing the project goal criteria
- Developing the management plan for the project
- Establishing a work breakdown structure
- Creating a scope baseline
Document providing a summary description of each component of the project's goal, including a basic budget and scheduling information for each activity.
Purposes of the work breakdown schedule
1. It echoes project objectives
2. It is the organization chart for the project
3. It creates the logic for tracking costs, schedule and performance specifications for each element in the project
4. It may be used to communicate project status
5. It may be used to improve overall project communication
6. It demonstrates how the project will be controlled
Defined as WBS elements of the project that are isolated for assignment to "work center" for accomplishment.
Used to allocate costs to specific activities in the WBS.
Organization breakdown structure
Allows companies to define the work to be accomplished and assign it to the owners of the work packages, including budget.
Responsibility assignment matrix
Identifies team personnel who will be responsible for each task in the project's development.
Often consists of the formal sign-off on all project plans, including detailed specifications of project deliverables.
Key identifiable features of contracts
- Contractual requirements
- Valid consideration
- Contracted terms
Turnkey / lump-sum
Project organization assumes all responsibility for successful performance.
Which fix the company's profit for a project in advance.
Determines the types of information that will be regularly reported. Determines the frequency and types of updates.
Typical parameters in project update reports
- Cost status
+ S curves
+ Earned value
+ Variance of exception reports
- Schedule status
- Technical performance status
Different development lifecycle models
- Waterfall models
- 'b' model
- 'V' model
- Incremental model
- Spiral models
- Extreme programming
Common factors apparent in agile approaches
1. The success of the approach depends on users and technical staff being empowered to make decisions without having to obtain explicit approval from senior managers.
2. All deliverables are reviewed for their business fitness rather than their adherence to requirements documents.
3. Testing is seen as being an integral part of the iterative cycle.
4. All changes are viewed as being reversible.
5. Incremental delivery is acceptable and so a partial system may be implemented initially and refined by subsequent increments.
6. The concept of a timebox is used to develop a system with a predefined scope within a short time limit.
7. Typically workshop-type methods are used to develop requirements and agree priorities.
Eight principles of DSDM
1. Focus on the business need.
2. Deliver on time.
4. Never compromise quality.
5. Develop the solution iteratively.
6. Build incrementally from firm foundations.
7. Communicate continuously and clearly.
8. Demonstrate control.
System development lifecycle
Covers the whole life of a system. Not only feasibility study, analysis, specification, design and development, but also the operation, maintenance and enhancement aspects which take place after the system has been accepted by the end-user. Often only focusses only the technical aspects.
Covers the delivery of whatever has been defined as constituting the end-product of the project. Although often shorter that system dev lifecycle it also includes associated management and quality aspects necessary for project success.
Concerned with the actual deliverables for the Information System.
Used to manage the project itself - the organization, plans, reports, etc.
Two basic development lifecycle models
Waterfall vs. Spiral
The waterfall method
- Is generally taken to mean any sequential model.
- Each stage has two elements: (1) the work being carried out and (2) the 'verification and validation' of that work.
- Rework when necessary is carried out in succeeding stages and the original stage in which the product was produced is not revisited.
- (Good) Addresses elements of quality management through verification and validation, and configuration management by baselining products at the end of each stage.
- (Bad) Does not have explicit means for exercising management control on a project, and planning control and risk management are not covered.
- Works best when the level of reworking of products is kept to a minimum and the requirements are well understood from the outset.
The 'b' model
Adds project maintenance as a cycle to the waterfall model, following the same stages as the original development.
The 'V' model
- Variant of the waterfall method.
- Shows correspondence between the different stages of the project.
- Demonstrates elements of quality assurance (QA).
- Enables the procurement and delivery stages to be clearly defined and the deliverables of each stage to be validated.
The incremental model
- Variant of the waterfall method
- Phased delivery; functionality is delivered in different phases.
- Not appropriate where the scope of the project is poorly defined or undecided, or the requirements are not clear.
The spiral model
- Differs from waterfall in that it has an evolutionary and iterative approach to system development.
- Works well when the requirements are not well understood by the users.
- Involves carrying out the same activities over a number of cycles in order to clarify the requirements, issues and solutions and in effect amount to repeating the development lifecycle several times.
- The total cost of the project will increase as the lengt of the spiral increases.
Structured development methods
1. User involvement
2. Separation of logical and physical
3. Emphasis on data
4. Diagrammatic documentation
5. Defined structure
Drawbacks of structured development methods
1. Users and analysts/developers need to be trained to understand the documentation
2. The users also needs to accept that the amount of time required from them will be much increased.
3. Leads to increased levels of documentation and therefore bureaucracy.
An example of a structured development method.
2. Requirements analysis
3. Requirements specification
4. Logical system specification
5. Physical design
Although it can be tailored to the demands of individual projects it is perceived as a large, bureaucratic approach ill-suited for the fast pace of change in the modern business world.
Reasons to choose for rapid application developement
1. Desire to provide results quickly
2. Business opportunities with limited life time
3. Non-rapid development methods did not deliver better results, faster is then simply cheaper
4. External changes are reduced because less time elapses.
Prototyping within agile
1. Assist users to define and confirm requirements by demonstrating possibilities.
2. Investigate the effectiveness of novel methods of working.
3. Test performance implications.
4. Assist in considering work practice.
Some believe that agile is only appropriate in a stable environment where:
1. The application is not complex and the scope is well defined.
2. The organizational environment is fixed and mature.
3. The technical environment is neither technically advanced nor novel.
4. The application fits well in with the existing infrastructure.
Two agile approaches
Dynamic System Development Method
Basic principles of object-oriented and component-based approaches
- Objects that communicate with each other.
- Object have variables and methods.
- Useful when developing larger systems.
- In stead of objects, libraries are the focus.
- Created to deal with common project problems of rapidly changing requirements, challenging deadlines and working with new or unfamiliar technologies.
- Will work best on relatively small projects or with small teams.
- Uses 'user stories' to determine product features.
- The customer must be available at all times.
- There is a good structural model to support it.
- Main drawback is that it cannot be scaled to large projects.
Package-based IS benefits and drawbacks
- Introduction of the new system is likely to take less time.
- Cost is likely to be lower, since the cost of development are shared among all package users.
- Ongoing support and system enhancements are usually readily available.
- May not be a perfect fit for the organization.
- Best package in terms of fit may not run on organizations hardware or fit with its software strategy.
- Organization is in the hands of the software supplier in terms of getting changes and enhancements made.
- Adoption of package software is unlikely to bring competitive advantage.
Package-constrained vs package-based
Package-constrained = Processes are changed to fit the package.
Package-based = Additional functionality is commissioned or added on top.
Package based solution implications for project manager
- There is still a need for proper analysis of requirements.
- Business and user management need to be clear on whether they are going for package-constrained or -based approach.
- Project manager will still have to coordinate the efforts of various stakeholders, specialists and vendors.
Soft Systems Methodology (SSM)
- Not an approach to information systems development.
Soft Systems Model:
1. The problem situation is stated, but perhaps in an unstructured way.
2. Root definitions are collected and explored, to find out what people believe about the system.
3. Based on the root definitions, a series of conceptual models are built that show what a human activity system would look like if built from each model.
4. The various conceptual models are compared and discussed and agreement is sought on the best model.
5. Real-world constraints are considered.
6. Actions are generated to implement the change.
The socio-technical approach
- Not really an IT approach
- Similar to business process re-engineering, but place greater emphasis on designing processes for people as well as efficiency.
Business process re-engineering (BPR)
- Based on the believe that large-scale gains only result from a fundamental rethinking about what is done and how it is done.
- In most BPR initiatives, IT emerges as a key enabler of change.
- (Negative) Is associated with downsizing.
Ability of interconnected autonomous agents of a complex adaptive system to evolve into an organized form without external force.
The edge of time
The balance between exploration (innovation, knowledge creation) and exploitation (improvements in productivity, processes and enhancements).
Technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
Encompasses data collection, cost accounting and cost control
Process to create a reasonable budget for the project and identify project resources (human and material) as well as, creating a time-phased budget for their involvement in the project.
Common sources of costs
4. Equipment and facilities
Types of costs
- Direct vs Indirect
- Recurring vs non-recurring
- Fixed vs variable
- Normal vs expedited
Estimation accuracy categories
- Ball park (~30%)
- Comparative (~15%)
- Feasability (~10%)
- Definitive (~5%)
Develop estimates by using old project data multiplied by inflation and increased in labor/material needs.
Repetition of activities often lead to reduction in time necessary per single activity. Y for x = aX^b, b = log(learning percentage)/log(2)
Function point analysis
A system for estimating the size of software projects based on what the software does.
Standard unit of measurement that represents the functional size of a software application.
Problems with cost estimation
1. Low initial estimates
2. Unexpected technical difficulties
3. Lack of definition
4. Specification changes
5. External factors
The plan that identifies the allocated resources, the project's goals and the schedule that allows an organization to achieve those goals.
Seeks to integrate corporate-level goals with department-specific objectives; short-term requirements with long-term plans; and broader, strategic missions with concise, needs-based issues.
Requires the direct input from the organization's top management. Ascertains the opinions and experiences of the top management regarding estimated project costs.
Begins inductively from the work breakdown structure to apply direct and indirect costs to project activities.
ABC, first assigns costs to activities, then to the project based on the amount of resources (specific activities) it requires.
1. Identify the activities that consume resources and assign costs to them.
2. Identify the cost drivers associated with the activity. Resources, in the form of project personnel, and materials are key cost drivers.
3. Compute a cost rate per cost driver unit or transaction. (e.g. for labour -> cost/hour)
4. Assign costs to projects by multiplying the cost driver rate times the volume of cost driver units consumed by the project.
The allocation of extra funds to cover uncertainties and improve the chances that the project can be completed within the time frame originally specified. Contingency is added after all costs are already specified.
Reasons for contingency
1. Project scope is subject to change.
2. Murphy's Law.
3. Cost estimation must anticipate interaction costs.
4. Normal conditions are rarely encountered.
Benefits of contingency funds
1. Recognizes the future contains unknowns.
2. Provision is made for increase in costs.
3. Application to contingency funds gives an early warning sign.
Factors influencing the quality of estimates
1. Planning horizon; estimates of current events are close to 100 percent accurate but are reduced for more distant events.
2. Project duration; long-duration projects increase the uncertainty in estimates.
3. People; skills of the people making the estimates. Skills of the people working on the project, learning curve. Time spent communicating between team members.
4. Project structure; will influence time and cost estimates. E.g. dedicated project team or matrix.
5. Padding estimates.
6. Organizational culture.
7. Other factors; such as non-project factors.
Guidelines for estimating
1. Responsibility; those most experienced should provide estimates.
2. Use several people.
3. Normal conditions.
4. Time units; should be selected early in the development phase.
5. (Task) independence.
6. (Do not allow for) contingencies.
7. Adding risk assessment to the estimate helps to avoid surprises to stakeholders.
Methods for estimating project times and costs
1. Consensus methods (delphi method)
2. Ratio methods (e.g. by features or complexity)
3. Apportion methods (costs are apportioned as a percentage of total costs, based on historical figures)
4. Function point methods (uses weighted macro variables called function points).
5. Learning curves
1. Template methods (use previous projects)
2. Parametric procedures applied to specific tasks
3. Range estimating
Hybrid: phase estimation
A detailed estimate is developed for the immediate phases and a macro for the remainder. The process is repeated as the project progresses.
The 'best' way to improve cost and time estimating
Creating a database for estimating.
Represents the conversion of project goals into an achievable methodology for their completion; it creates a timetable and reveals the network logic that relates project activities to each other in a coherent fashion.
The identification of the project objectives and the ordered activity necessary to complete the project including the identification of resource types and quantities required to carry out each activity or task.
Illustrates the scheduling goal, order through logic.
A schematic display of the project's sequential activities and the logical relationships between them.
Reasons for project networks and scheduling
- Clearly illustrate dependencies of all tasks and work packages
- Illustrating interrelationship between activities and project personnel facilitates communication flows.
- Helps with master scheduling of organizational resources because it shows times when various personnel must be fully committed to project activities.
- Identifies the critical activities and distinguishes them from the less critical.
- Determines when you can expect the project to be completed.
- Deadlines for activities are identified
The work content and products of a project or component of a project. Scope is fully described by naming all activities performed, the resources consumed, and the end products that result, including quality standards.
A task-oriented "family tree" of activities that organizes, defines, and graphically displays the total work to be accomplished in order to achieve the final objectives of a project. Each descending level represents an increasingly detailed definition of the project objective.
A deliverable at the lowest level of the work breakdown structure; it is an element of work performed during the course of a project. A work package normally has an expected duration plus an expected cost. Other generic terms for project work include task or activity.
Project network diagram PND
Any schematic display of the logical relationships of project activities.
A sequence of activities defined by the project network logic.
A point when an activity is either started or completed.
One of the defining points of a network; a junction point joined to some or all of the other by dependency lines (paths).
Those activities that must be completed prior to initiation of a later activity in the network
Activities that cannot be started until previous activities have been completed.
Early start date
Earliest possible date on which an activity can start based on the network
Late start date
The latest possible date an activity may begin without delaying a specified milestone.
Network calculations that determine the earliest start/earliest finish time (date) for each activity.
Calculation of late finish times for all uncompleted network activities.
An activity with two or more immediate predecessors. Merge activities can be located by forward pass.
An activity with two or more successors. Found via backward pass
The amount of time an activity may be delayed without delaying the finish time of the project.
The path through the project network with the longest duration. Critical path activities have zero float!
Critical path method CPM
A network analysis technique used to determine the amount of float on various logical network paths in the project schedule. And to determine the minimum total project duration.
A project schedule whose start and finish date reflect expected resource availability. The final project schedule should always be resource-limited.
Program Evaluation and Review Technique PERT
An event- and probability-based network analysis system generally used in projects where activities and their durations are difficult to define.
The arrow represents the task or activity and the node signifies an event marker that suggests the completion of one activity and the potential start of another.
The node represents an activity and the path arrows demonstrate the logical sequencing from node to node through the network.
Rules of thumb for network diagramming
1. Some determination of activity precedence muse be done prior to creating the network.
2. Network diagram flows from left to right.
3. An activity cannot start until all preceding activities have been completed.
4. Arrows on networks indicate precedence and logical flow.
5. Each activity should have a unique ID.
6. Looping is not permitted.
7. It's common to start and finish from and to a single node.
Should be clearly labeled, common information:
2. descriptive label,
3. activity duration,
4. early start time,
5. early finish time,
6. late start time,
7. late finish time,
8. activity float
Activities that flow from one to the next, in sequence.
Activities that can be accomplished at the same time.
Can be assessed in some of the following ways:
- Expert opinion
- Mathematical derivation
Asymmetrical distribution; suggests that certain events are more like to occur that others.
Estimated time duration with beta distribution
TE = (a + 4m + b)/6
Forward pass process
1. Add all activity times along each paths as we move through the network (Early Start + Duration) = Early Finish
2. Carry the EF to the immediate successor. The EF becomes that nodes ES point unless it is a merge point.
3. At merge point, the latest preceding EF becomes the ES for that node.
Backward pass process
1. Subtract activity times along each path as you move through the network (Late Finish - Duration = Late Start).
2. Carry back the LF to the immediate successor. That LS becomes the LF of the next node, unless it is a burst point.
3. For a burst point. The smallest succeeding LS becomes the LF for that node.
s^2 = ((b - a) / 6)^2
σ^2 for p = Project variance = ∑ (variances of activities on critical path)
Project standard deviation
Technique that allows us to redraw the activity network to more closely sequence project subtasks to make the overall network sequence more efficient.
Can be used to summarize some subset of activities identified in the overall project network. The hang below the activities like a 'hammock'.
Common methods for reducing critical path
1. Eliminate tasks on the critical path.
2. Replan serial paths to be in parallel.
3. Overlap sequential tasks.
4. Shorten the duration of critical path tasks.
5. Shorten early tasks.
6. Shorten longest tasks.
7. Shorten easiest tasks.
8. Shorten tasks that cost the least to speed up.
Logical relationship between the start and finish of one activity and the start and finish of another.
Logical relationships between tasks
1. Finish to start
2. Finish to finish
3. Start to start
4. Start to finish
Compressing the schedule by starting certain successor activities after the predecessor activity has started with a lag, instead of waiting until the predecessor is finished.
Establishes a time-phased network, which links project activities to a project schedule baseline. Can also be used to track the difference between planned and actual.
Gantt chart benefits
1. Easy to read and comprehend
2. Identify the project network coupled with its schedule baseline
3. Allow for updating and project control
4. Useful for identifying resource needs and assigning resources to tasks
5. Easy to create
Process of accelerating the project. Directly related to resource commitment. The more resources are spent, the quicker the project can finish.
Good reasons for crashing a project
1. The initial schedule may be too aggressive. Durations are simply too short. Crashing inevitable.
2. Market needs change and the project is in demand earlier than expected.
3. The project has slipped considerably behind schedule.
4. The contractual situations provides even more incentive to avoid schedule slippage.
Options for accelerating projects/crashing
1. Improve the productivity of existing project resources.
2. Change the working method employed for the activity, usually by altering the technology and types of resources employed.
3. Compromise quality and/or reduce project scope.
4. Fast-track the project by:
a. Shorten the longest critical activities.
b. Partially overlap activities.
c. Employ start to start lag relationships.
5. Use overtime.
6. Add resources to the project team.
Difference between AON and AOA
In AOA the arrow represents the activity with its duration time estimate, while the node is used only as an event marker, usually representing the completion of a task.
Are used in AOA networks to indicate the existence of precedent relationships between activities and their event nodes. They do not have any work or time values assigned to them.
AON strengths and weaknesses
- Most popular format for computer packages.
- Activity is placed in the node and arrows are merely connection devices, thereby simplifying the network labeling.
- With complex project with numerous paths it becomes hard to read.
AOA strengths and weaknesses
- Accepted use in business fields such as construction.
- In case of large complex projects it is often easier to employ the path process in AOA.
- AOA event nodes are easy to identify and flag as milestones.
- Dummy activities
- Information-intensive, because both nodes and arrows contain information.
Criticism and caveats to project activity networks
1. Networks can become too large and complex to be meaningful.
2. Faulty reasoning in network construction can sometimes lead to oversimplification or incorrect representations.
3. Networks are sometimes used for tasks for which they are not well suited.
4. Networks used to control the behavior of subcontractors have special dangers. When employing subcontractors:
a. All subcontractors should be privy to the prime contractor's overall network.
b. The networks of all subcontractors need to be merged.
5. There is a strong potential for positive bias in PERT estimations used in network construction.
The art and science of identifying, analyzing and responding to risk factors throughout the life of a project and in the best interests of its objectives.
Any possible event that can negatively affect the viability of a project.
Risk = (Probability of Event) (Consequences of Event)
Steps in systematic risk management
1. Risk identification
2. Analysis of probability and consequences
3. Risk mitigation strategies
4. Control and documentation
- Financial risk
- Technical risk
- Commercial risk
- Execution risk
- Contractual or legal risk
- Staff being pulled away by management
- Additional staff/skills not available
- Training not as effective as desired
- Initial specifications poor or incomplete
- Work or change orders multiplying due to various problems
- Enhancements taking longer than expected
Methods of risk assessment
- Brainstorming meetings
- Expert opinion
- Multiple (or team-based) assessments
Typical risk variables
- Market risks
- Political risks
- Technical risks
- Financing risks
- Environmental impact risks
- Cost risk
- Schedule risk
- Quality (functionality) risk
- Managerial risk
- Integration (stakeholder) risk
- Acts of God
Risk estimation methods
- Risk impact matrix with likelihood and consequences
- Quantitative method using probability of failure and consequence of failure scale (.1, .3, .5, .7, .9)
RF = Pf +Cf - (Pf)(Cf)
Pf = average probability of failure
Cf = average consequence of failure
Risk mitigation strategies
- Accept risk
- Minimize risk
- Share risk
- Transfer risk
+ Fixed-price contracts
+ Liquidated damages
One of the most common methods to mitigate project risks.
Budget reserves used to offset cutbacks, schedule overruns or other unforeseen circumstances accruing to individual tasks or project work packages.
Budget safety measures that address higher-level risks.
Part of risk mitigation strategy requiring proper documentation.
Risk documentation, key information
- What -> identify source of risk
- Who -> assign responsibility
- When -> will mitigation occur
- Why -> pinpoint most likely reason for risk
- How -> detailed plan for how to abate the risk
Project Risk Analysis and Management (PRAM)
- Recognizes that risk management follows its own life cycle
- The application of different risk management strategies at various points in the project life cycle
- The integration of multiple approaches to risk management into a coherent, synthesized approach
PRAM assessment phases
1. Define, make sure the project is wel defined.
2. Focus on Risk management as a project in itself.
3. Identify, assess the specific sources of risk at the outset.
4. Structure, review and refine methods.
5. Clarify ownership of risk.
6. Estimate, develop a reasonable estimate of the impact risks and the proposed solutions.
7. Evaluate process
8. Plan, produce proactive risk management plan
9. Manage, monitor actual progress and respond, be proactive.
The expected return value divided by the expected cost.
Reasons why straight-line ROI is wrong
Only true if:
- 100% guarantee of cost containment
- and 100% guarantee of value returned at expected value.
Elements to compute return at risk
1. The expected cost of the project.
2. The likelihood of achieving that expected cost.
3. The risk profile of the cost risk distribution.
4. The expected returned value of the project.
5. The likelihood of achieving that value.
6. The value profile of the value distribution.
Vital to ensure that any changes to the project baseline are conducted in a systematic and thorough manner.
A few project control systems
- Configuration control
- Design control
- Trend monitoring
- Document control
- Acquisition control
- Specification control
defined as the project's scope fixed at a specific point in time. The baseline is viewed as the project's configuration.
a management process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design and operational information throughout its life.
Reasons to make project changes or specification adjustements
- Initial planning errors, either technological or human
- Additional knowledge of project or environmental conditions
- Uncontrollable mandates
- Client request
Stages of configuration management
1. Configuration identification
a. Develop a breakdown of the project to the necessary level of definition.
b. Identify the specifications of the components of the breakdown and of the total project.
2. Configuration reviews
Meet with all the stakeholders to agree on current project definition.
3. Configuration control
a. If agreement is achieved repeat the first steps until the project is defined.
b. If agreement is not reached, either:
- Cycle back to the configuration as agreed at a previous review and repeat until succes; or
- Change the specifications last obtained by a process change control to match what people think it should be.
4. Status accounting
Memory of current and all previous configurations.
An individual who identifies with a new development using all the weapons at his command, against the funded resistance of the organization. Functions as an entrepreneur within the organization.
Usually and engineer or scientist who is the source of and driving force behind the idea.
The person who adopts the idea or technology and actively works to sell the system throughout the organization, eventually pushing it to success.
Godfather or sponsor
The project champion at senior management level.
What champions do
- Technical understanding
- Coordination and control
- Obtaining resources
- Risk taker
How to make a champion
- Identify and encourage the emergence of champions
- Encourage and reward risk takers
- Remember that champions are connected emotionally to their projects
- Don't tie champions too tightly to traditional project management duties
CM Critical Success Factors
- Execution Strategies
- Decision Taker(s)
- Performance monitoring
- Sufficient Resources
- Effective Environment
- Defined Boundary
Key Change Beliefs
1. Discrepancy; belief that change is needed.
2. Appropriateness; belief that the proposed change is the correct one.
3. Efficacy; belief that the change recipient and organization can execute the change.
4. Principal support; believe that formal leaders are committed to the change.
5. Valence; belief that the change is beneficial to the change recipient.
Classical project success criteria
Iron triangle/ triple constraints:
To this should be added
- Client acceptance
Additional approach to project assessment (from short to long-term importance):
- Project efficiency (meeting budget and schedule)
- Impact on customer (meeting specifications, client acceptance)
Business success (commercial success?)
Preparing for the future (was project good investement?)
Six criteria of IT Project Success
- System quality (build quality)
- Information quality
- Use (superficial customer acceptance)
- User satisfaction
- Individual impact (what value is added)
- Organizational impact
General model of organizational control / controle cycle
1. Setting a goal
2. Measuring progress
3. Comparing actual with planned performance
4. Taking action
Project control techniques
- Project S-curve
- Milestone analysis
Represents the typical form of the relationship between time passed and budget expended.
S-curve benefits and drawback
- Provides a way to show real-time tracking information
- Do not allow us to make reasonable assumptions as to the cause of the variance between planned and actual.
An event or stage of the project that represents a significant accomplishment on the road to the project's completion.
Milestone analysis benefits
1. Signal the completion of important project steps.
2. Can motivate the project team.
3. Offer points at which to reevaluate client needs and any potential change requests.
4. Help coordinate schedules with vendors and suppliers.
5. Identify key project review gates.
6. Signal other team members when their participation is expected to begin.
7. Can delineate the various deliverables developed in the WBS and thereby enable the project team to develop a better overall view of the project.
Problems with milestones
Are only a form of reactive control.
Tracking Gantt chart
Allows the project team to constantly update the project's status by linking task completion to the schedule baseline.
Tracking Gantt benefits and drawbacks
- Easy to understand
- Easy to assimilate and interpret
- Can be updated very quickly
- Don't identify the underlying source of the problems
- Does not allow for future projections of the project's status
Earned value management (EVM)
Recognizes that it is necessary to jointly consider the impact of time, cost and project performance on any analysis of current project status. This method inks all three primary project success metrics (cost, schedule, and performance).
Planned value (PV)
A cost estimate of the budgeted resources scheduled across the project's life cycle (cumulative baseline).
Earned value (EV)
This is the real budgeted cost, or "value," of the work that has actually been performed to date.
Actual cost of work performed (AC)
The cumulative total costs incurred in accomplishing the various project work packages.
Schedule performance index (SPI)
The earned value to date divided by the planned value of work scheduled to be performed (EV/PV). This value allows us to calculate the projected schedule of the project to completion.
Cost performance index (CPI)
The earned value divided by the actual, cumulative cost of the work performed to date (EV/AC). This value allows us to calculate the projected budget to completion.
Budgeted cost at completion (BAC)
This represents the total budget for a project.
Creating project baseline (EVM)
1. The WBS is used to identify the individual work packages and tasks.
2. The time-phased budget allows us to determine the correct sequencing and the points in the project when budget money is like to be spent.
Steps in Earned Value Management (EVM)
1. Clearly define each activity or task that will be performed on the project, including its resource needs as well as a detailed budget.
2. Create the activity and resource usage schedules.
3. Develop a "time-phased" budget that shows expenditures across the project's life.
4. Total the actual costs of doing each task to arrive at the actual cost of work performed (AC).
5. Calculate both a project's budget variance and schedule variance while it is still in process.
Estimate at Completion (EAC)
The expected total cost of the project to completion based on performance across the various tasks up to the status date.
Issues in the effective use of EVM
Depends highly on accurate and up-to-date information on the project.
Methods for assigning completion values
1. 0/100 rule
2. 50/50 rule
3. Percentage complete rule
10 critical success factors
1. Project mission
2. Top management support
3. Project plans and schedules
4. Client consultation
6. Technical tasks
7. Client acceptance
8. Monitoring and feedback
Root cause analysis
a structured process designed to help people understand the causes of past problems to prevent recurrence.
Root cause analysis steps
1. Define the problem
2. Create a causal understanding of the problem
3. Identify solutions that act on known causes of the problem
4. Implement the best solutions
Focus on implementing effective solutions, not labeling a root cause.
Root cause best practices
1. Based on business goals develop threshold criteria for initiation of RCA.
2. Precisely define each major problem and quantify the business impact.
3. Allocate adequate time and resources for each RCA that are in line with the associated risk.
4. Complete each RCA consistently.
5. Don't categorize problems or their causes.
6. Institute a rigorous validation process that uses evidence to verify causes and weed out uncertainty.
7. Based on the causes, use the talents of people, to help identify the best solutions.
8. Prioritize solutions based on criteria.
9. Develop solutions that are clear and descriptive enough to be implemented by a third party.
10. Focus monitoring metrics on implementation timing and effectiveness of the solutions and report regularly on your RCA's successes.
Requires project managers to consider the types of records and reports they and their clients will require at the completion of the project.
Some closeout documents
- Historical records
- Postproject analysis
- Financial closeout
Reasons why project closeout is important
1. in the case of contractual disputes
2. as a useful training tool for postproject analysis of either successes or failures
3. to facilitate project auditing tasks by showing the flow of expenses in and out of various project accounts
consists of all activities consistent with closing out the project.
types of project termination
natural vs unnatural
main methods of termination
1. Termination by extinction
2. Termination by addition
3. Termination by integration
4. Termination by starvation
Elements of project closeout management
1. Finishing the work
2. Handing over the project
3. Gaining acceptance for the project
4. Harvesting the benefits
5. Reviewing how it all went
6. Putting it all to bed
7. Disbanding the team
Private Finance Initiatives (PFIs)
Are used to protect the excessive financial exposure of a contracting agency to a project being developed.
Build, Operate, and Transfer (BOT)
Allows the eventual owner to mitigate risk in the short run.
Build, Operate, Own, and Transfer (BOOT)
Limits the client's financial exposure until all problems have been contractually resolved.
Common errors while reviewing how it all went
1. Misidentifying systematic errors
2. Misapplying or misinterpreting appropriate lessons based on events
3. Failing to pass along lessons learned conclusions
Important guidelines for lessons learned
1. Establish clear rules of behavior for all parties to the meeting
2. Describe, as objectively as possible, what occurred
3. Fix the problem, not the blame
Elements of putting it all to bed
Important elements of the project sign-off document
- General program and project management confidence
- Commercial confidence
- Market and sales confidence
- Product quality confidence
- Manufacturing confidence
- Supply chain logistics confidence
- Aftermarket confidence
- Health, safety, and environment confidence
What prevents effective project closeout
- Getting the project signed off discourages other closeout activities
- The assumed urgency of all projects pressures us to take shortcuts at the back end
- Closeout activities are given a low priority and are easily ignored
- Lessons learned analysis is viewed as a bookkeeping process
- People may assume that because all projects are unique, the actual carryover from project to project is minimal
Project factors to review for potential early termination
1. Static factors
2. Task-team factors
3. Sponsorship factors
4. Economic factors
5. Environmental factors
6. User factors
Important decision rules used for early termination
1. When costs exceed business benefits
2. When the project no longer meets strategic fit criteria
3. When deadlines continue to be missed
4. When technology evolves beyond the project's scope
Concerns when shutting down a project
- Emotional issues of the project team
- Emotional issues of the clients
- Intellectual issues internal
- Intellectual issues external
Should be factored into the decision to terminate early.
Common types of claims in the event of project closure
1. Ex-gratia claims, no contractual basis, but client feels there is a moral and commercial obligation.
2. Default claims by the project company in its obligations under the contract
How can project organizations protect themselves from problems with claims
- Consider the possible areas of claims at the start and plan accordingly.
- Make sure the project stakeholders know their particular areas of risk under the contract to help prevent baseless claims after the fact.
- Keep accurate and up-to-date records from the start of the contract.
- Keep clear details of customer change requests.
- Ensure that all correspondence is retained and archived.
Elements of the final project report
1. Project performance
2. Administrative performance
3. Organizational structure
4. Team performance
5. Techniques of project management
6. Benefits to the organization and the customer
Possibly also a source of innovation and motivation.
Represents the affective component of resistance. "I don't like it!".
Kinds of freedom in free software
• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
Tool that can be used to overcome resistance.
Strategies for overcoming resistance based on approach-avoidance model
Alpha vs. Omega
1. make messages more persuasive;
2. add incentives;
3. increase source credibility;
4. provide consensus information; and
5. engage in a norm of reciprocity.
1. sidestep resistance,
2. consuming resistance, and
3. use resistance to promote change.
software projects that spiral out of control exceeding original budget and schedule projections.
Theories to explain escalation behavior
1. Self-justification theory (SJT)
2. Prospect theory (PT)
3. Agency theory (AT)
4. Approach-avoidance theory (AAT)
Posits that individuals tend to escalate their commitment to a course of action in order to self-justify prior behavior.
Posits that individuals exhibit risk averse or risk seeking behavior depending on how a problem is framed. Specifically PT suggests that individuals will exhibit risk seeking behavior in choosing between two negative alternatives, especially when it is between a sure loss and the possibility of a larger loss combined with a chance to return to the reference point.
Under agency theory, goal incongruency between principal and agent can create a situation in which the agent acts to maximize their own utility, rather than acting in the best interest of the principal.
Approach avoidance theory
According to approach avoidance theory, in escalation situations, the cost of persistence (a restraining force) is often overshadowed by one or more driving forces such as: (1) the size of the reward for goal attainment, (2) the cost of withdrawal, or (3) the proximity to the goal.
Key constructs derived from the theory for the research in the article
- Psychological self-justification
- Social self-justification
- Sunk cost effect
- Goal incongruency
- Information asymmetry
- Completion effect
Types of control
1. Clan control
De-escalation management maturity (DMM) Model
Level 1: Discipline to change project plan.
Level 2: Discipline to detect deviations from project plan and prevent escalation.
Level 3: Discipline to execute project plan.
Level 4: Discipline to encourage bad news reporting and to change attitudes and behaviors.
Level 5: Discipline to engage in organizational learning.
Three de-escalation management models
1. The crisis management approach.
2. The change management approach.
3. The problem solving approach.
Crisis management approach steps
1. Develop a recovery plan
2. Manage the scope
3. Reevaluate project leadership
4. Re-estimate the business case and consider cancellation
5. Re-plan the project
6. Manage users' expectations
7. Formulate an open communications plan
8. Break the remainder of the project into small chunks
9. Deal with the people issues of the project team
10. Incorporate corrective practices in the development process
Change management approach steps
1. Unfreezing commitment to a failing course of action
2. Committing to a new course of action
3. Providing psychological safety nets
4. Developing new attitudes and behaviors
5. Refreezing commitment to a new course of action
Problem solving approach steps
1. Problem recognition
2. Re-examination of prior course of action
3. Search for alternative course of action
4. Implementing an exit strategy
integrated de-escalation management model
D. Re-evaluate and re-plan
E. Implement new course of action
THIS SET IS OFTEN IN FOLDERS WITH...
Project evaluation and control
Project selection and screening
Cost estimation and budgeting
YOU MIGHT ALSO LIKE...
50 Question PMA Test
OTHER SETS BY THIS CREATOR
Shell commands windows 1
OTHER QUIZLET SETS
PSY 3440 Unit 6
Abby Carlson World History Final Semester 2
Virology - Exam 2
Music App Part 3