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.

Implementing Nmbering Series

Number series is feature in NAV that allows usage of numbering methods and also allows the application to work the same everythere.

This tutorial will explain how to implement Number Series in a new table or add them to existing table. First part of tutorial is focused on creating No. Series columns in tables, middle part of tutorial is focused on coding auomatization of No. Series and last part of tutorial is focused on creating function which will be used to drill down to numbering series line of our specific numbering series.

Another thing, best way for designing and developing NAV is using existing functions and code because they're already tested and probably working without bugs.

Step 1: Creating numbering series columns in a table

In our new / existing table You need to create this two columns (fields) which will be used for storing number series. First field (No.) needs to be created as primary key field.

Please name columns as in next table because of copying functions from other tables, and also this is standard naming policy for No. Columns and Number Series columns in NAV.

To create this fields, go to the object designer and create a new Table / design existing table.

Now our table should look like this.

Step 2: Compile table and add C/AL code

When implementing number series automation, there are some required pieces of code that you must include in your table:

1. OnInsert() trigger,
2. OnValidate() trigger for No. field,
3. AssistEdit function.

Whithout writing New code You can paste it from Sales Header Table and modify it, or decide to write you own code. It's up to you.

Before writing Code You need to create Function AssistEdit in Table C/AL Globals with return value Boolean, which you enter in Locals parameters of function.

After function is created you need to create link to No. Series Setup table for your table and NoSeriesManagement codeunit for automatization of number series which will be explained later in this article.

After table C/AL globals are created, compile table, close it and reopen it in design view.

NOTE: Reason for compiling table is because Rec and xRec still aren't validated by compiler and table data so you need to do so in order to write and compile table later. In case you forget this you need to save your new table without Compiled option, and compile it later through object designer.

Now you can start writing your code and when you're deone with modifying your code your new table should look like this.

Now, lets through every trigger and AssistEdit function and explain what they are going to do:

• OnInsert() trigger. Basicly here we write code which tests value in No. Field and if it's empty it calls our rcdSetup record (C/AL Global variable that links our table with table where we're choosing number series for our table nad form) and test if there is value in field „Br. serija za RC“ which is field developed for setting up number series for this project. If we have previously choosed number series we are calling codeunit NoSeriesManagement (C/AL global NoSeriesMgt) which is inserting next value from No. Series Lines table into No. Series and No. fields.
• No. – On Validate () trigger. Here we write function which tests if value in No. field is equal as one in No. Series Lines table. If it is not, then it sets value of No.Series to blank because of insert automation which is dependent on No. Series fields.
• AssistEdit function. This function is developed for purposes of DrillUp to form of No. Series form based on No. Series data of No. Series field of our table. Basicly it calls for NoSeriesManagement function to validate No. Series. Later, when developing forms and pages, this function will enable us to call No. series window with exact No. series value un field of No. of our form.

Step 3: Creating own numbering series

In our table we have added existing No. Series settings whtough rcdSetup C/AL Global parameter. If yuo want to create new number series setting which will be added to Purchase & Payables Setup. Ofcourse you can add number series setup to any other form.

First step is to create new table field which will be used for our purpose. Best thing is to copy and paste existing field for number series.

Now go to last row of table and paste selected column.

Rewrite Field No. to to match row order.

After modifying row of table be sure to check properties of table and TableRelation parameter which needs to be set to „No. Series“ because we used this value in our based table as value for No. Series relation.

If you decide to change this to another value than you need to update our first table with this value – only in C/AL code.

Step 4: Update C/AL code and C/AL globals in first table

After modification of table, you need to go back to our table and change Record parameter in C/AL globals and in C/AL code replace "Br. serija za RC" with „Implementing Nos.“.

Now our C/AL globals need to look like this:

And C/AL code needs to look like this:

Save the table.

Step 5: Create user interface

Last step in implementing our Number series functionality is to set user interface. This is done with OnAssistEdit() trigger on No. field. This will add new button in form field which will open form with No. seris of our setup table.

Create new card form with form wizzard or page with page wizzard.

Now enter C/AL code to trigger

When developing page change CurrForm with CurrPage and you're set.

Now let's test our form.

Enjoy..

Deleting Rows from FA Journal Page

Working with new Dynamics NAV 2009 pages can be very frustrating, especially if you are used to using keyboard shortcuts in your work.

Other thing that, in my opinion, is nature of pages which is almost opposite of old classic NAV forms. This is what I've encountered during testing of NAV pages.
In classic NAV lists it was easy to mark rows (selecting rows (CTRL+a) and marking feature which is removed from Pages), but on pages it isn't so.
Despite easy of use and windows features, marking was more or less - the same. But I've encountered some strange issues with deleting marked rows in Fixed Asset Journals.

I've marked all of rows (with keyboard) and tried to delete them, but nothing happened.

In picture above you can see that when I selected all rows cursor came to last row and last column and positioned itself in field as if I'm going to enter data into it.

After some testing I still didn't found root of problem and fixed this issue.

I tried changing type of field and even set Edit parameter of last field to , but it didn't work.
Next I tried to mark them with mouse and then tried to delete rows and this time it worked.