FUNDAMENTALS

Projects: A projects is a temporary endeavor undertaken to create a unique product or service.

The project is unique because can exist 1000 project but each of them is different than others.
Also, it can be temporary. It is progressively elaborated with repetitive elements and should be
constantly re-elaborated.
Programs: There are many different definitions. The program often consist in several related
projects, usually are longer than projects. Also, it is different in scale from project.
Products: The product is the result of the project and is a tangible dimension.
Project Manager: The project manager is the responsible of the valuation, realization and check
of the project.
Program management: He/She is the responsible of the management of a set of projects that
are correlated.
Stakeholders: They are: project sponsor, manager, team, client, contract and functional
manager and any one that can be related in any way to the project.
THE 4 DIMENSIONS OF A PROJECT (McConnell)
1.People: The management of the people is always a problem. The team should be selected, ma
naged and motivated. Needed is the selection of the right team in order to complete the task an
d to establish a good communication between them. Pay attention to career development and i
ts balance of the team interest.
2.Process: there are two kind of process: Management and Technical. The development is the fu
ndamentals also the quality assurance, risk management, customer orientation and the lifecycle
of the project. It doesn’t rework.
3.Product: It is the tangible dimension, needs to know the requirements and features to plan th
e time.
4.Technology: it is often the least important. In this dimension is necessary select the tools and l
anguage, its value and cost of reuse.

1
THE 36 CLASSIC MISTAKES:
According to McConnell we have 4 types of mistakes: People, Process, Product and Technology

People related Mistakes:

Noisy, Crowded office: Workers who occupy quiet, private offices tend to perform significantly
better than workers who occupy noisy, crowded work bays or cubicles. Noisy, crowded work
environments lengthen development schedules.
Adding people to a late project: This is perhaps the most classic of the classic mistakes. When a
project is behind, adding people can take more productivity away from existing team members
2
than it adds through new ones. Fred Brooks likened adding people to a late project to pouring
gasoline on a fire.
Process Related Mistakes:
Insufficient planning: If you don't plan to achieve rapid development, you can't expect to
achieve it.
Code-like-hell programming: Some organizations think that fast, loose, all-as-you-go coding is a
route to rapid development. If the developers are sufficiently motivated, they reason, they can
overcome any obstacles. this is far from the truth.
Omitting necessary tasks from estimates: If people don't keep careful records of previous
projects, they forget about the less visible tasks, but those tasks add up. Omitted effort often
adds about 20 to 30 percent to a development schedule (van Genuchten 1991).
Product related mistakes:
Feature creep: Even if you're successful at avoiding requirements gold plating, the average
project experiences about a 25-percent change in requirements over its lifetime (Jones 1994).
Such a change can produce at least a 25-percent addition to the software schedule, which can
be fatal to a rapid development project.
Push-me, pull-me negotiation: One bizarre negotiating ploy occurs when a manager approves a
schedule slip on a project that's progressing slower than expected and then adds completely
new tasks after the schedule change. The underlying reason for this is hard to fathom, because
the manager who approves the schedule slip is implicitly acknowledging that the schedule was
in error. But once the schedule has been corrected, the same person takes explicit action to
make it wrong again. This can't help but undermine the schedule.
Technology related mistakes:
Switching tools in the middle of a project: This is an old standby that hardly ever works.
Sometimes it can make sense to upgrade incrementally within the same product line, from
version 3 to version 3.1 or sometimes even to version 4. But the learning curve, rework, and
inevitable mistakes made with a totally new tool usually cancel out any benefit when you're in
the middle of a project
Lack of automated source-code control: Failure to use automated source code control exposes
projects to needless risks. Without it, if two developers are working on the same part of the
program, they have to coordinate their work manually. They might agree to put the latest
versions of each file into a master directory and to check with each other

3
TRIANGOLE TRADE‐OFF
There are 3 dimensions: Product (Scope, Performance), Cost (Resources) and Schedule (Time) Th
ese 3 dimensions are always in a project and is not possible optimized it all together. It’s necess
ary to choose only two of these dimensions and focus on them,The third choice is a trade-
off that depend on the two choice.

PMI knowledge areas:

