De#ining  the  Project  

Chapter  4  

Creating  a  Project  Organization  

0  De#ine  who  is  going  to  do  what    –  De#ine  roles  and  responsibilities    –  Identify  people,  resources;  ensure  their  commitment  to  project    –  Identify  a  project  leader,  specify  her/his  authority  and  responsibilities    0  Important  questions:    –    Who  is  the  PM?  What  decisions  are  within  PM’s  area  of  authority?  Is  this  authority  suf#icient  to  carry  out  the  project?    –    Who  is  on  team?  Full-­‐time  or  part-­‐time?  What  are  their  areas  of  expertise?  Their  roles?    –    Who  is  the  project  sponsor?  Is  he  or  she  at  suf#iciently  high  level  in  the  organization  to  provide  the  project  with  support  and  a  good  chance  of  success?    

De#ining  the  Project’s  Objectives  and  Scope    

Make  sure  the  proposed  project  is  well  understood  an  that  all  stakeholders  agree  on  what  it  will  accomplish    –  Clearly  spell  out  expected  outcomes,  deliverables,  objectives    –  Agree  scope  –  what’s  in,  what’s  not  in    –  Document  agreements  formally,  in  writing,  to  surface/eliminate  ambiguity  in  different  stakeholders’  expectations    •  Important  questions:    –  What  is  the  scope?  –  What  does  the  project  need  to  accomplish?  –  By  when?      

Formal  Objective  Statement    A  Formal  Objective  Statement    –  Short,  simple  language,  unambiguous    –  Should  Scope,  Resources,  and  Schedule      •  A  Famous  Example:  “Put  a  man  on  the  moon  and  return  him  safely  to  Earth  by  the  end  of  the  decade  at  a  cost  of  $9  billion.”    –  Scope  –  “Put  a  man  on  the  moon  and  return  him  safely  to  Earth.”    –  Schedule  –  “By  the  end  of  the  decade.”  –  Resources  –”At  a  cost  of  $9  billion.”      •  The  advantage  in  keeping  it  short  and  simple:  Longer  statements  offer  greater  opportunity  for  people  to  come  away  with  different  understanding  of  what  the  project  will  accomplish  while  mistakenly  assuming  they  have  reached  agreement    

De#ining  the  Project  Scope  u Project  Scope  

u A  de#inition  of  the  end  result  or  mission  of  the  project—a  product  or  service  for  the  client/customer—in  speci#ic,  tangible,  and  measurable  terms.  

u Purpose  of  the  Scope  Statement    u To  clearly  de#ine  the  deliverable(s)  for  the  end  user.  u To  focus  the  project  on  successful  completion  of  its  goals.  

u To  be  used  by  the  project  owner  and  participants  as  a  planning  tool  and  for  measuring  project  success.  

Scoping  Agreement  0  The  purpose  is  to  de#ine  expectations  of  the  project’s  work,  responsibility,  and  accountability.    

 0  The  expectations  of  the  client  and  the  project  manager  must  be  known  and  shared  among  the  client,  project  manager,  and  the  project  team  members.    

 0   The  doer  and  the  receiver  agree  on  the  scope  of  the  doer’s  work.    0  External  to  the  project  team,  the  doer  is  the  project  manager  and  the  receiver  is  the  client.    

 0  Internal  to  the  project  team,  the  doer  is  the  task  manager  or  the  worker  and  the  receiver  is  the  project  manager  or  the  task  manager.    

Scoping  Agreement  u can  be  a  one  page  statement  that  includes  a  broad  de#inition  of  the  scope  of  work  (SOW),  but  it  is  not  the  same  as  the  SOW  (usually  detailed  and  can  require  several  pages  of  statement).    

 u state  the  big  picture  expectations,  not  the  details.      u is  the  beginning  or  de#inition  phase  of  the  management  process  and  gives  a  #irm  point  of  reference  for  project  efforts.    

 u gives  the  project  manager  a  de#ined  agreement  of  what  he  or  she  is  to  do.      u The  agreement  is  a  crisp  250-­‐word  statement  (easily  read  in  one  minute).    

 An  important  part  of  the  scoping  agreement  is  to  transfer  or  assign  

responsibility  and  accountability  of  an  effort  to  the  person  doing  the  work.    

0 #ile://localhost/Volumes/SEAGATE  BAC/BİM405/kurstedt.pdf  

