MS Project - Important Aspects

MS Project:

 

1.       What is elapsed duration?

2.       What is difference between Manually Scheduled Tasks and Auto Scheduled tasks?

3.       What is 8/80 rule?

4.       Using Calendar

a.       How do you set up partial working time for a resource, such as a portion of a day? (Pg 65)

b.      How will you set work schedule for a resource such as - 4 days 10 hours per week, 10 hours per day? (Pg 65)

 

5.       How many Type of Resources exists? (Work – People & Equipment, Cost & Material)

6.       How do you setup Cost Resource? (Pg 67)

7.       How do you apply cost resource to a Task? (Pg 88)

8.       What is Event Driven Scheduling? (Pg 83)

9.       What are different levels of Tracking ? (pg 124)

10.    How many baselines can be present? (First one is called ‘Baseline’ and rest are ‘Baseline 1 to Baseline 10’) -  Total 11 Baseline.

11.     When should you baseline? (Before you enter actual)

12.    What are Back-loaded tasks? (Pg 136)

13.    What happens when you enter actual values for task in below cases: (Pg 132)

a.       When you enter a task’s actual start date, Project moves the scheduled start date to match the actual start date.

b.       When you enter a task’s actual finish date, Project moves the scheduled finish date to match the actual finish date and sets the task to 100% complete.

c.        When you enter a task’s actual work value, Project recalculates the task’s remaining work value, if any.

d.       When you enter a task’s actual duration, if it is less than the scheduled duration, Project subtracts the actual duration from the scheduled duration to determine the remaining duration.

e.       When you enter a task’s actual duration, if it is equal to the scheduled duration, Project sets the task to 100% complete.

f.         When you enter a task’s actual duration, if it is longer than the scheduled duration, Project adjusts the scheduled duration to match the actual duration and sets the task to 100% complete.

 

14.    What are different Tasks Relationships? (Pg 142) - Finish-To-Finish, Finish-To-Start, Start-To-Start, Start-To-Finish

15.    What are techniques to fine tune tasks relationships? Pg – 147 – Two ways – First is , keeping start to start and second is entering lead times wherever appropriate.

16.    What are different types of Tasks Constraints? (Flexible [ASAP, ALAP], Semi-Flexible(SNET,SNLT,FNET,FNLT] and Inflexible[MSO, MFO])

17.    Can you set constraints on Manually scheduled tasks? (Pg 152)(Cannot)

18.    How can you force to honor the relationships over task constraint? (Pg 152)

19.    How do you split a task? (Pg-153)

20.    Can a task be split in multiple sections? (Yes)

21.    How do create/adjust different working time for a individual tasks? (Pg 155)

22.  Which calendar is applied for a task that have both Task Calendar and resource assignment? (Pg 155)

Two possible cases:

A.       If there is any common working time between two calendars, Resource Calendar takes precedence over Task Calendar and project is scheduled accordingly. E.g.

Task Calendar (3 Days) - Mon, Tue, Wed - Working

Resource Calendar (Only One Day) - Wed - Working

 

Then any task of just 5 days will take five elapsed weeks to complete this task, as one week has only one common working day I.e. Wed.

 

However you can choose to ignore Resource calendar over Task Calendar.

 

A.       If there is nothing common working time between two calendars - Then Resource Calendar gets overwritten by Task Calendar, by showing below dialog.

 

1.       Can you choose to ignore resource calendar while assigning Base Calendar to a task? (Pg 155)

 

2.       What are different Tasks Type? (Fixed Unit, Fixed Durations  and Fixed Work) (Pg 158)

3.       What is default Task Type? (Fixed Units) (Pg 158)

4.       Note: You cannot turn-off ‘Even Driven Scheduling’ for a Fixed Work Task. (Pg 158)

5.       What is ‘Peak Units’ compared to Assignment Units? (Pg 159) (This works with Fixed Duration Tasks. Increasing the work increase the Peak Units rather than Assignment Units)

6.       What is fixed cost task? (Pg 165) (Thru Task Sheet -> Cost Table)

7.       How to set up ‘Recurring Tasks’? (Pg 167) (Insert Menu -> Recurring Task)

8.       How to configure – Tasks are critical if slack is less than or equal to 2 days, instead of zero days? (Pg 172)

9.       What is Inactivating Task? (Pg 175)

10.    What is the impact on successor task after Inactivating a Task?

