What’s a Project? AD642

Copyright 2011 John Wiley & Sons, Inc. Why the Emphasis on Project Management? 2 ❑ Many tasks do not fit neatly into business-as-usual ❑ Organizations need to assign responsibility and authority for the achievement of their goals

Copyright 2011 John Wiley & Sons, Inc. Characteristics of Projects 3 ❑ Unique ❑ Specific deliverables ❑ Specific due date

Copyright 2011 John Wiley & Sons, Inc. Other Common Characteristics of Projects 4 ❑ Multidisciplinary ❑ Complex ❑ Often involve conflicts ❑ Part of programs

Definition of a Project “A project is a temporary endeavor undertaken to create a unique product or service.” Project Management Institute, 2007

Definition of Project Management 6 “The application of knowledge, skills, tools, and techniques to a broad range of activities in order to meet the requirements of a particular project.” Project Management Institute 2007

Why Do We Do Projects?

The Triple Constraint

A more realistic view

And even more so…

Copyright 2011 John Wiley & Sons, Inc. The Life Cycle of Projects 11 ❑ All organisms have a life cycle (i.e., they are born, grow, wane, and die) … and so do projects ❑ Some projects follow an S-shaped curve … they start slowly, develop momentum, and then finish slowly ❑ Other project follow a J-shaped curve … they start slowly, proceed slowly, and then finish rapidly

PMBOK Process Groups ● PMI describes the project lifecycle in five groups ● Initiating ● Planning ● Executing ● Monitoring and controlling ● Closing

Initiating ● Defining a new project ● Developing charter ● Identifying stakeholders ● Obtaining authorization

Planning ● Scope ● Requirements analysis ● Work Breakdown Structure ● Define activities and milestones ● Estimate resources and duration ● Develop project schedule and budget

Executing ● Manage the project ● Perform quality assurance ● Manage stakeholders ● Manage team

Monitoring and Controlling ● Change management ● Monitor actuals and baseline ● Scope ● Budget ● Schedule ● Risk management

Closing ● Obtain acceptance ● Post-project audit ● Document and archive

Initiating a project: SOW ● Projects typically start with a Statement of Work ● Describes the business need ● Has fairly broad scope ● Overall strategic plan ● SOW is often part of the response to an RFP when a third party is to be involved

Business case ● Part of the SOW ● The justification for the project ● Might contain competitive analysis, high-level ROI, opportunities for market expansion, regulatory requirements, and more

SOW signoff ● A signed SOW is the document that kicks off a project ● In third-party arrangements (such as consulting) it is a contract ● Information from the SOW is used to develop the Project Charter

Time for Meetings! ● Once a SOW has been signed, the project formally exists ● If a PM hasn’t been involved yet, now is the time ● Initial meetings are to help the PM understand the project, the players, and the resources ● No project plan yet ● A kickoff meeting introduces all the players

Initial Project Coordination and the Project Charter ● Early meetings are used to decide on participating in the project ● Used to “flesh out” the nature of the project ● Outcomes include: ● Technical scope ● Areas of responsibility ● Delivery dates or budgets ● Risk management group

Outside Clients ● When it is for outside clients, specifications cannot be changed without the client’s permission ● Client may place budget constraints on the project ● May be competing against other firms

Project Charter Elements ● Purpose ● Objectives ● Overview ● Schedules ● Resources ● Personnel ● Risk management plans ● Evaluation methods

Cut the Red Wire… ● But first… ● The SOW might (and often does) contain language that provides for a period of analysis and prototyping ● It isn’t always clear what approach should be taken to solve a problem ● It’d be a waste of time to plan a project and then realize that the approach was wrong ● More than one prototype might be developed 25

…After Cutting the Blue Wire ● Even before the prototype there might be a period of high-level requirements gathering ● These are often two-pronged ● Business requirements ● Technical requirements ● The requirements analysis drives the prototyping phase, which leads to a proposal, which THEN can be developed into a more robust project plan ● In an RFP/RFQ environment, the SOW might cover only work to this point, and competing groups would present proposals to win the work 26

Starting the Project Plan: The WBS ● Once the high-level requirements and prettying are complete we can start to think about the work ● From a PM perspective we need to understand ● What is to be done ● When it is to be started and finished ● Who is going to do it

WBS Constraints ● Some activities must be done sequentially ● Some activities may be done simultaneously ● Many things must happen when and how they are supposed to happen ● Each detail is uncertain and subjected to risk

Hierarchical Planning ● Major tasks are listed ● Each major task is broken down into detail ● This continues until all the activities to be completed are listed ● Need to know which activities “depend on” other activities ● There’s no time or resource against these yet

The Work Breakdown Structure (WBS) ● A hierarchical planning process ● Breaks tasks down into successively finer levels of detail ● Continues until all meaningful tasks or work packages have been identified ● These make tracking the work easier ● Need separate budget/schedule for each task or work package

A Visual WBS

Steps to Create a WBS 1. List the task breakdown in successive levels 2. Identify data for each work package 3. Review work package information 4. Cost the work packages 5. Schedule the work packages 6. Continually examine actual resource use 7. Continually examine schedule

Human Resources ● Useful to create a table that shows staff needed to execute WBS tasks ● One approach is a organizational breakdown structure ● Organizational units responsible for each WBS element ● Who must approve changes of scope ● Who must be notified of progress ● WBS and OBS may not be identical

The Responsibility (RACI) Matrix ● Another approach is the Responsible, Accountable, Consult, Inform (RACI) matrix ● Also known as a responsibility matrix, a linear responsibility chart, an assignment matrix, a responsibility assignment matrix ● Shows critical interfaces ● Keeps track of who must approve what and who must be notified

Sample RACI Matrix

Agile Project Planning and Management ● When scope cannot be determined in advance, traditional planning does not work ● Agile project management was developed to deal with this problem in IT ● Small teams are located at a single site ● Entire team collaborates ● Team deals with one requirement at-a-time with the scope frozen

Interface Coordination Through Integration Management ● Managing a project requires a great deal of coordination ● Projects typically draw from many parts of the organization as well as outsiders ● All of these must be coordinated ● The RACI matrix helps the project manager accomplish this

Bottom line ● For a PM to succeed, it’s crucial for them to be involved as early as possible in the project lifecycle ● The reality is that PMs are often brought in well after the WBS and scheduling is complete ● It’s up to the PM to carefully balance the triple or quad constraints with the expectations of the stakeholders