1-Project integration management:
Coordination between the various elements of the project for processes and activities should be
ensured
–  Integrated change control
–  Project plan execution and development
2-Scope:
Processes and activities required to ensure that the project includes all the work required, and
only the work required
–  Scope (planning, verification, definition, change control)
3-Time:
The dead line and completion time of the project should be respected.
–  Activity definition-sequencing
–  Activity duration estimating
–  Schedule development/control
4-Cost:
Processes required to ensure that all the project activities are completed within the budget
–  Cost (control, estimating, budgeting)
–  Resource planning
5-Quality:
Processes and activities that determine quality policies, objectives, and responsibilities so that
the project will satisfy needs and expectations

4
– (Quality planning, assurance, control)
6-Human resource:
Processes required to organize, manage and lead the project team, assuring the most effective
use of people involved to increase the efficiency
–  Organizational planning
–  Staff acquisition
–  Team development
7-Communications:
processes required to ensure collection, creation and distribution of project information
–  Communication planning
–  Information distribution
–  Performance reporting
8-Risk:
Processes related to the identification and analysis of project risks
–  Risk (management planning, identification, analysis (quantitative/qualitative), response
planning, monitoring and control)
9-Procurement:
processes required to acquire products and services (or results!) from outside the project team
–  Procurement and Solicitation planning
–  Source selection
–  Contract management
The 5 PMI Process Groups (STRUCTURES PM):
Projects are mainly composed of a set of processes and each of them is composed of (A-Input B-
Output/results/Tools & Techniques)
1-Initiating: (KA=2)
INPUT: Product Description, Strategic plan, Selection Criteria, Historical Information.
OUTPUT: Charter, Manager assigned, Constraints, Assumptions

5
2-Planning: (KA=1 to 9)
Devising and maintaining a workable scheme to accomplish the business and its needs.
ACTIVITY: Scope planning, Scope definition, Activity definition, Activity sequence, Activity durati
on estimating, Resource planning, Cost estimating, Cost budgeting, Risk planning, Schedule deve
lopment, Quality planning, Communications planning, Staff acquisition, Procurement Planning, P
roject plan development.
3-Executing: (KA=1,5,6,7,9)
Coordinating people and other resources to carry out the plan.
ACTVITY: Plan execution, Scope verification, Quality assurance, Team development, Information
distribution, Solicitation, Source selection, Contract administration.
4-Controlling: (KA=1,2,3,4,5,7,8)
Ensure that phases are completed and measuring progress and corrective when is necessary.
ACTIVITY: Overall change control, Scope change control, Schedule control, Cost control, Quality
control, Performance reporting, Risk response control.
5-Closing: (KA=7,9)
Formalizing the end of the project in terms of acceptance.
ACTIVITY: Administrative closure, Contract close‐out

6
Organizational structures, advantages & disadvantages of each form, role of PM in each
Functional, Project and Matrix
1-Functional:
Divide by areas on functionality. (Department, develop, marketing etc.)
Pro: Clear definition of authority (each department has its boss), eliminates duplication of
function, Encourages specialization and Clear career path.
Cons: “Walls” btw function can lack customer orientation, “Soils”create longer decision cycles
(bad communication), Conflicts across functional areas, Project leader have little power.
2-Project:
Divide by projects in progress that are being carried out in isolation.
Pro: Unity of command, Good communication in the same project
Cons: duplication of function, career paths not clear (do what your boss wants or what makes
the project successful).
3-Matrix:
Mix of the previous. Exist functional division but the projects are followed in coherent and
integrate mode. (it’s between, move people to project and then back them in function. more agile)
Pro: Project integration across functional lines, Efficient use of resources, Retains functional
teams.
Cons: two bosses for personnel (much), Complexity, Resource & priority conflicts (btw
functionality and project lines).

7
Classic project phases, Key documents at each phase, Characteristics and issues of each phase
1-Software Concept:
Also known as: Concept, Concept Exploration, System Exploration.
The why phase, it is not a mandatory phase, collecting projects Ideas, initial planning and
estimation.
Also, here we have project justification: Cost benefit analysis and ROI. Gathering the initial team
including PM if doesn’t exist. Identify the project sponsor.
OUTPUT: Concept document, Product document, RFPs, SOW and Project Charter.