11.    Using Resource Sheet

               i.      How do you setup a resource’s availablity to apply different at different times? (E.g. First Week 100%, 2^nd Week 200% and 3^rd Week onwards again 100%) (Pg 179) (Ans: Using Resource Sheet)

              ii.      How to set up multiple pay rates for a resource? (Pg 183) (Ans: Using Resource Sheet)

            iii.      How to set up multiple pay rates for a resource at different times? (Ans: Using Resource Sheet)

            iv.      What is ‘Cost Per Use’? (Pg 185) (Ans: Using Resource Sheet)

 

12.    Using Resource Usage

a.       How to verify resource capacity per day, week & month? (Pg 201)

 

13.    What are different states of Resource Allocation? Pg 212  (Under Allocated, Fully Allocated, Over Allocated)

14.    Does different states of Resource Allocation applies to Cost & Material resources? (No)

15.    What is the use of ‘Next Overallocation’ button? (Pg 216)

16.    What are different ways of Resource Leveling? (Manual - Pg 217 & Auto – Pg 220)?

17.    How you do grouping in MS Project? (Pg 238)

18.    What is ‘TimePhased Actuals’? (Pg 257) – Tracking Work By Time Period – Most Detailed Level of Tracking Progress.

19.  What is the difference between Baseline and ‘Interim Plans’? (Pg – 262)

20.  What are different ways to update actual work values for a task, which has multiple resources assigned? (Pg 263)

21.  How to enter Project Cost Manually/ (Pg 269)

 

22.    How do you reschedule incomplete work? (Pg – 274)

a.       If the task does not have any actual work recorded for it prior to the rescheduled date and does not have a constraint applied, the entire task is rescheduled to begin after that date.

b.       If the task has some actual work recorded prior to but none after the rescheduled date, the task is split so that all remaining work starts after the rescheduled date. The actual work is not affected.

c.        If the task has some actual work recorded for it prior to as well as after the rescheduled date, the task is not affected.

 

23.    How you can turn off Project’s ability to reschedule incomplete work on tasks for which any actual work has been recorded? (Pg 276)

24.  What are different ways to identify tasks that have slipped from baseline? (Pg – 281)

a.       Tracking Gantt

b.       Detail Gantt

c.        Variance Table

d.       Filter for Slipping  Tasks

e.       Reports – Slipping Tasks etc

 

25.    How can you quickly display Late Tasks (Tasks are late in relation to whatever status date you set)? (Pg 286)

26.    How do you examine task cost and ‘Cost OverBudget’? (Pg – 288)

27.    Check – Overbudget Tasks Report?  (Pg – 289)

28.    Check – Examining Resource Cost ? (Pg – 290)

 

 

Regards,

Arun Manglick

 

 

How To Handle/Process Change Request?

Changes  are requested during the ‘Executing’ or ‘Monitor & Controlling’ process.

These changes are accepted/rejected in the ‘Perform & Integrated Change Control’ process. 

Question: Stakeholder/Client/Functional Manager wants to make a change add scope to the project.

Question: Stakeholder/Client/Functional Manager wants to add scope to the project.

What Project Manager should do now? 

In summary –

• Normally change request are handled by preparing an Impact analysis document and then doing Re-Estimation. Example you have an ongoing project, which has a customer table. Now customer wants to also have addresses assigned to it. So you normally raise a change request and then do an impact analysis of the same.
• Depending on the impact you estimate and let know the client about the financial aspect of the project.
• Once client sign off or the upper management agrees to the change request you move ahead with implementation.

In Detail: The PM should follow below steps to process the change. 

1. Evaluate the Impact
2. Create a Change Request
3. Look for Options
4. Get the Change Request Approved
5. Adjust the Project Management Plan, Project Documents & Baselines
6. Manage Stakeholder Expectation

Evaluate the Impact:

• Check, if it’s a Scope Change, how it will affect the Project Cost, Quality, Risk, Resources, and Possibly Customer Satisfaction. I.e. Change in one Project Constraint must be evaluated for impacts on all other project constraints.
• Check, if it’s a Scope Change, how it will affect the rest of the schedule of the project.

Create a Change Request

• Once evaluation is completed, create a formal change request.

Look for Options

• This is taken to reduce/minimize the effect of change. Actions include compress the schedule thru crashing/fast-tracking, adjusting quality or cutting scope.
• However, be careful, it’s not wise to reduce the impact of every change. In doing so, PM could decrease the overall probability of success on the project.

Get the Change Request Approved

• Take the change and it’s estimation/cost to the Client/CCB/Sponsor to discuss the change.
• Get an approval/rejection from them.
• Once approved, update project documents as a result of approved changes.
• These approved changes are then implemented in ‘Direct & Manage Project Execution’ 

