Prince2 vs PMP

What is PMP?

PMP stands for Project Management Professional and PMP a professional certificate from PMI (Project Management Institute). PMI is a USA based non-for-profit organization focused on project management, which has developed and published a number of standards, including:

◈ A Guide to the Project Management Body of Knowledge (PMBOK® Guide) : PMBOK
◈ The Standard for Program Management
◈ The Standard for Portfolio Management
◈ Organizational Project Management Maturity Model (OPM3®)

And also a number of practice standards and frameworks:

◈ Practice Standard for Project Risk Management
◈ Practice Standard for Earned Value Management
◈ Practice Standard for Project Configuration Management
◈ Practice Standard for Work Breakdown Structures
◈ Practice Standard for Scheduling
◈ Project Manager Competency Development Framework

The PMBOK guide is the most famous standard among these, and its worldwide use led to the development of three extensions for it, which allows for a more effective use in certain areas of application:

◈ Software Extension to the PMBOK Guide
◈ Construction Extension to the PMBOK Guide
◈ Government Extension to the PMBOK Guide

PMI has recently added a line of practice guides, which includes:

◈ Managing Changes in Organizations: A Practice Guide

PMI Certifications

PMI has a number of popular certifications and these are globally recognised. Getting one of these certification is an easy way to prove your knowledge later on, but is also beneficial as preparations for the exams will give you the chance to learn more and fill in the gaps in your knowledge.

These are the PMI’s certifications:

◈ Project Management Professional (PMP)® – Although based on the PMBOK Guide, the exam questions are about the project management body of knowledge in general, and the PMBOK Guide is just a part of it; well, an important part.
◈ Certified Associate in Project Management (CAPM)® – a simple form of PMP
◈ Program Management Professional (PgMP)®
◈ Portfolio Management Professional (PfMP)SM
◈ PMI Agile Certified Practitioner (PMI-ACP)® – There is no standalone publication for this yet, but there is a syllabus and they award certifications
◈ PMI Risk Management Professional (PMI-RMP)®
◈ PMI Scheduling Professional (PMI-SP)® – A certification useful for project planners
◈ OPM3® Professional Certification

PRINCE2

PRINCE2 is a project management methodology previously owned by the UK’s Cabinet Office. PRINCE2, among other “Best Practices” are now owned by AXELOS, a new joint venture company in the UK.

This “Best Practice” family consist of the following:

◈ PRINCE2 : Project management
◈ MSP : Program management
◈ MoP : Portfolio management
◈ M_o_R – Risk management
◈ MoV – Value management
◈ P3O – Project, program, and portfolio management offices (PMO)
◈ P3M3 – Project, program, and portfolio management maturity model
◈ ITIL : IT service management

PRINCE2 Certifications

There are three levels of certification for PRINCE2 however:

◈ PRINCE2 Foundation – the simple one

◈ PRINCE2 Practitioner – the important one

