IT Project Design & Initiation Notes

IT Project Design & Initiation Notes

Introduction, Goals and Requirements
Goals and Requirements, Maya
Lecture slides
Laussen, the need to ask why
The Role of requirements and Project Types - S. Lauesen's book Chapter 1.1
Guide to requirements SL-07
Netflix Case
Business Cases, Maya
Lecture Slides
Ward & colleagues
Tutorial Netflix
Sample exam q
Introduction to IT Project Management, Renata
Project Management Standards
Project Management Standards, Effing
WORKSHOP ON PROJECT MANAGEMENT METHODS, Effing
Assignment, DO IT
Introduction, Goals and Requirements

Goals and Requirements, Maya

Lecture slides
Why do we need clear project goals?
●​ Provides the starting point for the planning process
●​ Provides clarity to know when you have finished
●​ Provides clarity to all stakeholders
●​ Describes what must be achieved for the project to be a success
●​ It helps us to scope the project
●​ It prevents unnecessary work
●​ Clear goals are a key to project success

Project Goals, ​
Goal Statements: Terminology
●​ Because a goal is a project management instrument that we use to achieve
results, it is closely linked to the concept of measuring
●​ It connects the needs that triggered the project to being the expected effects
●​ Effects are also called outcomes

Goal Statements: How to formulate them?

A goal should be:
●​ The big picture of what you want the final outcome to be,
●​ Related to the project need statement and scope,
●​ simply stated,
●​ needs to be explicit enough so that achievement can be measured,
●​ needs to be broad enough to allow flexibility of delivery

A goal statement should include the 5 W’s:

●​ What is to be achieved by the end of the project?
●​ Why do we want to achieve this?
●​ Where will it happen?
●​ Who will be involved?
●​ When will it be completed?

-​ A goal is a target or concern that guides the requirements definition process

-​ In IT management, it can be used to discover and evaluate functional and
non-functional requirements.
 -​ A goal is not yet a requirement

Contents of ReqSpec: Start with scope

Data Requirements:
-​ Input/Output formats

Functional requirements, each interface:

-​ Record, compute, transform, transmit
-​ Function list, pseudo-code, activity diagram
-​ Screen prototype, support tasks xx to yy

Quality reqs:
-​ Performance
-​ Usability
-​ Maintainability

Managerial reqs:
-​ Delivery Time
-​ Legal
-​ Development process…
Domain-level req:
​ The product shall support the following user activities…

Product-level req:
​ The product shall accept the following input…

The stakeholders and the role of the requirements per context type of the project

Requirements template to strike a

balance between customer & supplier
-​ Customer should not write very
detailed requirements
-​ Supplier should have a chance to
be innovative and reuse as much of
what he/she already has

Types of req documents

●​ Requirements definition
○​ An informal outline of the requirements using a few paragraphs or simple
diagrams
●​ Requirements specification
 ○​ A long list of specifications that contain thousands of pages of intricate
requirements describing the system in detail

The right requirements when working with a supplier

Goal level
-​ Those reqs are usually a responsibility of the client organization itself
-​ They say why a project exists at all
-​ A supplier cannot act on such reqs
-​ Conclusion: not suitable

Domain level
-​ Use tasks of the user in the description. Say what tasks will be supported, or
even what complete business processes will be supported
-​ Say if something is a problem and needs to be eliminated. The supplier will act
on this kind of requirement. It can also be met in more than one ways.
-​ Conclusion: suitable​

-​ Task descriptions as domain-level reqs

Product level
-​ Be explicit about the purpose of a feature/function
-​ Otherwise, it’s nearly impossible to ensure if a supplier meets the req
-​ Conclusion: suitable based on explicitly stating the purpose

Design level
-​ When talking about design, users are inspired by systems they saw in their past
-​ No supplier may meet such a requirement. Or, good suppliers would be ignored,
just because their screen may look different
-​ Conclusion: may be suitable based on amount of details.
Requirements concerning non-functional aspects of the project
-​ Standards as requirements
-​ Development process as a requirement
-​ Existing screens as data requirements

Right requirements level vs. being precise

Precise means that we can verify it - we can decide if the system meets it or not

Precision has nothing to do with the level