ISSUES:

1) Lack of full commitment and leadership.

2) Budget problem
3) Frustrations:
a. Finding the balanced team
b. Management only get rough estimate from development
2-Requirements: Requirements analysis
The what phases, it is complex and can be underestimated. This phase ends with the review of s
oftware requirements review (SRR) that is approved by sponsor/clients.
INPUT: SOW, Proposal

OUTPUT: Requirement documents (RD), Project baseline, Software Project Management Plan
(SPMP), Requirements approval, and sign-off
ISSUES: Conflict of the interest between developer and customer, frequent requirement changes,
achieving sing off, project planning occurring in parallel
Types: Functional (features and capabilities of the system) and Non-functional (everything,
usability, accessibility, performance etc.).
3-Analysis:
The “How” phase, it does the high level of design. Continues process from requirement definitio
n, ends with Critical Design Review(CDR)
INPUT: Requirements document.

OUTPUT: Functional specification, detailed design document, user interface specification, data m
odel, prototype, updated plan.

8
4-Design: Detailed design. It is together analysis phase.
5-Coding & debugging: Implementation, Development
The “do it” phase. coding and unit testing, ambient and instruments; often overlaps integration
and design phases.
Characteristics: pressure increase and staffing at highest levels.

ISSUES: Last‐minute changes, team coordination, communication, overhead, management of

sub‐contractors.
6-Systems Testing: Integration and Test phase
Evolves from Development phase. Often done as 2 parallel phases: partial integration & initial
test. Starts with integration of modules. An initial, incomplete version constructed. Progressively
add more components.
The integration phase can be of 2 kind: Top-down (core functionality first, empty shells for
incomplete routines), Bottom‐up (gradually blind low‐level modules) but top‐down is preferred.
The Tests: integration testing, black & whitebox testing, load & stress testing, Alpha & beta testin
g, Acceptance testing.
ISSUES: final budgeting, risk management, training, installation preparation, team reduce,
increased pressure, overtime, customer conflicts, frustration lastminute, motivation problems,
difficulty in customer acceptance.
7-Deployment & Maintenance: Production, Operations
Deployment: The installation depends on system type. Migration strategy and how to get
customers up on the systems.
Maintenance: fix defects, add new features, improve performance. Configuration control is very
important here, Documents need to be maintained also, sometimes a single team maintains
multiple products.
ISSUES: Lack of enthusiasm, pressure for quick fixed, insufficient budget, too many patches, pers
onnel turnover, Regression testing is critical.

9
Lifecycle
Methodologies (Trade-offs, Basic Pros & Cons):
Lifecycle Management or Systems Development Life Cycle (SDLC). There are many models 12:

1-Pure Waterfall:
It is the most common and oldest among the projects.
The phases of the project are carried out in a linear sequence of phases and all planning done
up-front. It is a document‐drive.
PRO: works well for the projects with: stable product definition, well understood technologies,
quality constrains stronger than cost and schedule and technically week stuff (provides
structure, good for overseas projects).
CON: It is not flexible. Difficulty to define the initial requirements, can produce excessive
documents, few visible signs of progress until the end.
2-Code & Fix: “Code‐like‐Hell”.
Work well for prototypes. The specifications are not established.
PRO: No overhead on timework. Requires little expertise of PM.

CON: no process, quality control. High risk.

3-Spiral:
Emphasizes risk analysis & mgmt. in each phase. A series of Mini projects and each of these
addresses a set of “risk”. The firsts iterations are cheaper. # of spiral are variable.
PRO: can be combined with other models. As costs increase, risk decrease. Risk orientation
provides early warning.
CON: More complex, there are too much phases and requires more management.

4-Sashimi (modified waterfall): overlapping phases.

PRO: Reduces time and documentation. Works well if personnel are continuity.
CON: Milestones more ambiguous. Progress tracking more difficult. Communication can be mor
e difficult.
5-Evolutionary Prototyping:
Design most prominent parts first → Usually via a visual prototype.