◈ PRINCE2 Professional – just too hard! (don't bother with this)

When people are talking about PRINCE2 certifications, they usually refer to the PRINCE2 Foundation and PRINCE2 Practitioner. The former is easier than PMP and it is unfair to compare them, while the latter is as hard as PMP or, as some people believe, even harder than PMP.

The main source for the both Foundation and Practitioner exams is an official publication named “Managing Successful Projects with PRINCE2” however the official guide should not be used if you are just preparing for the PRINCE2 Foundation Exam as it makes it to difficult.

Continue reading

How to survive a zombie apocalypse with PRINCE2®

It’s the spookiest time of year and, naturally, as an accredited training organisation, we thought it was only appropriate that we had a little think about zombies. Hey now, bear with us here – there’s method to our madness or, at least, a methodology…

A zombie apocalypse epitomises every project manager’s nightmare – no clear plan (other than, y’know… not dying), no clear budget, scope or even visibility on how many team members will turn up each day, and don’t even get us started on the ever-increasing log of risks…

So, how about if we employed the power of PRINCE2® – or more specifically, its seven principles – to help you survive the zombie apocalypse? Can they help you out of your impending sticky situation? Let’s see shall we…

1. Continued business justification

The first principle states that a good project must make good business sense – there should be a return on investment (ROI), and both your use of time and resources should be justified. We feel like this one is a bit of a no-brainer. Your continued business justification and ROI are to stay alive; whatever you are doing is justified and worthwhile if you all come out the other side, potentially minus a few limbs. As obvious as it seems, holding fast to this pearl of wisdom will keep you focussed on the task at hand, and may just save your life.

2. Learn from experience

Now, possibly another obvious one, but if someone died on day one because they forgot to check right, left and right again before crossing the zombie street, it’s probably a good idea to learn from this and avoid it in the future. Equally, everyone knows that you kill a zombie by destroying its brains, so learn from this – don’t go for the knees, that’s how you lose your head…

3. Define roles and responsibilities

Don’t underestimate the power of knowing what you’re doing before you do it. We need a rotating lookout each night, a route-planner, someone collecting weapons and someone to keep an eye on the younger, less-experienced members of the team, at least. And for the love of all things good, we can’t be having Tony and Susan fighting for team leadership in the middle of an all-out zombie brawl.

4. Manage by stages

Difficult tasks are better off broken into manageable chunks. If you’re facing a large-scale escape mission, it will probably help to take a back step and think about things stage by stage. Don’t all run out at once – that’s how Steve died, remember? Break it down – distract the zombies first, then get to shelter on the other side of the street, then get past the zombie hide-out and, finally, make the last leg to the safehouse. Now, have a nice cup of tea and wait for it all to blow over. Job done.

5. Manage by exception

Do not – we repeat, do not – inform the authorities of anything unless there is a serious problem. If the project is going well (or, in this case, not badly) then there shouldn’t be much need for intervention from higher managers. If you give away your position and let the army (or project-management equivalent) come parading in then someone is bound to end up dead. Work the problem out amongst yourselves, have some faith and use your brains… before the zombies do…

6. Focus on products

Everyone should know ahead of time what is expected of the product. In this case, everyone should know that the ‘product’ is your life, essentially, or collective lives. The ideal scenario is that everyone survives, limbs intact, and every team member should be aware of this. These requirements will determine your work activity, not the other way around – like we said, don’t go for the knees… loss of head… not ideal. See what we’re saying?

7. Tailor to environment

Lastly, PRINCE2 is a tailorable methodology. No matter what type of zombie apocalypse you may be facing – be it Dawn of the Dead, 28 days later or I am Legend – you’re good to go. Projects that adapt this methodology to their needs are more likely to succeed than those that don’t. To put this into perspective, zombies have taken on many interpretations over the years, and if you’re trying to use PRINCE2 to tackle land-based zombies when your environment actually calls for defence against water-based zombies, then the outlook is bleak, to say the least.

Continue reading

Understanding Emotional Intelligence in Leadership

The importance of emotional intelligence (EI) in business, particularly in leadership, is well understood. Leaders with high emotional intelligence can get the most out of their employees. In so doing, they propel projects and businesses to ever greater heights.

Leaders without emotional intelligence, on the other hand, often struggle to communicate their intentions and goals to team members. Motivating staff and inspiring confidence can also be a challenge for those lacking a good level of EI.

What is emotional intelligence?

Thanks to its nature, emotional intelligence is hard to define. However, we can loosely describe it as a group of non-cognitive skills and capabilities that help people understand themselves and others.

These skills and capabilities are fairly instinctive. They can make the difference between a good leader and a great one. Unlike technical management skills, emotional intelligence can’t really be taught. Although it’s possible to help people gain a better understanding of their own EI, it takes consistent effort and openness to improve emotional intelligence.

What does emotional intelligence in leadership look like?

Leaders with high emotional intelligence generally find it easier to motivate and communicate with team members. These types of leaders are generally more honest and more inspiring than those who lack emotional intelligence. This often helps them to appear more confident and more capable.

A higher level of self-awareness, empathy and social skills help leaders connect with team members. Keep lines of communication open, and try to really understand what employees mean to say. This helps leaders with high EI manage both small and large teams.

Working for leaders with high emotional intelligence

There are many benefits to working for a leader with high emotional intelligence. For a start, employees are more likely to feel valued and like their views are being listened to. These employees also enjoy inclusive working environments and dynamic company cultures.

Improving your emotional intelligence

It’s true that emotional intelligence is hard to teach. That said, there are a lot of techniques to help improve EI and make leaders more aware of the impact of their emotions. By raising their level of emotional intelligence, leaders can improve self-awareness, communication and empathy. In turn, they’ll get more from their team members.

Leaders who understand the importance of emotional intelligence, and work to improve it where possible, can become more effective and successful.

Continue reading

5 Service-based Business Process Mapping Tips

Business process mapping is a great method for understanding the complex processes that impact a business’s bottom line. Comparing a map of how a process is supposed to work and how a process actually works can be revealing. These methods, originally developed to understand manufacturing processes, do not always translate well to service or transactional types of businesses. Here are a few tips to help you better use business process mapping in your service-based business.

1. Accept That Your Business Is Not a Conveyor Belt

Most formal training for business process mapping uses some type of conveyor–belt-style manufacturing process. These processes are typically straightforward with raw materials entering and finished products exiting. Services are rarely this simple. Service processes will have a lot of back and forth between customers and employees. This human interaction will result in special cause variation that can be beneficial to understand. Embrace this and do not try to make your process map look like a conveyor belt.

2. Concentrate on Decision Points

Service processes will typically have many more decision points than you’d see in a manufacturing process. These decision points are a great source of information for your process. These decisions hold the key to understanding inefficiency and ineffectiveness in your processes.

3. Understand the Big Picture AND Get in the Weeds

Given the special cause nature of service processes and the volume of decision points, your process map may look more like a plate of spaghetti than a process map. There is an art to deciding how detailed to get with a process map. Understating the decisions is imperative, but too much complexity can hide problems from view.

4. Get Process Context

Do not map processes in a vacuum. While this is true for both manufacturing and service processes, it is especially true for service processes. The people working the actual process are the only ones that truly understand the complexity of the process. They are the ones who work through the myriad decisions on a daily basis. Having them in the room while you are mapping the process and observing the work will give valuable context to the business process map.

5. Stay Flexible

Use the business process map to help write standard operating procedures. These procedure maps should include the standard, but should also include exceptions to the standard. They will need to describe what should be done during a typical execution, during frequently occurring exceptions and what to do when an unexpected variation occurs.

Where to Start

There are two ways you can start process mapping: from the top down or from the bottom up. Bottom-up process mapping starts with the greatest detail; each iteration becomes more generalized until you can see the big picture. I prefer to start from the top, or generalized, process map and get deeper into the weeds with each iteration. I use a SIPOC (supplier, input, process, output, customer) to understand the process first from a high level. I then map processes between the SIPOC process steps. Gradually add detail to these process maps until I encounter data entropy.

Business process mapping is a valuable tool for improving efficiency and effectiveness. Implementing these five tips given will help you map those processes in a service or transactional business process.

Continue reading

How to Manage Scope Creep

How many times have we initiated a project only to find that as we move forward through project planning and into project execution, more and more changes to the project are required? While change is inevitable throughout almost any project’s lifecycle, if it is not properly managed and documented, it will result in scope creep. Scope creep is the uncontrolled addition of work, requirements, or deliverables to a project which fall outside of the project’s defined scope. A project’s scope defines exactly what a project is intended to accomplish to include all of the requirements and deliverables necessary to achieve the desired result. The project scope is the backbone of the project upon which all of the project’s planning activities are based. While changes may certainly be made to the project, it’s the unmanaged and uncontrolled changes which result in scope creep that must be avoided.

So how can scope creep be avoided? What project management tools exist to help us in the project planning phase so we can prevent scope creep from occurring? The key to understanding and preventing scope creep is to realize that the more thoroughly a project is planned, the more prepared the project manager and team will be to avoid scope creep. Fortunately there are several project management tools which help plan, baseline, and manage the project scope as well as manage any requested changes to the scope. These tools are used during the project planning phase and are all components of the formal project management plan.

Scope Baseline: The scope baseline consists of the approved project scope statement, work breakdown structure (WBS), and WBS dictionary. These components allow the project team to establish a baseline against which actual project scope will be measured. It is important that the scope baseline is created through careful and deliberate planning to ensure all project work is captured which supports the agreed upon project scope. The work descriptions must be as detailed as possible because if they’re not, then they’re open to interpretation which invites scope creep. As the project progresses, the team will be able to measure if the project’s work and requirements have been met in order to determine project success.

Scope Management Plan: This plan, also a component of the formal project plan, defines the formal process for how the project scope will be managed and controlled during the project’s lifecycle. It defines authority and responsibility for managing and controlling scope, as well as how scope will be controlled, measured, and verified. By carefully developing this plan and following it closely, it will help the project team avoid the introduction of any scope creep.

Change Management Plan: This plan is an extremely important tool in preventing scope creep on a project. Most projects have many stakeholders who bring many different interests into play. Some may want added functionality beyond what is included in the approved scope baseline. Others may see an opportunity to add work to a project to benefit their organization. By developing and adhering to a formal change management plan, the project team is empowered to consider any proposed change to the project while maintaining the integrity of the scope. If a change is determined to be necessary, it can be carefully managed and communicated and add to the project’s value instead of simply resulting in scope creep.

Configuration Management Plan: This plan defines how changes in project documentation and tools will be managed throughout the project. Configuration management is necessary in order to ensure that all project documentation and tools are managed based on the original project scope and any approved changes to the scope. This proactive approach to managing project documentation ensures that there is consistency between the scope baseline and any changes in project scope while preventing incidents of scope creep finding their way into the documentation.

Requirements Management Plan: This plan defines how project requirements will be identified, analyzed, documented, and managed. It is important during project planning to ensure all requirements are captured. These requirements coincide with the scope baseline and need to be met to ensure a successful project. Failure to capture all requirements or leave requirements poorly defined can result in scope creep as the project moves forward.

We know that through careful project planning we can utilize several components of the formal project plan as tools for preventing scope creep. So once the project moves into the execution phase how can we monitor the scope to ensure we continue working within the approved baseline? Fortunately there are also several project management tools available which aid in this purpose. The first tools are outputs of the Requirements Management Plan. These are the requirements documentation and the requirements traceability matrix.

Requirements Documentation and Traceability Matrix: All project requirements must be documented in order to ensure they can be understood, communicated, and completed in order to complete the project. However, just documenting the requirements is not sufficient for monitoring the project’s scope. There must be a clear understanding of each requirement and accountability or ownership of each requirement. The project manager uses the requirements documentation and traceability matrix to establish understanding and ownership of each requirement and track its status. Work requested or performed outside of the documented requirements and traceability matrix may be an indicator that there is some level of scope creep occurring. These tools provide an organized method for monitoring scope and ensuring all project work supports an approved and documented requirement.

Variance Analysis: Variance analysis is the process of measuring scope performance against the scope baseline. As part of the scope management plan every project should have an acceptable variance within which changes to the scope are not required and outside of which corrective action may be needed. If corrective actions are needed then this may also lead to updating the scope baseline, project plan, or other project documentation which should be done through the change control process. Variance analysis is an effective tool which can be used iteratively throughout the project lifecycle to monitor scope.

We know that project managers and teams work hard to plan for project requirements, milestones, and deliverables while considering all feedback from stakeholders. However, project changes are often needed to include an unplanned event or deliverable or to bring a project back in line to support its original intent. While the project manager wants to avoid unnecessary changes which are often the result of scope creep, necessary changes which benefit the project should be managed through the project’s change management process and incorporated into the project.

When a stakeholder or project team member identifies the need for a change the project manager must have a plan in place to manage the change through a review and approval process and to effectively communicate the change if it is accepted. This process should be detailed in the project’s Change Management Plan. Once the change is proposed the project manager must ensure it is documented and an analysis in conducted to determine the change’s impact on the scope, time, and cost of the project. The proposed change goes to the change control board who determine if the change is necessary and supports the project’s intent. Sometimes the change will require the project’s scope baseline, schedule, or budget to be modified. If the change is accepted by the change control board it is imperative for the project manager to ensure all project documentation is updated as necessary as well as to communicate the change to the stakeholders and project team. This process or carefully reviewing, approving, documenting, and communicating a change is what differentiates managed project changes from unmanaged scope creep.

Managing project scope and preventing scope creep are ongoing tasks the project manager must perform throughout the entire project lifecycle. The scope is the very essence of the project and determines if the outcome is successful or not. Many stakeholders may have many varying interests in a project because of how their work, organizations, budgets, schedules, or resources are affected. Because of this, and the many internal and external influences on projects, great care and consideration must be taken when planning and managing scope. Project managers must understand that all of these competing interests must be considered in order to maintain support for the project. By using the project management tools at their disposal, communicating with stakeholders, and managing scope as opposed to only reacting to scope creep, the project manager can maintain support for his or her project while ensuring all project work directly correlates with the tasks required to successfully complete the project.

Continue reading

Understanding Scatter Diagrams and Correlation Analysis

Six Sigma scatter diagrams and their correlation analyses often debunk management myths. Many times executives assume and/or presume that measures vary together when they do not. Sometimes they assume and/or presume that measures do not vary in concert with one another when they do. For better or worse, budget forecasts are based on these assumptions. Knowing which factors do and don’t vary together improves forecasting accuracy. Improved forecasts can reduce decision risk.

Being able to quantify the degree of co-variation, called correlation, helps leaders understand whether assumptions are on or off base. The word correlation does not imply or mean, causation. A correlation simply means that two measures tend to vary together. A perfect positive, one-to-one (1:1) correlation has a correlation coefficient of +1. A perfect 1:1 negative correlation has a correlation of -1. Since everything varies, one rarely sees a perfect correlation. If you see a perfect correlation coefficient doubt it.

The following table arrays an older Six Sigma executive’s age and the price of gasoline over the past 50 years. Because the paired recorded data is in sequential order, we can analyze the data. Notice each field is homogeneous; data fields are not mixed together as they would be in a traditional spreadsheet.

Table 1: Age and Gasoline Price Table

Year	My Age	Gasoline Price
1950	0	$0.06
1955	5	$0.12
1960	10	$0.27
1965	15	$0.15
1970	20	$0.52
1975	25	$0.64
1980	30	$0.76
1985	35	$0.89
1990	40	$1.10
1995	45	$1.19
2000	50	$1.40

With the data contained in the two columns labeled My Age and Gasoline Price, one can easily create a Scatter diagram using most of the statistical software programs available today. With a bit of advanced training you can add titles for eye appeal.

The linear relationship between the correlation’s coordinate points on the X axis, my age, and the price of gasoline on the Y axis is almost perfect, 0.984. The correlation number, 0.984 is called an r value in Six Sigma jargon. By using the straight black line to coordinate age values on the X axis and price values on the Y axis, what was the price when this executive was 22? What was the price when he was 48? Looking into the future, a process called extrapolation, what would you predict the price of gasoline and the executive’s age will be in 2005?

Did an executive’s age cause the price of gasoline to increase? No. But, the two measures do tend to vary together. As one gets larger, so does the other. This is a linear relationship, meaning the black line in the middle of the chart describes the relationship. It is an easy chart to interpret. The red ‘curved lines’ framing the line are called confidence intervals.

As a rule of thumb a strong correlation or relationship has an r-value range of between 0.85 to 1, or -0.85 to -1. In a moderate correlation, the r-value ranges from 0.75 to 0.85 or, -0.75 to -0.85. In a weak correlation, one that is not a very helpful predictor, r ranges from 0.60 to 0.74 or -0.60 to 0.74. Though an entirely random relationship equals, 0.00, any relationship that has a correlation r-value that is 0.59 and below is not considered to be a reliable predictor.

The scatter diagram below illustrates a case in point. In this enterprise, finance managers assumed that there was a linear relationship, a correlation, between monthly operating expenses and the number of units their factory processed. The shotgun pattern illustrates that the simple linear relationship is so weak, that their predictions were invariably misleading.

The low r value of 0.159 suggests that there was virtually no relationship between these two factors. This insight helped the team focus on other key factors that did matter. The insight gained from Six Sigma statistics saved time and money.

Continue reading

The Product Manager Vs. Project Manager— What Are the Differences & Relations?

Despite the similar names, there are some big differences between project manager and product manager. They are often used interchangeably, but are different disciplines requiring quite different skills. In a nutshell,

* The product manager is to do the right thing and make sure the product be line with the market demand, giving the company profits the highest priority.

* The project manager is to do the thing in a right way and make sure things conducted perfect, taking time, cost as well as resource constraints into consideration in order to complete the ultimate goal.

Before diving into more details, let’s take a prior look at what is project management and product management in below.

1. What Is Project and Project Management?

Simply speaking, the project is usually temporary work for outputting unique products, services and results. Project management is the application of knowledge, skills, tools and technology within the project activities in order to meet the current needs. This process includes project initiation, planning, execution, monitoring and project closure. As a project manager, the target is to manage the involved people, events and things to establish the project activities through careful planning.

2. What Is Product and Product Management?

Products are anything that can be provided to the market, used and consumed by people, and of course can satisfy people’s needs, including tangible goods, intangible services, organizations, ideas or a combination of these. Project management is the business activity of enterprise’s living organization in the product life cycle, such as product plan, development, marketing, sales and support to manage the business activities. The product manager are mainly responsible for market research, user research and defining the products in accordance with the users’ needs. They also consider the product’s business model, operation and promotion approaches.

3. Project Manager Vs. Product Manager — Differences

Firstly, the project manager requires a technical background, and in the IT company, they have to be very experienced with the responsibility to convert the objectives into quantified and achieved project plan, giving emphasis on management and implementation.

However, the product manager doesn’t require technology knowledge but needs to be knowledgeable in the field. Nowadays in the recruitment requirements for product manager in IT industry, the employees should have relevant work experience, informative in the Internet products, proficient in product design process (function analysis, user role analysis, prototyping, interface development, user testing, etc), with the excellent ability to express, write documentations and skills in using prototype design tools, including Axure, Mockplus or Marvel. The actual development capability is not necessarily required.

Moreover, from the responsibility cycle, the project manager should be responsible for the completion of a project, and then seamlessly switch to another project. However, the product manager should grow with the product, along with countless items.

4. Project Manager Vs. Product Manager — Relations

The product managers and project managers in fact work in a very close relationship, and it’s hard to set them apart from each other. For instance, e product manager needs to collaborate with the project manager under the relevant progress to ensure the project can meet the final quality and quantity on time.

Continue reading

Process Owners: The Unsung Heroes of Improvement

Look around a company that has been using Lean Six Sigma for awhile. Listen to the kinds of stories that circulate. Which people are mentioned the most? Likely it is the Black Belt who led a project that saved a million dollars or created a whole new market for a product. Or the Master Black Belt who solved a technical issue that had been bothering the company for years. Undoubtedly the senior executive or Champion who oversees the Six Sigma program or individual projects is getting a lot of credit too.

All well and good. No need to begrudge those people their hard-earned Six Sigma status. But examine more closely the companies which are sustaining the gains from their Lean Six Sigma efforts, and one finds unsung individuals who also are doing an exceptional job – the process owners.

A process owner is the person who has the authority to determine how a process operates, and the responsibility to make sure it continues to meet customer and business needs today and into the future. This is a role that no company can afford to overlook if it wants to be world class.

Responsibilities of an Effective Process Owner

A good process owner knows his or her process like an auto mechanic knows cars. A process owner:

1. Knows what is critical about the process. The process owner must understand what about the output is important to customers of the process and to the business, and must have a thorough understanding of how his or her process fits into the overall scheme of the business:

◈ What processes feed into this process?
◈ What processes rely on output from this process?
◈ What is strategically important about this process? Does it contribute to or support a particular product or service? Does it affect overall operational effectiveness?

2. Monitors process performance with data. This must include both input/process metrics (because they are early predictors of performance) and output measures. In many cases, the process owner is monitoring data compiled by process operators and summarized into a dashboard (Figure 1).

Figure 1: Loan Finance Dashboard

3. Makes sure the process is documented, and that the documentation is used and updated regularly. Some organizations have run into trouble by allowing too much variation in how a process 1s performed – each employee having their own particular way of doing business. It is up to the process owner to champion an effort to identify the best-known process methods, particularly what parts of the process must be standardized so that output quality and service to customers do not suffer. Those best-known methods must be documented (with flowcharts and other visual displays) and referenced constantly. (Work groups that do not refer to process documentation usually show more erratic performance than those that do.) If the process changes for good reason, the documentation must change as well.

4. Makes sure a process management (or control) plan is in place. (Figure 2)

◈ Everyone in the work area knows how the process should operate.
◈ Everyone knows how to detect signs of trouble and what to do if a problem appears (often called a response plan).
◈ Process data is charted and posted in the work area, visible to all.

Figure 2: Process Management Plan

5. Holds regular reviews. There are two levels of review that the process owner must lead:

◈ A process review – Is the process performing as required by customers and the business? Are the input and output metrics “in control” and “capable”? If not, what are the biggest issues? Who should be assigned to a project team to attack those problems?
◈ A process management review – Is the method of reviewing, monitoring, and managing the process working? If not, what needs to be improved?

6. Makes sure that any improvements identified through projects are incorporated and maintained in the process.

7. Provides linkage to customers, suppliers and other processes. A process owner is the critical link between a process and the rest of the world – both inside and outside the company. More so than any other individual working on the process, the process owner needs to maintain connections in all directions – with supplier processes, with customer processes, with processes above and below in the corporate hierarchy.

8. Makes sure that process operators have the training and resources to do their jobs well. A good process owner is in many ways a servant to the process operators. It is his or her job to figure out what the operators need in order to do their jobs well, and to keep getting better. Those needs can include appropriate training, materials and information.

Continue reading