Projects and Programs  Luis Seabra Coelho  November 21, 2014 

Introduction  Even  basic  notions  are  sometimes  misunderstood  and,  at  large,  this  is  the  case  of  the  concepts  associated  to  projects  and  programs.  On  one  hand,  there  is  a  common  understanding that programs are somehow bigger than projects and that you start as a project  manager  and  then  naturally  continue  as  a  program  manager,  once  you’ve  proven  your  professional  value. On the other hand, some project managers are in fact managing programs  without it being explicit to her/him, the sponsor or other main stakeholders.  The  issue  about  managing  programs using the tools and the mindset for managing projects is  that  you’re  bound for trouble. This is as simple as it gets: it’s just like  using a screw driver with  nails.  In  the  end, what you need to manage  a program is not just “more and bigger” than what   you  need  to  manage  a  project:  it’s  a  different  toolset,  different  skills  and  a  different  profile  altogether.  A  nice  analogy  for  this  is  the  engineer  and  the  manager:  all  too  often  a  good  engineer is promoted to a bad manager. 

Is there a difference?  Consider  a  project  with  a  few  sub­projects.  Is  it  any  different  than  a  program  with  a  few  projects?  It  doesn’t feel  like  there  is  any  difference,  does it? But there should be differences ­  and  that’s  why  they  have  different  names  and  there  are   different  certifications  and  different  “books of knowledge”, different job titles and so on.  Well,  let’s  start  from  the  very  basics  then.  If you  take a look at the Project Management Book  of  Knowledge  (PMBoK) of  the  PMI (Project  Management  Institute),  you’ll find that they define  project there as follows:  A  project  is  a temporary endeavor undertaken to create  a unique  product, service, or result.  in PMBoK 5th Ed., page 3  This  definition  is  not  much  different  than  any  other   you  can  find.  As  for  a  program,  PMI  defines it as follows:  A  program  is  defined  as  a  group  of  related  projects,   subprograms,  and  program  activities  managed  in  a  coordinated  way  to  obtain  benefits  not  available  from  managing   them  individually.   Programs  may  include  elements  of  related  work  outside the scope of the discrete projects in the program.  in PMBoK 5th Ed., page 9 

Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho,  www.ah­ha­moments.net  1 

If  a  program   was  defined  just  as  “a  group  of  related  projects,  subprograms,  and  program  activities   manages  in  a  coordinated  way”,  then  a  project  with  some  sub­projects  and  a  program  would  be  pretty  much  the  same  thing.  But  then  they  add  2  things  to  the  program  definition:  1. To obtain benefits not available from managing them individually, and that  2. Programs  may  include  elements  of  related  work  outside  the  scope  of  the  discrete  projects in the program.  How  is  that  managing  the  whole  can  bring  benefits  not  available  from  managing  them  individually?  And  why  do  you  need  work  not  defined  in  any  of  the  projects?  In  short,  the first  “program  add  on”  refers  to  the  program’s  focus  on  the  business   benefits  and  the  second  refers  to  the  lubricant  needed  to  put  all  the  pieces  (or  projects)  running  together  smoothly  ­  not only the politics but all that the larger picture involves.  These differences are compiled on the same book and a capture follows:   

  In PMBoK 5th Ed., page 7  Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho,  www.ah­ha­moments.net  2 

We’ll  be  disregarding  portfolios altogether  as  they  are  not  the  focus  of  this paper. This is just  to corroborate that in fact projects and programs have many differences. 

Outputs and outcomes  Some  differences,  like  outputs  and  comes,  are  not  explicitly  in  the  previous  table.  But  nevertheless,  projects  are  supposed  to  produce  outputs  and  programs  are  supposed  to  produce outcomes. Let me explain what these outputs and outcomes mean.  The  difference  between  output  and  outcome  is  a  bit  like  the  difference  between hardware  and  software  (in  the  sense  of  the  joke  “hardware  is  what  you  are  able  to  hit  and  software  is  what  you  insult”).  Outputs   are  the  things  that  your  project  is  going  to  deliver:  it  can  be  a  house,  an  IT  system or  even  a  new  process  but  it  is  always  something  that  you  can pinpoint  and put your finger on it even if you can’t actually touch it. It is always the answer to “what?”.  The  outcome  answers  the  “why?”: Why do you want the house  for? Or the IT system? Or the  new process? The answers will always be more difficult to pinpoint, but:  ● You  can  have  a  house  as  an  output  because  you’re  having  a  baby  and  need  some  extra room (or because you plan to move town, or…)  ● You  can  have  an  IT  system  as  an  output  because  your  current  billing  system  has no  more  support  services  (or  because  your  current  ERP  system  doesn’t  perform   well  enough anymore, or…)  ● You  have  a new  process to  approve  invoices  because  you’re  opening  a  new  office  in  another  town  (or  because  you  need  to  plan  your  spendings more  ahead  than  you’re   doing now, or…)  At  any  rate,  the  outcomes  are  always much  larger  than  the  outputs  and  they’re  always the  reason  why  you  want  to  outputs  in the  first place: because  you’re  having a baby you need a  house  ­  that’s  your  root  cause  for  getting  a  new  house.  Keep  in  mind  that  the  outcome  is  always  somehow  larger  than  the  output:  having  a  baby  and  a  new  house  is  not  the  same  thing! But having a baby can require a new house, amongst other things. 