A goal level req is too high level, but is after using the system for some time

A requirement can be verifiable, however, unable to distinguish suppliers

​ Example: the supplier should have agile methodology in place and should have
used it in at least 2 projects

Watch for Quality Requirements

-​ The availability should be 98% or better
-​ If ‘better’ is not stated, then there is no incentive for the vendor to specify
that a solution is better
-​ If ‘better’ is stated, then the vendor wins a plus regarding other vendors, if
the solution specifications indicate ‘how much better’

Laussen, the need to ask why

★​ The Danish Shipyard case highlights the importance of careful requirement
specification; a critical feature (recording experience data) was accidentally
omitted, leading to issues when the system was operational.
★​ To avoid such errors, it's important to trace business goals to requirements and
check them multiple times during development; using domain-level requirements
rather than product-level ones can also help.
★​ Analysts should try to move up and down the goal-design scale by asking "why"
each requirement is necessary and "how" it can be achieved, to choose the
appropriate requirement level.
★​ An example is given of a device measuring neural signals; the requirement for a
mini-keyboard was explored through "why" and "how" questions, leading to a
clearer understanding of the real requirement: the device needs to be operable
while both of the surgeon's hands are on the patient.
 ★​ It is beneficial to include business goals, domain-descriptions, and examples in
the requirement process as they:
○​ Improve the supplier's understanding of the domain,
○​ Allow you to check if the goals are fully reflected in the requirements and
considered during development,
○​ Help the supplier to guess tacit requirements or ask for further information.
★​ However, caution is advised when using examples to avoid turning requirement
issues into design issues.

The Role of requirements and Project Types - S. Lauesen's book Chapter

1.1
★​ The role of requirements in a project is crucial. They include tacit demands,
elicitation and analysis (finding and structuring requirements), validation (the
customer’s check that requirements match demands), and verification (checking
that the product fulfills the requirements).
★​ A requirements specification plays several roles during a project and is produced
early in system development. It is often part of a contract between customer and
supplier.
★​ The waterfall model for systems development is an idealistic model where
development starts with an analysis phase that produces the requirements
specification.
★​ Requirements will change during development as developers and customers find
missing, wrong, and unrealistic requirements. This is called requirements
management.
★​ The requirements come from users and other stakeholders of the system. The
role of the analyst is to elicit these demands, analyze them for consistency,
feasibility, and completeness, and formulate them as requirements.
★​ There are many types of projects: in-house development, buying commercial
software, tenders and contracts, etc. Requirements have different roles in
different types of projects.
○​ In-house development often occurs in larger companies, where the
customer and the supplier are departments of the same company.
○​ Product development is carried out inside the company. The “customer” is
the marketing department and the “supplier” the development department.
○​ Time-and-material based development is when a software house develops
the system on a time-and-materials base, i.e. the customer pays the costs,
for instance month by month.
 ○​ COTS purchase is when a commercial package is bought. Whatever
extensions and configurations are required, the customer takes care of
them himself.
○​ Tender is when the customer company starts a tender process and sends
out a request for proposal (RFP). Several suppliers are invited to submit
proposals.
○​ Contract development is when a supplier company develops or delivers a
system to the customer company. The requirements specification and the
contract specify what is to be delivered.
○​ Sub-contracting is when a sub-contractor develops or delivers part of a
system to a main contractor, who delivers the total system to a customer.
★​ Sometimes the project type is unknown. High-level requirements can help to
resolve these issues. They may help compare the alternatives from a cost/benefit
and risk perspective, and they may help in looking for potential suppliers
in-house or outside.

When a demand is not reflected in the requirements specification, we say it is a tacit

requirement.
​ We also talk about tacit demands, demands that the user is not aware of or
cannot express

Acceptance test - the parties go through the requirements one by one and check that he
product satisfies them

●​ Validation
○​ The customer must be able to validate the requirements to see that they
correctly reflect his needs
●​ Verification
○​ Check that the product satisfies the requirements (minimum acceptance
test; test also intermediate work)
●​ Tracing
○​ Requirements tracing is needed to compare requirements against other
information. 4 types​

