Plan Stakeholder Management

The Plan Stakeholder management process is concerned with coming up with the stakeholder management plan - how different project stakeholders, identified as part of initiating process, will be handled. The idea here is to ensure that all types of stakeholders are thought over and covered in order to have a viable approach to handle their needs.

Based on the same, here are the inputs:

Project Management Plan: As with all of the planning processes, this is a general input in terms of the fact that the project manager usually starts with an outline plan and develops more specific plans, relevant to each knowledge area.
Stakeholder Register: An output from the Identify Stakeholders - initiating process that has the list of stakeholders who need to be taken care in terms of ensuring that their objectives are prime to the project success.
Organizational Process Assets: As will all planning processes, this is an important input to look at lessons learnt, processes followed so far, tailoring guidelines etc.
Enterprise Environmental Factors: Another vital input for all the planning processes. Since planning mainly needs to account for external factors affecting the project.


Here are the tools and techniques:

Expert Judgment: The general technique applied in case of planning processes because it is necessary to leverage consultant and senior manager view point here to ensure that the project is covered of all aspects.
Meetings: Lot of time is spent on meetings during the planning phase since it is necessary to take the input from various quarters during the planning phase.
Analytical Techniques: A usual technique used when developing the plan. The current engagement level and desired engagement level are analyzed. The following are the different engagement levels of the stakeholders:

Unaware: Unaware of project and potential impacts. Needs utmost guidance.
Resistant: aware of project and potential impacts but resistant to change. Mostly tough to handle.
Neutral: aware of project and potential impacts but neutral to change. Can be influenced with proper facts.
Leading: aware of project and potential impacts. Proactive in ensuring that the project is a success. Easy to work with.

Here are the outputs:
1. Stakeholder management Plan: Has details about how to handle different group of project stakeholders, current and desired engagement levels, communication requirements and communication points, general process as to what other processes in stakeholder management knowledge are applicable and how they will be tailored to the current context, how changes will be handled.
2. Project Document Updates: Updates to other documents as management plan is developed.


Although not stated in the PMBOK, project management plan updates can also be an output to this process.

Visit http://pm-prep35.com/ittolaunchpage.aspx

Project Stakeholder Management - Introduction

While Project Human Resource Management is concerned with assigning the project team , training the team and ensure that their performance stays appraised, the project stakeholder management is concerned with not only with the project team but generally people influencing the project. The stakeholders might be the customers or contractors or project team's family members.

Here are the processes falling in this knowledge area:
1. Identify Stakeholders
2. Plan Stakeholder Management
3. Manage Stakeholder Engagement
4. Control Stakeholder Engagement

Based on these processes, the stakeholder management knowledge are has the following responsibilities:

1. The project stakeholders are identitied initially in order to ensure that their requirements are accounted during the requirement collection process.
2. Once the stakeholders are identified and the gamut of stakeholders is known, then how they will be managed will help in having having a plan on hand. Planning might involve at what points they will be contacted, what sort of communication model will be followed for the different categories of stakeholders are some of the things to be planned.
3. Once a plan is in place, the next step is to ensure that the plan is executed at the appropriate phase or point in the project lifecycle.
4. Control Stakeholder Engagement is concerned with coming up with corrective or preventive actions if there is any deviation from the plan or there needs to be a change in approach in dealing with the stakeholders.

Stakeholders can have a positive or negative impact on the project objectives. As a project manager, it is important to influence factors that case positive impacts while reducing the effect of negative impacts. This is what differentiates project success from failure.

Visit http://pm-prep35.com/ittolaunchpage.aspx

Control Schedule Process

The Control Schedule process is concerned with -
1. Ensuring that changes are processed in a controlled manner.
2. What has been accomplished so far and what is yet to be accomplished.
3. Ensuring that changes are properly managed.
4. Ensuring that the schedule will be under control in future as the project progresses
5. Ensuring that the project schedule is covered for all possible impacts
6. Ensuring that the schedule data (actuals) collected in the schedule model is correct
7. The availability of resources in case if schedule goes out of control
8. Ensuring critical path and buffers are under control
9. Incorporating changes to the baseline once change is approved by the change control board