Adjust the Project Management Plan, Project Documents & Baselines

• Approved changes needs to be incorporated into the Project Baseline.
• Also the PMP and Project documents requires updating.

Manage Stakeholder Expectation

• Manage Stakeholder Expectation by communicating the change to stakeholders, affected by the change.
• This could be thought of as a configuration management, a form of version control, or a way to make sure everyone is working off the same project documentation.

Some More Concepts:

What is Change Control Board:

• Depending on the PM’s level of authority, he can facilitate the impact of change, rather than actually making the go or no go decision.
• For this reason, many projects have CCB.
• CCB is responsible for reviewing and analyzing change request.
• It then approve or reject the change.
• Board may include PM, Customer, Sponsor etc.

How PM  Should Control Changes?

• Generally the PM should proactively remain cautious in preventing the root cause of changes.
• Often Root cause are:
• PM did not talk to all the stakeholders and uncover their requirements.
• Get a sign-off on the functional specification before starting construction.
• PM did not properly plan the project. 

PM should make sure below to control changes:

• Obtain final requirements asap and get them signed-off.
• Come up with time and cost reserve.
• Have a process in place to process changes.
• Have ready CR templates
• Allow only approved changes to be added to the project baseline.
• Terminate the project having excessive changes and start a new project.

Hope this helps.

Regards,

Arun Manglick

Scope Control - Effective Business Requirements Analysis

Clearly Agreeing What You're Going to Deliver

 

Many times in projects you’ll find mismatch between what has been designed and what is actually needed.

Many times client changed thier mind altogether about the deliverable, when you were halfway through a project, leading to conflicts with clients.

Many times you receive new requirements just after you thought you'd finished creating a product.

 

To avoid problems like these a focused and detailed business requirements analysis can help you. It’s the process by which you clearly and precisely define the scope of the project, so that you can assess the timescales and resources needed to complete it.

 

Below is a five-step guide to conducting your own business requirements analysis.

 

Step 1: Identify Key Stakeholders

Identify the key people who will be affected by the project. Start by clarifying exactly who the project's sponsor is. This may be an internal or external client. Either way, it is essential that you know who has the final say on what will be included in the project's scope, and what won't.

Then, identify who will use the solution, product, or service. These are your end-users. Your project is intended to meet their needs, so you must consider their inputs.

 

Step 2: Capture Stakeholder Requirements

Ask each of these key stakeholders, or groups of stakeholders, for their requirements from the new product or service. What do they want and expect from this project?

 

Remember, each person considers the project from his or her individual perspective. You must understand these different perspectives and gather the different requirements to build a complete picture of what the project should achieve.

 

When interviewing stakeholders, be clear about what the basic scope of the project is, and keep your discussions within this. Otherwise, end-users may be tempted to describe all sorts of functionality that your project was never designed to provide. If users have articulated these desires in detail, they may be disappointed when they are not included in the final specification.

You can use several methods to understand and capture these requirements. Here, we give you four techniques:

 

·         Technique 1: Using stakeholder interviews
Talk with each stakeholder or end-user individually. This allows you to understand each person's specific views and needs.

 

·         Technique 2: Using joint interviews or focus groups
Conduct group workshops. This helps you understand how information flows between different divisions or departments, and ensure that hand-overs will be managed smoothly.

 

·         Technique 3: Using "use cases"
This scenario-based technique lets you walk through the whole system or process, step by step, as a user. It helps you understand how the system or service would work. This is a very good technique for gathering functional requirements, but you may need multiple "use cases" to understand the functionality of the whole system.

 

·         Technique 4: Building Prototypes
Build a mock-up or model of the system or product to give users an idea of what the final product will look like. Using this, users can address feasibility issues, and they can help identify any inconsistencies and problems.

 

Step 3: Categorize Requirements

 

To make analysis easier, consider grouping the requirements into these four categories:

• Functional Requirements – These define how a product/service/solution should function from the end-user's perspective. They describe the features and functions with which the end-user will interact directly.
• Operational Requirements – These define operations that must be carried out in the background to keep the product or process functioning over a period of time.
• Technical Requirements – These define the technical issues that must be considered to successfully implement the process or create the product.
• Transitional Requirements – These are the steps needed to implement the new product or process smoothly.

 

Step 4: Interpret and Record Requirements

 

Once you have gathered and categorized all of the requirements, determine which requirements are achievable, and how the system or product can deliver them.

To interpret the requirements, do the following:

• Define requirements precisely – Ensure that the requirements are:
• Not ambiguous or vague.
• Clearly worded.
• Sufficiently detailed so that everything is known. (Project over-runs and problems usually come from unknowns that were not identified, or sufficiently well-analyzed.)
• Related to the business needs.
• Listed in sufficient detail to create a working system or product design.
• Prioritize requirements – Although many requirements are important, some are more important than others, and budgets are usually limited. Therefore, identify which requirements are the most critical, and which are "nice-to-haves".
• Analyze the impact of change – carry out an Impact Analysis to make sure that you understand fully the consequences your project will have for existing processes, products and people.
• Resolve conflicting issues – Sit down with the key stakeholders and resolve any conflicting requirements issues. You may find Scenario Analysis helpful in doing this, as it will allow all those involved to explore how the proposed project would work in different possible "futures".
• Analyze feasibility – Determine how reliable and easy-to-use the new product or system will be. A detailed analysis can help identify any major problems.

 

Once everything is analyzed, present your key results and a detailed report of the business needs. This should be a written document.

Circulate this document among the key stakeholders, end-users, and development teams, with a realistic deadline for feedback. This can help resolve any remaining stakeholder conflicts, and can form part of a "contract" or agreement between you and the stakeholders.

 

Step 5: Sign Off

Finally, make sure you get the signed agreement of key stakeholders, or representatives of key stakeholder groups, saying that the requirements as presented precisely reflect their needs. This formal commitment will play an important part in ensuring that the project does not suffer from "scope creep" later on.

 

 

Hope this helps.

 

Regards,

Arun Manglick

 

 

Remember These Seven Items When Closing Your Project

Just as it is important to formally kick off a project, it is also important to successfully close the project. The value of having a planned project termination is in leveraging all of the information and experience gathered throughout the project. This is true whether the project was a success or not.

 

When the project schedule is created, think about the activities that need to be performed to gracefully close the project. These activities include:

 

1.       Hold end-of-project review meeting. A meeting should be held with the project team, sponsor and appropriate stakeholders to formally conclude the project. This meeting will include a recap of the project, documenting things that went right and things that went wrong, strengths and weaknesses of the project and project management processes, and the remaining steps required to terminate the project. PM reviews all information (from the previous phase closures) to ensure that all project work is complete and that the project has met its objectives. If your organization has a way to publish or leverage these key learning’s, they should be sent to the appropriate group.

 

2.       Declare success or failure. Sometimes it is obvious the project was completely successful and in other cases the project is a total failure. However, in many cases, there are mixed results. For instance, the major deliverables may have been completed, but the project was over budget. Or, the project team delivered on time and within budget, but the solution only met 80% of the business requirements. The project team should first rate itself on how successful they were, and then take the recommendation to the sponsor for validation. If the project is terminated before completion, then this process also establishes the procedures to investigate and document the reasons. Also If the project is terminated before completion, the formal documentation should indicate 'why the project was terminated' and formalize the procedure for the transfer of the finished and unfinished deliverables of the cancelled project to others.

 

3.      Analyzing the PM processes to determine their effectiveness. A meeting should be held with the project team, sponsor and appropriate stakeholders to formally conclude the project. This meeting will include a recap of the project, documenting things that went right and things that went wrong, strengths and weaknesses of the project and project management processes.

 

4.       Transition the solution to operations (if applicable). If the solution will exist outside of the project, it should be transitioned to the appropriate operations organization. The transition includes knowledge transfer to the operations team, completion and turnover of all documentation, turnover of the list of remaining work, etc

 

5.       Turn over project files (if applicable). Determine which project and project management materials accumulated during the project should be turned over to the operations team. Some of the project material may be deleted or destroyed, backed-up, archived, etc. Those files and documents needed by the operations organization should be turned over to them to store in the appropriate long-term library or folders.

 

6.       Update Historical Information. Historical Information and Lessons Learnt information must be transferred to appropriate knowledge base for use by other projects or phases. This can include information on risks and issues as well as techniques that worked well and can be applied to future projects.

 

7.       Reassign the remaining project team. Any remaining team members should be reassigned when all the termination activities are completed. For some people, this may mean completely new projects. For contract people, it may mean the end of their assignments. For part-timers, it may mean a return to their other full-time role. Some team members may transition into the support organization to continue working on this same solution.

 

It is the responsibility of the project manager to build project closure activities into the project schedule. These should be seen as vital parts of the project, not an afterthought as the team is getting disbanded. The project is not considered complete until the closure activities are performed.

 

 

Hope this helps.

 

Regards,

Arun Manglick