○​ Forward
■​ Tracing from requirements to program to see that all the
requirements are dealt with. Roughly the same as verification
■​ Tracing from demands to requirements to see that all demands
are reflected in the requirements. This is part of validation., but
 often neglected with the result that important business goals may
be lost.
○​ Backward
■​ Tracing from requirements to demands to see that all
requirements have a purpose. (another part of validation)
■​ Tracing from program to requirements to see that all parts of the
program are [Link] is neither validation, nor verification, but
a useful check to avoid feature creep.
●​ Requirements Management
○​ Reqs change during development
●​ Court cases
○​ The requirements specification and contract may be used as evidence of
what was agreed (‘reasonable’ tacit reqs)

Project types
●​ In-house development
○​ Developed inside a company for company’s own use; larger companies
●​ Product development
○​ Commercial product to be marketed by a company. Carried out inside the
company, the customer is the marketing department, the supplier is the
development department
●​ Time-and-material based development
○​ A software house develops the system on a time-and-material base, the
customer pays the costs for instance, month by month, Requirements are
informal and develop over time.
●​ COTS purchase
○​ Commercial Off The Shelf prods.
○​ When we want a COTS product including some tailor-made configuration
or extension, we use the term COTS-based acquisition. Requirements and
contracts are very important here.
●​ Tender
○​ the customer company starts a tender process and sends out a request
for proposal (RFP). Several suppliers are invited to submit proposals.
○​ Particularly used by gov organiations
●​ Contract development
○​ a supplier company develops or delivers a system to the customer
company. The requirements specification and the contract specify what is
to be delivered
●​ Sub-contracting
 ○​ is when a sub-contractor develops or delivers part of a system to a main
contractor, who delivers the total system to a customer.
○​ Can be requirements based or time-material based without written reqs
●​ Situation unknown
○​ Sometimes the project type is unknown. High-level requirements can help
to resolve these issues. They may help compare the alternatives from a
cost/benefit and risk perspective, and they may help in looking for
potential suppliers in-house or outside.

Guide to requirements SL-07

Testing is often organized in stages:
●​ Installation test: System delivery often starts with installation of the new
hardware, software, etc. The purpose of the installation test is to ensure that the
components work together and have basic functionality.
●​ System test: The purpose of the system test is to check that requirements are
met, screens work, etc. according to points 1-4 above. Special test data and
database contents are used to allow testing of all the cases.
●​ Deployment test: The purpose of the deployment test is to check that the product
can work satisfactorily in daily operation with production data.
●​ Acceptance test: An acceptance test is a system test plus a deployment test.
These two tests may be performed at different times or in combination.
●​ Operational test: The purpose of the operational test is to check those
requirements that can be verified only after a period of daily operation. It might be
the response time under real load, breakdown frequency, task time for
experienced users, qualifications of the supplier's hotline, etc.

Netflix Case
Goal-level requirements:
-​ The system shall be available to at least 1 billion clients worldwide to watch the
same film at the same time.
-​ The downtime of the system should be reduced to 0 minutes.
-​ The BusInt system should help Netflix discover the needs, wants and behaviors
of the customers.

Domain-level requirements:
-​ The system should support the task of calculating the key metrics that are
needed by the Billing team to generate the trend report.
-​ The BIS application will provide a pricing catalogue in support of the task of
promotion design and planning.
-​ The system should support Apple clients to make payments through Apple TV.
 -​ The system should support the Complaint Analyst in tracing negative feedback.
-​ The BusInt system should support the derivation of patterns in consumer’s
behavior.

Product-level requirements:
-​ The system shall be able to generate a graph that shows the connections that
are active in the time.
-​ For Netflix customers who are also Apple customers, the system should reuse
credit card information saved by Apple so that these customers do not need
repeat entry of data.
-​ The SQL database shall be on the cloud to support a maximum number of
streaming connections.
-​ The system should send a message to Billing Analysts when a credit card has
insufficient funds.
-​ The system should report the following data to Billing Analysts when an
insufficient fund card is identified: client name, postcode, landline phone, mobile
phone, location, recent billing history, movie-watching history.
-​ The system should have the recommendation rating function with a five-star
scale where one star mean “very low” and 5 stars means “great”.
-​ Opening a recommendation should take no longer than 1.5 seconds.
-​ The BusInt will have the feature for generating daily consumers’ recommendation
patterns.

Design-level requirements:
-​ The client growth metrics should be calculated as per the Standard “Metrics
2013AX”.
-​ The system should present a drop-down box to complaint analysts when
planning a call with a client who has insufficient fund.
-​ The system should present a full record of client info when a Complaint analyst
selects an item from drop-down list.
-​ The Netflix library of films should be divided in clusters of similarly-rated films by
customers.
-​ The Cinematch system should implement two methods for predicting customers’
preferences: collaborative filtering and adaptive filtering.
Business Cases, Maya

Lecture Slides
Strategy
-​ An integrated set of actions that will over the long term provide benefits to
enterprise stakeholders

Therefore strategy is about 2 questions:

-​ What benefits do we wish to provide and to whom?
-​ How are we going to deliver them?

Current level of using business cases in IT industry

-​ Around 70% of IT companies produce a business case just for approval and
archive it once approval is achieved
-​ Strong believe that maintaining the business case current, and using it
throughout the project does increase value
-​ Around 50% of projects to do not trace the benefits realized

Organizations with mature benefits realization processes draw advantages from:

●​ Clearly identifying the strategic rewards prior to starting a project
 ●​ Effectively assessing and monitoring risks to project success
●​ Proactively planning for making necessary changes in the organization
●​ Explicitly defining accountability for project success
●​ Routinely extending responsibility for integration to the the project team

A Business Case assists organizational stakeholders in making decisions regarding

the viability of a proposed project effort.
Principles of benefits realization
●​ IT has no inherent value
●​ Benefits arise when IT enables people to do things differently
●​ Only business managers and users can release business benefits
●​ All IT projects have outcomes but not all outcomes are benefits
●​ Benefits must be actively managed for

Benefits realization is the process of organizing and managing such that the potential
benefits arising from the use of IT are actually realized.

The approach of Ward and colleagues

Aspects involved:
●​ Tangible and intangible benefits
●​ Measures are defined (both for qualitative and quantitative benefits)
●​ Evidence is included whenever available
●​ The role of a benefit owner is established
●​ Accent on how the business case will be realized: what changes to watch for
●​ Business change owners are included, too

Fundamental Aspects:
●​ Ownership: every benefit stream must have a benefit owner
●​ Measurement: unless a benefit can at least be observed it does not exist
●​ Improvement: performance only improves when people do things differently
(doing old things with new tech won’t do much)

The Means-end theory

-​ Objectives = ‘ends’ that are achieved through ‘means’

The Benefits Dependency Network: a high-level view

Defintions
●​ Business Driver
○​ A view held by senior manager(s) about what is important in the business
over a given timescale - such that changes must occur
●​ Investment Objective
○​ Organizational target for achievement agreed for the project in relation to
the drivers and envisaged changes
●​ Benefit
○​ An advantage on behalf of an individual stakeholder or stakeholder group.

Business Driver Analysis

​ It aims at finding out:
-​ The rationale behind the desired changes and the degree of dissatisfaction with
the current situation
-​ The strength and nature of ownership of the change initiative
-​ At a high level, what will constitute success, who will determine success, and
how will it be measured

The output:
​ Agreed objectives for the project which clearly define what the organization
intends to achieve

Establishing drivers and objectives

Example: using tokens as the payment solution in large-scale events
Structuring benefits, degree of explicitness
●​ Observable: personal judgement, perception, experience
●​ Measurable: examples are existing measures in the organization, such as KPIs,
client retention rates, performance
●​ Quantifiable: focus on our ability to predict reliably the scope of the benefit
●​ Financial: expressed in financial terms
Business Value from IT demands a management process focused on value delivery

IT by itself has no value: performance only improves when people do things differently
Ward & colleagues
Building the business case

1.​ Define Business Drivers and Investment Objectives

a.​ A convincing and robust business case should start with a statement of
the current issues facing the organization that need to be addressed – the
business drivers. Senior management and others within the organization
will quickly recognise these issues and will be looking for ways to deal with
them. The business case should then clearly state what the proposed
investment seeks to achieve for the organization – the investment
objectives – in a way that shows it can clearly address some or all of the
business drivers. An example is a mobile phone company that was losing
customers due to service failures and competitive offerings. Despite its
strategy to differentiate based on service quality, the uptake of its new
services was low. To resolve this, it decided to enhance its call center
operations to reduce customer complaints and increase sales of new
services. The project aimed to improve call center services, increase the
adoption of new services, and gather customer profiling information for
better targeting, all without expanding the call center staff, thus increasing
operational efficiency.
2.​ Identify benefits, measures and owners
a.​ Once the investment objectives are established, it's essential to identify
the expected benefits that will result if these objectives are achieved.
Unlike objectives, which are overall goals agreed by stakeholders, benefits
are specific advantages conferred upon particular groups or individuals.
Often, there may be more benefits than objectives, as each objective can
result in multiple benefits. For instance, a new EPOS system in a
supermarket chain provided management with real-time sales data, made
operations easier for checkout staff, and improved product availability and
checkout speed for customers.
b.​ After recognizing the benefits, each should be assigned a method of
measurement and a benefit owner. The measurement helps in
understanding the exact nature of the benefit. For example, 'increased
sales' might be better defined as 'sales of a new product' or 'sales to a
new market'.
c.​ A benefit owner is someone who stands to gain from the benefit and is
thus motivated to ensure its realization, either personally or by leveraging
their resources and influence. They need to provide a value for that benefit
in the business case and ensure a realization plan is in place. Successful
 organizations often assign benefit ownership to senior managers,
demonstrating the project's importance and enhancing the business case.
3.​ Structure the benefits

a.​
4.​ Identify organizational changes enabling benefits
a.​ The first stage of using the suggested framework is to classify each
expected benefit according to the main type of change that will be needed
to realize it, as shown in the columns in Figure 1. It may seem simplistic to
relate each benefit to one of only three causes, but benefits arise
because:
i.​ The organization, its staff or trading partners can do new things, or
do things in new ways, that prior to this investment were not
possible, or
ii.​ The organization can improve the performance of activities it must
continue to do, i.e. doing things better, or
iii.​ The organization can stop doing things that are no longer needed
to operate the business successfully.
b.​ In our experience, senior management are likely to be more interested in
the benefits which enable new activities or innovations, or those that stop
wastage, rather than ‘do things better’ benefits
5.​ Determine the Explicit Value of each benefit
a.​ An important feature of locating benefits in the rows is the provision of
evidence. Each benefit should be initially allocated to the observable row.
Evidence should then be provided, by the benefit owner, to move it to the
rows above, which represent increasing levels of explicitness and
knowledge about the value of the benefit.
b.​
i.​ Measurable benefits. These are defined as benefits where there is
already an identified measure for the benefit or where one can be
easily put in place. This allows current performance to be
determined as the baseline prior to the investment. However,
importantly, it is not possible to estimate how much performance
will improve when the investment is completed.
ii.​ Quantifiable benefits. Like measurable benefits, quantifiable
benefits are ones where an existing measure is in place or can be
put in place relatively easily. However, in addition to being able to
measure performance before the investment is made, the size or
magnitude of the benefit can also be reliably estimated. Since this
inevitably involves forecasting the future, the challenge for
quantifiable benefits is to find a ways of doing this as robustly as
possible.
iii.​ Financial benefits. These are benefits that can be expressed in
financial terms. A benefit should only be placed in this row, when
sufficient evidence is available to show that the stated value is likely
to be achieved. Hence all financial benefits should be the result of
applying a financial value or formula to a ‘proven’ quantifiable
benefit. The financial benefits can then be combined to calculate an
overall financial value of the investment, rate of return or payback.
c.​ Ways of Overcoming the Quantification Problem​
​ There are a number of ways that evidence can be gathered to
enable the measurable to quantifiable ‘barrier’ to be bridged​

i.​ Detailed Evidence and Modelling/Simulation