In an agile approach, control schedule process might also cover -
1. Work re-prioritization
2. Determine the work velocity in a given iteration and ensure everything stays controlled

The common inputs to this process are:
1. Project management plan: This is the baseline document against which helps in deciding if corrective action is required and impacts to other constraints.
2. Work performance data: The common monitoring and controlling  process input coming from the executing process to cross-check if the schedule is under control.
project schedule: This gives an idea of what has been accomplished and what is planned ahead and if the schedule is under conrtol.
3. Project calendars: In case if schedule is not under control , then there might be a need to plan for corrective action in which case, project calendars of the resources need to be looked up to bring the schedule under control.
4. Schedule data: What has been collated in the form of actual dates and resource allocations will be checked and ensured to be correct.
5. Organizational process assets: Reporting methods , policies for schedule control etc.

The tools and techniques part of this process are:
1. Performance reviews: How is the schedule performing and will perform - forecasts. Here are some of the review techniques:
- Trend Analysis: Based on current performance, what will be the future and if everything will be under control at a later point.
- Critical Path Method: What mileage has been covered in the critical path will give a better idea of the project health and corrective / preventive actions needed.
- Critical Chain Method: What amount of buffer was allocated and what is used will give an idea of a need for corrective actions
- Earned Value Management: Schedule Variance (planned v/s actual), schedule performance indicator to check the health of the project and decide on corrective actions.
2. Project Management Software: Softwares like Microsoft Project Plan are useful in looking and understanding the schedule data and finding variance / trends and then useful in finding if there will be a need for corrective action.
3. Resource Optimization Techniques: How effectively resources can be used to get the schedule under control.
4. Modeling Techniques: They are used to simulate what-if scenarios affecting the project objectives and seeing the impacts to the schedule.
5. Leads and Lags: Leads and lags can facilitate paralleling of activities and thus help in gaining time-saving or schedule time gain or schedule catchup.
6. Schedule Compression: Adding more resources if schedule is lagging behind, in order to get schedule back on track.
7. Scheduling Tool: Usually part of the project management software, the scheduling tool is used to build the network diagrams and do some base work that can be looked up and corrected if needed.

The outputs from this process are:
1. Work Performance Information: The data is made concise good for reporting or to be fed in the change requests and then to be presented before the change control board.'
2. Change Requests: The document holding the changes and their impacts to different project objectives like cost and schedule impact. This becomes the input to the integrated change control process.
3. Organizational Process Assets Update: Any new lessons learnt or process tailoring guidelines become part of the organizational process assets.
4. Schedule Forecasts: These become inputs to the integrated change control process.
5. Project management plan updates: Changes to Schedule baseline, once changes are approved by the change control board.
6. Project Document Updates: Any updates to other documents like risk register or other relevant documents based on the change.

Visit http://pm-prep35.com/ittolaunchpage.aspx

Estimate Activity Durations

For the list of activities identified along with the list of identified resources for the concerned activities and based on the resouce calendars, what is the estimated time to complete each of the activities is what gets covered as part of Estimate Activity Durations process. Most of the times, the resource estimation, duration estimation is all done as part of project scheduling and it is also an iterative process considering the need to come up with a better schedule that befits client deadlines.

