ITOM 6231 Special Topics in ITOM Project Management Introduction

1
ITOM 6231 Special Topics in ITOMProject
Management Introduction Requirements(Section
1)
2
Agenda

• Welcome and introduction
• Challenges to project management
• The solution
• Establishing the vision

3
Introduction Welcome...

• Introductions
• Name
• Background/company
• Project management experience
• What you expect out of the class
• Something that few people know about you

4
Challenges
5
Large Corporations Succeed on 1 in 10 Systems
Projects

• Success
• Completed on-time and on-budget
• All features and functions as initially specified
• Challenged
• Completed and operational but over-budget
• Delivered late and offers fewer features and
  functions than originally specified
• Impaired
• Cancelled at some point during the development
  cycle
• I.e., Failed

6
The Chance of Failure Increases With Project Size
Note A function point is roughly equivalent to
a screen, window, report, database access or
file input/output
7
The Solution
8
Critical Factors for Project Success

• There are many critical factors that result in
  project success
• Business user involvement
• Executive team buy-in/governance
• Appropriate budget resources, skills, scope,
  timing
• Technology
• Communication
• Perhaps the most important factor is the
  approach to solving the business project
• Project management
• Problem dissection
• Architecture

9
Top Principles of a Modern Software Process

• Risk mitigation approach architecture-first
  approach balance requirements, the
  architecturally significant design decisions and
  lifecycle planning before committing to
  full-scale development do the hard stuff
  first
• Small phases (i.e., Iterative life-cycle process)
  plan end-to-end proof-of-concepts, prototypes
  and pilots provide appropriately scope
  development efforts continuous life vs. single
  life smaller projects have much greater chance
  of success break problems into small projects
• Transparency keep no secrets about the project
  status or issues everyone from the project team,
  management and client sponsors know the state of
  the project focus on solutions not blame
• Managed scope define project outcomes know
  where you are going know when you are changing
  the destination understand implications of scope
  changes to resources, schedule, costs
• Demonstration-based approach provides early
  visibility to artifacts, executables, etc.
  a.k.a. horizontal vs. vertical development plan
  towards tangible project deliverables and
  outcomes understand completion state of all
  deliverables

10
Top Principles of a Modern Software Process
(contd)

• Rich communications supports rich semantics and
  comprehensive system investigation more
  objective and effective than ad-hoc
  representations visual representations followed
  by formatted followed by narratives (e.g.,
  graphics then tables then paragraphs)
• Progressive Elaboration Planning understand the
  big picture and how you will get there allow the
  detailed plan to grow with the project plan when
  you have the best information have the plan
  reflect the reality of the project
• Objective quality control/smart metrics apply
  metrics to accurately track progress of the
  project use only metrics required by the project
  and management minimize the impact of data
  collection and reporting
• Tool supported process encourage the use of
  tools and techniques to aid in the
  synchronization of documentation, code, etc
• Configurable process no single process is
  appropriate for all projects it must be
  flexible process should also adapt during a
  project to meet additional demands

11
You need to balance formality vs. bureaucracy
Ideal
Informal Custom
Benefit
Cumbersome
Formal Process
Anarchy
Gridlock
Formally Defined Process Is aProven Enabler
of Operational Excellence
12
The Bottom Line As Reported by the Software
Engineering Institute

• Benefits of formally defined process
• Median Productivity Gain Per Year 35
• Median Yearly Reduction in Time to Market 19
• Median Yearly Reduction in Post-Release Defect
  Reports 39
• Source www.sei.cmu.edu

Five Dollars of Business Value are Realized for
Every Dollar Invested in Software Process
Improvement
13
The role of the project manager

• Management manage the project through the
  development life-cycle to ensure scope/quality,
  time and resources
• Communication communicate frequently with
  various stakeholders, tailored to their specific
  needs, quirks and desired outcomes
• Presentations and reporting kick-off meetings,
  status meetings, change control meetings,
  executive briefings, demonstrations, etc.
• Project documentation responsibility to ensure
  all life-cycle documents are written and
  submitted to the appropriate stakeholders
