Commit 73de7ce4 authored by Florian Moser's avatar Florian Moser
Browse files

Working on project management course

parent 2ff480a3
MIT License
Copyright (c) 2021 Florian Moser
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
# Project management
How to manage an IT project.
Main objectives:
- Know what makes a good project: High-level view about a suitable environment for you and your project.
- Know how to manage a project: Concrete resources how to start, execute and finish a project.
body { font-family: sans-serif; }
h1, h2, h3 {
font-family: serif;
font-weight: normal;
}
.remark-code, .remark-inline-code { font-family: monospace; }
.row {
display: flex;
}
.column {
flex-basis: 0;
flex-grow: 1;
max-width: 100%;
}
table {
border-collapse: collapse;
border-bottom: 1px solid #dee2e6;
border-top: 1px solid #dee2e6;
width: 100%;
}
table th,
table td {
border-top: 1px solid #dee2e6;
padding: 5px;
}
table tr:nth-child(2n) {
background-color: rgba(0, 0, 0, 0.05);
}
table thead th {
border-bottom: 2px solid #dee2e6;
vertical-align: bottom;
}
@media print {
.remark-slide-scaler {
width: 100% !important;
height: 100% !important;
transform: scale(1) !important;
top: 0 !important;
left: 0 !important;
}
}
\ No newline at end of file
var slideshow = remark.create();
\ No newline at end of file
This diff is collapsed.
<!DOCTYPE html>
<html>
<head>
<title>It Project Management</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<link rel="stylesheet" href="css/remark.css">
<link rel="stylesheet" media="print" href="css/remark.print.css">
</head>
<body>
<textarea id="source">
class: center, middle
# IT project management
<img src="images/thealternative-logo.jpg" width="30%">
---
# Get authority
> When a program manager or product owner is assigned to lead the project, that project head must also be given the appropriate authority to make decisions in that capacity.
---
# Epirical data
Unfortunately, mostly useless.
Littered with strong opinions, baseless claims, bad statistics, unprocessed experience, ...
<img src="images/success_rate_vs_project_cost.png" width="100%">
---
# Why projects fail
List out of "Project Recovery" by Harold Kerzner
- End-user stakeholders not involved throughout the project
- Minimal or no stakeholder backing; lack of ownership
- Weak initial business case
- Business case deterioration
- Business case requirements that changed significantly over the life of the project
- Technical obsolescence
- Technologically unrealistic requirements
- Lack of a clear vision
- New executive team in place with different visions and goals
- Corporate goals and/or vision not understood at the lower organiza-tional level
- Plan that asks for too much in too little time
- Poor estimates, especially financial
- Unclear stakeholder requirements
- Passive user stakeholder involvement after handoff
- Unclear or unrealistic expectations
- Unrealistic assumptions, if they exist at all
- Plans based upon insufficient data
- No systemization of the planning process
- Planning performed by a planning group
- Inadequate or incomplete requirements
- Lack of resources
- Assigned resources that lack experience or the necessary skills
---
- Resources that lack focus or motivation
- Staffing requirements that are not fully known
- Constantly changing resources
- Poor overall project planning
- Established milestones not measurable
- Established milestones too far apart
- Environmental factors that have changes causing outdated scope
- Missed deadlines and no recovery plan
- Budgets exceeded and out of control
- Lack of replanning on a regular basis
- Lack of attention provided to human and organizational aspects of project
- Project estimates that are best guesses and not based upon history or standards
- Not enough time provided for estimating
- Exact major milestone dates or due dates for reporting not known
- Team members working with conflicting requirements
- People shuffled in and out of project with little regard for schedule
- Poor or fragmented cost control
- Each stakeholder uses different organizational process assets, which may be incompatible with each other
- Weak project and stakeholder communications
- Poor assessment of risks, if done at all
- Wrong type of contract
- Poor project management; team members possess a poor understanding of project management, especially virtual team members
- Technical objectives that are more important than business objectives
- Assigning critically skilled workers, including the project manager, on a part-time basis
---
# Applicability of course
IT-projects as a freelancer.
Yes:
- Marketing webpage for the shop of your dad
- Online shop for small printing shop
- eVoting application for members of UZH
- App & Webapplication combination for construction firm
No:
- Führungsinformationssystem Heer
- Mainframe migration
- Medical software
- Bitcoin trading bot
---
# Experience of author
Until bachelors:
- Freelancer webpages since 2014
- Bachelor ETH (Computer Science) 2015 - 2018
- Projectmanagement & Development @ JKweb 2016 - 2017
- Freelancer webapplications since 2018
After bachelors:
- Professional Software Engineer @ Zühlke 2018 - 2019
- VSETH board member 2019-2020
- Master ETH (Computer Science) 2019 - 2022
Projects: https://famoser.ch/
---
# Targets of this course
**Know what makes a good project.** High-level view about a suitable environment for you and your project.
**Know how to manage a project.** Concrete resources how to start, execute and finish a project.
Claims:
- Projects are successful or fail before the first line of code is written
- Small projects (&lt;300h) are accurately estimatable in both time and cost
- Complexity increases implementation efforts exponential
---
# Reasons for project failures
Unrealistic Goals, Schedules and Budgets
Failure to Address or Adequately Consider the Need to Simplify Complex Business Processes and Rules That Cannot Readily Be Implemented Into New Solutions
Governance and Oversight Lack Accountability and Responsibility
Organizational Culture and "Optimism Bias" During Supplier Evaluation and Procurement
Poor Project Discipline and Process Controls That Impede the Ability to Make Informed Decisions
Failure to Define, Control and Track Change Requirements, and, in Particular, to Reference Changes Back to the Original Need
Underestimation and Overconfidence With Regard to Risk
Insufficient Management or Technical Expertise From External Service Provider, System Integrator or Consultant
Failure to Understand or Address Nonfunctional and Technical Performance Requirements
Program Manager Not Provided With Adequate Authority to Ensure the Project Is Undertaken as Required
---
# Measure productivity
---
# Estimation
can't predict the future
can estimate *relative* complexity
concrete process:
- decompose tasks i
---
# basic tasks
ownership product -> outside
vision, expertise, schedule -> team
progress, relationships -> stakeholders
---
# The right project
vision is clear
business case makes sense
stakeholders are motivated, agreed and (personally!) back the project
enviroment is stable during execution of the project
expectations are realistic
---
# The right plan
responsibility = capability
requirements are clear
schedule is realistic
risks are manageable
environment is controlled
ressources are appropriate
(financial) incentives match
---
# Making requirements
requirements:
decompose to suitable abstraciton level
non-conflicting, appropriate for business case, on the correct abstraction level
agreed upon
---
# Making a schedule
estimation:
complexity
milestones:
measurable
realistic
properly spaced
---
# During the project
keep stakeholders informed
manage expectations
measure progress & react early
control change
control risks
---
# Rollout
incremental updates & releases help to adapt rapidly (saving time with shortcuts, skipping unneeded functionality, improving through early feedback)
big bang is more efficient with no unknown unknowns (the longer the project, the smaller the chance)
maintenance needs to be considered
---
# aspects
complexity exponential
APIs complex
getting it done
bugs after launch
maintenance is 10-20%
complexity / estimation technology independent
---
# plan:
vision (what to do; priorities)
elements (what needed to solve)
cost/complexity, benefit/reward, risk
calculate priority
order
milestones
risk analysis
risk mitigation
---
# during project
continuously overview risks
manage cost
manage expectations
---
# About changes
Changes happen: Deal with it.
Proposals:
- Incorporate in project execution plan.
- Clarify expectiations.
- Finish (sub-)projects quickly.
- Define how & when changes are applied (and who pays for it).
---
# About people
People are strange, but predictable.
Get to know all involved persons:
- Motivation (agenda?)
- Way of working (early/late?, procrastination?)
- Experience (how have they performed in the past?)
- Personality (impulsive? diligent? analytical? risk-taking?)
Likely True Facts About People™:
- People are predictable
- People can't be changed
- People are good
---
# About bad people
With some, you will not get along!
Powerful combination:
- Ignorance (don't care about everybody their work affects)
- Incompetence (don't have relevant experience)
- Arrogance (don't consider inputs)
- Rhetorics (can defend their shortcomings)
Options:
- Fight (usually a bad idea)
- Co-exist (sometimes not possible)
- Run (sometimes required)
---
# Agile development
For developer teams in enterprises.
For engineers, not programmers.
Agile:
- https://scrumguides.org/scrum-guide.html
- https://www.scaledagileframework.com/
---
# Measure size of bigger software projects
**Function points**: Assign points depending on complexity of inputs / outputs.
**Use Case points**: Translate components of use case diagram into sizes metrics. Adjust for complexity and technical factors.
*Attention: Studies usually use small data models / overclaim.*
---
# Resources
Some resources used for this presentation:
- Azzeh, Mohammad, and Ali Bou Nassif. "Analyzing the relationship between project productivity and environment factors in the use case points method." Journal of Software: Evolution and Process 29.9 (2017): e1882.
- https://www.gartner.com/en/documents/2892218
</textarea>
<script src="js/remark.min.js" type="text/javascript"></script>
<script src="js/remark.driver.js" type="text/javascript"></script>
</body>
</html>
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment