My way to PMP certificate

Probably all of You know what are projects, their importance and PMP certificate.

My first contact with PMI and PMP was during my first Project Manager experience and ever since I started thinking how to obtain this certificate. It is currently considered most valuable certificate in whole world, but it is also one of most difficult one to obtain. Many of my friends and colleagues tried to pass it and failed. Naturally this brought something like a really big fear of "PMP exam" - even thou I still didn't know what is this exam really about..

After talking to many people tutoring for this exam, and few of them who passed it I decided to give it a try.

Here is my path for PMP preparation - what materials I used, what test examples and books I read.

PMP Preparation seminar

PMP preparation seminar. This is obligatory because You'll gain needed 30 PDU points to access PMP exam and You'll get insight to what PMP is all about. My advice is to listen to prep seminar in Your native language or any language You're most comfortable in and try to get involved in lectures and discussions as much as you can. Don't go to one of those fast seminars that last from 1 to 3 days because You won't learn "anything". The way I see it this short seminars are best to repeat what You have learned and NOT to learn something new. You need time to think through what You have heared and learned. Also try to implement what You have learned on prep seminars in Your everyday life and business life. Also, keep all materials from Your PMP prep course - they will probably came in handy to You as much they did to me when I was learning through Rita PMP prep book.

Rita Mulcahy PMP Prep Book 

I'd like to say that this book is also obligatory, even thou You can find all sorts of PMP Exam Prep (I've also red one of them) books on Amazon or other Internet sites. Why Rita? Everyone will tell You that Rita is book that You need to read, learn and that it will be enough to pass this exam. NOT! ¨Maybe because I've used Rita 6 on current exam, but I don't thik so. Rita (the one which I read and learned) has few sections written wrong, and also some sections aren't covered in enough detail to pass exam. Remember that if You plan to use Rita (or any other book) You'll have to do extra reading. If you decide to go with Rita (like I did) read it WHOLE, try to answer all test prep questions (I did it in 3rd pass of book) and remember to learn Rita's process chart (it will help you answer 50% of questions on exam). Also read last chapter (don't skip) where Rita in 2-3 pages writes about what to do to pass exam. If You're wondering how many times I read Rita - 4 times :).

PMP Exam Examples

This is, by far,  most useful learning tool. After I learned (at least i thought I've learned it) Rita, all of formulas and methods I started those exams. Of course I didn't know answers to all of questions, but 50% of them. Then Google is Your best friend :). I started google-ing through exam questions terms, questions, formulas. After a while I managed to learn few thing and narrowed my gap in knowledge. I've tried 3 test simulations - about 630 questions.

Own Notes and Handbooks

Wrote my own PMP exam prep notes and handbook. While I was reading Rita, looking for answers to unknowns of test PMP exams I was writing it all in my little notebook. Also Rita stresses out that inputs and outputs of each Project phase, knowledge area and PM process aren't so important to remember if You know Rita Process Chart. Well that just isn't so. I've had 30 questions about inputs and outputs which even waren't in Rita's Prep Book. This is important for exam. Only source for that data I could think of was PMBOK - but I hadn't time. So I decided to google-it. After some effort I found what I was looking for and I will share it with all of You through my Blog :)
Here are my notes that could help you prepare for exam, and helped me to learn faster: My PMP Notes

Get Rested Before Exam

Remember to get good night sleep before exam because You have little time to review Your answers so You'll need Your concentration!

If you try to go through my steps, I'm sure that You'll pass it from first try like me :)

Good luck!

Zoom Functionality In RTC 2009 R2

Zoom is very handy function that all of NAV users, in very short time, learned what it and use it daily. In classic client Zoom function is started by pressing F8 button or using Tools menu function Zoom.

RTC client also has built in Zoom functionality but it's slightly different than old Zoom function.

Starting Zoom

You can start Zoom function by pressing Ctrl+Alt+F1 key kombination on current page or use standard windows function „Help > About“

 

 You can start Zoom function by pressing Ctrl+Alt+F1 key kombination on current page or use standard windows function „Help > About“

Zoom Data

After starting function RTC Zoom page will appear with more dana than old Zoom:

• Page Information – information about page type, page mode, source table and current record.
• Table fields – old Zoom data
• Source Expressions
• FlowFilter Fields – All flowFilter Fields on current form with applied filters

