Tathagat Varma

Tathagat Varma Session 9/12: 14-Jul-2010

  Goals: what are the objectives of this phase ?   Entry Criteria: what all conditions must be fulfilled

before the project could enter this phase ?   Inputs: what all management and technical inputs are

required in this phase ?   Activities: what key activities are performed in this

phase ?   Tools & Techniques: what are the key tools and

techniques used in this phase ?   Actors: who are the key project personnel involved in

this phase and what are their respective roles and responsibilities ?

  Outputs: what are the outputs of this phase ?   Exit Criteria: what conditions must be satisfied in

order for the project to exit out of this phase and proceed further ?

  Identify, document and get agreement on  What is required ?  When is it required ?  How much time, budget and resources are

available ?  Who are the key stakeholders ?  What are the key risks and assumptions ?  What are the project cost / benefits ?

  Prepare Project Charter   Get GO / NO GO approval for project

  Project initiation verifies that your project is required, feasible, and secures agreement by all parties. Your objectives in project initiation are:   Confirming that your project has an acceptable Business

Case.   Agreeing whether or not your project has sufficient

justification to proceed.   Ensuring that your project has a firm and accepted

foundation prior to commencement of work.   Ensuring that there is project ownership at stakeholder

and management levels.   Agreeing to the commitment of resources for at least the

initial stages of your project.   Ensuring that a workable plan is in place so that the

investment of time and materials is effectively employed.   Taking account of risks to your project's success.

  May not be very strictly defined in all cases   PRINCE2 talks of a ‘Project Brief’ to be

available   Different organizations might have different

standards, but might require some form of  LOI / RFP / SOW from Customer o Several pieces of information might be missing !

  PM assigned (even if temporarily)  Effort approval during Initiation Phase

  Project SoW / RFP / LOI   Business Case   Contract   Enterprise Environmental Factors

 E.g. Government or industry standards, organizational infrastructure, marketplace conditions, etc.

  Organizational Process Assets

  Develop Business Case   Feasibility Study / Proof of Concept (as

required)   Develop Project Charter   Stakeholders Analysis   Identify Project Constraints   Identify Assumptions   Appoint Project Team   Setup Project Office   Perform Phase Review

  A Business Case expands on the original project description or brief. It offers a detailed outline and analysis of the anticipated business benefits in terms of strategy, and materials and resource costs. The Business Case also contains detailed description and analysis of the project approach and identified risks

  The business case is created as a result of one or more of the following:   Market demand   Organizational need   Customer request   Technological advance   Legal requirement   Ecological impacts   Social needs

  Process of developing a document that formally authorizes a project or a phase and documenting initial requirements that satisfy the stakeholder’s needs and expectations.

  In multi-phase projects, this process is used to validate or refine the decisions made during the previous iteration of similar phase.

  The approved project charter formally initiates a project

  A project manager is identified and assigned as early in the project as is feasible, preferably while the project charter is being developed and always prior to the start of planning.

  Projects are authorized by someone external to the project such as a sponsor, PMO or portfolio steering committee.

  Documents the business needs, current understanding of the customer’s needs, and the new product, service or result that it is intended to satisfy, such as:   Project purpose or justification   Measurable project objectives and related success criteria   High-level requirements   High-level project description   High-level risks   Summary milestone schedule   Summary budget   Project approval requirements – what constitutes project

success, who decides the project is successful, and who signs off on the project

  Assigned project manager, responsibility and authority level   Name and authority of sponsor or other persons authorizing

the project charter

  Develop Business Case   Undertake Feasibility Study   Establish Project Charter   Identify Stakeholders   Appoint Project Team   Setup Project Office   Perform Phase Review

  Recommend reading: Project Clarity through Stakeholder Analysis

  Stakeholder Analysis   Identify Stakeholders   Identify Stakeholders’ interest, impact level, and

relative priority  Assess Stakeholders for importance and influence  Outline Assumptions and Risks  Define Stakeholder Participation

  Stakeholders are anyone who has an interest in the project. Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. They may also exert influence over the project’s objectives and outcomes. Project stakeholders are those entities within or outside an organization which:   Sponsor a project or,   Have an interest or a gain upon a successful completion of a project.   May have a positive or negative influence in the Project Completion.

  Examples   Customer   Government   Society

o  Directly affected citizens o  NGOs, Environmental Activities, PETA, etc.

  Project Sponsor   Project Manager   Project Team   Program Steering Team

  A stakeholder is often incorrectly believed to be a person who is providing financial backing for a specific function or project to be completed. In actual fact a stakeholder is a more widely ranging term.   They can be individual persons such as customers or sponsors to whole

groups such as performing organizations and the public.   Anyone who is actively involved with the project may be regarded as a

stakeholder, as well as anyone who may be positively or negatively affected by the project’s outcome.

  Project management personnel may be regarded as stakeholders as well seeing as they are directly involved with the project and are likely to be affected by the project’s conclusion.

  A stakeholder is often a random and unforeseen variable when it comes to project management. They can be divided up into two categories, positive stakeholders and negative stakeholders. o  A positive stakeholder will benefit from the successful completion of a project in

some way, either by increasing their own quality of life or by profiting financially. o  Negative stakeholders will be affected negatively by a successfully completed

project and will work to have the project slowed or scrapped altogether. An example of this would be an environmentalist faction who opposes the decisions of project management to place a housing development into an area with a high concentration of natural plants and wildlife.

  The importance of stakeholder management is to support an organization in achieving its strategic objectives by interpreting and influencing both the external and internal environments and by creating positive relationships with stakeholders through the appropriate management of their expectations and agreed objectives. Stakeholder Management is a process and control that must be planned and guided by underlying Principles.

  Stakeholder Management, within business or projects, prepares a strategy utilising information (or intelligence) gathered during the following common processes:   Stakeholder Identification - Interested parties either internal or external to organisation/project. A

stakeholder map is helpful for identifying the stakeholders[1].   Stakeholder Analysis - Recognise and acknowledge stakeholder's needs, concerns, wants, authority,

common relationships, interfaces and align this information within the Stakeholder Matrix.   Stakeholder Matrix - Positioning stakeholders according to the level of influence, impact or enhancement

they may provide to the business or it's projects.   Stakeholder Engagement - Different to Stakeholder Management in that the engagement does not seek to

develop the project/business requirements, solution or problem creation, or establishing roles and responsibilities. It is primarily focused at getting to know and understand each other, at the Executive level. Engagement is the opportunity to discuss and agree expectations of communication and, primarily, agree a set of Values and Principles that all stakeholders will abide by.

  Communicating Information - Expectations are established and agreed for the manner in which communications are managed between stakeholders - who receives communications, when, how and to what level of detail. Protocols may be established including security and confidentiality classifications.)

  Power/interest grid: grouping the stakeholders based on their level of authority (“power”) and their level of concern (“interest”) regarding the project outcomes

  Power/influence grid: grouping level of authority (“power”) vs. their active involvement (“influence”)

  Influence/impact grid: grouping level of active involvement (“influence”) and their ability to effect changes to project’s planning or execution (“impact”)

  Salience model: describing classes of stakeholders based on their power (ability to impose their will), urgency (need for immediate attention), and legitimacy (their involvement is appropriate)

  Expert judgment  Often used to assess the inputs used to develop the

project charter   Such judgment and expertise is applied to any

technical and management details during this process.

  Such expertise is provided by any group or individual with specialized knowledge or training, and is available from many sources, including other units within the organization, consultants, stakeholders, customers, sponsors, professional and technical associations, industry groups, subject matter experts and PMOs

  Customer   Issues LOI / RFP/ SOW  Releases Business Case  Approves Contract  Clarifies queries from PM

  Senior Management   Identifies and authorizes PM and Project Charter

  Project Manager  Translates LOI / RFP / SOW and other inputs

(Business Case, Contract) into Project Charter   Perform Stakeholder analysis   Identify risks, assumptions, constraints

  Project Charter   GO / No GO Decision

  Approved Project Charter (in case of a GO decision)

  (from Successful Project Management, Trevor Young)

  Background   Context   Approach   Objectives   Constraints

  Why is the project necessary ?   What is the overall problem or opportunity being

addressed ?   Has the current situation been explored and

understood ?   Has a statement of requirements been derived from

the needs list ?   Is this an old problem ?   How long as it existed ?   Who wants to change things ?   Have previous attempts (projects) been made to

address this problem ?   What information exists about past attempts to fix

things ?   What assumptions have been made ?

  Is the project in line with current organizational strategy

  Will the project form past of a chain of linked projects or a program ?

  What is the timescale of the project ?   Is there a business critical date to get the

results ?   Will the results be of value to another

customer or part of the organization ?

  Have all the needs been identified and analysed ?   Has a statement of requirements been agreed ?   Are there predetermined solutions ?   What are these solutions ?   Is there a best option and a least worst option ?   Is there enough time to explore more than one

option ?   Are there known checkpoints for project review

other than the phase gates ?   What specialized skills are expected to be

required for the project work ?

  Are the primary deliverables known ?   What does the customer need, what and wish to get from the

project ?   Can these deliverables be clearly defined and specified ?   Does the end user agree with these deliverables ?   What does the end user need, want and wish to get from the

project ?   What are the perceived project benefits ?   Have the benefits been quantified ?   Has a project budget been fixed?   Is capital investment necessary ?   Has a capital expenditure request been initiated ?   Is time used for project work to be measured and costed ?   Has were the costs derived ?   Has a cost/benefit analysis been carried out ?   Has a financial appraisal been carried out to establish payback ?

  Have all project constraints been identified ?   Is there a time constraint for all or part of the deliverables list ?   Are there any financial constraints, for example manufacturer cost,

project cost ?   Is there a financial payback constraint ?   Are there any known technical constraints, for example new or untried

technology ?   Are there known resource constraints ?   Is the project team to be located together on one site ?   Is part of the work to be carried out at another site ?   Is part of the work to be carried out by sub-contractors or suppliers ?   Is there a preferred list of approved sub-contractors and suppliers ?   What existing specs and standards are to be applied to the project ?   Are there any legal constraints that might affect the project work ?   Are there any security implications ?   Are there any operational constraints, for example access to production

area / test equipments etc ?   Are the any health and safety requirements ?

  Perhaps the most important of all activities!

  If you are planning for a year, sow rice; if you are planning for a decade, plant trees; if you are planning for a lifetime, educate people - Chinese Proverb

  A man who does not plan long ahead will find trouble at his door – Confucius (551-479 BC)

  Plan for what is difficult while it is easy, do what is great while it is small. The difficult things in this world must be done while they are easy, the greatest things in the world must be done while they are still small. For this reason sages never do what is great, and this is why they achieve greatness - Sun Tzu, Chinese General, The Art of War, 400 BC

  Before beginning, plan carefully - Marcus Tulius Cicero, Roman statesman and orator (106-43 BC)

  Long-range planning works best in the short term - Euripides, poet (480-406 AD)   Forewarned, forearmed; to be prepared is half the victory - Miguel de Cervantes

Saavedra, Spanish writer and author of Don Quixote (1547-1616).   By failing to prepare, you are preparing to fail - Benjamin Franklin   In preparing for battle I have always found that plans are useless, but planning is

indispensable - Dwight D. Eisenhower, general and president (1890 - 1969)   A plan which succeeds is bold, one which fails is reckless - General Karl von

Clauswitz   Always plan ahead. It wasn't raining when Noah built the ark - Richard Cushing,

novelist

  Whatever failures I have known, whatever errors I have committed, whatever follies I have witnessed in private and public life have been the consequence of action without thought - Bernard Baruch,  stock broker, advisor to presidents Woodrow Wilson, Harry S. Truman, (1870-1965)

  Those who plan do better than those who do not plan even thou they rarely stick to their plan - Winston Churchill, British Prime Minister

  In the space of two days I had evolved two plans, wholly distinct, both of which were equally feasible. The point I am trying to bring out is that one does not plan and then try to make circumstances fit those plans. One tries to make plans fit the circumstances - General George Patton (1947).

  A good plan today is better that a perfect plan tomorrow - George S. Patton   Planning is a process of choosing among those many options. If we do not

choose to plan, then we choose to have others plan for us - Richard I. Winwood

  Plans are only good intentions unless they immediately degenerate into hard work - Peter Drucker

  Prediction is difficult, especially about the future - Yogi Berra, baseball catcher (1925-present)

  It's a bad plan that admits of no modification - Publilius Syrus, Roman slave and poet (circa 100 BC)

  Observe always that everything is the result of change, and get used to thinking that there is nothing Nature loves so well as to change existing forms and make new ones of them - Marcus Aurelius, emperor of Rome (121-180 AD)

  It is not the strongest of the species that survive, not the most intelligent, but the one most responsive to change - Charles Darwin, scientist

  A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody directly or indirectly impacted by the project.

  As a first step it is important to identify the stakeholders in your project. It is not always easy to identify the stakeholders of a project, particularly those impacted indirectly. Examples of stakeholders are:   The project sponsor   The customer who receives the deliverables   The users of the project outputs   The project manager and project team

  Once you understand who the stakeholders are, the next step is to establish their needs. The best way to do this is by conducting stakeholder interviews. Take time during the interviews to draw out the true needs that create real benefits. Often stakeholders will talk about needs that aren't relevant and don't deliver benefits. These can be recorded and set as a low priority.

  The next step once you have conducted all the interviews and have a comprehensive list of needs is to prioritise them. From the prioritised list create a set of goals that can be easily measured. A technique for doing this is to review them against the SMART principle. This way it will be easy to know when a goal has been achieved.

  Once you have established a clear set of goals they should be recorded in the project plan. It can be useful to also include the needs and expectations of your stakeholders.

  This is the most difficult part of the planning process completed. It's time to move on and look at the project deliverables.

  Using the goals you have defined in step 1, create a list of things the project needs to deliver in order to meet those goals. Specify when and how each item must be delivered.

  Add the deliverables to the project plan with an estimated delivery date. More accurate delivery dates will be established during the scheduling phase, which is next

  Create a list of tasks that need to be carried out for each deliverable identified in step 2. For each task identify the following:   The amount of effort (hours or days) required to complete the task   The resource who will carryout the task

  Once you have established the amount of effort for each task, you can workout the effort required for each deliverable and an accurate delivery date. Update your deliverables section with the more accurate delivery dates.

  A common problem discovered at this point is when a project has an imposed delivery deadline from the sponsor that is not realistic based on your estimates. If you discover that this is the case you must contact the sponsor immediately. The options you have in this situation are:   Renegotiate the deadline (project delay)   Employ additional resources (increased cost)   Reduce the scope of the project (less delivered)

  Use the project schedule to justify pursuing one of these options.

  Quality Plan   Human Resources Plan   Communication Plan   Risk Management Plan

  Based on available inputs, information, constraints, assumptions from customer, organization and key stakeholders   Prepare a Project Management Plan that will act as a

three-way contract between Customer, Senior Management, and Project Team on how the project will be executed to achieve its set objectives

  Identify the resources required to meet project objectives   Identify suitable risk mitigation strategies to minimize

(ideally eliminate) risks   Establish a mechanism to handle subsequent changes to

project scope, schedule or cost   Based on actual performance of the project, identify how

best to meet original or revised project objectives

  Approved Business Case   Approved Project Charter

  Project Charter   Environmental Factors   Organizational Process Assets

  Develop Project Management Plan   Collect Requirements   Define Scope   Create WBS,   Define Activities,   Sequence Activities   Estimate Activity Resources   Estimate Activity Durations   Develop Schedule

  Estimate Costs   Determine Budget   Plan Quality   Develop Human Resources Plan   Plan Communications   Plan Risk Management,   Identify Risks,   Perform Qualitative Risk Analysis,   Perform Quantitative Risk Analysis,   Plan Risk Responses   Plan Procurements

  Expert Judgment   WBS   Risk Management   Estimation techniques

  Project Manager  Collate and validate all inputs and prepare Project

Management Plan

  Project Team   Participate in project planning activities and give

appropriate commitments

  Senior Management  Approve Project funding and resources as required

  Customer  Approve Project Management Plan

  Project Management Plan   Subsidiary Plans

o  Scope Management Plan o  Requirements Management Plan o  Schedule Management Plan o  Cost Management Plan o  Quality Management Plan o  Process Improvement Plan o  Human Resources Plan o  Communications Management Plan o  Risk Management Plan o  Procurement Management Plan

  Project Baselines   Schedule Baseline   Cost Baseline   Scope Baseline

  Approved Project Management Plan

  Includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully  Collecting requirements  Defining scope  Create WBS  Verify Scope  Control Scope

  Process of defining and documenting stakeholder’s needs to meet the project objectives.  Requirements include the quantified and

documented needs and expectations of the sponsor, customer and other stakeholders

  Project requirements can include business requirements, project management requirements, delivery requirements, etc.

  Product requirements can include information on technical requirements, security requirements, performance requirements, etc.

  Interviews   Focus Groups   Facilitated Workshop   Group creativity techniques   Group decision making techniques   Questionnaires and surveys   Observations   Prototypes

  An interview is a formal or informal approach to discover information from stakeholders by talking to them directly.

  It is typically performed by asking prepared and spontaneous questions and recording the responses.

  Interviews are typically conducted one on one, but may involve multiple interviewers or multiple interviewees

  Focus groups bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service or result

  A trained moderator guides the group through an interactive discussion, designed to be more conversational than a one-on-one interview

  Requirements workshops are focused sessions that bring key cross-functional stakeholders together to define product requirements.

  Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. Because of their interactive group nature, well facilitated sessions can build trust, foster relationship, and improve communication among the participants which can lead to increased stakeholder consensus.

  Another benefit is that issues can be discovered and resolved more quickly than in individual sessions

  Several group activities can be organized to identify project and product requirements, e.g.:   Brainstorming: a technique used to generate and collect

multiple ideas related to project and product requirements   Nominal group technique: this technique enhances

brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization

  The Delphi technique: a selected group of experts answers questionnaires and provides feedback regarding the responses from each round of requirements gathering. The responses are only available to the facilitator to maintain anonymity

  Idea/mind mapping: ideas created through individual brainstorming are consolidated into a single map to reflect commonality and differences in understanding, and generate new ideas

  Affinity diagrams: allows large numbers of ideas to be sorted into groups for review and analysis

  Group decision making is an assessment process of multiple alternatives with an expected outcome in the form of future actions resolution.

  Can be used to generate, classify, and prioritize product requirements, e.g:  Unanimity: everyone agrees on a single course of

action  Majority: support from >50% members of the group  Plurality: largest block in a group decides even if a

majority is not achieved  Dictatorship: one individual makes decision for the

group

  They are written set of questions designed to quickly accumulate information from a wide number of respondents.

  They are most appropriate with broad audiences, when quick turnaround is needed, and where statistical analysis is appropriate.

  Observations provide a direct way of viewing individuals in their environment and how they perform their jobs or tasks and carry out processes.

  It is particularly helpful for detailed processes when the people that use the product have difficult or are reluctant to articulate their requirements.

  Also called ‘job shadowing’, is usually done externally by the observer viewing the user performing his or her job. It can also be done by a ‘participant observer’ who actually performed a process or procedure to experience how it is done to uncover hidden requirements

  Prototyping is a method of obtaining early feedback by providing a working model of the expected product before actually building it.   Prototypes are tangible, so they allow stakeholders to

experiment with a model of heir final product rather than only discuss abstract representations of their requirements.

  Prototypes support the concept of ‘progressive elaboration’ because they are used in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision.

  When enough feedback cycles have been performed, the requirements obtained from the prototype are sufficiently complete to move to a design or build phase

  Business need or opportunity to be seized, describing the limitations of the current situation and why the project has been undertaken

  Business and project objectives or traceability   Function requirements, describing business

processes, information and interaction with the product, as appropriate which can be documented textually in a requirement list, in models, or both

  Non-functional requirements (NFRs) such as level of service, performance, safety, security, compliance, supportability, retention/purge, etc.

  Quality requirements   Acceptance criteria   Business rules stating the guiding principles

of the organization   Impacts to other organizational areas, such as

the call centre, sales force, etc.   Impacts to other entities inside or outside the

performing organization   Support and training requirements   Requirements assumptions and constraints

  RTM is a table that links requirements to their origin and traces them throughout the project lifecycle. It helps ensure that each requirement adds business value by linking it to the business and project objectives.

  It provides a means to track requirements throughout the project lifecycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project.

  Finally, it provides a structure for managing changes to the product scope

  Refers to a portion of a total project management plan that is used by the project management team to organize a project into manageable objectives and create a blueprint by which the steps leading to the completion of a project are obtained.

  The Work Breakdown Structure can be thought of like an outline of the project and like an outline, becomes more detailed under the subheadings or work packages. The whole project is defined by the Work Breakdown Structure, with the work packages fitting together at the completion of the project to complete the whole.

  The work packages are individual steps or portions of the task that must be completed in order to achieve the project management goal.

  It allows for several different teams to work simultaneously on separate components of a project. This outline applies to any project where a good or service must be presented to the client in timely manner. These goods or services are called the deliverables, and can be either internal or external. Other terms that are related are work package, control account, contract work breakdown structure, and project summary work breakdown structure.

  Decomposition is the subdivision of project deliverables into smaller, more manageable components until the work and deliverables are defined to the work package level.

  The work package level is the lowest level in the WBS, and is the point at which the cost and activity durations for the work can be reliably estimated and managed. The level of detail for work packages will vary with the size and complexity of the project.

  Decomposition may not be possible for a deliverable or subproject that will be accomplished far into the future. The project management team usually waits until the deliverable or subproject is clarified so that details of the WBS can be developed. This technique is sometimes referred to as rolling-wave planning.

  A project network is a graph (flow chart) depicting the sequence in which a project's terminal elements are to be completed by showing terminal elements and their dduct breakdown structure show the "part-whole" relations. In contrast, the project network shows the "before-after" relations.

  The most popular form of project network is activity on node, the other one is activity on arrow.

  The condition for a valid project network is that it doesn't contain any circular references.

  Project dependencies can also be depicted by a predecessor table. Although such a form is very inconvenient for human analysis, project management software often offers such a view for data entry.

  PDM is used in Critical Path Methodology (CPM) for constructing a project schedule network diagram that uses boxes (“nodes”) to represent activities and connects them with arrows that show the logical relationships that exist between them

  Also called Activity-on-Node (AON) and is the method used by most project management software packages

  Includes   Finish to Start (FS) – most commonly used   Start to Start (SS)   Finish to Finish (FF)   Start to Finish (SF) – rarely used

  http://blogs.msdn.com/b/project/archive/2008/07/29/back-to-basics-understanding-task-dependencies.aspx

  This is the most common type of dependency and is the default type of dependency that Project uses. In a finish-to-start dependency, the second task in the relationship can't begin until the first task finishes.   So, for example, if you were planning a project to make a

wedding cake, you might use a finish-to-start dependency between the "Bake cake" and "Decorate cake" tasks. When the "Bake cake" task is finished, the "Decorate cake" task begins.

  Start-to-start (SS) dependencies are used when the second task in the relationship can't begin until after the first task in the relationship begins. Start-to-start dependencies don't require that both tasks start at the same time. They simply require that the first task has begun, in order for the second task to begin.   Going back to the wedding cake example, let's say you had

planned to make the icing for the cake while the cake is baking in the oven. You can't start making the icing until the cake has started baking, so you might use a start-to-start dependency between the "Bake cake" and "Make icing" tasks.

  If one of your tasks can't finish until another one finishes, you can use a finish-to-finish (FF) dependency between them. Finish-to-finish dependencies don't require that both tasks be completed simultaneously. They simply require that the first task be finished, in order for the second task to finish. The second task can finish any time after the first task finishes.   In our wedding cake example, let's say there are some finishing

touches to the decorations that you can't finish until the cake is delivered. You can use a finish-to-finish dependency between the "Decorate cake" and "Deliver cake" tasks. When the "Decorate cake" task is finished, then the "Deliver cake" task can be completed.

  Finally, the start-to-finish (SF) dependency is a little tricky. When you use this type of dependency, you are saying that the second task in the relationship can't finish until the first task starts. However, the second task can finish any time after the first task starts.   Going back to our wedding cake example, let's say you have a