10
PRO: good for solutions with: rapidly changing requirements, non‐committal customer and
vague problem domains.
CON: time estimation is difficult, Project completion date can be unknown and an excuse to do
“code & fix”.
6-Staged Delivery: Waterfall steps through architectural design.
Then detailed design, code, test, deliver in stages.
PRO: Sooner delivery. Tangible signs of progress soon. Problem discovered earlier.
Increases flexibility. Reduces estimate mistakes and the overhead for the status reporting.
CON: Requires more planning for PM. More releases increase effort.
It is similar to evolutionary prototyping, but guided by strong architectural design.
7-V Process model:
It is designed for testability. In fact, emphasized verification and validation at all phases.
It is a variation of waterfall. It is more indicated for the systems that require high reliability.
PRO: Encourages V&V at all phase.
CON: require more planning and more power for future releases.
8-RAD (rapid application): 1980s popular.
It is composed of four main phases: JRP-JAD- Construction- Cutover
PRO: fast develop. Good for systems with extensive user input available
CON: Reduced scale and functionality.
9-COTS (commercial off the shelf software):
Build VS Buy solution.
PRO: available immediately and potentially lower cost.

CON: not as tailored to your requirements.

10-XP (eXstreme Programming):

It is maybe the most knows as Agile development.
PRO: it is iterative/incremental and mphasized the progress client feedback with a continuity me
eting.

11
PRO: suitable for little groups, minimize unnecessary work. Stories as requirements.
CON: the availability by client is mandatory, needs expert developers.

11.Other methodologies (agile):

In general, the agile methodologies are “light” and required little documents and are iterative.
PRO: Reduce overhead, responsive to user feedback, amenable to change.
CON: requires close monitoring by PM, Can not “scale” to large projects, often requires better
quality developers.

Given a specific scenario decide what SDLC is most appropriate:

12
Requirements: capabilities and conditions to which the system must conform
Functional: behavioral = features and capabilities

Non-Functional (6+1): the conditions under which the functional capabilities should work

• Usability: human factors, help, documentation

• Reliability: Failure rates, recoverability, availability
• Performance: response times, throughput, resource usage
• Supportability: Maintainability, internationalization
• Operations: Systems management, installation
• Interface: integration with other systems
• Other: legal, packaging, h/w

SOW & CHARTER

SOW is a document describing the work that needs a project.
Scope of work: work that needs & hw/sw.
Location of work: where the work is.
13
Period of performance: temporal variables
Deliverables Schedule: things that are & when
Acceptance Standards: rules of sector
Acceptance criteria: criteria determining values
Special Requirements:
CHARTER it is a document describing a first definition of roles and responsibility, define the obje
cts of project, define the part of interest of a project and the authority.

14
ESTIMATE & SCHEDULE
4 primary steps: 1. Define “what” needs to be done. In this step, there is (initial documents,
SOW and Project Charter) 2. Identify “how much” (the size) to do. Size estimation techniques:
The dimension of the project in terms of complexity/quantity. 3. Identify the dependency
between tasks: Dependency graph, network diagram. 4. Estimate total duration of the work to
be done (The actual schedule).
Planning: Determining the size and duration of activities.
Estimation: Adds specific start and end dates, relationships and resources.
Scheduling: Add specific data of start and end, relationship and measure.
WBS
INFO:
It is a hierarchal activity list of projects. It Shows the relationship btw activities
Formats: Outline or graphical org chart.

It can compose of 6 levels:

• Managerial level: (Total program, Project, Task)
• Technical Level: (Subtask, package of work and level of effort)
TYPES: Process, product and hybrid.
Process: Activity oriented. Divided the project in different steps (design, requirements, analysis,
testing). Typically used by PM.
Product: Entity oriented. It shows the product created by project and its composed. (Financial e
ngine, interface system, db.). Typically used by engineering manager.
Hybrid: off course is both above. This is not unusual. In top, there are the activity in down level t
he entity produced by activity.
STRUCTURE: Contract, Project
Contract: first 2 or 3 levels. It allows a view of high level of project. It can used for user‐report
Project: it is the lowest level tracking defined by PM and team members. It usually used for tech
nicality review within project.

15
ESTIMATION
Estimation means determining the duration and the dimensions of the activities. It a difficult
process but often necessary. Estimate the dimensions (size) of project, the effort required and
the general schedule.
Size Estimation Techniques:
Top‐down:
Based on overall characteristics of project. It used in initial phase. It often used with others tec.
like analogy or Expert Judgment
PRO: Easy to calculate and effective early on.