Access NAV Server Through Multiple Different Domains

Accessing NAV Server Through Multiple Different Domains tends to be wery frustrating! Have you ever encountered situation where You needed to connect NAV RTC client from one domain to NAV Server which is on other domain? Well, I did. And I must say that this is kind'a BIG problem with international companies who have strong security policy.

Well, luckily Microsoft has server and infrastructure issues that came great in solving this problem.

When thinking about how to solve this problem main thing that came to my attention is how to transfer permissions from one domain to another with same users, and at the end how will those users authenticate to NAV server with Windows authentication. I must say that I was really surprised when I found out that windows recognizes users between domains as same users if they have same user name and password.

For start, lets assume that You have created users on NAV server which is in different organizational unit and different domain.

Active Directory Setup

Create users on Server in Active Directory with appropriate rights and in appropriate organizational unit.
When creating users remember that newly created users must have:

• Same username as users on NAV Server
• Same password users set up on NAV Server

When You’ve created user, just click Finish to apply newly created user.

To check if Your user is created as it should check your Organizational unit to see if Your new user is positioned in that Organizational unit.

SQL Server Setup

Create New login with Windows authentication. This user must be with same user name as the one on NAV server, but with domain where is SQL server.

Don't forget to Map user on appropirate NAV Database.

VIEW SERVER STATE on SQL ERROR

Now, users are created and theoretically they should be able to connect to SQL server – but not.
If You try to connect to database (and You have created users in NAV), You'll get View Server State Error.

Next thing is to set up Database properties and grant View Server State Permission to all users that need to connect to Your NAV Database.
To set up users edit Database Permissions on SQL Server Properties.

In upper part of Form You need to find user who You'll give that permission to. After You have found it You need to Grant Explicit permission to View Server State parameter in lower part of form.

Confirm setup with OK button and You're set.

Create Users in NAV

Following standard procedure in NAV create users with Windows Logins and with appropriate permissions.

 

When created, don’t forget to Synchronize them.

This principle is best used in companies who want to use NAV RTC client in their business, otherwise You can direct users to connect through Database logins.

Critical Chain Method

This method is a technique that modifies the project schedule to account for limited resources by adding duration buffers that are non-work schedule activities to maintain focus on the planned activity durations.

Critical chain is completed after determining critical path by entering resource availability and the resulting schedule produces a resource-constrained critical path, which is usually altered from the original. Critical chain focuses on managing remaining buffer durations against the remaining durations of task chains

Critical chain is a Schedule development technique that modifies project schedule to account for limited resources.

Quality Circle

A quality circle is a volunteer group composed of project workers, usually under the leadership of their supervisor, who are trained to identify, analyze and solve work-related problems and present their solutions to management in order to improve the performance of the organization, and motivate and enrich the work of employees. When matured, true quality circles become self-managing, having gained the confidence of management.

Quality circles are an alternative to the dehumanizing concept of the division of labor, where workers or individuals are treated like robots. They bring back the concept of craftsmanship, which when operated on an individual basis is uneconomic but when used in group form can be devastatingly powerful. Quality circles enable the enrichment of the lives of the workers or students and creates harmony and high performance. Typical topics are improving occupational safety and health, improving product design, and improvement in the workplace and manufacturing processes.

The term quality circles derives from the concept of PDCA (Plan, Do, Check, Act) circles developed by Dr. W. Edwards Deming.

Quality circles are not normally paid a share of the cost benefit of any improvements but usually a proportion of the savings made is spent on improvements to the work environment.[citation needed]