task for billing the customer. It begins when the customer requests the cake, but it can't be completed until after the cake delivery has begun. You can use a start-to-finish dependency between the "Deliver cake" and "Bill customer" tasks, so that when the "Deliver cake" task has begun, it is okay for the "Bill customer" task to finish.

  So when you put the entire plan together, with these dependencies intact, the plan might look something like this:

  Mandatory Dependencies   Discretionary Dependencies   External Dependencies

  They are contractually required or inherent in the nature of work. The project team determines which dependencies are mandatory during the process of sequencing the activities

  Often involve physical limiations   A.k.a. “hard logic”

  Project team determines which dependencies are discretionary during the process of sequencing the activities.

  they are established based on knowledge of best practices within a particular application or some unusual aspect of the project where a specific sequence is desired, even though there may be other acceptable sequences.

  A.k.a. “preferred logic”, “preferential logic”, or “soft logic”

  Project team determines which dependencies are external during the process of sequencing the activities.

  They involve a relationship between project activities and non-project activities, and are usually outside the project team’s control

  Project management team determines the dependencies that may require a lead or a lag to accurately define the logical relationships.

  The use of leads and lags should not replace schedule logic.

  A lead allow an acceleration of the successor activity

  A lag directs a delay in the successor activity

  The process of arriving at estimates to aid project planning / re-planning throughout the project lifecycle

  Estimates are estimates – they are not 100% guaranteed to be accurate, that’s why we call them estimate

  The project, or a task, still takes the same time whatever its estimate might be!

  Estimates get better with time

  An estimate is an input output mechanism that represents a method in which a project leader or project team member makes a judgment based on either previous experience or based on a compilation of information that has been gathered via various methods of information gathering is made as to the expected cost of a project in terms of either financial resources needed and/or in terms of man hours that may be needed in completion of this project. This judgment is typically determined through a careful quantitative assessment, and is traditionally applied to a modifier of sorts. Some examples of modifiers in this instance are preliminary, conceptual, feasibility, definitive, and/or order-of-magnitude.

  It is very important when providing and detailing an estimate via either a written or oral form to provide an indication of accuracy, such as a margin of error in terms of plus or minus percent that an estimate may be off.

  Approximating the size (duration and cost) and risk of a project (or phase) by looking at the project as a whole and comparing it to previously performed similar projects. The comparison may be made directly using “analogous estimating,” through an algorithm as in “parametric estimating,” or from the memory of estimating experts.

  Expert Judgment   Analogous Estimation   Parametric Estimation

  Expert Judgment is a term that refers a specifically to a technique in which judgment is made based upon a specific set of criteria and/or expertise that has been acquired in a specific knowledge area, or product area, a particular discipline, an industry, etc. This knowledge base can be provided by a member of the project team, or multiple members of the project team, or by a team leader or team leaders. However, typically expert judgment requires an expertise that is not present within the project team and, as such, it is common for an external group or person with a specific relevant skill set or knowledge base to be brought in for a consultation, Some examples of resources of expert knowledge can be stakeholders, customers, professional and technical organizations, and other miscellaneous industry groups that may provide these types of services for a small fee, or may provider them free of charge (in some cases, only free if one of the members of the project team is a dues paying member of said organization).

  Analogous estimating is a technique for estimating a variety of project parameters and measures of scale. The project parameters that can be measured include those of project cost, project budget, scope of the project, and expected project duration.

  The project measures that can be estimated using this technique can range from the size of the project, to the project weight, to the complexity. The estimates are made by comparing the current activity to that of a smaller activity that took place previously and drawing comparisons in proportion to that.

  It is frequently used to estimate the size of a particular parameter when information as to that particular parameter within the current project is limited or unavailable until a later date.

  Analogous estimating is typically a form of expert judgment that is most reliable not only when the previous activities are similar to the current activity in fact, and not just in appearance, and also is traditionally most effective when the team members preparing the estimates have the expertise necessary to accurately do so.

  An estimating technique that uses a statistical relationship between historical data and other variables (for example, square footage in construction, lines of code in software development) to calculate an estimate for activity parameters, such as scope, cost, budget, and duration.

  This technique can produce higher levels of accuracy depending upon the sophistication and the underlying data built into the model. An example for the cost parameter is multiplying the planned quantity of work to be performed by the historical cost per unit to obtain the estimated cost.

  Bottom-up estimating is an extremely helpful technique in project management as it allows for the ability to get a more refined estimate of a particular component of work. In bottom-up estimating, each task is broken down into smaller components. Then, individual estimates are developed to determine what specifically is needed to meet the requirements of each of these smaller components of the work. The estimates for the smaller individual components are then aggregated to develop a larger estimate for the entire task as a whole. In doing this, the estimate for the task as a whole is typically far more accurate, as it allows for careful consideration of each of the smaller parts of the task and then combining these carefully considered estimates rather than merely making one large estimate which typically will not as thoroughly consider all of the individual components of a task. In general, the smaller the scope, the greater the accuracy.

  Wideband Delphi Estimation

  The Delphi Technique is an essential project management technique that refers to an information gathering technique in which the opinions of those whose opinions are most valuable, traditionally industry experts, is solicited, with the ultimate hope and goal of attaining a consensus. Typically, the polling of these industry experts is done on an anonymous basis, in hopes of attaining opinions that are unfettered by fears or identifiability. The experts are presented with a series of questions in regards to the project, which is typically, but not always, presented to the expert by a third-party facilitator, in hopes of eliciting new ideas regarding specific project points. The responses from all experts are typically combined in the form of an overall summary, which is then provided to the experts for a review and for the opportunity to make further comments.

  This process typically results in consensus within a number of rounds, and this technique typically helps minimize bias, and minimizes the possibility that any one person can have too much influence on the outcomes.

  Activity resource estimating is a process in which the project team carefully compiles a thorough listing of the resources that will be needed in completing a project. There are six inputs that are to be used in the process of activity resource estimating. Those six inputs are the activity list, the activity attributes, the organizational process assets, the enterprise environmental factors, and project management plan, and the resource availability. There are a number of tools that can also be utilized in most effectively estimating the required activity resources. Those tools include expert judgment, a complete alternatives analysis, the use of published estimating data, project management software, and the use of bottom-up estimating. The resulting outputs from this process include activity resource requirements, activity attributes updates, requested changes, a resource breakdown structure, and the development of a resource calendar. The successful utilization of activity resource estimates will help assure that enough resources are acquired without waste and excessive expenditure.

  Activity duration estimating represents the act of quantifying the amount of time that it is anticipated the activity will take to complete. This phase of the project, that which consists of the estimating of the amount of time needed to complete all individual schedule activities, typically and traditionally takes place before a project is kicked off, during the conception phase, however, it is possible for the actual activity duration estimating period to take place later, perhaps close to or even slightly after the project has officially kicked off, however, even in those cases a draft or preliminary estimation has typically been made. Estimations can be made in any calendar unit that seems appropriate, such as months, weeks, days, etc., the entirety of the activity duration estimate can be further broken down into subparts or milestones at which certain elements, or deliverables, of the activity are to have been completed in final or draft form.

  In project management, top-down planning gives senior management control of the decision making process. Top-level managers are often reluctant to accept advice or guidance from lower level employees. Therefore, upper management should be specific with their expectations if they want those who aren’t part of the planning process to follow the plan. Often this type of planning, which can invoke fear or rely on incentives, creates problems with motivation and moral.

  Some critics might hold that using top down planning in project management is not taking full advantage of talented employees who could have much to offer the project. On the other hand, top down planning allows for the division of a project into steps which can be studied and tasks properly assigned.

  With bottom-up planning, a greater number of employees are involved, each with a specialized area of expertise. Team members work together and and take their plans to the next higher level until reaching the senior management level for approval.

  Advantages to bottom-up planning is that lower-level employees take a personal interest in the plan which can improve motivation and moral. Though lower-level team members help to develop and implement the plan, it is primarily the project manager’s responsibility to see that the project is completed within budget and on time.

  A blend of the two approaches is probably best in most cases. Needs can be determined at the top with accountability falling at lower levels. By combining the vision of senior management with the skills of lower-level team members efficiency and project success are more likely.

  Those in project management must be aware of the total float time they have available to them at the beginning of the project. Total float is how many delays are allowed from the beginning of the project which will not interfere with the projected completion date. Anything can happen during the course of working on an extended task. Outdoor projects can be affected by adverse weather conditions which might create delays of hours or even days. Even indoor projects and virtual tasks can be met with unforeseen circumstances which sidetrack workers on the job. These delays are known as the total float, and project management must always keep this number in mind to ensure that the project will be finished on time.

  In order to determine the total float, project management use the critical path method, and they can also figure the earliest possible and latest completion dates for the task. Ideally, a project should never go beyond the late finish date, and by knowing how many days are built into the schedule for delays, those in management can keep the project running right on schedule.

  In the context of project management, the term “free float” is used to describe amount of time that spans from the completion of one previously scheduled activity and extends to the point at which the next scheduled activity is set to begin. Free float can be calculated by determining the amount of the time between the earliest start date of the initial activity and the earliest start date of the succeeding activity, and then subtracting from that total the amount of time that it is expected the first activity will take to complete. During this period of free float, the completion time or date of the earlier of the activities can be extended up until the scheduled early start date or time of the next scheduled activity without causing delays. If there is no succeeding activity scheduled, the project end date would be used to determine the back end of the free float window.

  Lead time: the time by which a predecessor event must be completed in order to allow sufficient time for the activities that must elapse before a specific event reaches completion.

  Lag time: the earliest time by which a successor event can follow a specific event.

  Slack: the slack of an event is a measure of the excess time and resources available in achieving this event. Positive slack would indicate ahead of schedule; negative slack would indicate behind schedule; and zero slack would indicate on schedule.

  Float or Slack is the amount of time that a task in a project network can be delayed without causing a delay - Subsequent tasks – (free float) or Project Completion – (total float)

  Schedule Network Analysis   Critical Path Method   Critical Chain Method

  The longest possible continuous pathway taken from the initial event to the terminal event.

  It determines the total calendar time required for the project; and, therefore, any time delays along the critical path will delay the reaching of the terminal event by at least the same amount.

  Critical Activity: An activity that has total float equal to zero. Activity with zero float does not mean it is on the critical path.

  The Critical Path Method (CPM) is a project modeling technique developed in the late 1950s by Morgan R. Walker of DuPont and James E. Kelley, Jr. of Remington Rand.[2] Kelley and Walker related their memories of the development of CPM in 1989.[3]At about the same time, Booz Allen Hamilton and the US Navy were developing the Program Evaluation and Review Technique [4] CPM is commonly used with all forms of projects, including construction, aerospace and defense, software development, research projects, product development, engineering, and plant maintenance, among others.

  Any project with interdependent activities can apply this method of mathematical analysis. Although the original CPM program and approach is no longer used, the term is generally applied to any approach used to analyze a project network logic diagram.

  The essential technique for using CPM [5] is to construct a model of the project that includes the following:   A list of all activities required to complete the project (typically categorized within a

work breakdown structure),   The time (duration) that each activity will take to completion, and   The dependencies between the activities

  Using these values, CPM calculates the longest path of planned activities to the end of the project, and the earliest and latest that each activity can start and finish without making the project longer.

  This process determines which activities are "critical" (i.e., on the longest path) and which have "total float" (i.e., can be delayed without making the project longer).

  In project management, a critical path is the sequence of project network activities which add up to the longest overall duration. This determines the shortest time possible to complete the project. Any delay of an activity on the critical path directly impacts the planned project completion date (i.e. there is no float on the critical path).

  A project can have several, parallel, near critical paths.   An additional parallel path through the network with the total