CON: Some models are questionable or may not fit and Less accurate because it doesn’t look
at details
Bottom‐up:
Decompose the project with WBS with bottom up type. It needs more work but is more
accurate and often used with judgment.
PRO: Works well if activities well understood.

CON: Specific activities not always know and more time consuming.

Analogy: Use past project (similar for technology, type, organization) and can be formal or not.
PRO: Based on reality project not theory.
CON: Difficulty matching project types, previously projects can be bad calculated and is hard me
asure differences among past projects.
Expert Judgment: use somebody who has recent experience or similar project. The accuracy
depends on experience.
Wideband Delphi: Group consensus approach. Present experts with a problem and response
form. Conduct group discussion; collect anonymous opinions and then feedback.
PRO: easy utilizes expertise of several people and doesn’t require historical data.
CON: difficult to repeat, can fail to reach consensus, reach wrong one.
Priced to Win: The cost is estimated on budget project. It is not a really estimate technique. It n
eeds to have others data from past estimates. It usually used on public auction.

16
Parametric Method: LOC & FUNCION POINT
1. Loc (lines of code): based on # code lines that will compose the final program.
a. PRO: Commonly understood metric, permits specific comparison and actuals easily
measured.
b. CON: difficult to estimate early in cycle (because the requirements are not
considered and is regard on the technology used), Counts vary on the languages,
many costs not considered, Code generators produce excess code.
2. Function Points: Software size measured by number & complexity of functions it performs
(instead of the size measure the complexity the bathroom)
More methodical than LOC counts. There are three steps:
a. Count # of biz functions per category (like: outputs, inputs, DB inquiries, files or
data structures, and interfaces)
b. Establish Complexity Factor for each and apply (like: Simple, Average, Complex)
c. Compute an “influence multiplier” and apply
d. Results in “function point total” (This can be used in comparative estimates)
EFFORT ESTIMATION:
After calculating the measuring size there is the effort estimation in terms of people/time. Exist
different models: Empiric, mathematic and subjective. McConnell use a table to converse size in
effort. It is as measuring size in terms that works well when there are past data.
Estimation Issues: Usually initial estimation is required but often the data are limited. The data
are available in the final phase when doesn’t needs. The best estimations are based on past exp
erience. Important to remember that the estimations are iterative progress.
Overestimation: the project can be not financed, the estimation that ensure 100% to success of
ten not are financed.
Underestimation: quality problem, impossible to respect the deadlines. Motivation problem.
Target vs. Committed Dates:
Target:
•  According to marketing/business proposal
•  Do not commit to this too soon!
Committed:
•  Team agreement on this
•  After development of a schedule
17
Schedule presentation techniques: Exist different techniques to present the estimation to stake
holders.
1. Use +/‐ to give error margin.
2. Use time range 6‐8 months.
3. Quantity of risk +1 months if the tools are new.
4. Use best and worst cases.
5. (Coarse dates)Use generic date fine 2015
6. (Confidence factor) Use the probability 10% June & 60 July.

The cone of uncertainty:

18
In project management, the Cone of Uncertainty describes the evolution of the amount of
uncertainty during a project. Uncertainty not only decreases over time passing, but it also
diminishes its impact by risk management, specifically by decision-making.
Just to know that by passing the time the uncertainty will be decreased and after architecture
phase there will not be any more negative uncertainty.
SCHEDULING
DEF: After defining the task (WBS) estimates of size/effort is planned in detail from the point of
view of time the project, defining the timing of start/end of each activity. In general, we can say
that the scheduling aims to achieve a balance between these three basic goals: best time, least c
ost, least risk and evaluate different schedule alternatives, effective use of resources, reduce com
munication among resources.
4 types among task: FS ‐ SS ‐ FF ‐ SF
FS: Finish-to-start: “A f-to-s B”: B cannot start until A finishes
SS: Start-to-start: “A s-to-s B”: B cannot start until A starts
FF: Finish-to-finish: “A f-to-f B “: B cannot finish until A finishes (like: you cannot finish codding
until you finish testing)
SF: Start-to-finish: “A s-to-f B “: B cannot finish until A starts
4 Reasons for dependencies among task:
1.Mandatory: the dependence among task can’t be ignored. Nature of the work dictates an ord
ering. Ex. design precedes implementation.
2.Discretionary: it is more soft and determined by project management team. It can be modifie
d if is necessary. Ex. The modules code must be wrote in order.
3.External: legate by external factors. Ex. the module delivery by 3th part.
4.Resource: two tasks rely on the same resource, one usability expert can do more then one
task
Milestone: identify crucial points in schedule. It’s a time instant and typically shown as inverted
triangle or a diamond. Often used at review or delivery times.
SCHEDULING TECHNIQUES (Network Diagrams and Bar Charts):
Network diagrams: It used a graphical representation of the tasks necessary to complete a proj
ect. It is clearly visualizes the flow of task & relationship.