How much concrete does it take to make a happy home?  An  example  should make this distinction between outputs (and projects) and outcomes (and  programs).  Consider  the  following scenario: you are building a new  house for you family. What you really,  really  want  is  a  happy home  and  in  the  end  the  options  you’re  making  are  the  ones  that  you  believe  will  help  you  have  a  happy  home.  For  example,  suppose  you want a barbecue and a   large  table  on your  backyard so  you  get  the  entire  family  together  for the weekends because  you believe this will provide happy moments.  Now  your  constructor  needs  to  know  how  long  and  how  much  it will take to build your house,  he  really  doesn’t  need  to  know  what  you  plan  to  do  in  your  backyard  ­ he just needs to know  what he will have to deliver, not why you want it.  And  this  is  the  source  of  many  of  the  problems  that  arise   in  such  situations  and  it  largely  explains  why  it  is  expected  that  building  a  house  will  cost  more  than estimated. The problem  is much like answering the question: How much concrete does it take to make a happy home?  Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho,  www.ah­ha­moments.net  3 

Measuring success  One  of  the  key  differences  listed  by  the  PMI  on  the previous table is about success. Success  is  always  difficult  to  evaluate  for  any  given  project,  right?  Some  just  say  “projects  are  successful  if  at  end  the  customer is  happy”, some say that  “projects are successful if they are  OTOBOS  (on  time,  on  budget,  on  schedule)”  and  so  on.  The timeline is also important: if you  evaluate  your  project  when  you  close  the  project  you’ll  probably get different results about its  success than if you do it 3 months after you close it.  But  what is explicit on the table is that a project is successful on some criteria while a program  success  is  measured  by  its  business  fit:  if  the  program  added   business  value  then  the  program  is  successful.  Please  notice  there  isn’t  a  single  word  about  schedule,  cost or quality  regarding the program success.  So  let’s  think  about  a  project  largely  not  OTOBOS  (there  are  a  few  tens  of  public  recent  examples  of  large  projects that didn’t  finish  on  time  or  on  budget  but  I’ll  go  for an older one).  Please  consider  the  Sidney  Opera  House  for  a  moment  and  before  taking  a  look  at  the  wikipedia  try  to  answer  this:  was  the  Sidney  Opera  House  a  successful  project?  The  fact  is  that the project:  Costed 

14 times more 

Took 

10 years more 

  This  is  not  a  close  miss:  the  Sidney  Opera  House  didn’t  cost  close  to  the  initially  estimated  $7,000,000.  It costed  $102,000,000  ­  that  is over 14 times more! Now just consider this: have   you  ever  missed  project  objectives regarding  cost  or  schedule  by  this much? Do you actually  know anyone who has? I’m betting you can’t recall nothing like this…  Is  this  an  oddity?  By no  means,  no!  The  Suez  Canal  was  even  worst than  the Sidney Opera  House.   The  Concorde  was  pretty much  as  bad.  And  for  any  of  these,  you  can  easily  double  check  them  online.  The thing is: if you’re missing your current project objectives by this much,  you will probably be fired, right? So why weren’t these projects canceled?  How  can  this  happen to a project? Well, if you ask me, my answer  is:  these were not projects,  they  were programs. Why is the difference key? Because in a program your focus is not about  being  OTOBOS,  your  focus  is  on the  business  return.  And,  as  far  I  know, the  Sidney  Opera  House  was,  and  still  is,  largely  a  business  success  ­  and  also  a  landmark  and  a  national  symbol.  For   a  program,  success  is  linked  to  the  business  benefits  that  it  brings   ­   and  that  is  a  big  difference. 

Required skills  Now,  with  all  the  information  provided, do  you  still  think  that  a  project  manager’s  career path  should  make  him/her  a  program  manager?  Are  the  required  skills  and  knowledge  of  a  program  manager  a  natural  development  of  the  skills  and  knowledge  of  a project  manager?  Are program managers just project managers that are really, really good?  Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho,  www.ah­ha­moments.net  4 

