Sep
25
2014
0

Quality Conference in October

We are happy to draw your attention to the upcoming Quality in Ireland Conference taking place in the Radisson Blu Hotel in Galway on Tues 21st Oct hosted by NSAI and IT Sligo.

This is an excellent event with many great speakers so worth noting in diaries.

See http://www.nsai.ie/NSAI-Quality-in-Ireland-2014.aspx for more details.

nsai_conference

Sep
16
2014
0

How to transition from Project to Program Management

The world of project management is becoming all too familiar. Yes, there are still challenges and learning to be had but when project management is discussed it is known on how to develop and mature. As a project manager, the biggest driver is being able to deliver under the pressures of time, cost and scope constraints and can be considered to be a balance of project management skills, leadership skills and process management skills.

One of the items that gains continual attention now … is how to transition from project to program. If you are in a PMO, you may have heard the following question, which of the project managers is ready to take on the program of work? This is now the easiest question to answer because first we ask ourselves, what is exactly Program Management and what do we mean by it.
In projects, we talk about planning, team development and process management. Whereas in programs we talk about business delivery, team dependencies and strategic management. They are two different sets of skills and to assume that a project manager can develop these without guidance / structure is a lot to ask. The first step in transitioning from project to program manager is to develop the mind-set for program management. For example, moving from the world of project / timeline delivery to program strategic execution.
My 10-steps or factors that are essential is developing professionals from a project manager’s role into a program management role are: -
  1. Think Business instead of Delivery
  2. Think Dependencies instead of Schedule
  3. Think Escalation instead of Reporting
  4. Think Strategy instead of Scope
  5.  Think conflict instead of Crisis
  6.  Think Governance instead of Teams
  7. Think Transition instead of Transfer
  8. Think Challenge instead of Salary
  9. Think Relaxation instead of Stress
  10. Think Program Triple Constraints (Benefit, Customer, cost)
Why are these different from project management? To answer this question, they are all business related and not one of them are focused on the task mindset that is often evident in project management. This is the subject matter of the paper I will be presenting at PMI® Global Congress 2014—North America on the 27th October in Phoenix, AZ
Liam DillonSubmitted by Liam Dillon, Turlon, SQT Project Management tutor
Sep
03
2014
0

Don’t Set Threshold RPN’s for Actions to be Taken in FMEA

It is common practice in organizations where Failure Mode Effect Analysis (FMEA) is used as a quality improvement tool, to set thresholds on the Risk Priority Numbers (RPN’s), above which actions should be taken to reduce the RPN. I don’t believe that setting such thresholds is good practice. I propose instead that responsibility should be placed on the team to decide whether action is appropriate. In the event that the team decides that it is not necessary to take action on a particular identified cause of the failure mode, then the team leader should sign off on this decision on behalf of the team; i.e. the team will take responsibility for proposing no corrective action be taken, should that be the decision.

The reality is that the choice of the values (Severity, Occurrence, and Detection ratings) which go to make up the RPN is very much based on the judgement of the team members, and there is wide scope for variability in the values that will be chosen. It is a virtual certainty that if two teams with identical backgrounds are given the same failure mode to analyse, even if the causes are agreed among them, they will come up with different RPN’s. That is the nature of FMEA. In these circumstances, I don’t believe it makes sense to have fixed RPN thresholds for action on causes. One of the teams may well have RPN’s below the threshold whereas the other team working on the same failure mode may not.

I think there tends to be too much emphasis and reliance on the RPN values in FMEA in making decisions on whether or not corrective actions should be implemented. I believe the real benefit of the FMEA is the intense discussion that takes place between the team members. I believe that by the time the team has reached the stage of calculating the RPN, the discussion that has taken place up to that point should be sufficient to inform the team’s decision on whether or not corrective action is to be taken, and the responsibility for the decision, should rest with the team.

Learn more about FMEA techniques by attending our Failure Mode Effect Analysis training course.

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com