Project Management Using Microsoft Project Professional 2010

HOW TO KEEP THE PROJECT MOMEMTUM GOING

2014-02-12T22:27:00.002-08:00

Tip #1: Set achievable deadlines

Complete everything by Friday? That's a lot to ask. So set deadlines for your team members that are achievable. In fact, it's even better to get them to help you set the deadlines. If they sign up to completing a task by a particular date then they are far more likely to achieve it than if you told them what the deadline is.

Split big tasks into smaller tasks so that each part has a separate end date. This will also make the deadlines more achievable and easier to monitor.

Tip #2: Monitor progress

You'll be able to see how well you are making progress on your project if you monitor the status of each task. Monitoring will also help you see if anything (or anyone) is slowing down, allowing you to talk to them about keeping the momentum going. Use real-time information to check the progress of tasks and ensure that everything is moving forward.

Of course, you need a plan to monitor progress against, so make sure you have all the tasks and proposed completion dates noted down for you to check against.

Tip #3: Share your progress with others

It isn't enough for you to know that progress is being made. In order for others on the team to feel as if they are achieving their project goals everyone should be updated on the project progress.

Being able to see that the project is moving forward is a great motivator and will help the team keep going towards those end goals.

Tip #4: Celebrate success

Don't wait until the end of the project to celebrate success! Find a few moments through the project where something has been achieved that is worth shouting about and celebrate those. For example, the end of the testing phase when you have a product that is fit for shipping, or the completion of a big piece of design. It really doesn't matter what you are celebrating as long as it is linked to the project somehow and you can use the occasion to demonstrate what progress is being made and what is still to do. Even small celebrations motivate team members which in turn helps you drive the project onward.

Tip #5: Don't take on too much

A massive project can be daunting for everyone on the team and you might find that work slows down because people are overwhelmed. Split your project into smaller phases and deliver it a bit at a time. This can help structure the work into achievable pieces and make it manageable. If it feels less daunting, the team will be more confident about making progress.

5 BIGGEST CHALLENGES AS A PROJECT MANAGER

2014-02-12T22:23:00.001-08:00

1. Dispelling PM myths about Project Manager’s and project management in general

It’s the myth that Project Manager’s are just paper pushers. They’re just working on admin, administrative stuff, that they’re bullies. They’re the ones who are always on my back about things and they get in the way. They give me too much extra stuff to do. They just add extra work to the project. Those are myths that I think Project Manager’s spend a lot of time working on trying to dispel. Just to get the credibility back into their role and to the field of Project Management.

2. You have to re craft and reorganize

There’s so much going on now whether it’s your industry, whether it’s technology, but it’s keeping up, not only on that, but also the changes that are occurring constantly on the project. So, hang on, change is coming, because what happens is that changes the priorities and when priorities change you lose your resources, you lose your budget, and things constantly change.

3. Staying relevant. So, having the time to develop yourself

To learn what are the trends going on in my industry. What’s the technology that people are using? Now organizations are incorporating using mobile phones, social media, and new tools. Also, policies. What kind of policies are infecting the environment, our industry? Whether it’s telecommunications, technology, real estate, all types of industries. What methods? There are all kinds of methods now and knowing which method is appropriate for you type of project.

4. Losing resources

So, as things change and they’re higher priority projects, invariably you lose your people or your budget. You know, the critical resource, the super star on your project, that you fear, “Oh my god if I lose that person, I’m dead in the water”. Well typically, we do, and then the budget, so budget gets reallocated to other projects. So therefore, you have to go back re prioritize your work. Change it, and that’s constantly happening.

Then the other one is standing firm. There’s actually a song that says “Know when to hold ‘em and when to fold ‘em”. I think it’s harder to actually stand and hold ‘em. Meaning, step up or go to bat for things in your group, whether it’s resources, trying to fight for or stand for the people so that you don’t lose them. Go to your organization and let them know why it’s important that you keep that resource. Or time, you may have to go back to your stake holders and position and stand firm that you need more time, things have changed, actually go to your change control board. Then process changes. So, there may need to be some process changes in your organization where you have to change things in order to be more efficient.

5. Politics, dealing with the gremlin of politics in your organization

So, it’s harder to stand firm. I think if a Project manager can overcome some of these challenges then they can begin arming themselves to handle the other challenges, like the risk, the change, the managing risk holders expectations, and all those things that the other research reports back.

