Great Manager

I have always believed that managers are born, not made. There are certain innate qualities that a manager should possess. However, not every person who becomes a manager has all the great qualities that you would expect to see. So, in my opinion, these are the traits that transform a manager into a great manager:

 

·         Be Approachable – Whether you have a solution to your team member's problem or not, your team member should feel free to come up to you and discuss their issues.

·         Be Receptive – You need to be open to how your team members perceive you and your actions – you need to be open to negative feedback and also discuss about corrective actions, if any.

·         Be An Example – You cannot expect your team members to follow certain rules if you do not follow them yourselves – you have to set the example and lead the path – that is the true mark of a leader.

·         Be Assertive – When a team member is going down the wrong path, you need to immediately take corrective action and guide them back – if you are reactive and just point out mistakes without any guidance on how things could be handled differently, your team member will not know how to improve.

·         Be Well Judged – Not every team member needs to be monitored or managed the same way. Some people need focused mentoring, some people are independent contributors who require some guidance from time to time, some are go-getters and don't need much support – so don't use the same yardstick for all team members.

·         Be Appreciative – Whenever your team member does well, be prompt in appreciating – if we forget, they don't forget… J Shower your team with accolades when they deserve it! It costs you nothing!

·         Be Humble – Modesty as a manager is a very important quality to have. When your team sees you as another human being, who is just their bridge to upper management and who protects them in adverse situations, the usual barriers start to dissolve.

·         Be Objective – As a manager, you always have to play fair and be objective. You may personally like some of your team members more than others, but when it comes to a professional environment, nobody can be your favorite. Everyone has to be treated equally. That does not imply that you give the same professional responsibilities to everybody – that has to be decided based on your team member's capabilities.

·         Be Genuine – Most people can see through artificiality. As a manager, you have to care about the growth of your team members, and not as part of some goal-setting activity. You have to be able to understand their strengths and guide them to use their strengths to their advantage.

·         Be Fun – Nothing endears a team to their manager more than somebody who can let down his or her hair at times when the occasion calls for it. Sometimes the fear of losing the team's respect prevents you, as the manager, from participating wholeheartedly in team activities, and this can affect how the team perceives you.

 

I hope this article proves helpful to those who are struggling as a manager or are soon going to become one!

 

 

 

 

Thanks & Regards,

Arun Manglick, (PMP®, PMI-ACP®, PRINCE2® Practitioner, CSM®, MS-Project, CSSGB, ITIL V3, MCPD, MCTS, MTECH)

Project Manager - Forecasting
Mobile: 9158041782| 9850901262| Desk Phone: +912040265348 | http://www.synechron.com

SYNECHRON -
- 4,000+ professionals globally.
- USA | Canada | UK | The Netherlands | UAE | India | Singapore | Hong Kong | Japan

web - facebook - twitter - linkedin

❚ Watch: The Synechron Story ➪
❚ In the News: CNBC, Inc., Economic Times, ... ➪

 

 

 

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