1.​ If a benefit results from stopping doing something the
organization no longer needs or wishes to do, then the size
of the expected benefit can usually be estimated from
existing internal data or evidence. It is often important to
establish evidence over a relevant time period, such as a
year or through a peak in the trading cycle, however, it may
only be necessary to sample the data to find sufficient
representative evidence from which the overall value can be
extrapolated. Internal data on its own may not be enough to
determine how performance will improve when the new IT
capability and associated business changes have been
completed. In such cases, modelling can be useful
ii.​ Benchmarking and reference sites
1.​ Benchmarking is commonly used in a number of industries
as the starting point for improvement programmes. This can
be a valuable approach to quantifying benefits, in relation to
‘best practices’ in the industry, or in comparable processes in
other industries. For example, the time and cost taken to
process loan and mortgage applications or insurance claims
are considered as competitive KPIs in the financial services
industry. Unless the innovation is the first of its kind in the
industry, there should be some reference sites where similar
changes have been made or the technology is being used.
Obviously care is needed to select relevant implementations
and to be able to compare not only how the technology has
 been deployed, but also to understand the required business
and organizational changes.
iii.​ Pilot implementations
1.​ Pilot implementations can be used to not only test the
technology, but also to evaluate the benefits that can be
achieved from new systems and ways of working. To provide
the best evidence it is good to identify a comparable control
group still working in the old way.
6.​ Identify Costs and Risks
a.​ In addition to the benefits, a full business case must obviously include all
the costs and an assessment of the associated risk. The majority of IT
costs are relatively easily calculated. However, the costs associated with
making business and organizational changes are less predictable and are
usually either underestimated or not included at all. In our experience it is
the cost of these changes, particularly when they affect a wide range of
stakeholders that leads to the significant cost overruns often reported for
large IT investments. ​
The three factors which most differentiated the more and less successful companies in
our study were their ability to identify all the potential benefits from the investment (3
times more likely in the successful organizations), quantify those benefits (again 3 times
more likely) and whether lessons were transferred from completed to new projects
(twice as likely). The creation of a structured and rigorous business case, as described
here, is a key means of ensuring all possible benefits are recognised and that lessons
can be learnt from investments and transferred to other projects. From the evidence
provided by the more successful companies in our survey, and our experience of
working with a wide range of organizations, developing such benefitsled business cases
offers organizations a means of significantly improving the success rate of their IT
investments.

Tutorial Netflix

Benefit: stop paying for expensive databases (in the data center)
Measure: The annual spending on databases ​
Benefit owner: Robison, CTO
Explicitness: Financial

Benefit: Opening a recommendation will take a maximum of 1.5 seconds.

Measure: time it takes to open a reccommendation
Benefit owner: Ron Bergman, Business Intelligence VP
Explicitness: Measurable; doing things better

Benefit: Generating more income on subscription

Measure: Amount of new subscriptions per month
Benefit owner: Billing directors
Explicitness: Financial, doing things better

Benefit: increasing profit from Apple users after applying Bisys

Measure: calculation of profit is based on assumptions
Benefit Owner: Sale manager responsible for Apple side
Expl: Financial, doing things better

Sample exam q
Please consider Ward’s approach to business case development. In the case study it is
stated that the app is expected to provide interactive maps and should display
accommodations in close proximity to the user's current location. For this statement,
identify the benefit, the measure and the benefit owner (as in the Ward’s template).

Benefit: Acquire 500 000 new clients in the next 3 months

Benefit owner: the Marketing Director
Measure: number of new clients per month (Quantifiable, Do things better)

Introduction to IT Project Management, Renata

IT Project Definition:
-​ An IT project is a temporary endeavor, involving the use of hardware, software,
and networks to create a unique product, service, or result

Project attributes:
●​ Having a unique purpose
●​ Being temporary
●​ Driving change and enabling value creation
●​ Developed using progressive elaboration
●​ Requiring resources, often from various areas
●​ Having a primary customer or sponsor
●​ Involving uncertainty

Scope, Cost, Time

Important constraint aspects: Quality, Resource, Risk

Project Management
●​ The application of knowledge, skills, tools, and techniques to project activities to
meet project requirements
●​ Project managers must not only strive to meet specific scope, time, cost and
quality goals of projects but also facilitate the entire process to meet the needs
and expectations of people involved in project activities or affected by them

Why invest in Project management?

●​ New technologies have become a significant factor in many businesses
●​ The complexity and importance of IT projects have evolved dramatically
●​ Today;s organizations recognize that to be successful, they need to use modern
project management techniques, especially for IT projects
●​ Individuals are realizing that to remain competitive in the workplace, they must
develop skills to become good project team members and project managers