durations shorter than the critical path is called a sub-critical or non-critical path.

  A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e. precedence network) relationships between activities. Gantt charts can be used to show current schedule status using percent-complete shadings and a vertical "TODAY" line as shown here.

  The Program (or Project) Evaluation and Review Technique, commonly abbreviated PERT, is a model for project management designed to analyze and represent the tasks involved in completing a given project. It is commonly used in conjunction with the critical path method or CPM.

  PERT is a method to analyze the involved tasks in completing a given project, especially the time needed to complete each task, and identifying the minimum time needed to complete the total project.

  PERT was developed primarily to simplify the planning and scheduling of large and complex projects. It was developed by Bill Pocock of Booz Allen Hamilton and Gordon Perhson of the U.S. Navy Special Projects Office in 1957 to support the U.S. Navy's Polaris nuclear submarine project. It was able to incorporate uncertainty by making it possible to schedule a project while not knowing precisely the details and durations of all the activities.

  It is more of an event-oriented technique rather than start- and completion-oriented, and is used more in projects where time, rather than cost, is the major factor. It is applied to very large-scale, one-time, complex, non-routine infrastructure and Research and Development projects.

  This project model was the first of its kind, a revival for scientific management, founded by Frederick Taylor (Taylorism) and later refined by Henry Ford (Fordism). DuPont corporation's critical path method was invented at roughly the same time as PERT.

  Optimistic time (O): the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected

  Pessimistic time (P): the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes).

  Most likely time (M): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal.

  Expected time (TE): the best estimate of the time required to accomplish a task, assuming everything proceeds as normal (the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time).   TE = (O + 4M + P) ÷ 6

  During project execution, however, a real-life project will never execute exactly as it was planned due to uncertainty. It can be ambiguity resulting from subjective estimates that are prone to human errors or it can be variability arising from unexpected events or risks. And PERT may provide inaccurate information about the project completion time for main reason uncertainty. This inaccuracy is large enough to render such estimates as not helpful.

  One possibility to maximize solution robustness is to include safety in the baseline schedule in order to absorb the anticipated disruptions. This is called proactive scheduling. A pure proactive scheduling is an utopia, incorporating safety in a baseline schedule that allows to cope with every possible disruption would lead to a baseline schedule with a very large make-span. A second approach, reactive scheduling, consists of defining a procedure to react to disruptions that cannot be absorbed by the baseline schedule.

  Rolling wave planning is the process of planning for a project in waves as the project becomes clearer and unfolds. It is important in such projects to at least highlight in the initial plan the key milestones for the project.

  Rolling Wave Planning acknowledges the fact that we can see more clearly what is in close proximity, but looking further ahead our vision becomes less clear. Rolling Wave Planning is a multi-step, intermittent process - like waves - because we cannot provide the details very far out in our planning. Depending upon the project - its length and complexity - we may be able to plan as much as a few weeks or even a few months in advance with a fair amount of clarity. This involves creating a detailed, well-defined Work Breakdown Structure for that period of clarity, but just highlighting the milestone for the rest of the project.

  Progressive Elaboration is what occurs in this rolling wave planning process. Progressive Elaboration means that over time we elaborate the work packages in greater detail. Progressive Elaboration refers to the fact that as the weeks and months pass we have planned to provide that missing, more elaborated detail for the work packages as they now appear on the horizon.

  The most efficient way to shorten the schedule is to change the tasks that lie on the critical path (critical path: The series of tasks that must be completed on schedule for a project to finish on schedule. Each task on the critical path is a critical task.). The critical path is a series of dependent tasks whose last task finishes at the project end date. If any of the tasks in this series move, the project end date also moves. Modifying tasks that are not on the critical path may not affect the schedule. You can:   Shorten the durations of tasks (usually a reflection of reduced

scope or increased resources).   Overlap tasks so that they can be worked on simultaneously.   Remove tasks to meet the finish date (usually a reflection of

reduced scope).   Assign additional resources.   Decrease the amount of work assigned (usually a reflection of

reduced scope or more efficient resources).

  Over the course of a given project, often times, it is up to the project management team and or the project management team leader to make a determination that the previously determined and derived schedule may need to be modified and or tweaked in one way or another in order to accommodate one of more schedule events. This may be because a particular event is running behind schedule, or in other cases because a succeeding event’s timing has to e changed one way or another. One technique that is often employed by the project management team and or the project management team leader is that of project schedule compression.

  Schedule compression specifically speaking is a technique that is employed that involves taking the previously determined schedule and shortening the project schedule duration, but doing so in a manner which does not reduce and or minimize the project scope in any way.

  Fast tracking is a technique that is often implemented in crisis and/or crunch times so to speak as it involves in taking a specific schedule activity and/or work breakdown event that has been previously scheduled and/or is underway and expediting it in some way or another.

  Fast tracking is referred to as a project schedule compression technique of sorts in that its intent is to take an entire schedule of a project and attempting to compress it into a smaller period of time by conducting some events either quicker or by doing some events that were intended to be done in a more spaced out manner but rather doing some of them simultaneously. The network logic has essentially been changed allowing for some items that would otherwise have been done in a sequence are instead overlapped as such.

  Crashing refers to a particular variety of project schedule compression which is performed for the purposes of decreasing total period of time (also known as the total project schedule duration). The diminishing of the project duration typically take place after a careful and thorough analysis of all possible project duration minimization alternatives in which any and all methods to attain the maximum schedule duration for the least additional cost.

  There are a number of standard and typical approaches to attempting to crash a project schedule. One of the most commonly utilized methods of crashing a project schedule involves minimizing the schedule activity durations while, at the same time, increasing the assignment of resources on schedule activities.

  Crashing is something which can be utilized to attempt to get the most value out of a project assignment. Essentially, it boils down to an attempt to get the most productivity out of the least time and expense.

  Schedule performance measurement (SV, SPI) are used to assess the magnitude of variation to the original schedule baseline. The total float variance is also an essential planning component to evaluate project time performance.

  Important aspects of project schedule control include determining the cause and degree of variance relative to the schedule baseline and deciding whether corrective or preventive action is required.

  The phrase estimate at completion, which can also be referred to by the three letter anagram EAC, is an input output device that is used to measure the expected total cost of a particular schedule activity, a work breakdown structure, or of the project as a whole, in cases where the scope of work that has been previously defined will ultimately be completed. The estimate at completion is equal to the amount of actual cost (also know by the anagram of AC) plus the estimate to complete (also known by the anagram of ETC) for the entirety of the remainder of the work. The estimate at completion can be determined by deriving calculations based on the performance to date, or may be derived by the project leader or team via using other miscellaneous factors entirely. The estimate at completion, when updated based on progress to date, is then referred to as a latest revised estimate. See also the terms estimate to complete as well as earned value technique for more information.

  Duration estimates may include contingency reserves (sometimes referred to as time reserves or buffers) into the overall project schedule to account for schedule uncertainty. The contingency reserve may be a percentage of the estimates activity duration, a fixed number of work periods, or may be developed by using quantitative analysis methods

  As more precise information about the project becomes available, the contingency reserve may be used, reduced, or eliminated.

  Direct and manage project execution is the process of performing the work defined in the project management plan to achieve the project’s objectives. These include:   Perform activities to accomplish project requirements   Create project deliverables   Staff, train, and manage the team members assigned to