They are formal groups. They meet at least once a week on company time and are trained by competent persons (usually designated as facilitators) who may be personnel and industrial relations specialists trained in human factors and the basic skills of problem identification, information gathering and analysis, basic statistics, and solution generation. Quality circles are generally free to select any topic they wish (other than those related to salary and terms and conditions of work, as there are other channels through which these issues are usually considered.

Quality circles have the advantage of continuity; the circle remains intact from project to project.

Pareto Analysis

Pareto Analysis is a statistical technique in decision making that is used for the selection of a limited number of tasks that produce significant overall effect. It uses the Pareto Principle (also know as the 80/20 rule) the idea that by doing 20% of the work you can generate 80% of the benefit of doing the whole job. Or in terms of quality improvement, a large majority of problems (80%) are produced by a few key causes (20%). This is also known as the vital few and the trivial many.

In the late 1940s quality management guru Joseph M. Juran suggested the principle and named it after Italian economist Vilfredo Pareto, who observed that 80% of income in Italy went to 20% of the population. Pareto later carried out surveys on a number of other countries and found to his surprise that a similar distribution applied.

The 80/20 rule can be applied to almost anything:

• 80% of customer complaints arise from 20% of your products or services.
• 80% of delays in schedule arise from 20% of the possible causes of the delays.
• 20% of your products or services account for 80% of your profit.
• 20% of your sales-force produces 80% of your company revenues.
• 20% of a systems defects cause 80% of its problems.

The Pareto Principle has many applications in quality control. It is the basis for the Pareto diagram, one of the key tools used in total quality control and Six Sigma.
In PMBOK Pareto ordering is used to guide corrective action and to help the project team take action to fix the problems that are causing the greatest number of defects first.

Pareto Analysis

Seven steps to identifying the important causes using Pareto Analysis

1. orm a table listing the causes and their frequency as a percentage.
2. Arrange the rows in the decreasing order of importance of the causes, i.e. the most important cause first.
3. Add a cumulative percentage column to the table.
4. Plot with causes on x-axis and cumulative percentage on y-axis.
5. Join the above points to form a curve.
6. Plot (on the same graph) a bar graph with causes on x-axis and percent frequency on y-axis.
7. Draw a line at 80% on y-axis parallel to x-axis. Then drop the line at the point of intersection with the curve on x-axis. This point on the x-axis separates the important causes on the left and less important causes on the right.

Abode diagram is a simple example of a Pareto diagram using sample data showing the relative frequency of causes for errors on websites. It enables you to see what 20% of cases are causing 80% of the problems and where efforts should be focussed to achieve the greatest improvement.
The value of the Pareto Principle for a project manager is that it reminds you to focus on the 20% of things that matter. Of the things you do during your project, only 20% are really important. Those 20% produce 80% of your results. Identify and focus on those things first, but don't totally ignore the remaining 80% of causes.

Hersey-Blanchard Situational Leadership Theory

The Hersey-Blanchard Situational Leadership Theory was created by Dr Paul Hersey, a professor and author of "The Situational Leader," and Ken Blanchard, author of the best selling "The One-Minute Manager," among others.

The theory states that instead of using just one style, successful leaders should change their leadership styles based on the maturity of the people they're leading and the details of the task. Using this theory, leaders should be able to place more or less emphasis on the task, and more or less emphasis on the relationships with the people they're leading, depending on what's needed to get the job done successfully.

Leadership Styles

According to Hersey and Blanchard, there are four main leadership styles:

• Telling (S1) – Leaders tell their people exactly what to do, and how to do it.
• Selling (S2) – Leaders still provide information and direction, but there's more communication with followers. Leaders "sell" their message to get the team on board.
• Participating (S3) – Leaders focus more on the relationship and less on direction. The leader works with the team, and shares decision-making responsibilities.
• Delegating (S4) – Leaders pass most of the responsibility onto the follower or group. The leaders still monitor progress, but they're less involved in decisions.

As you can see, styles S1 and S2 are focused on getting the task done. Styles S3 and S4 are more concerned with developing team members' abilities to work independently.

Maturity Levels

According to Hersey and Blanchard, knowing when to use each style is largely dependent on the maturity of the person or group you're leading. They break maturity down into four different levels:

• M1 – People at this level of maturity are at the bottom level of the scale. They lack the knowledge, skills, or confidence to work on their own, and they often need to be pushed to take the task on.
• M2 – At this level, followers might be willing to work on the task, but they still don't have the skills to do it successfully.
• M3 – Here, followers are ready and willing to help with the task. They have more skills than the M2 group, but they're still not confident in their abilities.
• M4 – These followers are able to work on their own. They have high confidence and strong skills, and they're committed to the task.

The Hersey-Blanchard model maps each leadership style to each maturity level, as shown below.

Maturity Level	Most Appropriate Leadership Style
M1: Low maturity	S1: Telling/directing
M2: Medium maturity, limited skills	S2: Selling/coaching
M3: Medium maturity, higher skills but lacking confidence	S3: Participating/supporting
M4: High maturity	S4: Delegating

To use this model, reflect on the maturity of individuals within your team. The table above then shows which leadership style Hersey and Blanchard consider the most effective for people with that level of maturity.

Preassignment

Preassignment is a tool and technique of the Acquire Project Team process.
This occurs:

• when a project is put out for bid and specific team members are promised as part of the proposal
• when internal project team members are promised and assigned as a condition of the project.

When staff members are promised as part of the project proposal—particularly on internal projects—they should be identified in the project charter.

Phase-To-Phase Relationships

A large project may be broken into specific phases, with each of these phases having specific deliverables. At the end of a phase, a Phase-End Review may occur, which formally concludes that phase, and if the project is deemed worthwhile to continue, authorizes the next phase to begin. There are three major phase-to-phase relationships described in the PMBOK®:

• Sequential Relationship. Here when one phase is complete, the next phase may begin.
• Overlapping Relationship presents that the next phase may begin before the previous phase is completely finished
• Iterative Relationship is useful for largely undefined projects. Planning for the next phase occurs during the current phase

Project may have more than one of these relationships. For example, the early phases may have been performed sequentially, but due to falling behind schedule, later phases will be overlapped.

Sensivity Analysis

Sensitivity analysis is method for modeling risks to projects. It is implemented to analyze the various risks to the project by looking at all aspects of the project and their potential impact on the overall goal. Knowing the level of impact various elements have on a project can assist management with setting priorities to more quickly achieve the end result.
Project management can easily convey the results of a sensitivity analysis through the use of a tornado diagram.

The differences among the risks can be easily seen since the analysis is a quantitative value. Rather than qualifiers describing the risks, the impact of each is quantified in a numerical value. This facilitates comparisons between the various elements to quickly discern which risks are worth taking. Project management can use the sensitivity analysis to create priorities in dealing with elemental risks to the project. By knowing which affects the objective the most, more efforts can be concentrated to lessen that risk. Lowering risk potential allows for projects to flow in a smoother fashion with fewer unexpected delays.

Project Closure

Project Closure is the process or activities associated with finalizing the hand off of the project deliverables to the business team and completing the administrative aspects of closing the project. Most of the project management activities at this time are administrative and are unique to the organization. They involve gaining stakeholder acceptance of the project deliverables, integrating project resources back into the organizations pool of resources, and capturing any lessons learned from the project for use on future projects.

There are four techniques for managing the Project Closeout. This first technique, Closeout Approach, is an organizing principle for guiding the administrative closeout activities. The second technique is a Stakeholder Acceptance meeting. The third technique is the development of a Punch List to drive project closure and prevent scope creep. The final technique is the conduct of a Lessons Learned assessment on the project.


Closeout Approach

The Closeout Approach considers the method that the project deliverables are being hand off to stakeholders and changes the administrative activity accordingly. In all cases, any supplier contracts must be closed with the procurement department. However, the internal closeout process of other activities will vary.

Project Inclusion (addition)

This form of closeout is the simplest from an administrative standpoint. The project team, who has developed the project deliverables, now become the primary user/maintainer of the deliverables. The team essentially hands off the project deliverables to itself. In this case, the project management team needs to close any administrative accounts or files that are associated with development and reopen them for operational deployment of the deliverables. The transition is virtually seamless and administrative in nature.

Project Extinction

This form of closeout is also straight forward. The project activities are immediately terminated. Resources are either redeployed in the organization or they are released. This condition may be created because of problems within the project, or it may be because of conditions that are completely outside of the control of the project team. For instance, closing a project in this fashion because of unexpected ruling by a government regulatory body eliminated the need for the project deliverables.

Project Integration

This form of closeout is the most difficult. The project deliverables are completed and the project team believes that they meet the project objective. However, the project team must ensure that the portion of the organization that is to make use of the deliverables is prepared to embrace them and apply them appropriately to achieve the business benefit. At times there is significant resistance to accepting the deliverables. When a project team is facing this type of closeout they need to ensure that appropriate change management activities are being conducted at the same time they are performing the administrative closeout activities. When the change management is likely to be a significant issue for the project, I include a transition phase to the project that has pilot runs, beta tests, or other transition activities to enhance acceptance by stakeholders.

Stakeholder Acceptance Meeting

The project team meets with project stakeholders to review the deliverables of the project and ensure that the deliverables are acceptable to the stakeholders. It is strongly recommended that this meeting be held by Program Managers with all sub-project teams on Complex programs. This approach is useful when doing projects under contract to ensure that there is a clear endpoint to the project and that the final invoice can be submitted. The format of this meeting often is based upon the Project Charter. The deliverable for each item of the Charter is presented and explained to the stakeholders.

Project Punch List

The Punch List is a technique borrowed from construction projects. When conducting Stakeholder Meetings, gaps are often identified between what the stakeholders wanted from the deliverables and what is being supplied by the project team. The Punch List is used to manage the closure of those gaps. As a deliverables is presented - whether in a Stakeholder Meeting, pilot run, or Beta test - any gaps or deviations are listed and placed upon the Punch List. The project team then identifies the cost and schedule impact of completing the Punch List items and they come to an agreement with the stakeholders concerning which items they must complete and the end point of those new tasks. Both the stakeholders and the project team manage the effort to the Punch List. Stakeholders cannot continue to add items and the Project Team must complete all the items on the list. This technique will quickly drive the project to closure.

Lessons Learned

The Lessons Learned process is usually tailored to the organization. If the organization has a PMO the Lessons Learned process is normally a formal part of project closeout. When there is no PMO, often any Lessons Learned activities are done informally if at all. When I conduct Lessons Learned sessions, I follow a four step process.

Evaluate the Business Case

The first question I ask is whether the project created the business benefit that was used to justify approving the project. This question is less about how well the project team did and is much more focused on senior management and the project selection and approval process. The lessons learned at this point improve the ability of the organization to select projects and to establish realistic project charters.

Evaluate the Project Plan

This question addresses how well the project manager and project management team planned the project. It concerns topics like:

• identification of required activities,
• cost and schedule estimates,
• risk factors,
• team integration and communication.

Evaluate the Project Management Methodology

This question addresses whether the organization's procedures and systems were beneficial for the project or not. It includes asking questions like:

• Are procedures current and relevant?
• Are checklists and templates current and relevant?
• Are the mandated reviews and control points appropriate?
• Is the PMIS useful?

Evaluate Team and Personal Performance

The team then considers how well they executed the plan and followed the methodology. This is normally a self-assessment by the team and can be aided with techniques such as 360 reviews. With respect to formal personal performance appraisals, I recommend that this be done for the core team members on all large projects. The method for conducting the performance appraisal must be accomplished in accordance with local Human Resource practices.

Configuration Management System

The configuration management system is a tool that serves as a subsystem of the top level project management system. It exists to provide formal and specific guidelines to the project management team in applying administrative and technical direction and supervision to a wide range of processes including the identification and documentation of descriptive characteristics of specific items within a project. These items can include products, services, or other assorted components. The configuration management system, when properly implemented, can also guide the project management team when they attempt to change any of these characteristics, demonstrating the proper way to record and document these changes to best meet requirements for documentation and approvals.

Traditionally, the configuration management system is an high-level system that encompasses many other small essential systems such as the change control system. It, like most other project management system, should be implemented at the outset of a project to assure that it is most effective.

Overhead rate

The overhead rate is a component of net multiplier. Overhead expenses are all costs not chargeable to specific projects such as rent, utilities and insurance. The overhead rate indicates the relationship of all indirect expense to each dollar of direct labor. The overhead rate is used to estimate the overhead expense for fixed-fee projects. The overhead rate is obtained by dividing indirect (overhead) expense by direct labor.

An overhead rate of 150% means that for each $1.00 of direct labor budgeted for a project, $1.50 needs to be budgeted for overhead costs. If the total direct labor budget for a project is $1,000, then the overhead budget would be $1,500 ($1,000 x 150%). Indirect labor is usually the greatest line-item overhead expense.

The most effective way to lower the overhead rate is to charge all project related labor and expense to the appropriate project. If a project's expense is charged to overhead, then all projects share in the cost of that project thus overstating the profit on that project and understating the profit on all other projects. Overhead expense is usually allocated to a project in the same proportion as direct labor charged to that project. Another method of overhead allocation is based on revenue.  Most firms use Direct Labor rather than Revenue to allocate overhead to projects.