Stakeholders
●​ Project Sponsors
○​ pays/benefits from the project
●​ Financial Institutions
 ○​ Must be informed of any changes to the plans or schedule because the
project is part of a legal context
●​ Project Manager
○​ Needs to work with all the project stakeholders to meet their needs and
expectations
●​ Project Team
○​ Develops the project
●​ Supporting Staff
○​ Includes buyers, administrative assistants, or any other professional who
supports the work of the project team
●​ Suppliers
○​ Responsible to supply components, material or equipment used in the
project
●​ Opponents or competitors
○​ Oppose to the project or compete on its results

Project Management Framework

Project Management Knowledge Areas

●​ Scope Management
○​ Involves defining and managing all the work required to complete the
project successfully
●​ Schedule Management (formerly time management)
 ○​ Includes estimating how long it will take to complete the work, developing
an acceptable project schedule, and ensuring timely completion of the
project
●​ Cost Management
○​ Consists of preparing and managing the budget for the project
●​ Quality Management
○​ Ensures that the project will satisfy the stated or implied needs for which it
was undertaken
●​ Resource Management
○​ Concerned with making effective use of the people and physical resources
involved with the project
●​ Communications Management
○​ Involves generating, collecting, disseminating, and storing project
information
●​ Risk Management
○​ Includes identifying, analyzing, and responding to risks related to the
project
​

Project Management Tools and Techniques

-​ Project management tools and techniques assist project managers and their
teams in carrying out work in all 10 knowledge areas.
Ways to measure project success
●​ Met scope, time and cost goals
●​ Satisfied the customer/sponsor
●​ Results met its main objective

Project Success Factors

Required Skills for a Project Manager
●​ Understand the organization in which they work and how that organization
develops products and provides services
●​ Feel comfortable leading and handling change
●​ Possess general management knowledge and skills, related to financial
management, accounting, procurement sales, marketing, etc
●​ Have soft skills, including effective communication, influencing the organization
to get things done, leadership, motivation, negotiation, conflict, management, and
problem-solving
●​ Be able to make efective use of technology as it relates to the specific project
●​ Continuously develop their knowledge and experience in project management,
general management, soft skills, and the industries they support

Project Management Institute (PMI) Talent Triangle

Portfolio managers help their organizations make wise investment decisions by helping
to select and analyze projects from a strategic perspective
Examining the context in a graph
Deciding about projects
Project Management Standards

Project Management Standards, Effing

A project is a ‘a temporary endeavor undertaken to create a unique product, service, or
result’
-​ A project has a unique purpose
-​ A project is temporary
-​ A project drives change and enables value creation
-​ A project is developed using progressive elaboration
-​ A project requires resources, often from various areas
-​ A project should have a primary customer or sponsor
-​ A project involves uncertainty

A software development process is a scheme to:

-​ structure and manage the various aspects of development
-​ requirements elicitation
-​ design
-​ Implementation
-​ verification
-​ maintenance
-​ Software engineering”

Agility
-​ The agility of the organization can be defined as the ability to react quickly to
changes in the dynamic business environment

Traditional project management assumes that

●​ The circumstances that affect the project are predictable
●​ The requirements are clear and well understood

Actually,
-​ The project rarely follows sequential flow during the implementation
-​ Clients are usually unable to define all the requirements at the beginning of the
project

"Little research has been done as to whether Agile projects truly are more successful.”
(Serrador & Pinto, 2015)
Monitoring
Project Control Variables

Basic Control variables of Project Management Success (PMS)

●​ TQM Aspects of project management (Triple constraint / Iron Triangle)
○​ Time
■​ How long should it take to complete the project? What is the
project’s schedule? How will the team track actual schedule
performance?
○​ Scope
■​ What work will be done as part of the project? What unique
product, service or result does the customer or sponsor expect from
the project? How will the scope be verified?
○​ Cost
■​ What should it cost to complete the project? What is the project’s
budget? How will costs be tracked? Who can authorize changes to
the project?
○​ (Business Benefits)
○​ (Team satisfaction)
○​ (Organisation)
○​ (Information)