19
Two types: CPM and PERT. Two formats: AOA (activity on arrow) the activity represented on arr
ow that adds the nodes and shows events; AON (activity on node) the activity represented on n
odes, with arrows indicating the auctions among tasks.
CPM: The process for determining and optimizing the critical path. It should be done in
conjunction with the project manager & the functional manager. All projects have a CP. It is
based on 2 passes approach: Forward Pass (determine the time of early start ES and early finish
EF for each task. Rule: when several tasks converge, the ES for the next task is the largest of
preceding EF times) and Backward Pass (calculate late start LS and late finish LF for each task,
Rule: when several tasks converge, the last finish for the previous task is the smallest of
following last start times). As result of the 2‐passes the critical path becomes evident.
PRO: show the precedence of task, reveal interdependencies not shown in other techniques,
ability to calculate critical path and ability to perform what if exercises.
CON: default model assumes resources are unlimited, difficult to draw and to read on large
project.
PERT: Program Evaluation Review Technique
Based on idea that estimates are uncertain:
• Therefore, uses duration ranges
• And the probability of falling to a given range
1. Start with 3 estimates for each task: Optimistic (would be occur 1 time in 20), Most likely
(modal value of distribution) and Pessimistic (Would be exceeded only one time in 20).
a. PRO: accounts for uncertainty
b. CON: time and labor are intensive, lack of functional ownership of estimates, assum
ption of unlimited resources and used only complex.
2. Calculate the expected time of each task
3. Calculate the standard deviation of each task
PRO: Accounts for uncertainty

CON: Time and labor intensive, Assumption of unlimited resources is big issue, Lack of functional
ownership of estimates, mostly only used on large, complex project
CPM vs PERT:
Both use Network Diagrams, CMP deterministic, PERT probabilistic, CPM one estimate, PERT
three estimates, PERT is infrequently used.
Bar Charts:

20
 • Milestone: It shows the temporal sequence of tasks
o One bar per each task.
o Bar length is proportional to task duration
o It shows only more general tasks of the WBS.
• GANTT: As the milestone chart, it shows the temporal sequence of tasks and their
duration
o As the milestone chart, it shows the temporal sequence of tasks and their duration
o It shows dependencies among tasks
o It considers all tasks organized in groups and subgroups
PRO: easy to understand, easy to create and maintenance. Good support from software tools

CON: It has difficulties to show complex relationships among Tasks, it does not show uncertainty
of a given activity (the same as pert)
Some definition for Gantt chart:
• Lag time: It means a delay between tasks in sequence
• Lead time: It means an advance between tasks in sequence
• A Slack is the amount of time that a task can be delayed without causing a delay to:
o any downstream task (named Free Slack)
▪ Maximum delay of a task without causing a delay for any downstream task
o the end of the project (named Total Slack)
▪ Maximum delay of a task without causing a delay for the end of the project
Optimize techniques:
Reduce work, reduce quality, add resources. Crashing (reduce requirements) and Fast Tracking (
overlap tasks).
Mythical Man‐month:
1.Estimate techniques assume that things will do well. 2. Estimate techniques confused effort wi
th work in progress. 3. The progress is bed monitored. 4. When have a retard add people. 5. Too
much optimistic. 6. Not considered cost and overhead derived on communication team. 7. Some
process can’t be accelerated also adding people. 8. Testing is worst part little time. 9. Not consi
dered the necessary time for different development activity.

21