Establishing  Project  Priorities  u Causes  of  Project  Trade-­‐offs  

u Shifts  in  the  relative  importance  of  criterions  related  to  cost,  time,  and  performance  parameters  u Budget–Cost  u Schedule–Time  u Performance–Scope  

u Managing  the  Priorities  of  Project  Trade-­‐offs  u Constrain:  a  parameter  is  a  #ixed  requirement.  u Enhance:  optimizing  a  parameter  over  others.  u Accept:  reducing  (or  not  meeting)  a  parameter  requirement.  

The  Requirement  Statements  ü Purpose  is  to  capture,  clarify,  communicate,  con#irm,  and  track  WHAT  the  client  needs  and  expects.    

ü focus  on  the  output  of  the  project  and  the  capability  of  the  output.    ü constrain  the  solution  space  for  the  project  manager.    ü include  capabilities,  characteristics,  and  constraints.    ü If  the  requirements  statements  are  wrong,  so  is  everything  else  in  the  project,  including  architecture,  design,  implementation,  veri#ication,  and  validation.    

ü take  the  form  of  lists  of  sentences  that  include  the  word  “shall.”  Use  active  rather  than  passive  voice  in  the  sentences.    

ü must  be  correct,  complete,  consistent,  measurable,  testable,  clear,  and  unambiguous.    

ü are  formal,  speci#ic,  legalistic  statements.    ü mandate  what  the  project  output  will  be  and  do.    

Types  of  Requirement  Statements  

ü contractual  or  management  requirements,  including  the  statement  of  work,  the  required  reports,  the  terms  and  conditions,  etc.;    

ü regulatory  or  environmental  requirements,  including  standards,  directives,  regulations,  etc.;    

ü technical  or  operational  requirements,  including  performance,  functional,  design-­‐to,  build  to,  etc.;    

ü maintenance  and  support,  including  preventive  and  on-­‐the-­‐spot  repair  and  auxiliary  needs  that  keep  the  project  output  functioning  as  needed;  and    

ü veri#ication,  which  tells  us  when  we’re  really  #inished.    

Task  List  ü Purpose  is  to  identify  the  tasks  required  to  complete  the  project,  the  needed  level  of  effort,  and  the  important  events  (milestones)  of  some  of  the  tasks.    

ü With  the  scoping  agreement  ;  –  the  expectations  of  both  the  doer  and  the  receiver  for  the  project  are  de#ined    

ü With  the  requirements  statements  –  expectations  around  project  content  are  de#ined.    

ü The  next  step  in  project  planning  is  brainstorming  to  create  a  list  of  all  project  tasks.    

WHAT  IS  TASK?    ü –  A  task  is  a  de#ined  piece  of  work  with  start  and  end  dates  and  is  assigned  to  a  responsible  person.    

ü –  All  tasks  include  activity,  and  they  end  in  an  event.    

Events_  Milestones  

ü Milestones  are  events    1.  That  you  wish  to  highlight  and  follow.    2.  that  have  clear  results  or  ending  points.    3.  that  are  signi#icant;  they  give  you  a  feel  for  whether  or  

not  you’re  behind  schedule.    4.  that  should  not  be  more  than  10  days  apart.    ü For  example,  a  good  milestone  might  be  to  complete  an  important  weekly  Report,  because  it  meets  all  four  criteria.    

ü A  monthly  report  could  be  a  poor  milestone  because  it  may  not  satisfy  the  last  two  criteria.    

Creating  the  Work    Breakdown  Structure  

ü Work  Breakdown  Structure  (WBS)  ü An  hierarchical  outline  (map)  that  identi#ies  the  products  and  work  elements  involved  in  a  project  

ü De#ines  the  relationship  of  the  #inal  deliverable  (the  project)  to  its  subdeliverables,  and  in  turn,  their  relationships  to  work  packages  

ü Best  suited  for  design  and  build  projects  that  have  tangible  outcomes  rather  than  process-­‐oriented  projects  

ü A  structured  grouping  of  tasks  into  categories  of  broad  tasks,  subtasks,  subsubtasks,  etc.    

Hierarchical  Breakdown  of  the  WBS  

FIGURE 4.3

How  WBS  Helps  the  Project  Manager  •  WBS  

•  Facilitates  evaluation  of  cost,  time,  and  technical  performance  of  the  organization  on  a  project  

•  Provides  management  with  information  appropriate  to  each  organizational  level  