Most adopted Agile practices for success

●​ Daily stand-up (85%)
●​ Iteration planning (75%)
●​ Retrospectives (likes, dislikes, stories, decisions) (74%)
●​ Unit testing (72%)
●​ Release planning (versions) (70%)

Issues
-​ Just in time specifications with agile methods
-​ Complex system architectures with agile methods (resultin in too many
workarounds)
-​ Lack of pro-active team members for interaction

soft factor team collaboration

-​ Focus on relationships
-​ Shift in pm
-​ Together everyone achieves more
-​ Toll ein ander machts
-​ Team cultures
-​ interests

●​ Project level effects

○​ Larger projects with long duration positively influence PMS
○​ Delaying and postponing the beginning of a project can avoid additional
investments and cash flow losses
●​ Project manager-level effects
○​ High levels of project manager diversity have a positive effect on PMS
(Experience with various projects and complexity)
●​ Team network-level effects
○​ Smaller, focused and less-disperse teams can present better
○​ Team members working on central project perform better
Cost and Time Project Management Success Factors (CTPMS)
-​ PMS, delivering the output (result) on time, within the budget with the required
features and functions
Discussion and conclusions
●​ Larger projects with long duration positively influence PMS and, accordingly,
project success
●​ Postponing the beginning of a project is closed related to project risk
management. Making this decision at the start of an IS project can avoid
additional investments and even cash flow losses. It showed a positive effect on
PMS.
●​ The beginning of a project is usually heavily dependent upon the conclusion of
other projects that will release necessary resources.
●​ A project manager who can be exposed to projects of different sizes and types
during his/her career is better prepared to address unexpected situations that
could affect PMS.
●​ However, this is only one banking case, big limitation for results.
WORKSHOP ON PROJECT MANAGEMENT METHODS, Effing
Project Evaluation and Review Techniques (PERT) and Critical Path Method (CPM)

Critical Path:
-​ path without any slack
-​ Longest continuous path
-​ Determines the total duration of the project
-​ Any delays will delay the overall project
1.​ Critical Path: In project management, the critical path is the sequence of project
network tasks with the longest overall duration. This determines the shortest
time possible to complete the project. Any delay in the tasks on the critical path
directly impacts the project's completion date. Critical path tasks typically have
zero slack.
2.​ Slack: Slack, or float, is the amount of time that you can delay a task without
affecting the project's completion date. Slack is usually associated with tasks
that are not on the critical path. They have a bit of wiggle room regarding when
they start and finish. If a task has a slack of 10 days, it means you can delay it by
10 days without affecting the project's completion date.
3.​ Early Start (ES) and Early Finish (EF): In project scheduling, ES is the earliest time
at which a task can start, assuming all previous tasks are completed in the
shortest possible time. EF is the earliest time a task can finish. It's calculated by
adding the task's duration to its ES. These times are calculated via a forward
pass through the network diagram, starting from day zero.
4.​ Late Start (LS) and Late Finish (LF): LS is the latest time at which you can start a
task without delaying the project. LF is the latest time at which a task can be
completed without delaying the project. These times are calculated via a
backward pass through the network diagram, starting from the project end date.
5.​ Duration: The duration is the total time required to complete a task. It's usually
defined as the work hours or days from the start to the end of a task.
How these concepts work together in a PERT/CPM network:

First, you identify all the tasks required to complete the project and estimate their
durations. Then, you create a network diagram where the nodes represent tasks and the
edges represent dependencies between tasks.

Next, you perform a forward pass through the network to calculate the ES and EF for
each task. Starting from the first task (where ES is zero), the ES of the next task is the
EF of the previous one. The EF of a task is its ES plus its duration.

Then, perform a backward pass to calculate the LS and LF. Starting from the last task
(where LF is the project end date or the EF from your forward pass), the LF of the
preceding task is the LS of the next one. The LS of a task is its LF minus its duration.

The slack for each task can then be calculated. If a task's LS equals its ES (and LF
equals EF), then the task is on the critical path. Any delay in these tasks will delay the
project.

Finally, you identify the critical path by finding the path through the network with the
longest total duration. This gives you the shortest time in which the project can be
completed, assuming everything goes as planned.

Assignment, DO IT