• Estimation working collaboratively with
  appropriate subject matter experts (SMEs) to
  determine level of effort (LOE) and estimated
  time to complete (ETC)
• Project scheduling project planning,
  baselining, ongoing updating, etc.
• Managing the team people manager, cheerleader,
  authority, etc.
• Conflict and change management dealing with
  conflicts and unforseen change

14
What skills are required?

• Organizational skills i.e., juggling many
  balls, impeccable time management, etc.
• Leadership taking control, leading by example,
  demonstrate integrity and respect, etc.
• People management being able to manage direct
  reports driving them towards deliverables or
  other objectives
• Communication being clear, being crisp, details
  at the appropriate level, etc.
• Time management manage the time of others,
  especially SMEs who may not be as driven towards
  the project goals
• Technical or specialized skills if you are
  acting as a technology project manager or
  providing any other type of SME yourself
• Business management must be able to translate
  lower level details into the appropriate business
  language to justify the project, address changes
  and help budget appropriately
• Creating and giving presentations leading
  meetings, facilitating various types of sessions,
  etc.

15
Establishing the Vision
16
Understanding The Problem Is The First Step In
Understanding Requirements
Traceability
Leffingwell and Widrig, Managing Software
Requirements A Unified Approach
17
Cant We Just Start the Requirements Gathering?

• A system cant be successful unless it meets the
  needs of the stakeholders therefore, we need to
• Establish a good understanding of the stakeholder
  community
• Demonstrate an understanding of the problem to be
  solved
• Capture the real needs of the stakeholders and
  the system features required to fulfill them
• Ensure that the views of the stakeholder
  community are actively and appropriately
  represented throughout the project
• Activities
• Establishing an understanding of the problems the
  project should be addressing
• Preparing for requirements workshops
• Identifying the sources of the systems
  requirements

18
More on Stakeholders

• Who are they?
• Users actual users of the system will become
  actors in use cases
• Sponsors business managers, financiers,
  shareholders, champions, directors, etc.
• Developers project managers, maintainers,
  testers, support staff, designers, coders,
  writers, production staff, etc.
• Experts authorities in a particular aspect of
  the problem and/or solution domain (e.g., SMEs as
  well as technical architects, legislators, etc.)
• Customers the people and/or organizations who
  will actually be purchasing the final system
• Sample stakeholder roles
• Ambassador user bringing knowledge of the user
  community into the project team and disseminating
  information from the team back to the users
• Visionary responsible for ensuring that the
  right decisions are made with respect to system
  scope and that original business objectives of
  the project are met
• Executive sponsor responsible for project
  funding ultimately responsible for decisions on
  behalf of the business

19
The Vision Document

• Contains the following sections
• The business case opportunity, problem, user
  environment, ROI, etc.
• Stakeholders and users definition, types,
  identification, etc.
• Key stakeholder and user needs definition of
  the problem and needs of the community
• Background work to date, motivations, etc.
• Product overview high-level view of the
  capabilities, assumptions, dependencies and
  alternatives to the product
• Features lists key product features of the
  system necessary to meet user defined needs
  (usually the longest and most important section
  of the vision document)
• Other product requirements constraints, known
  issues, etc. that may affect the product (e.g.,
  legislation, regulation, etc.)
• Without the vision document, it is essentially
  impossible to have traceability of problem needs
  to features to requirements without writing it
  down first, change and uncertainty will creep
  into the project putting the scope, schedule
  and resources at risk

20
Exercise Build a Vision

• For this exercise, we are going to build a vision
  document for a new system
• Our primary focus is on the key system features
  that we will want to implement
• For each feature, list it briefly along with a
  priority must have, want to have or nice to
  have
• We will review your answers with the class

21
Assignment 1 Project Vision

• Read Chapters 1, 3 and 4 and review slide
  materials
• Each student will write their own first version
  of their Project Vision document
• You may pick any major web site (should have high
  level of functionality) to form as the basis of
  your project vision
• You may deviate from the actual implementation,
  but the spirit of the business should make sense
• Each section should be from 1/2 to 1 page in
  length
• For sections that are still new/difficult for
  you, fill in as much detail as you can we will
  be updating this document throughout the class
• Just fill in section 1 through 14