Provided  the  given  context,  the  answer  to  all  these  questions  is  always  no. The  scenario  is  similar  to  the  scenario  where  you  have  a  really  good  engineer  that  you  want  to  promote  and  so  you  give   him  a  management  position.  In  general,  this   a  a  great  way  to  turn  a  good  engineer into a bad manager: the skills required are just different.  But  what  exactly  are the  skills  required?  Well,  it’s  a melting pot, really. But a  project manager  needs  more focusing than awareness, more detail than overview, more technical than political  skills, and so on:    Projects 

Programs 

Focus 

Awareness 

Detail 

Overview 

Technical 

Political 

Tactical 

Strategic 

Objective driven 

Business fitness 

Analysis 

Synthesis 

What 

Why 

  I  insist  than  all  these  skills,  if  you can  classify  them as skills, are required  both by project and  program  managers.  But  there’s  no  doubt  in  my  mind  that  a  project  manager  needs  more  analytical   skills  than  synthesis  skills  and  so  on.  Bottom  line  is  that  the   balance  I  see  as  required is precisely as the above table. 

Take aways  Don’t stand taller than what you are  There’s  this  Simpsons  episode  where  Mr  Burns  checks  himself  on  the  mirror  and  sees  a  young  man,  tall,  blonde  and  musculated.   There’s   this  ad   on  anorexia  where  you  see  the  reflection  of  a  chubby  young  woman  checking   herself   on  the  mirror  but,  when  finally  the  camera  is  set  on  her, you see a skinny young woman (really just bones with skin around). We  have this tendency to see things as you want them to be ­ and not what they are. In a way,    we’re all anorectic Mr Burns    We   project   managers  tend  to  find  that  project  management  should  be  a  requirement  for  CEOs.  We  like  to  think  that  our  career path  may  start as a systems engineer, it  may takes us  to   be  a   project  manager,  a  program  manager  and  then   we’ll  be  a  CEO  on  some company.  And in some cases, it does.  Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho,  www.ah­ha­moments.net  5 

But  I’m  sorry  to break it to you, this is not the general case. Of course some  project managers  will  be   outstanding  program  managers,  but  that  will   never  be  the  general  case.  There’s  a  Portuguese  saying  that  states  that  “each  monkey  has  its  tree  brunch”  meaning  you  should  now your place and act accordingly. 

Focus on what you should, not what you want  Just   because  you’re  told  you  have  a  project  to  manage  that  doesn’t  mean  that  it’s  true.  Sometimes  what  you  really  need  to manage  is  a  program  ­  and  yes,  the  same  thing  can  be  both  at  the  same  time,  just  like  building  a  house   is  a  program  to  you  and  a project  for  your  constructor.  Recognizing what  you  should  really  be  managing  is  the  first  step  to success: at least you get  to choose the right tools. Failing to do this would result on using a screw driver for nails. 

There is such a thing as a “2 weeks long program with a single project”  If  nothing  else,  I  really  hope that  after reading this you’ll let go of the idea that “a program is  a  set  of  2  or  more  projects”.  In fact, programs that consist of just one project are more common  that what you might expect.  Programs  are  always   somehow  larger/deeper  than  projects  but   they  can  be  just  as  short  in  time.   I  have  managed  quite  a  few  really  short  programs,  some  as  short   as  2  weeks.  The  notion  that  a  program  is  larger  than  a  project  is  still  valid  as  a  program  is  never  about  delivering some output, a program is about getting some output to work in your organization in  order to get some benefit.  So  next  time  someone  knocks  at  your  door  and  says  “I’ve  got  a   project  for  you”  don’t  start  asking  for  its  requirements.  Before  getting  to  that,  find  out  what  exactly  are you  expected  to  manage: is it a project? Or is it a program? 

Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho,  www.ah­ha­moments.net  6 

Projects and Programs.pdf

Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho,. www.ahhamoments.net. 3. Page 3 of 6. Projects and Programs.pdf.

308KB Sizes 1 Downloads 98 Views

Recommend Documents

MATLAB Projects - IEEE Projects
... Human Action Recognition with Multimodal Feature Selection and Fusion. ... Medical Image Segmentation by Combining Graph Cuts and Oriented Active.

INEQUALITY AND INEFFICIENCY IN JOINT PROJECTS*
Dec 8, 2004 - complemented by similar efforts elsewhere in the network for the ... perfect equality of shares maximises social surplus over all share vectors.

201 crochet motifs blocks projects and ideas
Book 201 crochet motifs blocks projects and ideas pdf free download

Projects, Tools and MiniGrants -
Sep 26, 2016 - community enhancement projects such as planting trees and flowers, ... Clarke Central High School by planting bulbs around the sides of.

PDF and EPuB Arduino and Kinect Projects
Page 1. Arduino and Kinect Projects: Design, Build, Blow Their Minds (Technology in ..... Build your own set of responsive, gesture controllable LED lamps.