the project   Obtain, manage and use resources including materials,

tools, equipment and facilities   Implement the planned methods and standards   Establish and manage project communication channels,

both external and internal to the project team   Generate project data, such as cost, schedule, technical

and quality progress, and status to facilitate forecasting

  Issue change requests and adapt approved changes into the project’s scope, plans and environment

 Manage risks and implement risk response activities  Manage sellers and suppliers, and  Collect and document lessons learnt, and implement

approved process improvement activities

  Corrective action: documented direction for executing the project work to bring expected future performance of the project work in line with the project management plan

  Preventive action: a documented direction to perform an activity that can reduce the probability of negative consequences associated with project risks

  Defect repair: the formally documented identification of a defect in a project component with a recommendation to either repair the defect or completely replace the component

  Process of tracking, reviewing and regulating the progress to meet the performance objectives defined in the project management plan.

  Monitoring is an aspect of project management performed throughout the projects   Monitoring includes collecting, measuring, and

distributing performance information, and assessing measurements and trends to effect process improvements.

  Continuous monitoring gives the project management team insight into the health of the projects, and identified any areas that may require special attention

  Control includes determining corrective or preventive actions or replanning and following up on action plans to determine if the actions taken resolved the performance issue.

 Comparing actual project performance against the project management plan

 Assessing performance to determine whether any corrective or preventive actions are indicated, and then recommending those actions as necessary

  Identifying new risks and analyzing, tracking, and monitoring existing project risks to make sure the risks are identified, their status is reporting, and that appropriate risk response plans are being executed

 Maintaining an accurate, timely infomration base concerning the project’s products and their associated documention through project completion

  Providing information to support status reporting, progress measurement, and forecasting

  Providing forecasts to update current cost and current schedule information, and

 Monitoring implementation of approved changes as they occur

  Reports should be prepared by the project team detailing activities, accomplishments, milestones, identified issues, and problems.

  Performance reports can be used to report the key information including, but not limited to:  Current status   Significant accomplishments for the period   Scheduled activities   Forecasts, and   Issues