Inputs:
The Schedule Management Plan has details about how to come up with the duration estimates. The plan is a common input to all the processes within the concerned knowledge area since it provides direction and guidelines to tailor the different processes within the knowledge area.
Activity list contains the list of all activities identified for the project while Activity attributes has additional information like description or priority and so on.
In order to come up with the duration estimates, the key input is the no. of resources to work on the concerned activity. Understandably, based on the quantity and quality of the resource, the activity's duration would change. An experienced resource is better equipped with skills to complete the activity in a lesser duration compared to an inexperienced one.
Resource Calendars are nothing but identified resource's availability in the project timeline. Certain resources will be available only in the night shift. It also holds the vacation schedule for the concerned resource. The vacation schedule needs to be accounted when coming up with the activity duration.
While requirements usually cover aspects related to the project work as needed by the stakeholders, the project scope statement is more stringent in terms of specifying what is mandatory and what is not. Also, since the activity list is derived from the scope statement as the original source, the scope statement is looked up in order to be sure about any assumptions / constraints. Examples of constraints might include anything related to organizational constraints in terms of not having resources in the expected experience range.
Risk register covers the list of project risks. The risks might influence the duration of the activity. If a resource would be unavailable midway, then that will affect the activity duration as such.
The resource breakdown structure provides the hierarchy of available resource by category and type. This helps in understanding the available options in order to make a quick decision about the activity durations.
Enterprise Environment Factors is a vital input to this process plainly because this is a planning process since planning needs good understanding of environmental factors influencing the project and they need to be accounted.
Organizational Process Assets: Any formats or lessons learnt in similar projects in the past.

The tools and techniques used as part of this process are:
Expert Judgment: A vital tool during planning normally employed by SMEs.
Analogous Estimating: A technique wherein one project is estimated based on another due to the similarity and then the estimation accommodates for any differences by adding a buffer using expert judgement. This technique is used when there is very less details available about the project requirements. This is less time consuming and it has more risk too because due diligence is not used to come up with an accurate estimate.
Parametric Estimating: Based on what work a resource can do per time period, the time period to cover the activity is calculated and this is termed parametric estimation. This is normally used when there wouldn't be much change in the kind of work being done from time to time.
Three-point Estimating uses 3 possible estimates like optimistic, pessimistic and most likely values and extra-polates the values to come up with the estimate number. This needs good expert judgment else, this can become inaccurate or totally irrelevant to say the least. There are two types of calculations shown as below:
- Triangular Distribution. tE = (tO + tM + tP) / 3
- Beta Distribution (from the traditional PERT technique). tE = (tO + 4tM + tP) / 6
Group Decision Making Technique: In some scenarios where there is no proper data available to make an estimate, a group decision making approach based on available information is the best approach to follow. This uses techniques like braistorming, Delphi technique etc.
Reserve Analysis:Duration Estimates also involves estimation for contingencies or risks. There are different types of risks like Known Unknowns and Unknown Unknowns. These are accounted in the estimate as buffers. The different types of reserves are:
Contingency reserves are buffers for known unknowns for which mitigation plan is available. They are a percentage of the activity duration or a fixed work period might be added to account for them. The duration gets reduced as more clear visibility is available about the mitigation approach.
Another type of reserve is management reserve to account for unknown unknowns. They are not part of schedule baseline. So, use of the management reserve may include a change in the schedule baseline.

The outputs from this process are:
Activity Duration Estimates: What is the duration for the concerned activity based on different constraints like resource capability , resource calendar and so on. This estimate usually has a range to denote a rough order magnitude.
Project Document Updates: Project documents like activity attributes get updated as part of this process.


 Visit http://pm-prep35.com/ittolaunchpage.aspx

Control Scope Process