5 RISKS TO PROJECT SCHEDULE

2014-02-12T22:14:00.000-08:00

Project managers rely on their schedules. The Project Schedule is the one document that tells everyone what they should be doing, when it needs to start and how long it should take. It is also used to track progress, so managing a project without a schedule is virtually impossible if you want to achieve the agreed milestones and delivery dates. However good we think our schedules are, there are always risks when it comes to managing tasks, resources and the project scope. Here are 5 scheduling risks that you could be facing – how will you manage these on your project?

1. Not Scheduling Vacations

Is anyone taking an annual vacation this year? Yes? Well, are those dates incorporated into your project schedule? It can be difficult to get this information from your project team members, especially if they don’t work directly for you, but the best thing to do is to bring it up during one of your regular team meetings. Use your normal team collaboration approaches to check the dates of everyone’s planned annual leave (including your own). Then you can incorporate this downtime into the schedule. If you don’t, there is a risk that you’ll be allocating tasks to team members when they aren't even in the country. This will delay the project overall and it could inconvenience other teams and departments that are waiting for those tasks to be completed.

2. Scheduling Everyone At 100%

Everyone is dedicated to your project and gives it their all, right? Wrong, but not for the reasons you might think! Even the most dedicated project team member won’t spend 100% of their day – 7 or 8 hours – working on your project. They go and buy a sandwich, they talk to a colleague they haven’t seen for ages, they have a doctor’s appointment… The list of things to fill up a day with (that aren't your project) is huge.

The risk here is that your schedule will suffer delays as tasks take longer in reality than you planned. The best way to handle this is to make sure that you only schedule project team resources at 80% capacity. You can do this every day by limiting the amount of hours of tasks they have to do, but it is probably easier to do it by week. Everyone’s availability per week then only becomes 4 days out of 5.

If you report or update your schedule on a weekly basis this should be manageable. If you do update your schedule more regularly than this you may have to look at scheduling on a daily or hourly basis instead.

3. Forgetting Tasks

Ideally, your project schedule should include absolutely everything from the very first day that you commit your thoughts to your online project management tool. Unfortunately, it is rare that project teams have that much clarity about project tasks, and there is normally something that has been forgotten!

Small tasks may be able to be accommodated without many issues, but if you have left out something major – well, that’s a different problem.

There’s a risk that uncovering a large task that has been missed delays your schedule to the point where you can’t achieve the published deadlines. Then you’ll have to submit a change request to your project sponsor and ask for the end date to be officially moved.

Build in a mechanism or process to deal with forgotten tasks and remember to review your schedule regularly with your team. This will at least ensure that you have the time to discuss any extra tasks with your team members, so there is less likelihood of tasks being overlooked.

4. Inaccurate Estimates

If you are doing something for the first time it can be difficult to work out exactly how long tasks will take. Even subject matter experts may not know, even if they have done something similar before.

Projects are generally unique and anything with a bit of innovative thinking may require you to plan for tasks that have never been carried out in the company before, such as the launch of a new piece of software or a new product.

Inaccurate estimates can be a risk to your project schedule because they mean your milestones and end date can change dramatically. Normally the problem comes when the estimates are too low – not many project sponsors worry about delivering a project early!

5. Scope Creep

Scope creep is when unauthorized changes slip through and make it into the project scope. This results in the team doing more work than originally planned. Scope creep normally happens when a key stakeholder puts forward a request to change something and this does not, for whatever reason, go through the change management process.

Over-enthusiastic sponsors are often the culprit! They ask for changes without necessarily understanding the full implications for the schedule, resource plan or budget, and yet the team has to make the change. The risk here is that the overall project schedule slips. Critical tasks may not get completed on time as team members are working on new changes, and that can create delays that you might not be able to make up.

The best way to avoid the risk of scope creep is to ensure that all changes go through the approved change management process. A good project schedule is the foundation for any project, and the project manager should make sure that it is as accurate as possible. All projects face risks, and risks to your schedule are no different.

RISK PROFILES & RESOLUTION : RISK MANAGEMENT IN A PROJECT

2013-10-07T01:11:00.004-07:00

Risk Profiles

Risk to a project can be measured on two major axes: Likelihood of failure and Impact of failure

The more likely a problem is to occur, the more risk it poses to the project. Even fairly minor problems or issues can become a threat to the project if they occur so frequently that they can’t be avoided. Similarly, the impact or consequences of a problem are also important. Some problems can stop a project in its tracks all by themselves.

Many systems exist for categorizing risks into different categories but the one presented here is fairly simple. In this system each risk item is qualified on two scales: likelihood and impact.

Each scale is divided into two simple categories of “ Low ” or “ High ” and risks are rated according to each scale.

A. “ Critical ” issue represents one that will stop the project in its tracks (known as a “Show Stopper”) and must be dealt with immediately.

B. “ Major ” risks represent a significant threat to the project because of their frequency or because of the seriousness of their impact; these threats usually have to be dealt with as soon as possible.

C. “ Minor ” risks which are neither likely nor particularly serious and can be left until others have been dealt with. Minor risks however have an annoying habit of turning into major ones when your back is turned.

Resolution of risks

Once you have profiled your risk they can be ranked into an ordered list representing the various threats to the project to be dealt with. The more significant can then be examined and assigned an action by the project team.

Typical actions are as below

Research : The risk is not yet fully understood. Its impact or likelihood of occurrence may be unclear or the context in which it may occur could seem unreasonable. Further research by members of the project team is
warranted.

Accept : The risk is unavoidable and must be accepted as-is. This category of risks become extremely important to a project since they cannot be resolved but still represent a threat to completion. Anticipation therefore become the key to dealing with this category of risk.

Reduce : The risk as it stands is unacceptable. The project team must act to reduce the risk and to establish contingency plans should the risk occur. The risk will have to reviewed in future to define the threat it poses.

Eliminate : The risk is unacceptable under any circumstances and must be eliminated as a possibility. The project team must put in place processes and procedures not only to ensure the immediate threat is eliminated but that it does not re-occur in the future.

COSTING & BUDGETING OF A PROJECT

2013-09-30T23:14:00.000-07:00

COSTING & BUDGETING OF A PROJECT

Some projects are relatively straightforward to cost but most are not. Even simple figures like the cost per man/hour of labor can be incredibly difficult to calculate and in most cases approximations are used. Some fundamental principles to keep in mind are derived from standing accounting practice as below:

The Concept of 'Prudence' - You should be pessimistic in your accounts (“Anticipate No Profit and provide for all possible losses”). Provide yourself with a margin for error and not just show the best possible financial position. It’s the old maxim: promise low-deliver / high once again.

The 'Accruals' Concept - Revenue and costs are accrued or matched with one another and are attributed to the same point in the schedule. For example if the costs of hardware are in your budget at the point where you pay the invoice, then ALL the costs for hardware should be “Accrued” when the invoice is received.

The ‘Consistency’ Concept - This is similar to accruals but it emphasizes consistency over different periods. If you change the basis on which you count certain costs you either need to revise all previous finance accounts in line with this or annotate the change appropriately so people can make comparisons on a like-for-like basis.

Costing

At a basic level the process of costing is reasonably simple. You draw up a list of all your possible expenditure and put a numerical value against each item; the total therefore represents the Tangible Cost of your project.

Tangible Costs

Capital Expenditure - Any large asset of the project which is purchased outright. This usually includes plant, hardware, software and sometimes buildings although these can be accounted for in a number of ways

Lease Costs - Some assets are not purchased outright but are leased to spread the cost over the life of the project. These should be accounted for separately to capital expenditure since the project or company does not own these assets

Staff costs - All costs for staff must be accounted for and this includes (but is not limited to): Salary and Pension (superannuation) costs; insurance costs; recruitment costs; anything which can be tied directly to employing, training and retaining staff

Professional services - All large-scale projects require the input of one or more professional groups such as lawyers or accountants. These are normally accounted for separately since a close watch needs to be kept upon expenditure in this area. Without scrutiny the costs of a consultant engineer, accountant or lawyer can quickly dwarf other costs

Supplies and Consumables - Regular expenditure on supplies is often best covered by a single item in your budget under which these figures are accrued.

One-off costs - One-off costs apply to expenditure which is not related to any of the above categories but occurs on an irregular basis. Staff training might be an example. While it might be appropriate to list this under staff costs you might wish to track it independently as an irregular cost. The choice is yours but the principles of prudence and consistency apply.

Overheads – Sometime called indirect costs, these are costs which are not directly attributable to any of the above categories but never-the-less impact upon your budget. For example it may not be appropriate to reflect the phone bill for your project in staff costs, yet this still has to be paid and accounted for. Costing for overheads is usually done as a rough percentage of one of the other factors such as “staff costs”.

Intangible Costs

It has become fashionable to account for “Intangible” assets on the balance sheets of companies and possibly also projects. The argument goes like this: some contributions to a project are extremely valuable but cannot necessarily have a tangible value associated with them.

Typical things you might place in the budget under intangibles are “Goodwill” and “Intellectual Property”. Personnel-related figures are a frequent source of intangible assets and so you might find things like “Management Team”, “Relationships” & “Contacts” on an intangibles balance sheet.

Budgeting

Once you have costed your project you can then prepare an appropriate budget to secure the requisite funds and plan your Cash Flow over the life of the project. An accurate cost model will of course entail a fairly detailed design or at the very least requirement specification so that you can determine your scope of work. This is normally completed well into the design phase of the project.

The sad truth of the matter however is that more often than not you are required to prepare some sort of indicative budget before approval of the project and you are often held to your original estimates. You must be extremely careful with initial estimates and always follow the “Promise Low / Deliver High” commandment.

Costing and Budgeting follow the Iterative life cycle as do other tasks within the project. As you refine your design, so you will need to refine the costing which is based upon it. As in scheduling, you need to build in adequate contingency (reserves) to account for unexpected expenditure. For example, if due to a failure in the critical path a task is delayed and a milestone (like software purchase) falls due in the month after it was scheduled. This can wreck your carefully planned cash flow. But if you have carefully budgeted your project then variations should be relatively easy to spot and cope with as they arise.

PRINCIPLES OF PROJECT SCHEDULING

2013-09-25T23:00:00.003-07:00

In truth the art of scheduling a Project is based on experience and the more experience you have, the more

accurate your schedule will be.

However, by following some simple rules you can still produce an accurate schedule.

Rule #1 - Don't commit to something you can’t Deliver

Scheduling is one part prediction and one part expectation management. If you are pressured into picking a date “on-the-fly” at a random meeting you can bet that the date will not only be wrong, it will come back to haunt you.

Rule #2 - Eliminate uncertainty wherever you can

The more specific you can be in your project planning, the more accurate your schedule will be. If you leave functionality or other items unspecified in your plan, then you will, at best, only be able to approximate them in the schedule. Don’t go overboard, though, there is a balance. If you are spending time adding detail to tasks which will have no impact on the project delivery date, then you are probably wasting your time.

Rule #3 - Build in plenty of contingency to cope with variation

No matter how well specified your project and how accurate your schedule, there will be the inevitable random influences that will wreck your carefully crafted schedule. People get sick, equipment fails and external factors join together in a conspiracy to see that you miss your target date. In order to buy yourself some insurance you should build in an adequate amount of contingency, so that you can cope with unexpected delays.

Rule #4 - Pick the right level of granularity

When drawing up your schedule it is important to pick the right level of detail. If you are going to require daily updates from your team then it makes sense to break into day-by-day chunks. That way everybody has the same understanding of what must be achieved by when.

On the other hand if your project has large portions of time devoted to similar activities, testing for example, then it may be better to simply block-schedule one or two months of testing. Maybe you can leave the details up to your team, it all depends on the level of control you want.

Rule #5 - Schedule for the unexpected

Project management is the art of handling the unknown.

Often events and circumstances you could not have foreseen will interrupt the flow of your project. It’s your job to take them all in your stride. Schedule for the most likely delays and cope with them should they arise. If experience or instinct tells you that a certain type of task will overrun, then anticipate it, pad it with some

contingency and make sure you have adequate resources on hand when it comes up.

THE PURPOSE AND ELEMENTS OF PROJECT PLAN

2013-09-25T22:38:00.003-07:00

The purpose of a project plan is to maintain control of a project.

As a complicated process, a project always threatens to exceed the limit of your control. To maintain control you need help in the form of tools, your best tool is your plan.

The project plan controls the project by:

• Breaking a complex process down into a number of simpler components

• Providing visibility for obscure or ambiguous tasks in the project

• Providing a single point of reference for everyone

• Enforcing scrutiny of the sequence and nature of events

• Providing a baseline against which the actual execution of the project can be compared

• Anticipating likely events and providing pre-planned means of avoiding them

A project plan must be as accurate, complete and as specific as possible. How accurate, complete

and specific of course depends upon how much time and resource you have available.

The Elements of a Project Plan

Every project planning methodology has its own specific taxonomy and names for its parts. But in a very broad sense the minimum elements a project plan must specify are:

What is to be done – what is desired of the project and what it must deliver to succeed. This is a scope document at a high level and requirements specs. at lower levels

When it needs to be done by– the deadlines by which the objectives must be met

Who is to do it – The people, sometimes unkindly labelled “resources”, or the team who are to deliver those objectives. This also usually implies costs since in most projects the application of costs implies the use of skilled employee

How it is to be achieved – This is normally in documents such as a technical specification

You do not need to complete all of these prior to starting your project. Typically one draft of the proposal, schedule and budget are completed before your project commences. Each of the other documents will be completed at some point through the life cycle.

SMART REQUIREMENT IN PROJECT

2013-09-25T04:38:00.001-07:00

SMART requirements

One useful acronym for defining requirements is SMART :

Specific : A goal or requirement must be specific. It should be worded in definite terms that do not offer any ambiguity in interpretation. It should also be concise and avoid extraneous information.

Measurable : A requirement must have a measurable outcome, otherwise you will not be able to determine when you have delivered it.

Achievable : A requirement or task should be achievable, there is no point in setting requirements that cannot realistically be achieved.

Relevant: Requirements specifications often contain more information than is strictly necessary which complicates documentation. Be concise and coherent.

Time Bound: In order to be of value requirements must be completed within a defined time frame. As well as T stands for testable. You must be able to prove that the requirement has been satisfied. Requirements which are not testable can leave the project in limbo with no proof of delivery.

FUNCTIONAL & NON-FUNCTIONAL REQUIREMENTS OF PROJECT

2013-09-20T04:47:00.001-07:00

Requirements specification is the process of refining the goals of a project to decide what must be achieved to satisfy the clients.

Functional Requirements

Functional requirements are the obvious day-to-day requirements end-users and stakeholders will have for the product. They revolve around the functionality that must be present in the project for it to be of use to them.

A functional requirement typically states as “The system X must perform function Y”. This is known as an ‘assertion’. An assertion asserts or affirms a necessary or desirable behavior for the system or product in the eyes of a stakeholder. Without clear assertions requirements are nothing more than vague discussions which have a regrettable tendency to clutter up your desk and your mind.

Some more ‘better’ statements of requirements:

A customer account record must contain a unique account reference, a primary contact name, contact details and a list of all sales to the customer within the past sales year
Contact details must consist of a phone number, an address and an optional email address
For each contact up to five separate phone numbers should be catered for

Non-Functional Requirements

It is essential to consider the other requirements too, these are called “non-functional requirements” which, to my mind, is a bit of an oxymoron.

1. Performance : Performance usually covers areas such as responsiveness, throughput and speed of operation. What is the minimum performance that will satisfy your client ?

2. Usability : How “easy-to-use” will the finished product be ? For example do you cater for disabled or handicapped users ? Generic ease of use should be considered though, more than one product has failed by supplying full functionality with an obscure or convoluted interface.

3. Reliability : Reliability requirements deal with the continuous availability of the product to users. They should state what availability is necessary and desirable.

4. Security : In products which deal with confidential or sensitive information, security considerations should be taken into account. Requirements for different levels of access, encryption and protection should be gathered.

5. Financial : There may be financial considerations which will determine the success or failure of the project. For example a bank or investor might specify certain financial constraints or covenants which must be satisfied during the project.

6. Legal : There may be legal requirements that must be met due to the environment in which your product will operate. Consult a legal expert for these.

7. Operational : There may be a number of day-to-day operational issues that need to be considered. Failure to accommodate these will not delay project launch but may limit or halt its uptake by end-users once it has been launched.

8. Specialist : In every project there are a number of specialist requirements which are dependent upon the nature of the project or the nature of the business. These should be considered separately and explicitly stated within design docs.

THE MYTHICAL MAN MONTH : SIMPLY ADDING RESOURCES IN PROJECT WILL NOT ENSURE EARLIER DELIVERY

2013-09-18T01:58:00.001-07:00

Simply Adding Resources to your Project will not Ensure

Earlier Delivery

In “The Mythical Man Month” Brooks argues Main article: No Silver Bullet that adding people to a project doesn't speed it up. While it is true that more resources can speed up the delivery of a software product, the increase in speed is not directly proportional to the amount of resource added. To put it another way, simply adding resources to your project will not ensure earlier delivery.

The Main reason for this is the increased complexity of communications which results from adding more people. As each person is added to the project team the complexity of communications goes up exponentially. For each project there is a break-even limit where adding more people will in fact slow down the project.

The diagram above demonstrates the principle graphically. Note that you need not consider each of the ‘nodes’ in the graph an individual person – they could be a group of people or an organisation within the project that has an interface.

Every additional person brought into a project during the development cycle will need to be trained and briefed on the current status and assigned tasks. As more and more people are added, more of the original team must be devoted to managing the overall structure. This is a truism of all types of management, not just project management.

Adding more people to a project requires ‘bandwidth’ to manage them and can distract you from more important goals at hand.

There are a few things to learn from Brook's “Mythical Man Month” :

1. Small autonomous teams are more efficient than large bureaucratic ones, so divide your project up into manageable chunks and let each group work within some kind of defined boundary.

2. If you want to add people to a project, you had better plan carefully plan how those people are introduced into the team, there will be a lag before they become productive and even be a drain on the productivity of other members of the team. Look for ‘flat spots’ in the schedule to introduce these people to the team.

3. One of your options in the “scope triangle” has just been reduced! If the scope of your project expands you know there’s only a limited benefit in adding more people to the project because of the overheads involved. We’re back to those same two options again :ask for more time; or cut functionality!

SCOPE TRIANGLE IN PROJECT

2013-09-18T00:06:00.001-07:00

SCOPE TRIANGLE IN PROJECT

Scope Triangle’ or the ‘Quality Triangle’ shows the trade-offs inherent in any project.

The triangle illustrates the relationship between three primary forces in a project.

Time is the available time to deliver the project
Cost represents the amount of money or resources available
Quality represents the “fit-to purpose”that the project must achieve to be a success.

In reality the normal situation is that one of these factors is fixed and the other two will vary in inverse proportion to each other.

For example “Time” is often fixed in a project and the “Quality” of the end project will depend on the “Cost” or resources available. Similarly if you are working to a fixed level of “Quality” then the “Cost” of the project will largely be dependent upon the “Time” available.

A phenomenon known in project management circles as “Scope creep” can be linked to the triangle too. Scope creep is the almost unstoppable tendency a project has to accumulate new functionality. Some scope creep is inevitable since early on, your project will probably be poorly defined and will need to evolve. A large amount of scope creep however can be disastrous. When the scope starts to creep new functionality must be added to cover the increased scope. This is represented by the quality arm of the triangle, representing the ability of the ‘product’ to fulfill users’ requirements.

More requirements fulfilled = a Better Quality Product

In this situation you have three, and only three options :

1. Add time – delay the project to give you more time to add the functionality

2. Add cost – recruit, hire or acquire more people to do the extra work

3. Cut quality – trade off some non-essential requirements for the new requirements

If the art of management lies in making decisions, then the art of project management lies in making decisions quickly! When faced with such a dilemma you should not hesitate to take one of the three options listed above. Delaying raises the risk of your project failing.

The best project managers will juggle all three like hot potatoes and will make decisions every day which effectively trade-off time vs quality vs resources.

CHANGE WORKING HOUR IN MS PROJECT PROFESSIONAL 2010

2012-06-12T06:57:00.004-07:00

Change Working Hour From 11 AM To 8:30 PM for 5 Days in a Week

Please Follow the Below Steps

Project > Change Working time.
In the Change Working Time dialog, click the Work Weeks tab and click details.
Select Sunday in the left side, Shift+Click on Saturday to select all 5 days.
Click in the option button "Set days to these specific working times" and enter: From: 11:00 To: 20:30

INSERTING NEW RESOURCES IN RESOURCE SHEET VIEW IN PROJECT PROFESSIONAL

2012-06-12T06:28:00.002-07:00

Inserting New Resources in the Resource Sheet View

During the resource planning process, you first build the team of resources to work on tasks in your project. Microsoft Project 2010, like its 2007 predecessor, offers Work, Material, and Cost resource types. A new feature in the software, the Add Resources Pick list, allows you to insert a new resource in the Resource Sheet view, by selecting a resource Type.

To insert a new resource in your project, complete the following steps:

1. Click the Resource tab to display the Resource ribbon.
2. In the View section of the Resource ribbon, click the View pick list button and select the Resource Sheet view.
3. In the Insert section of the Resource ribbon, click the Add Resources pick list button.

4. On the Add Resources pick list, select the Work Resource, Material Resource, or Cost Resource item.

Microsoft Project 2010 inserts a new resource of the type you selected as below Resource of each type (Work, Material, and Cost).

When you insert a new resource using the Add Resources pick list, Microsoft Project 2010 creates the new resource by inserting the name <New Resource> in the Resource Name field, inserting the < symbol in the Initials field, andselecting the Prorated value in the Accrue At field for all three types of resources.

For a Work Resource, the system also selects the Work value in the Type field, defaults the Max. Units field value to 100%, enters $0.00/hr in the Std. Rate and selects the Standard calendar in the Base Calendar field.

For a Material Resource, the system selects the Material value in the Type field and enters $0.00 in the Std. Rate and Cost/Use fields.

For a Cost Resource, the system selects the Cost value in the Type field.

EXPORTING PROJECT PLAN TO EXCEL WITH MS PROJECT PROFESSIONAL 2010

2012-06-12T05:57:00.001-07:00

Exporting Project Plan Plan to Excel with MS Project Professional 2010

Please Follow the Steps which allow to export to Excel by retaining the formatting of MS Project Professional

1. Select all the Tasks with corresponding details from the Gantt Chart view.

2. Click on File --> Save As
2. Note where the file is being saved
3. Under the Save As Type, select Excel Workbook
4. Click on Save. This starts the Export Wizard
5. Choose Selected Data, then Click Next.

6. Then click on Use Existing Map, then Next
7.Choose the Proper option according to your requirement. i.e. "Task and Resource Pivot table Report"

8. Select Task and Resource as Type of Project Information and Choose Export Includes headers

9. Click on Next until it is no longer available, then click on Finish

WORKING WITH CRITICAL PATH IN MS PROJECT 2010

2012-06-05T04:44:00.000-07:00

Working with CRITICAL Path in Project 2010

The critical path is the series of tasks (or even a single task) that dictates the calculated start date or finish date of the project. If a single task is late on the critical path, the end date of the entire project will also be late. Viewing project information in this manner is also known as the critical path method of project management.

To change the sensitivity of critical tasks, click the File tab, click Options, and then click Advanced. In the Tasks are critical if slack is less than or equal to list, enter the number of days of slack under which a task is considered critical.

There is no point in analyzing the critical path if you can't see it. You can show the critical path in the Detail Gantt view.

HIGHLIGHT THE CRITICAL PATH

Click the View tab.
In the Task Views group, click the arrow beneath Gantt Chart, and then click More Views.
In the More Views dialog box, in the Views list, select Detail Gantt, and then click Apply. By default, the critical task Gantt bars and link lines are red
This format change overrides any direct formatting changes that you might have already made to bar styles or individual bars. This formatting of critical tasks only applies to the current Gantt Chart view in the current project. To save this formatting, click Organizer in the More Views dialog box.

SHOW ONLY THE CRITICAL PATH

Go to a Gantt Chart view, if you are not in one already.
On the View tab, in the Data group, click the Filter list and then click Critical.
To display all tasks again, in the Filter list, click No Filter.
To quickly see the list of tasks on the critical path, on the View tab, in the Data group, click the Group list and then click Critical. The critical path tasks are listed together under the heading Critical.

TASK DEPENDENCIES: FS / SS / FF / SF IN MS PROJECT PROFESSIONAL

2012-06-01T03:30:00.002-07:00

Task Dependencies : To Define the Relationships Between Tasks

Predecessor :

A predecessor is a task whose start or finish date determines the start or finish date of its successor task.

Successor :

A successor is a task whose start or finish date is driven by its predecessor task.

The nature of the relationship between a predecessor task and a successor task determines the type of task dependency to use. We can use FOUR types of task dependencies.

Finish - To - Start [ FS ]
Start - To - Start [ SS ]
Finish - To - Finish [ FF ]
Start - To - Finish [ SF ]

For Example, if we have Two tasks, Task 1 and Task 2 in our Testing Project , we can define all the 4 relationships by following steps:

If Task 2 is having Predecessor as Task 1, double Click on Task 2
Task Information window will appear
In the Predecessor section, select the option from Type Drop down list ( FS / SS / FF / SF)
Ok

A. Finish - to - Start Dependency

Task 1 must finish before Task 2 can start. This is the By Default Dependency created and very commonly used Relationship in Project.

B. Start - to - Start Dependency

Task 1 and Task 2 must start at the same time.

Benefit of using SS Dependency

Overlapping work helps to reduce the overall duration of a project. In our Testing Project, as we can see from the Total Duration of the Project, we Save 3 days’ work by using SS Dependency.

C. Finish - to - Finish Dependency

Task 1 and Task 2 must finish at the same time.

FF dependencies also reduce the overall amount of time in Project, same as SS Dependency.

If Task 1 will take 5 days to complete, and Task 2 will take 3 days to complete, with FS dependency the overall duration of the two tasks is 8 days.
If we set an FF dependency, the overall duration of the two tasks is only 5 days.

D. Start - to - Finish Dependency

Task 2 cannot finish until the start of Task 1. This is VERY RARE scenario of Task in any type of Project.

As we can see Task 2 has been moved from his scheduled Start date due to SF Relationship.

As an Example, A particular task needs to finish before a milestone or project finish date, but it doesn't matter exactly when and we don't want a finish it late to affect the regular task in that scenario we can use SF dependency

FIX ISSUE : BASELINE IS NOT APPEARING FOR THE TASK IN TIME SCALE SECTION

2012-05-31T03:32:00.003-07:00

Problem with Baseline Appearance for Task

Definition: Baseline is the value or condition against which all future measurements will be compared .

Baseline Finish Date:

The term baseline finish date applies to the date on which a schedule activity is expected to be completed.

Baseline Start Date :
The term baseline start date applies to the actual scheduled start date of a schedule activity within the approved schedule.

To Configure Baseline for Task in Project Professional

Project Tab - in Schedule Section Select Set Baseline
Select Any of the 11 baseline available from the Set Baseline Drop Down List
Select Entire Project or Selected Task depends on your requirement
OK

If the Baseline does not appear

Right Click on Time Scale section
Select Bar Style
Select Baseline option from List
Select Baseline Start and Baseline Finish from the Drop Down
Change the Color and Shape of the Bar if you want
Same changes can be Done for Baseline Milestone and Baseline Summary Option as well.
OK

MAINTAIN HOLIDAYS/NON-WORKING DAYS IN PROJECT CALENDAR : SET EXCEPTION

2012-05-31T02:57:00.004-07:00

Define Holidays or Exceptions in Project Calendar

Go to Project Tab
Under Properties - select Change Working Time
Lets say we want to maintain 15th August as Independence Day Holiday for our Project During Project life cycle.
Select 15th August from the Current Year Calendar i.e. 2012
Write Down Independence Day or the Holiday Reason in Name section under Exception tab as below
The Start and Finish date will appear automatically

Click on Details option
Choose the Recurrence Pattern as Yearly, since Independence Day come once in a Year
Select the Range of Recurrence according to the requirement
Choose the End After or End By option to make sure how long you want to continue this exception. ( Project Professional Supports up to the year 2049)

OK
Come back to calendar and see the difference
now we can see 15th August as Exception/ Non working day with the reason of the Holiday as below up to the year 2049.
As we can noticed 15th August date is Grayed out in the Calendar.

Same way we can put weekly holidays for particular resource or all resources
We can maintain the work hour/special work hour on weekend on in Saturday
We can maintain the schedule for a particular weekday for every month (Example: Third Wednesday every month) [Check the entire recurrence pattern one by one]

CHANGE THE VIEW OF TASK DURATION & % COMPLETE IN TIME SCALE IN MS PROJECT PROFESSIONAL

2012-05-31T01:22:00.001-07:00

Change the Style and View : Task Duration and % Complete of Task

In Microsoft Project Professional 2010 we can see the Resource Name and % completed for any of the Task in the Time scale section under Gantt Chart View.

To Change the View and Style:

Right Click on Time Scale empty section.
Select Bar Style
Click on Text Tab below
Change the appearance by choose the desired option from Drop Down List for Left and Right align

Click OK
Now we can see the difference in the Appearance