•  Helps  in  the  development  of  the  organization  breakdown  structure  (OBS),  which  assigns  project  responsibilities  to  organizational  units  and  individuals  

•  Helps  manage  plan,  schedule,  and  budget  •  De#ines  communication  channels  and  assists  in  coordinating  the  various  project  elements  

Work  Breakdown  Structure  

FIGURE 4.4

Work  Packages  ü A  Work  Package  Is  the  Lowest  Level  of  the  WBS.  

ü It  is  output-­‐oriented  in  that  it:  

ü De#ines  work  (what)  

ü Identi#ies  time  to  complete  a  work  package  (how  long)  

ü Identi#ies  a  time-­‐phased  budget  to  complete  a  work  package  (cost)  

ü Identi#ies  resources  needed  to  complete  a  work  package  (how  much)  

ü Identi#ies  a  single  person  responsible  for  units  of  work  (who)  

Integrating  the  WBS    with  the  Organization  

ü Organizational  Breakdown  Structure  (OBS)  ü Depicts  how  the  #irm  is  organized  to  discharge  its  work  responsibility  for  a  project  ü Provides  a  framework  to  summarize  organization  work  unit  performance  

ü Identi#ies  organization  units  responsible  for  work  packages  

ü Ties  the  organizational  units  to  cost  control  accounts  

FIGURE 4.5

Integration  of  WBS  and  OBS  

Coding  the  WBS    for  the  Information  System  

ü WBS  Coding  System  ü De#ines:  

ü Levels  and  elements  of  the  WBS  ü Organization  elements  ü Work  packages  ü Budget  and  cost  information  

ü Allows  reports  to  be  consolidated  at  any    level  in  the  organization  structure  

WBS  Coding  

Process  Breakdown  Structure  •  Process-­‐Oriented  Projects  

•  Are  driven  by  performance  requirements  in  which  the  #inal  outcome  is  the  product  of  a  series  of  steps  of  phases  in  which  one  phase  affects  the  next  phase  

•  Process  Breakdown  Structure  (PBS)  •  De#ines  deliverables  as  outputs  required  to  move  to  the  next  phase    

•  Checklists  for  managing  PBS:  •  Deliverables  needed  to  exit  one  phase  and  begin  the  next  •  Quality  checkpoints  for  complete  and  accurate  deliverables  •  Sign-­‐offs  by  responsible  stakeholders  to  monitor  progress  

PBS  for  Software  Project  Development  

FIGURE 4.6

Responsibility  Matrix  Also  called  a  linear  responsibility  chart  Summarizes  the  tasks  to  be  accomplished  and  who  is  responsible  for  what  on  the  project  

u Lists  project  activities  and  participants  

u Clari#ies  critical  interfaces  between  units  and  individuals  that  need  coordination  

u Provide  an  means  for  all  participants  to  view  their  responsibilities  and  agree  on  their  assignments  

u Clari#ies  the  extent  or  type  of  authority  that  can  be  exercised  by  each  participant  

Responsibility  Matrix  A tool for clarifying organizational roles and

responsibilities § Every organizational role is clear § Each work package has an identified “owner” § No two groups think they are responsible for the

same work package §  Promotes discussion and agreement about roles,

responsibilities and organizational relationships § Clarifies who is responsible for each work package § Source of information for preparing schedule and

budget

Responsibility  Matrix  for  a  Market  Research  Project  

FIGURE 4.7

Responsibility  Matrix  for  the  Conveyor  Belt  Project  

FIGURE 4.8

Guidelines  §  What  are  the  project’s  tasks?  List  the  tasks  along  the  y-­‐axis.    §  Who’ll  be  working  on  the  project  team?  List  team  members  along  the  x-­‐axis.    §  Who’s  responsible  for  each  task?  Who’ll  participate  in  the  tasks?  Whose  approval  is  needed  for  the  tasks?  Who  plays  a  key  supportive  role?  Show  them  in  the  matrix  cells  using  the  letters  R,  P,  A,  and  S.    

Helpful  Hints:    §  This  tool  helps  empower  others  if  used  correctly.    §  Each  task  should  have  only  one  ‘R’.    § Don’t  confuse  ‘A’  and  ‘R’.  § Use  many  ‘P’s’.    

Symbols: R: Person responsible for the task, P: Person participating on the task, A: Person who approves the task, and S: Person playing a key supportive role