The Control Scope Process is concerned with ensuring that the scope baseline is pristine and is not breached unless a proper change control process is followed. The baselines are usually maintained in the project management plan and the PM plan also being the master plan can also be useful in analyzing the impacts when one of the baseline changes. So, that way, the PM plan is a common input for all the monitoring and controlling processes. Note that the scope baseline includes the scope statement so, that also gets included when PM Plan is the input.
Apart from this, the requirements documentation is also useful in this process. The requirement documentation is an exhaustive document to be considered for the control scope process since the scope statement has the boundaries but, the requirement document probably provides better details about the context when requirements were collected.
The requirement traceability matrix provides a quicker lookup in terms of finding what all requirements have been covered across the project phases and ensuring that all requirements have been covered and only the requirements relevant to the project context are covered. Also, in order to be sure that the baselines are under control , metrics are  an important factor. This is where the work performance data is useful.
Work Performance data is an output from the executing process provided by the project team. This has details about what requirements have been covered and what percentage has been covered. Apart from these, how scope control has been handled so far in other similar projects? What issues have been faced and how they were handled so far is picked from organizational process assets.
So, these are the inputs for this process:
1. Project Management Plan: What are the baselines and the concerned impacts in case of a change.
2. Requirement Documentation: List of requirements provided by different stakeholders providing the need to control scope.
3. Requirement Traceability Matrix: What requirements have been handled and what are not or is there any scope creep? Control Scope is needed then.
4. Work Performance Data: Is project health good? Is something wrong because of a scope creep introduced recently by the project team?
5. organizational Process Assets: How scope creep has been handled before?

Once the inputs are available, the most important technique employed is variance analysis. Is there a variance from the baseline? What amount of variance from the baseline and what are the possible solutions without impacting the other factors or, what other factors get impacted.
So, here is the most important technique utilized in this process:
1. Variance Analysis

Once variance analysis is done, there might be a need to present the information to the change control board, in case there is a variance or deviation from the planned scope. So, presentation of the data is important. Impacts to different project constraints like cost, time, risks are documented to be presented as work performance information. While Work Performance information has details about project health, the change request is used to present the information in a format desired by the change control board so that the board can make the necessary decision and sign off the request. In the whole process of collating the work performance information and documenting the change request, the project documents and project management plan might be updated. Since the control scope process is also concerned with including approved changes in the scope baseline, the approved changes can in turn impact the project management plan milestones or the risk register. So, these take the form of project management plan updates and project document updates respectively. Organizational Process Assets get more documents in the form of approved or rejected change requests or any lessons learnt as part of this process. So, these are the outputs of this process:
1. Work Performance Information: Collating the information in a presentable format to analyse project impacts and solutions.
2. Change Requests: Present the information in a format needed by the Change Control Board (CCB).
3. Project Management Plan Updates: Milestones updates as a result of change in baseline.
4. Project Document Updates: Changes to other documents like risk register, change register.
5. Organizational Process Asset Updates: Lessons Learnt, more documentation updates.

Visit http://pm-prep35.com/ittolaunchpage.aspx

Define Scope - PM Process for a Bachelor/Bachelorette looking for a date

Define Scope for Dating

The scope is to date someone who fits your constraints like budget, time period in hand etc.

So, how do you define the scope for this process? Or, in other words, you have a vague idea
that you need a date but then there are too many requirements making rounds in your mind. So,
you need to prioritize and come up with a trimmed list that will fit your bill and can give a quick solution for the situation on hand.

As a first step, you need to clear how you will go about defining the concerned scope. What kind of person will suit you. So, you must have a plan on hand before defining the scope.

The plan anticipates all kinds of problems how will you handle those. This particular plan is called scope management plan. In our case, it is dating management plan.

The next valuable input would be to be sure about what all you need. It is nothing but out-of-the-box thinking. You think wild to come up with the most exhaustive list of requirements about your date. For girls, it might be something like having Billion dollars in bank, looks like Tom Cruise but as tall as Amitabh but then can play soccer like Beckham etc. Now, this is too exhaustive and this is your requirement documentation. It goes blah blah... very wild thinking indeed. You don't care if all requirements will be met but you just go about collecting requirements! So, (dating) requirement documentation is an input to the define scope process.

Now, your plan is ready and your list of requirements is also ready. Now, you need a roadmap. Think this to be a set of values. You  have accumulated a set of high-level expectations about your date as such and these have been passed on by the way you have grown up over a period or blame it on your friends and the books you read, videos you saw!
In other words, You vaguely have an idea of what kind of person will actually fit you. This might not be a perfect fit for the guys because we are ok with anything that comes our way! Anyway, to nail this, this input is nothing but a high-level idea of different impacts or risks, money you are willing to spend etc. This is nothing but your dating charter. It becomes project charter in PM context.

Now, you might have some previous experience - failing or succeeding in a similar context. Some people might use friends who have failed many times in such situations and leverage their experience. How sadistic? but then anything for a girl. These friends are called as consultants (yes, uncle) in project management context. These people are definitely assets. So,  in project management context, they become organizational process assets.

Now, let us derive the tools and techniques from the above process:
Expert Judgment: Whether you will get beaten by a girl if you approach in a particular way, the capability to tell that - This is called expert judgment. This might come from your friend who is full of scars or, it might be your own talent.

Product Analysis: Sorry to make the date an object but we are here with a goal. So, you spend a lot of time analyzing the product err the date. This will help you define the date better so that you are better equipped the next time you try because we don't give up just in one attempt and this is called as progressive elaboration since we get to know the person better as we put more effort.

Alternatives Identification: This is perfect for a dating scenario. You keep multiple options as backup. What if one fails to turn up, so, you always need to have a couple  of alternatives maybe a bit of a costlier option but then the goal matters rather than anything!

Facilitated Workshop: Sometimes you pull your friends, next house old man and first street uncle to understand the context and see what approach will be better. This is nothing but cross-functional team - people totally unrelated to each other sitting in one room and brainstorming just because you gave then 5 chips packet and one full bottle of scotch whisky!

Now, the output of this process (hopefully!) is a defined scope written in a scope statement. If your scope doesn't get defined here, then blame on the consultants and their so called expert judgment! Anyway, at the end of this process, you have a scope statement that has the following details:
- product characteristics: yes, guys can relate to this very easily!
- Exclusions: What features or characters you specifically DON'T want. This is too much of a specification and this is what annoys the boys because girls have too much of preferences
- Assumptions: As with anything, You assume certain things about the product and its features!
- Constraints: Too many brothers?
- Acceptance Criteria: You fairly get an idea as to what is the chance of being accepted. So, do you still want to proceed with the concerned project on hand?

Project Document Updates: Might want to update more requirements. Some more? Maybe even God would fail fitting the bill!

visit http://pm-prep35.com/ittolaunchpage.aspx

Project Scope Management - Define Scope Process

The Define Scope Process deals with defining the inclusions and exclusions of the project. The actual product features are defined here. While the Collect Requirements will result in an exhaustive list of requirements, not all those requirements can be handled now. So, this is where define scope process is important. In this process, the product features get defined and mainly the exclusions for the current project phase are clearly defined.

Define Scope Process Introduction

The project scope statement, the main output for this process, has the following details :
- Product Characteristics
- Exclusions
- Product Acceptance Criteria
- Assumptions
- Constraints

The following are the inputs to this process:
1. The scope management plan has the details about how the scope will be defined and how the scope statement will be tailored for this project.
2. The Project Charter has the high-level details, provided by the sponsor. The different constraints, assumptions are picked from here and detailed thereon by progressively elaborating  the details.
3. Requirements Documentation has the sum total  of all requirements collected from different stakeholders with mostly a priority assigned to each of the requirements
4. Organizational Process Assets are used to refer prior lessons or best practices.

Define Scope Process Inputs - 2

The following are the tools and techniques for this process:
1. Expert Judgment: Consultants might be used if the project is in a niche area.
2. Product Analysis: Requirement breakdown to come up with proper details and product characteristics.
3. Alternatives Identification: For the given constraints, what other alternatives exist and how they can fit the current context.
4. Facilitated Workshops: A cross-functional team brainstorms and analyses different options to come up with the most feasible product features or breakdown.

Define Scope Process Tools and Techniques - 1

Define Scope Process Tools and Techniques - 2

Define Scope Process Tools and Techniques - 3

The following are the outputs:
1. Project Scope Statement
2. Project Document Updates: Updates to supporting documents like requirement traceability matrix, risk register etc.

Visit http://pm-prep35.com/scopelaunchpage.aspx