APM Project Management Training

In this podcast episode, Paul Naybour and Tom O'Shea discuss the PPQ assessment criteria, specifically focusing on 1.1, which relates to governance in project management. They highlight the importance of aligning project structures and hierarchies with the organisation's structure and the chosen project lifecycle. They also discuss the possibility of proposing a different approach to project management if it aligns better with the project's nature.

They emphasise the need to evaluate appropriate structures and hierarchies, considering factors like organisation structure and team setup, especially when taking over an ongoing project. They mention the relevance of the seventh edition of the Body of Knowledge as a reference and provide insights into creating governance structures, such as project boards or steering groups.

The conversation continues with a discussion on establishing roles and responsibilities within a project team, ensuring formal documentation and individual acceptance. They suggest methods like mapping roles to skill sets and conducting workshops to gain team buy-in.

Lastly, they touch on maintaining reporting hierarchies and structures throughout the project's lifecycle, stressing the importance of adapting to changing needs and circumstances. They mention that regular progress reporting can help reinforce accountabilities.

Overall, this podcast episode delves into the complexities of governance, roles, responsibilities, and reporting structures in project management, offering insights and guidance for project managers.

In this Parallel Project Training podcast, Paul Naybour welcomes Tom O'Shea, the new leader of their PPQ programs. Tom shares his extensive involvement with the PPQ, including his role in its initial development and evolution from the previous PQ version. He highlights the PPQ's transition to a more efficient half-day assessment format and discusses his work in guiding and coaching candidates through the PPQ assessment process.

The podcast delves into the PPQ's purpose, positioning it as a crucial bridge between foundational project management knowledge, as covered in the PMQ, and the advanced technical skills required for achieving chartered status. Unlike the PMQ, which focuses on theoretical knowledge, the PPQ emphasises practical application. It requires candidates to demonstrate their project management capabilities in real-world scenarios, particularly through case study assessments.

Thomas explains that these case studies often involve turnaround situations, challenging candidates to apply their knowledge and experience to poorly managed projects. He underscores the importance of practical application in the PPQ, as it assesses the candidates’ ability to bring tangible improvements to real-life project scenarios. The podcast aims to provide insights and tips for candidates preparing for the PPQ, emphasizing the value of practical experience over theoretical knowledge in achieving success in the assessment.

In this episode, we discuss competence 7. stakeholder management and communication management. The professional practice criteria are

PP1.1 Determined stakeholder interests, and levels of influence for a project.

PP1.2 Produced a communication plan and undertaken effective stakeholder engagement based upon it.

PP1.3 Monitored effectiveness of the communication plans and stakeholder engagement activities.

PP1.4 Adjusted the communication plan and responded to any changing stakeholder engagement needs.

PP1.5 Employed relevant communication methods and media to meet stakeholder requirements and expectations.

PP1.6 Disseminated clear, timely and relevant information to stakeholders.

PP1.7 Obtained, and responded to, feedback from stakeholders which may have an impact on a project.

For more guidance on the Association for Project Management Chartered Project Professional (ChPP), or any other project management training, please visit www.parallelprojecttraining.com or call 0118 321 5030

In this episode, we discuss competence 6. Risk and issue management. the professional practice criteria are

PP1.1 Continually identified risks within a project.

PP1.2 Created a risk register including potential impact and suitable responses.

PP1.3 Assessed the probabilities and impacts of risks and planned their responses.

PP1.4 Capture and recorded issues, how they were resolved, and their implications to inform planning for future projects.

PP1.5 Reacted, assessed, and planned responses to issues.

PP1.6 Implemented responses to risks and issues including escalation, recording lessons learned.

PP1.7 Transferred and/or formally closed unresolved risks at the end of a project or phase.

For more guidance on the Association for Project Management Chartered Project Professional (ChPP), or any other project management training, please visit www.parallelprojecttraining.com or call 0118 321 5030.

In this episode, we discuss competencies 5a. Leadership and 5b. Team management

The professional practice criteria for 5A. Leadership

PP1.1 Maintained a team’s understanding of, and commitment to the vision, values, and objectives of a project.

PP1.2 Selected an appropriate leadership style based on the situation and/or context.

PP1.3 Collaborated with others to maintain the momentum of a project.

PP1.4 Encouraged others to adopt behaviours which built trust, confidence, and collaboration either within or between teams.

PP1.5 Established environments which presented opportunities for empowered and autonomous working.

PP1.6 Established leadership approaches to work with remote teams, colleagues and stakeholders.

PP1.7 Identified and addressed difficulties and challenges through facilitating open discussions in a timely manner.

The professional practice criteria for 5B. Team management are

PP1.1 Agreed team objectives and ways of working to achieve the vision and goals of a project.

PP1.2 Evaluated the maturity level of the team.

PP1.3 Adopted a proactive approach to communication to establish networks of support and facilitate effective ownership of delegated tasks.

PP1.4 Built a relationship of trust and support, taking into consideration the possible complexities of collaboration, virtual working, time zones and cultures.

PP1.5 Met the demands of a project through balancing individual and team needs.

PP1.6 Provided opportunities for coaching and/or mentoring to members of a team, creating an environment of learning and trust thus promoting continual professional development.

PP1.7 Addressed performance issues likely to negatively impact on the success of a project whilst remaining alert to any signs of stress within the team.

PP1.8 Acknowledged levels of performance through constructive feedback to individuals and teams and celebrated success when evident.

PP1.9 Established a learning culture and promoted continued professional development.

For more guidance on the Association for Project Management Chartered Project Professional (ChPP), or any other project management training, please visit www.parallelprojecttraining.com or call 0118 321 5030.

In this episode, we discuss competencies 4a. Integrated planning and 4b. Schedule management

The professional practice criteria for 4A. Integrated planning

PP1.1 Considered constraints and assumptions when creating an integrated plan.

PP1.2 Considered dependencies and governance arrangements, when creating an integrated plan.

PP1.3 Demonstrated compliance with organisational practice when establishing the size, structure, and contents of an integrated plan.

PP1.4 Included other relevant components, plans and documentation to support a comprehensive integrated plan, and ensured formal acceptance of it.

PP1.5 Completed formal sign off and acceptance of an integrated plan.

PP1.6 Continually monitored the progress of a project against the integrated plan.

PP1.7 Adjusted the integrated plan utilising a change control process

PP1.8 Applied configuration management to a plan once it had been formally accepted.

The professional practice criteria for 4B. Schedule management are

PP1.1 Defined tools and techniques for creating and updating a schedule.

PP1.2 Established units of measure to accurately define activities and events to be completed during a project.

PP1.3 Developed duration estimates and critical dates for each activity and event.

PP1.4 Determined relationships and dependencies between activities and events, when constructing a schedule.

PP1.5 Documented a schedule of phases, milestones, and reviews to support project monitoring and progress reporting.

PP1.6 Agreed a schedule baseline, exceptions, and tolerance thresholds.

PP1.7 Communicated regular schedule updates to internal or external stakeholders.

PP1.8 Refined a schedule of activities based on effective monitoring, implementing the change control process when required.

For more guidance on the Association for Project Management Chartered Project Professional (ChPP), or any other project management training, please visit www.parallelprojecttraining.com or call 0118 321 5030.

In this episode, we discuss competencies 3a. governance and 3b. reviews.

The professional practice criteria for 3A. Governance are

PP1.1 Defined reporting, decision-making hierarchies, and levels of authority for a project.

PP1.2 Established the relationship between a project’s governance and the organisation’s governance structures.

PP1.3 Designed the project governance structure taking into account context, complexity, and potential impact.

PP1.4 Adapted or adjusted the governance structure as required

PP1.5 Ensured clarity of ownership and levels of authority by agreeing the responsibilities and accountabilities with relevant individuals.

PP1.6 Ensured effective decision making through maintained governance structures.

PP1.7 Ensured effective reporting through maintained governance structures for appropriate staffing and maintenance

The professional practice criteria for 3B. Reviews are

PP1.1 Considered factors which need to be evaluated during a review.

PP1.2 Established and implemented a schedule of reviews incorporating key milestones.

PP1.3 Obtained appropriate information from valid sources to inform the reviews.

PP1.4 Maintained records of any deviations from plans to include reasons for and responses to, the deviations. PP1.5 Communicated the outcomes of reviews to relevant stakeholders.

PP1.6 Confirmed stakeholder understanding and acceptance of proposed actions.

PP1.7 Implemented agreed actions and updated lessons learned.

PP1.8 Conducted and documented a close out review.

For more guidance on the Association for Project Management Chartered Project Professional (ChPP), or any other project management training, please visit www.parallelprojecttraining.com or call 0118 321 5030.

In this episode, we discuss competencies, 2a. Change control and 2b. Conflict management.

The professional practice criteria for 2A. Change control;

PP1.1 Established a suitable change control process.

PP1.2 Implemented and maintained a suitable change control process.

PP1.3 Captured and recorded proposed changes to the agreed project scope.

PP1.4 Determined the high-level impact of proposed changes to the project scope including reference to relevant sources.

PP1.5 Determined the detailed impact on time and cost estimates of options relating to a proposed change.

PP1.6 Reached justified recommendations on the approval, rejection, or deferral of proposed changes to a project and updated stakeholders as necessary.

PP1.7 Updated plans and schedules reflecting the approved changes to a project demonstrating configuration management.

PP1.8 Used trend analysis to help determine the performance of the current and future projects.

The professional practice criteria for 2b. Conflict management;

PP1.1 Taken a proactive approach to identifying and addressing potential conflict situations which may have impacted on the project.

PP1.2 Taken an impartial approach to investigating the cause of conflict.

PP1.3 Evaluated and implemented conflict resolution measures, seeking assistance from others when necessary.

PP1.4 Responded appropriately and promptly to conflict situations where intervention was required.

PP1.5 Monitored the extent to which conflict resolution measures have been successful.

PP1.6 Sought to resolve conflict respecting the views, opinions, and concerns of all parties.

PP1.7 Supported others to resolve conflict.

For more guidance on the Association for Project Management Chartered Project Professional (ChPP), or any other project management training, please visit www.parallelprojecttraining.com or call 0118 321 5030.

In this episode, we discuss the first two competencies, 1a. budgetting and cost control, and 1b. financial management.

The professional practice criteria for 1A. Budgetting and cost control are;

PP1.1 Established estimates for different project costs.

PP1.2 Established and gained agreement to a project budget.

PP1.3 Set up funding drawdown arrangements based on cash flow forecasts.

PP1.4 Applied metrics to establish cost trends within a project.

PP1.5 Refined budget allocations based on cost analysis, applying change control processes as required.

PP1.6 Produced financial reports for stakeholders based on financial performance monitoring.

PP1.7 Upon project closure, produced final financial reports and distributed them to relevant stakeholders.

The professional practice criteria for 1B. Financial management are;

PP1.1 Established estimates for different project costs.

PP1.2 Established and gained agreement to a project budget.

PP1.3 Set up funding drawdown arrangements based on cash flow forecasts.

PP1.4 Applied metrics to establish cost trends within a project.

PP1.5 Refined budget allocations based on cost analysis, applying change control processes as required.

PP1.6 Produced financial reports for stakeholders based on financial performance monitoring.

PP1.7 Upon project closure, produced final financial reports and distributed them to relevant stakeholders.

For more guidance on the Association for Project Management Chartered Project Professional (ChPP), or any other project management training, please visit www.parallelprojecttraining.com or call 0118 321 5030.

In this episode, Parallel Project Training discuss some further details around the application process for ChPP.

We also start to look deeper into the Technical Knowledge and Professional Practice statements. These statements are written on a number of mandatory and elective competencies, and we set the scene for the upcoming podcasts on each competence.

For more guidance on the Association for Project Management Chartered Project Professional (ChPP), or any other project management training, please visit www.parallelprojecttraining.com or call 0118 321 5030.

In this episode, Parallel Project Training offer an introduction to some APM ChPP topics.

We cover;

For more guidance on the Association for Project Management Chartered Project Professional (ChPP), or any other project management training, please visit www.parallelprojecttraining.com or call 0118 321 5030.

In this APM Project Management Qualification (BoK7) podcast Paul and Jan discuss quality control, quality management and quality assurance. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain what is meant by quality planning
• Differentiate between quality control and quality assurance

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

Here is a summary of the different aspects of quality within a project management environment:

A project manager will always need to create a quality plan detailing how the project will produce products of the required quality. Included in the quality plan will be the following:

• Roles and Responsibilities related to quality issues
• The processes to be followed for both production and testing procedures
• A description of how continual improvement will performed
• Details of quality assurance such as supplier vetting
• Details of quality control techniques such as Pareto Analysis
• How to establish and manage interactions with other project processes such as configuration management

Quality assurance demonstrates how the necessary quality will be achieved and in doing so instils confidence in stakeholders regarding quality levels of the final outcome.

The typical components of quality assurance are:

Are members of the project team competent and fully trained to complete the work assigned to them.

A formal, external audit of processes provides reassurance that the project will be carried out as expected.

When goods and materials are supplied to be used in creating the products that will form the project deliverables then those goods or materials must be assessed to be of the required quality.

Lessons should be learned throughout the project and effectively communicated so that any problems are resolved at the point they are being made. This ensures the root of the problem is identified rather than issues recurring again and again.

Quality control measures will vary widely depending on the type of project and the type of project deliverable. The key similarity, however, will be a comparison of the final deliverable with the original specification.

Some of the quality control techniques that might be used in a project management environment include:

• Pareto analysis
• Walk-throughs
• Process control charts
• Visual inspection and measurement
• Continuous improvement

And here is a transcript of this podcast:

Introduction

Welcome to a parallel project training APM project management qualification podcast based on the APM body of knowledge seventh edition, you should be using this in conjunction with our elearning podcasts, and potentially a tutor led course. For more information, please visit www.parallelprojecttraining.com

Paul

Hello, welcome to another Parallel Project Training podcast today we're doing quality podcasts with Jan. Hello, Jan

Jan

Hi there.

Paul

Very good. Very good. So this is based on the seventh edition of the body of knowledge with PMQ. So the learning so the assessment criteria in this question section are explained what is meant by quality management and differentiate between quality control and quality assurance?

Jan

Right? That's a mouthful

Paul

Explain what is meant by Quality Management, I suspect we have two definition of what quality is first.

Jan

Okay, so it's going for the body of knowledge. It says qualities assessment of a product's fitness of purpose. While the definition appears to be limited the products that the project will produce. It also implies not only to these products is the process and procedures deployed in managing the project iself.

Paul

So there's two things,

Jan

There's two things Yes, because quality to the to the product itself, you can see why it conforms to specification. And of course, the specification is set out when we have to do things like scope management and kind of requirements. So does it meet or does not meet the actual requirements. And of course, that has to be kind of agreed and kind of baseline. And then we talk about change control and all that sort of stuff. But qualities can be very, very subjective as well. So quality to you like a quality car to you may not be To me, that's what I want to use car for. But also, its terms around people's experience of the project management and the processes itself is how we manage, it's like the work we do, we can actually get a lot of people through a course and get the exams passed. But what they'll actually remember is our interaction with those people our service, if you like, and once you start talking about that it's our processes, how we actually took the order, how we had to get a production sorted out how we actually manage the classroom into managing any sort of queries or problems, or maybe issues about have had is around experience. So there's two sides of it, you can actually have something like a fantastic stadium that is built and is fit for purpose. But it's a project management, everything Oh, my goodness, you know, the experience was so bad. The processes weren't there. We did lots of changes in the project, we didn't know what quality was, or all the requirements was he can actually set up for a bad experience. So it's

Paul

two sides summary qualities, two things. It's the delivery of the output. Yes. Fitness for purpose.

Jan

To specification.

Paul

Yeah. to auto specification. Yes. And it's to the quality of the process that got us there.

Jan

Yes. Good. Yes, it is. And it also, it can be against the processes, because projects don't just deliver products, they can deliver processes, especially when you start talking about quality in the service sector industry is a process like your experience of a restaurant, for example, you remember the experience, and the food, the food being the product. Okay.

Paul

Okay. So we need to differentiate between quality control and quality assurance, right? I spoke about talk about quality planning to really hadn't we aspect.

Jan

So that's what we need to do at the very beginning.

So sorry.

So we talked about quality planning at the very beginning is how we actually and it should be should be sorted out as a separate product or separate entity is embedded in what we do. The minute we start to talk about scope of the project, or even the parameters of the project in terms of the time, the cost, the scope, quality, I often put into the middle part of triangle, we deliver it, it's fit for purpose as…

Paul

…the quality plan.

Jan

A quality plan will be the roles responsibilities, often, you know who's responsible for the quality of the project will actually pretty everybody is, and we actually has interaction with it to how we're going to actually define quality criteria, what tools and process of going to be using to manage the quality, what sort of resources we're going to be using, what sort of testing can a specialist test equipment, specialists, people to do the testing, what assurance we're going to put around that to make sure that we are doing what we think we should be doing. We can carry out audits and interactions to other processes. We talked in other podcasts around change and configuration management to what we often called managed The the baselines of the projects and together with the assets, the configuration version control of the project.

Paul

So it's part of the PMP.

Jan

Yes, certainly is developed by the project manager with the teams. Okay. Okay. So that's done early in the project lifecycle? Yes, yes, certainly, actually, quality may be kicking off. Sitting around the concept, we started the business case, but certainly will be teased out as we go into definition.

Paul

So how's that different from quality assurance, as quality assurance, different from quality planning,

Jan

the quality assurance might be a higher end it often I call that the umbrella of quality incorporates a planning and control. And it's making sure the organisation and city qualified experienced people have scripts, that we have processes in place that will manage the process, run the project, like we have a risk management process, change management process, this is how we actually do the requirements, we actually will have testing, certain organisations have testing labs or procedures. There's certain laws and legislation we have to follow, like your health and safety and other legislation. And we have to make sure that these procedures are being followed through an audit certifies assurance provides confidence to stakeholders that we can time after time, deliver a quality product to the customer, we have the infrastructure, if you like or the structure to do it.

Paul

So I like the idea of the assurance being an umbrella. Yes. So the bit how's that different from quality control for control is you control the quality that we deliver?

Jan

The quality is around inspection, testing, measuring, okay, whatever that from the requirements, you actually define the quality criteria of each of the products have the output and does it or does not meet specification. Okay, so we may have tolerances

Paul

so each product gets right quality assessed in some way.

Jan

Is that measuring something that that item needs to be four centimetres, is it four centimetres, yes or no plus or minus and plus or minus tolerances?

Paul

Good. And as different techniques, you can use walkthroughs? Or

Jan

Yes, we offer his walkthroughs within parallel project training, when we actually walk in through both sayings, especially mission testing very much in engineering environments or software environments. You can use process control charts, there's 101 different quality control techniques. But when we're doing resource management for the project, there's but he ran the policy planning is what resources do we need? What facilities Do we need to actually carry out the testing?

Paul

Good, as short and sweet. So to summarise quality is the delivery the fitness for purpose for the project? Yes, performance, the specification and who decides that? Yeah, it's it's about the control of the products. Yes, making sure those products meet the specification. Of course

Jan

specification is control for configuration management, and then change control.

Paul

It's about that overarching quality assurance umbrella. Yes. And it's about project quality plan as part of project management. Yes,

Jan

what we need to do for this project specifically to do quality management, and of course, within the quality plan, we may be drawing down certain key process procedures from the quality management, the quality assurance bit, okay, you know, if you're going to do a testing, this is how we do testing. This is how we, you know, do risk risk management within this organisation. Excellent, good fracture. Okay, thanks very much.

We hope you enjoyed this podcast and found it informative. To find out about our training courses elearning or tutor led course please go to www.parallelprojecttraining.com

It is always difficult to be precise about the causes of project failure for a number of reasons. Our human inclination is to avoid any blame being attached to us, no matter how much we might proclaim the benefits of a no-blame culture, when it comes to our own career on the line, we don't want to stand up and take full responsibility for the failure ourselves. So clients will blame the project manager, the stakeholders will blame the business analyst for inadequate requirements, the project manager might blame the client for a poorly articulated business case but none of this helps to define the real cause of the failure.

Questionnaires can be used to gather information on the causes of project failure, but the questions are usually too general and the answers given to the questions are biased depending on the role the individual played in the project. There are also, frequently, several different reasons which contributed to the project failure so such questionnaires make it difficult to pinpoint the exact reasons for failure.

Add to this the fact that many projects are completely unique: with objectives, scope, technology etc that have not been experienced before and it is understandable that assessing the true reasons for project failure is extremely difficult. Nevertheless, if you take note of some of the reasons regularly cited for project breakdown they might help you to avoid disaster in your own projects.

The most commonly identified reasons are:

• Deadline missed
• Budget exceeded
• Poor communication
• Requirements not met
• Inadequate quality of final product/service
• Poor planning with respect to risk management, estimates and schedule
• Poor client - supplier relationship
• Final deliverable not acceptable to the client
• Lack or professional / technical skills within the team
• Failure to manage client expectations or unrealistic expectations
• Poorly defined or incomplete requirements
• Frequent changes to requirements and/or specification
• Weak business case
• New technology did not live up to expectations
• No support from senior management
• No involvement from end-users
• Limited Resources
• Lack of focus on the business needs

Some of these reasons are the result of an underlying failure. For example, a poor client-supplier relationship is usually the result of poor communication or communication that lacks detail and fails to manage client expectations. A factor that could be improved by developing project managers via professional courses in project management.

And some of the reasons are not actually the reason for the failure but simply the outward manifestation of the project failure such as a deadline not being met. The reason the deadline was not met is actually the reason for the project failure and that could be any number of things such as failure to understand new technology, staffing issues, skills issues etc.

So if we accept that there are problems in genuinely determining why a project failed, we cannot fully understand the failure and so avoid making the same mistakes again. All the more reason why an experienced project manager is vital on major projects and why that person should have undertaken professional project management training. The experience will assist in avoiding problems that have occurred before and the training will provide the skills to deal with those problems that are unexpected and new to everyone.

So next time you are conducting, or involved in, a post-project review to analyse the causes of a project failure, try and look below the surface of the standard answers and resist the temptation to rush on to the next project and put the failure behind you. You just might learn a worthwhile lesson that could help you during your next project.

I met up with an old colleague recently who I worked with when we were both IT Project Managers for a large blue-chip corporation. Our conversation got me thinking about how often the opinions of end-users in IT projects are dismissed as of little importance or, worse, ignored completely. The stakeholders, senior management, project manager, suppliers and vendors all have a voice in IT projects – they can articulate their needs and requirements and their opinions are duly noted and acted on because of their importance within the organisation and within the project hierarchy.

And yet it is the end-user who will be using a new software system on a daily basis. It is the end-user who knows and understands the data in the legacy system, who knows how to work around problems with the current system and understands how to get their job done quickly and efficiently. So why don't more project managers take more notice of the comments and concerns of this important group?

Is it that the group itself does not believe their opinions carry any weight and, therefore, do not speak up when given the opportunity to do so. Is it that they are never fully involved in the project and so don't have the opportunity to speak up? Whatever the reasons might be, don't ignore users' concerns and comments throughout the project. In my experience it is often the user who can identify a potential problem before it happens.

If it is proving difficult to get feedback from the everyday user of a system then it is in the interests of the project manager to elicit that information by the best means possible. There are many approaches to obtaining feedback from users. Informal brainstorming sessions, formal meetings and questionnaires all may work well for different projects and different individuals. The best project management training courses will suggest other ideas for gleaning the information you need to ensure the new system delivered can actually be used effectively from day one and hence make your project a success.

I have personally found that cultivating a good personal relationship with key users is the best way to do this. Talk to them informally and on a personal level about their concerns – perhaps at a casual lunch or over coffee. Find out what their day-to-day tasks are now (on the existing system) and understand what they do. I have often shadowed a key user for their typical working day – it can be hugely revealing and throw up information that is almost impossible to find out in a more formal session.

So involve key users from the outset of the project. This is particularly important if a legacy system is being replaced with new technology or software to ensure the wealth of information in the existing database is not lost through incorrect handling. Data conversion can be a huge stumbling block if not done properly – I know of new IT systems that have been implemented without the full suite of data required for the users to perform their jobs. These are new IT systems that looked good, went live on time, had all the required features but the databases were incomplete so the systems were effectively useless. This sort of project will always have a poor reputation even if the problems with the data are quickly rectified.

I have also found that in many IT projects the most resistant user to the new technology can become the greatest advocate given the right involvement, training, encouragement and a good deal of hand-holding. The benefits of this effort on the part of the project manager are enormous. The chances of a highly successful project are much greater, the "reputation" of the software is immediately a good one, as soon as it goes live. And we all know it is much easier to get people to accept a few faults in an otherwise good system than to rescue the reputation of a system that starts off badly.

So learn from previous project problems and failures, take the advice of more experienced project managers and ensure you attend one of the professional project management courses available but never ignore the comments and concerns of the end-users in IT projects. You do so at your peril.

If you are not a project manager, you may feel the whole process of project management with all its methodologies, techniques, meetings, reports and other assorted documentation is just a thorn in your side. You may even feel you would be better off without it - but I suggest you read these 10 benefits of project management and they may just change your opinion.

Project Management is simply a series of strategies that help to turn an idea into reality and get you from the ideas stage to a finished product or process as efficiently as possible and with least risk of failure. It's a process that can be used on any type of project in any industry. From major infrastructure projects, construction and healthcare through to IT, web development, digital marketing and search engine optimisation projects.

If you are the client you know that the budget will be well-controlled and that the final product will meet your requirements and expectations. But it is only by applying formal techniques and using the skills and knowledge of the project manager that this will be the likely outcome.

So here's my 10 benefits of project management:

So next time you are thinking about taking (or sending someone on) one of the many project management courses available and what you might learn, think about these benefits. They are all essential project management skills that will help your project be a success and that is good news for your company and good news for your career.

GANTT CHART

Gantt charts are the most generally useful tool in project planning. They are used for scheduling and monitoring tasks, for showing costs and expenditure at all stages throughout the project, for communicating progress and producing reports. They show, on a simple block diagram, the activities and costs over time in an easy-to-understand way. They can be created in a range of software tools or even in a spreadsheet.

The project is broken down into individual tasks which are listed in rows on the chart. Each task has a timeline extending out to the deadline of the task. Overlaying the timeline is a progress line, showing how much work has been done on the task so far, and also the important milestones along the way. Estimated and actual costs to date can also be added at the end of the timeline.

Because the chart covers the days, weeks and months of the whole project it is simple to track progress of the project provided the chart is updated regularly and accurately.

PROJECT SCOPE

Project Scope is a definition of the limits or boundaries of a project and the reason it is so important is because poor management of the project scope is one of the major causes of project failure. Good management of the project scope by the project manager involves 3 key factors:

• devote adequate time to fully defining the requirements
• reach a formal agreement on the scope with the stakeholders
• avoid scope creep

Scope creep is when un-authorised or un-budgeted tasks lead to uncontrolled alterations to the documented requirements during the course of the project.

There is, of course, a tendency for changes to be requested during the life of a project. As projects progress, the end-users inevitably see areas where additional features could provide increased benefits. And the purpose of scope management is not to prevent such changes either being requested or implemented, but to ensure that all changes bring substantial, well-defined benefits.

RISK MANAGEMENT

In order to deliver successful projects that come in on-budget and on-schedule and meet the needs of the business, it is critical to manage the risks inherent in every project effectively. Managing risks within a project involves identifying and analysing the risks then designing a strategy to deal with the risks. No project is ever without risks, but it is the nature and complexity of the project that are likely to determine the impact of the risks on the overall success of the project.

The main tasks involved in Risk Management are:

• Identify and analyse the risks.
• Establishing and maintaining a Risk Log listing the risks and their severity.
• Analysing the probability of each risk occurring and its impact
• Developing a strategy for responding to risks that occur
• Allocating contingency funds and time in the schedule

BUSINESS REQUIREMENTS

Every project needs a business requirements specification document because it is the formal agreement between the client, the business stakeholder and the project manager. It states exactly what will and will not be included in a project and what the client can expect once the project is completed.

Fully analysing your business requirements before embarking on a new project will lead not only to improvements but to a transformation of the business. So instead of ending up with a new business process, policy or system you could actually enable a substantial change in the business.

PRINCE2

PRINCE2 is a methodology for managing projects effectively. It stands for Projects In Controlled Environments and is a flexible process with a strong focus on the business justification of a project and an emphasis on dividing the project into small manageable and clearly defined stages. It also has a defined organisation structure for the project management team.

It is a framework that focuses on the delivery of products rather than carrying out specific tasks and has a finite lifecycle. PRINCE2 is used to ensure the following:

• Effective use of available resources
• Effective management of risks
• Early identification of issues
• Good communication
• Lessons are learned from every project

APM PMQ

APM PMQ (previously known as APMP) is a knowledge based project management qualification for which a project manager needs to be able to demonstrate knowledge of all aspects of project management and understand how they interact and how a project fits into the strategic and commercial environment. It is an internationally recognised qualification sponsored by the Association for Project Management (APM) aimed at those wishing to achieve a broad level of project management knowledge.

The breadth of knowledge required includes budgeting and cost management, conflict management, communication, earned value management, leadership, negotiation, procurement, sponsorship and teamwork.

PMP

PMP is an internationally recognised project management certification sponsored by the Project Management Institute (PMI). It is designed to objectively assess and measure professional knowledge and candidates must satisfy educational requirements and demonstrate a defined level of experience before embarking on the course. To achieve the certification a project manager must demonstrate a high level of understanding and knowledge about project management and those granted the PMP certification must also demonstrate ongoing professional commitment.

Anyone applying for PMP Certification must hold a university degree and have a minimum of 4,500 hours of project management experience in Initiation, Planning, Controlling, Execution and Closing. They must also have at least 3 years of project management experience within the last 6 years and at least 35 hours of project management education.

SWOT ANALYSIS

SWOT is an acronym of Strengths, Weaknesses, Opportunities and Threats and is used to help with decision-making in the planning and risk elements of large, complex projects.

But it is not purely a method used for controlling areas of planning and risk - it is also used to highlight areas of the project that could be maximised to the benefit of the whole project or individual areas where some competitive advantage may be gained. It is used to evaluate particular activities of the project in order to optimise their potential as well as to evaluate risks in order to determine the most appropriate way of mitigating those risks.

SWOT analysis is normally performed during the initial project start-up phase so that the elements of the analysis can form the basis of the project plan, but it can also be used later in the project if the project is running into difficulties with scheduling, deliverables or budget and needs to be brought back on track.

SMART

Smart is a method within project management designed to ultimately achieve a goal or aim. Goals have a much greater chance of being accomplished if they follow the Smart philosophy which is a mnemonic for Specific, Measurable, Achievable, Reasonable, Time-bound

Goals or tasks must be clear and unambiguous so the project team knows exactly what is expected, why is it important and who’s involved. Clear criteria for measuring progress must be set so you know whether the team is making progress towards successful completion.

The goals must be achievable – if expectations are too high (or too low) then they tend to be ignored. They must also be reasonable or realistic, given your specific resources, so they represent an objective towards which the team can work. Lastly, every goal should be set within a time frame and have a target date. Without deadlines it is difficult to focus on completing a task.

PEOPLE

Remember that the people involved in the project are the key to whether it is delivered successfully or not. Develop, encourage and motivate the project team because an enthusiastic, committed team of people can often achieve more than expected. Deal diplomatically with the stakeholders to ensure that business politics do not become a risk to the project and communicate clearly with the client or end-users to ensure they understand fully what to expect when the project is completed.

Successful Project Managers often have soft skills that set them apart from their colleagues and help them to deliver projects successfully where other equally well-qualified project managers would fail. Of course, you can't be a successful project manager with only the right personality traits – you also need the right training and experience but combining that with well-developed soft skills might just make all the difference.

Here are some ways to improve your project management skills:

• Be assertive without being aggressive.
• Display an optimistic, "can-do" attitude at all times.
• Expect resources to be limited and have a contingency plan.
• Plan for changes to priorities and requirements.
• Deal calmly with changes to the project.
• Promote a good team spirit – motivate, develop and encourage the team members.
• Communicate in person whenever possible.
• Talk to team members individually - give praise where it is due and clearly state your expectations if standards fall below what are required.
• Take an active interest in every aspect of the project.
• Communicate with team members and stakeholders at their level and in their language – avoid technical jargon.
• Keep reports as clear and simple as possible – develop the ability to explain complex issues in a straightforward way.
• Stay clear of business politics where possible – and when it is not possible try to take a rational, diplomatic approach and stay focussed on the original business objective.
• Be receptive to new ideas without losing sight of the business objective. As a project progresses there can be situations where a re-think is required of how to achieve a particular goal or milestone.
• Don't assume the original plan was the best approach if new information comes along part-way through the project.
• Don't lose sight of the detail.
• Celebrate each successful project with the team and don't forget to thank everyone, and involve everyone in the celebration, regardless of how junior or senior they might be.
• Learn something from every project and take that knowledge forward with you to the next.

.

Like all professional careers, the path to successful project management begins with a sure foundation. This foundation can be built by a combination of formal courses in project management and work experience. If you are very fortunate you may also have a mentor. You can work well and effectively as a project manager with this base but to progress to being truly successful and consistently successful you will need to develop your "soft skills" and progress to more advanced levels of understanding with professional qualifications such as PMP Certification.

I've been reading a lot lately about what motivates a person in a work environment and, more specifically, in a project environment. Motivation is one of those things that is different for different individuals but if you can get it right in your project team then a motivated team can overcome all sorts of problems and issues. In my experience a motivated team will always deliver a project successfully.

And yet, for all the advice available on how to motivate people, somehow many organisations fail to do it well. That's, of course, partly because they don't have the will or the ability to implement changes that might improve motivation. And that's just as true in small business as in large corporations; and in the construction industry or more creative digital marketing industries.

I used to work with a bunch of high-flying city traders – almost without exception they said that money was the only thing that motivated them. But they were all young and I have to wonder what is the motivation once you have more than enough money. They would probably argue that you can never have enough money but in the real world when you are being paid well to do a job, what then motivates a person week after week, month after month and year after year?

Well, this is my highly distilled list of the top ways to motivate your project team:

Now that I have written that list it doesn't sound too hard to motivate a project team. Just remember the key points are to allow the team to learn and develop professionally in a creative environment.

Being a Project Manager is a multi-skilled role and when I was thinking recently about what exactly that role involved my first thoughts, naturally, were the "managing" aspects. It is fairly obvious that a project manager manages:

• Budget
• Schedule
• Risks
• Quality
• Change

But being an effective, successful project manager involves far more than simply "managing" those elements of a project, whatever industry you might be in. It also involves co-ordinating different teams, internally in different departments and externally at suppliers or providers of outsourced activities. It involves co-ordinating dependencies within the project – a major task in complex and global projects.

And what about the people? If you want to be truly outstanding and you want your projects to be consistently successful then you need to be motivating, encouraging and developing your team. Even holding their hands and mopping their brows when necessary. Dealing with a whole range of staffing issues, including interviewing and recruitment often fall into the lap of the project manager. So this really isn't the role for you if you simply want to sit in your office with your schedules, charts and progress reports.

And, of course, as a project manager you don't just need to report the progress of a project to senior management and explain why issues have arisen (as they always do), you must deal with the issues that have occurred and ensure they do not affect the schedule and budget. On top of all that you must have a good understanding of all the work that is being carried out to ensure it is within the scope of the project and actually ensure that all necessary work gets done. After all, project management is simply about getting things done.

These are only some of the most obvious items that a project manager becomes involved with. Depending on the type of project there could be many more. For example, on IT projects there may be the need to become involved in technical meetings, technical specifications and functional and user-testing. Because of their added complexity (not to mention their high failure rate) IT project managers typically come from an IT background.

I was in a meeting earlier this week that was typical of so many project meetings I have attended. A rough agenda had been drawn up by the person chairing the meeting but no-one else had seen it before the meeting started so we didn't quite know what to expect. And one person was allowed to dominate the conversation so we didn't really achieve anything (but I don't know what we expected to achieve anyway as no objective had been stated).

Unusually it didn't drag on too long as the meeting room had only been booked for half-an-hour and another group were at the door before we had concluded the meeting. I, for one, left with a sense of dissatisfaction and it made me think about how the meeting should have been run.

So here are my 10 steps to a perfect project meeting:

Many project managers are under pressure to estimate projects accurately without being given the time to gather the information required for an accurate estimate. Conversely they are also expected to meet deadlines that were imposed by market forces, such as producing a new product before the competition, which bears no relevance to the amount of time/resources actually required or available.

These sorts of challenging situations are bound to lead to a disappointing outcome to the project. The problem, and it is not the project manager's alone, is that organisations do not always follow 3 basic project management principles:

Lessons Learned

Use the knowledge learned from earlier projects about how accurate estimates were compared to the actual time and resources used. Use these examples to highlight that accurate estimates can only be provided once a full evaluation of the project has been made by experienced members of the project team.

Definition

Defining what is required in the project is a critical step that begins with a scope statement. This should contain enough detail to specify what the purpose of the project is and what work will be required to complete the project. It will also serve as a basis for managing expectations of the project.

Methods

We have probably all been on one of those project management courses aimed at enabling us to define, estimate, plan and deliver projects more successfully. You may have attended PRINCE2 or PMP Training but it is implementing the processes and methods learned on such courses in our real project environments that will result in project success.

So when you are being asked to take shortcuts in any area of a project try and remember the basics of good project management. Collaborate with the project sponsor to ensure the project is clearly defined, get expert estimates, where possible, and learn from previous projects then implement your project management processes rigorously. These basics will lay a strong foundation for building a successful project.

Someone said to me recently that they always only use Gantt charts to manage projects. And certainly there are many projects for which a detailed Gantt chart would be sufficient – projects that are simple and straightforward, or similar to other projects previously completed successfully. But when the project is highly complex or involving new technology with many dependencies and many tasks running in parallel then only using a Gantt chart is unnecessarily running the risk of the project failing.

There are a whole range of techniques that you can use as a project manager for planning a project both in the initial stages and right through to managing risks, dependencies, change and day-to-day progress. Some of them were developed as long ago as 1910 but one of the advantages of this is that these are techniques for which a software tool is not actually necessary. Of course, I don't mean to say that a software tool is not useful but the diagrams and charts associated with these techniques can all be drawn by hand (if you're really keen). This means you can gain an understanding of the basic techniques without the influence of a particular software package.

I have spent most of my career working in IT and have used many, many different software tools and packages but I'm always slightly bugged by the assumption that an ability to use a software tool equates to an understanding of the principle behind the tool. A software tool is simply something that makes it easier to do the job. But that's my personal gripe over – it just happens to be one of the reasons I'm a fan of powerful project management techniques such as Gantt Charts and PERT (Program Evaluation and Review Technique).

PERT charts are a form of Critical Path Analysis and are ideal for identifying dependencies – those individual tasks on which other tasks, and indeed the whole project, depend in order to be completed successfully. Because PERT charts can also indicate relative priorities they are also useful in identifying those activities that can be scrapped if the schedule starts to slip.

As with Gantt charts, the underlying concept behind the PERT chart is ordering tasks; in parallel, where possible, to reduce the overall project completion time but sequentially, where necessary because of dependencies that mean one or more tasks must be completed satisfactorily before another can be started.

Gantt charts and PERT charts can both be used to establish the initial project schedule, allocate resources and monitor progress. But the most common form of the project plan that you will use to communicate the schedule, progress and problems to the stakeholders of a project is, of course, the Gantt chart. It shows information in a clear and easy to understand way but is less useful for showing dependencies, the relative priorities of individual tasks and the resources expended on a task. For example, they can clearly and simply show the elapsed time of a task but cannot so easily communicate how many people may have to be involved in completing the task. This is where a PERT chart becomes useful but it is also very effective at highlighting where problems are likely to occur.

One of the reasons I particularly like using PERT charts is that they essentially take a pessimistic view of how long a project will take to complete. One common cause of schedule slippage in a project is the tendency to under-estimate how long individual tasks will take. This tendency is due to a number of factors – pressure from senior management to complete a project by a pre-defined deadline, and a desire to win a contract are just a couple of them. The great advantage of a PERT chart is that it counteracts this optimistic tendency to give a more realistic view of the project.

This is done by producing three estimates for the most optimistic, the most likely and the most pessimistic time that any one task is likely to take to complete and using all three figures to produce a reliable estimate. But PERT is also an effective means of determining and communicating which tasks can be performed in parallel, what the relative priorities of each task are and hence which tasks can be dropped if time pressures make this necessary.

Neither technique is without its disadvantages, but when used together they can complement each other perfectly and as a combined force they do provide the best chance of managing a project successfully. So whether you use PRINCE2, APMP or PMP, next time you are planning a project and intend to use only a Gantt chart think about its weaknesses and how those weaknesses might be avoided by also using a PERT chart.

Dealing with conflict is one of the many tasks you will have to perform in your role as a project manager if you want your project to be a success. Never underestimate the importance of resolving conflicts (even if they might seem trivial) as projects can, and will, be derailed if personality clashes and disagreements are allowed to get out of hand.

Problems of one sort or another will always arise on a project but it is how they are handled by the different personalities within the project team that will determine the effect they have on the overall project.

One of the best ways to deal with problems and, more importantly, people's reactions to those problems is to confront the issues early on. If you let disagreements drag on then bad feelings will fester and resolving the conflict will become harder. And the way to confront the issue is by communicating – and I don't mean an email, but a face-to-face talk. Take the team out for coffee or lunch so that you can talk through the issue on neutral ground and encourage openness and honesty about the issues. I'm always amazed at the positive effect coffee and cake can have on a disgruntled team. Of course, that's not the solution to all problems but many minor issues can be prevented from escalating by simple human concern for each member of the team.

But do remember that honest communication is not about allowing direct personal criticism. All criticism must be constructive and should not be aimed at personal shortcomings of any one individual (even though we all have them) if you want to build a motivated team that will work collaboratively.

Accept that there will always be differences of opinion within a team but treat that as a positive aspect of the group as it will ensure a varied flow of ideas and suggestions. Ideas that could be used to solve the problem that caused the conflict in the first place. And as a project manager make a concerted effort to really listen to the team members and give them the opportunity to express themselves.

Conflict often arises because team members are working on interdependent tasks and maybe one task has not been delivered so there is a knock-on effect to other tasks. I always think a project team would do well to reflect on army tactics - soldiers may have personal disagreements but on the battle field they are all on the same side.

A project team will be stronger and more successful if they work as a single unit and put the needs of the group ahead of individual needs. Of course, this is the ideal and not often achieved in my experience but it is worth aiming for. Many courses in project management using recognised methodologies such as PMP, PRINCE2 or APM PMQ, cover conflict resolution as an integral part of project management training.

Activity -
Any work performed on a project. May be synonymous with task but in some cases it may be a specific level in the WBS (e.g., a phase is broken down into a set of activities, activities into a set of tasks). An activity must have duration and will result in one or more deliverables. An activity will generally have cost and resource requirements. See Task.

Actuals -
The cost or effort incurred in the performance of tasks. Also, the dates tasks have been started or completed and the dates milestones have been reached.

Analogous Estimating -
Estimating using similar projects or activities as a basis for determining the effort, cost and/or duration of a current one. Usually used in Top-down Estimating.

Assumption -
Something taken as true without proof. In planning, assumptions regarding staffing, complexity, learning curves and many other factors are made to create plan scenarios. These provide the basis for estimating. Remember, assumptions are not facts. Make alternative assumptions to get a sense of what might happen in your project.

Authority -
The ability to get other people to act based on your decisions. Authority is generally based on the perception that a person has been officially empowered to issue binding orders. See Power.

Baseline -
A point of reference. The plan used as the comparison point for project control reporting. There are three baselines in a project—schedule baseline, cost baseline and product (scope) baseline. The combination of these is referred to as the performance measurement baseline.

Bottom-up Estimating -
Approximating the size (duration and cost) and risk of a project (or phase) by breaking it down into activities, tasks and sub-tasks, estimating the effort, duration and cost of each and rolling them up to determine the full estimate. Determining duration through a bottom-up approach requires sequencing and resource leveling to be done as part of the scheduling process.

Budget -
The amount allotted for the project that represents the estimate of planned expenditures and income. The budget may be expressed in terms of money or resource units (effort).

Business Case -
The information that describes the justification for the project. The project is justified if the expected benefits outweigh estimated costs and risks. The business case is often complex and may require financial analysis, technical analysis, organization impact analysis and a feasibility study.

Calendar Date -
A specific date shown on the calendar (e.g., July 3, 1942) as opposed to a relative date. See Relative Date.

Change -
Difference in an expected value or event. The most significant changes in project management are related to scope definition, availability of resources, schedule and budget.

Change Control -
The process of managing scope, schedule and budget changes to the plan. See Scope Change Control.

Change Request -
A documented request for a change in scope or other aspects of the plan.

Client -
The person or organization that is the principle beneficiary of the project. Generally the client has a significant authority regarding scope definition and whether the project should be initiated and/or continued.

Closing -
The process of gaining formal acceptance for the results of a project or phase and bringing it to an orderly end, including the archiving of project information and post-project review.

Consensus -
Unanimous agreement among the decision-makers that everyone can at least live with the decision (or solution). To live with the decision, one has to be convinced that the decision will adequately achieve objectives. As long as someone believes that the decision will not achieve the objectives, there is no consensus.

Constraint -
A restriction or limitation that influences the project plan. For example, a target date may be a constraint on scheduling. A schedule may be constrained by resource limitations.

Content Expert -
See Subject Matter Expert (SME).

Contingency Reserve -
A designated amount of time and/or budget to account for parts of the project that cannot be fully predicted. For example, it is relatively certain that there will be some rework, but the amount of rework and where it will occur in the project (or phase) are not known. These are sometimes called "known unknowns".
The purpose of the contingency reserve is to provide a more accurate sense of the expected completion date and cost of the project (or phase). Some PMs separate contingency reserves from management reserves while others combine the two into a single reserve. Reserves for changes and issues may be part of the contingency reserve or separate reserves.

Controlling -
The process of monitoring, measuring and reporting on progress and taking corrective action to ensure project objectives are met.

Critical Path -
The path(s) in a project network that has the longest duration. This represents the series of activities that determines the earliest completion of the project. There may be more than one critical path and the critical path(s) may change during the project.

Debate -
A discussion in which the participants exchange information for the purpose of supporting or refuting one anothers' positions. Debates are win-lose discussions, as opposed to dialogues, which are win-win discussions.

Deliverable -
Any item produced as the outcome of a project or any part of a project. The project deliverable is differentiated from interim deliverables that result from activities within the project. A deliverable must be tangible and verifiable. Every element of the WBS (activity or task) must have one or more deliverables.

Dependency -
A relationship between two or more tasks. A dependency may be logical (see Logical Relationship) or resource based (see Resource dependency). Also see Link.

Dialogue -
A discussion in which the participants share their thoughts and gain a better understanding of the subject and, possibly, reach consensus. This is contrasted with debate.

Duration -
The length of time required or planned for the execution of a project activity. Measured in calendar time units—days, weeks, months.

Early Start -
The earliest time a task can begin. The time at which all the tasks' predecessors have been completed and its resources are planned to be available.

Effort -
The amount of human resource time required to perform an activity. Measured in terms of person hours, person days, etc.

Estimate -
An assessment of the required duration, effort and/or cost to complete a task or project. Since estimates are not actuals, they should always be expressed with some indication of the degree of accuracy.

Estimate to Completion -
The expected effort, cost and/or duration to complete a project or any part of a project. It may be made at any point in the project's life.

Executing -
The process of coordinating the people and other resources in the performance of the project or the actual performance of the project.

Float -
The amount of time available for a task to slip before it results in a delay of the project end date. It is the difference between the task's early and late start dates.

Functional Manager -
A manager responsible for the activities of an organizational unit (department, work group, etc.), which provides some specialized products, services or staff to projects. For example, the manager of an engineering group, testing department or procedures development department. Also called a line manager.

Functional Group -
An organizational unit that performs a specialized business function (e.g., design, Human Resource management, etc.) and may provide staff, products or services to a project.

Gantt Chart -
A bar chart that depicts a schedule of activities and milestones. Generally activities (which may be projects, operational activities, project activities, tasks, etc.) are listed along the left side of the chart and the time line along the top or bottom. The activities are shown as horizontal bars of a length equivalent to the duration of the activity. Gantt Charts may be annotated with dependency relationships and other schedule-related information.

Goal -
A desired end result, often synonymous with objective. May be a high-level objective that has less-than-complete definition. See Objective.

Implementation -
May be a phase in the project life cycle in which a product is put into use. Also a term used as a synonym for development.

Incremental Delivery -
A project life cycle strategy used to reduce risk of project failure by dividing projects into more manageable pieces. The resulting sub-projects may deliver parts of the full product, or product versions. These will be enhanced to increase functionality or improve product quality in subsequent sub-projects.

In-house Projects -
Projects performed primarily by performers who are part of the same organization as the client. For example, a product developed by a manufacturing company's own Engineering Department is an in-house project. If an outside contractor developed the same product, the project would be externally sourced. Note that vendors might be used in in-house projects depending on the degree to which they are responsible.

Initiating (Project) -
The process of describing and deciding to begin a project (or phase) and authorizing the Project Manager to expend resources, effort and money for those that are initiated.

Kick-Off Meeting -
A meeting at the beginning of the project or at the beginning of a major phase of the project to align peoples' understanding of project objectives, procedures and plans, and to begin the team-building and bonding process.

Late Start -
The latest time a task can start before it causes a delay in the project end date.

Leveling -
See Resource Leveling.

Link -
A relationship between two or more tasks. See Logical Relationship.

Logical Relationship -
A dependency relationship between two or more tasks or between tasks and milestones, such that one cannot start or finish before another has started or finished.

Management Reserve -
A designated amount of time and/or budget to account for parts of the project that cannot be predicted. These are sometimes called "unknown unknowns." For example, major disruptions in the project caused by serious weather conditions, accidents, etc. Use of the management reserve generally requires a baseline change.
See Contingency Reserve.

Multi-Project Schedule -
A schedule of all the work (projects, operational activities, etc.) planned for an individual or organization unit. The purpose is to ensure that resources are not overburdened by inadvertently scheduling project or other work without regard to previously scheduled work. The Multi-Project Schedule is also used to determine the impact of slippage in one project on other projects assigned to the same resources.

Matrix Organization -
A business structure in which people are assigned to both a functional group (departments, disciplines, etc.) and to projects or processes which cut across the organization and require resources from multiple functional groups.

Metrics -
Metrics are quantitative measures such as the number of on time projects. They are used in improvement programs to determine if improvement has taken place or to determine if goals and objectives are met.

Milestone -
A point in time when a deliverable or set of deliverables is available. Generally used to denote a significant event such as the completion of a phase of the project or of a set of critical activities. A milestone is an event; it has no duration or effort. It must be preceded by one or more tasks (even the beginning of a project is preceded by a set of tasks, which may be implied).

Murphy's Laws -
A set of laws regarding the perverse nature of things. For example:

Network Diagram -
A graphic tool for depicting the sequence and relationships between tasks in a project. PERT Diagram, Critical Path Diagram, Arrow Diagram, Precedence Diagram are all forms of network diagrams.

Objective -
An objective is something to be achieved. In project management, the objectives are the desired outcomes of the project or any part of the project, both in terms of concrete deliverables and behavioral outcomes (e.g., improved service, more money, etc.).

Parametric Estimating -
Estimating using an algorithm in which parameters that represent different attributes of the project are used to calculate project effort, cost, and/or duration. Parametric estimating is usually used in top-down Estimating.

PERT—Program Evaluation and Review Technique -
A scheduling technique that makes use of dependency analysis and critical path to determine the duration of a project and slack to determine priorities of tasks. In PERT, task durations are computed as (Optimistic + 4xMost likely + Pessimistic estimates) / 6).

PERT Diagram -
A type of network diagram deriving its name from the PERT technique. The term is often used as a synonym for network diagram.

Phase -
A grouping of activities in a project that are required to meet a major milestone by providing a significant deliverable, such as a requirements definition or product design document. A project is broken down into a set of phases for control purposes. The phase is usually the highest level of breakdown of a project in the WBS.

Planning -
The process of establishing and maintaining the definition of the scope of a project, the way the project will be performed (procedures and tasks), roles and responsibilities and the time and cost estimates.

Post-implementation Review -
See Post-Project Review.

Post-Project Review -
An activity to assess and evaluate the way a project was performed, so as to learn from the experience and continuously improve project performance.

Power -
Power is the ability to influence the actions of others. Power may come from formal delegation of authority, reference power, subject matter expertise, the ability to influence rewards and penalties, as well as other sources.

Predecessor Task -
A task (or activity) that must be started or finished before another task or milestone can be performed.

Process -
A series of steps or actions to accomplish something. A natural series of changes or occurrences.

Product -
The project's material outcome. It maybe a service, event or any material object (e.g., a machine, computer system, new drug, building, etc.). The product includes all necessary aspects of the deliverable (e.g., training, documentation, etc.).

Product Life Cycle -
The time from the delivery of a product, until the product is withdrawn from use or sale. There may be many projects during the product life cycle.

Program -
A suite of related projects and ongoing operational activities managed as a whole.

Project -
An effort to provide a product or service within finite time and cost constraints.

Project Charter -
A document that describes the project at a high level of detail and is used to authorize the Project Manager to begin work. It may also be called a "Project Brief," or any number of other synonyms.

Project Life Cycle -
The full set of activities from the beginning to the end of a project. Generally associated with a set of phases, which are determined based on the major parts of project performance (e.g., requirements definition, design, construction, deployment) and the need for control by the Client organization (checkpoints for Go/No go decision-making).

Project Management -
The process of managing a project which requires the application of planning, team-building, communicating, controlling, decision-making and closing skills, principles, tools and techniques.

Project Manager -
The person responsible and accountable for managing a project's planning and performance. The single point of accountability for a project.

Quality Assurance (QA) -
Making sure standards and procedures are effective and that they are complied with. Note, in some organizations QA is used to refer to the quality control function.

Quality Control (QC) -
Making sure deliverables comply with acceptance criteria. Includes testing and reviews.

Ramp Down -
Ramp down is the effort required to close or suspend a task. It may consist of filing away information, making notes, clean-up, etc. Ramp down can be significant, depending on the task. For tasks that are suspended the degree of ramp down (e.g., notes and filing away information) performed will reduce the ramp up effort. See Ramp Up.

Ramp Up -
Ramp up is the work required to get ready to do a task. It consists of assembling materials, learning about the task (including new tools and techniques) and the time required getting into an optimum work pace. Initial ramp up can be significant, depending on the task. Each time a task is interrupted there is an additional ramp up—getting back to that optimal work pace. See Ramp Down.

Relative Date -
A date expressed as a number of periods (e.g., days, weeks, or months) from a reference point. For example, two months after the project start date. See Calendar Date.

Request for Proposal (RFP) -
A document that describes a need for products and/or services and the conditions under which they are to be provided. The purpose of the RFP is to solicit bids or proposals from prospective suppliers. Also called a Request for Quote (RFQ).

Requirements -
The statement of detailed product objectives that describes the features and functions and performance constraints to be delivered in the product. The requirements provide the basis for accepting the product.

Resource -
Any tangible support such as, a person, tool, supply item or facility used in the performance of a project. Human resources are people.

Resource Dependency -
A dependency between tasks in which the tasks share the same resources and therefore cannot be worked on simultaneously. Resource dependent tasks can be scheduled at the same time but are limited by the availability of the shared resources.

Resource Leveling -
Resource leveling is the part of the scheduling process in which the start and end dates of tasks are driven by resource limitations (e.g., limited availability of resources or difficult-to-manage resource levels). Among the scheduling objectives, is to ensure that resources are not overburdened (don’t schedule more resources for a period than are available) and that (as much as possible) there are not significant peaks and valleys in the resource schedule.

Resource Loading -
The process of assigning resources (people, facilities and equipment) to a project, usually activity by activity.

Responsibility -
The obligation to perform or take care of something, usually with the liability to be accountable for loss or failure. Responsibility may be delegated to others but the delegation does not eliminate the responsibility.

Responsibility Assignment Matrix (RAM) -
A tool used to relate each project activity in the WBS with a responsible organization unit or individual. Its purpose is to ensure that every activity is assigned to one or more individuals (only one with primary responsibility) and that the individuals are aware of their responsibilities.

Risk -
The likelihood of the occurrence of an event. Generally, the event is a negative one like project failure, but may also be a positive event, like the early completion of a task.

Risk Assessment -
Part of risk management in which planners identify potential risks and describe them, usually in terms of their symptoms, causes, probability of occurrence and potential impact.

Risk Response -
Action that can be taken to address the occurrence of a risk event. Contingency plans are collections of risk responses.

Risk Response Control -
Responding to risk event occurrences throughout the project life cycle. Taking corrective action is an aspect of risk response control.

Risk Response Development -
Part of risk management in which planners identify and define actions to be taken in case a risk (positive or negative) occurs.

Schedule -
The project timeline, identifying the dates (absolute or relative to a start date) that project tasks will be started and completed, resources will be required and upon which milestones will be reached.

Scope -
Scope is defined in terms of three dimensions—product, project and impact. Product scope is the full set of features and functions to be provided as a result of the project. Project scope is the work that has to be done to deliver the product. Impact scope is the depth and breadth of involvement by, and effect on, the performing and client organizations.

Scope Change -
Any change in the definition of the project scope. Scope change can result from changes in client needs, discovery of defects or omissions, regulatory changes, etc.

Scope Change Control -
Also called scope change management. The process of making sure that all changes to the project scope are consciously evaluated and their implications to the project plan are considered in making a decision to make the change, postpone it or reject it.

Scope Creep -
The unconscious growth of the project scope resulting from uncontrolled changes to requirements.

Scope Definition -
Breaking down the project's major deliverables into small, more manageable components to make verification, development and project control easier. This may be part of requirements definition and/or design.

Scope Planning -
Development of a statement of the principle deliverables of a project along with the project's justification (business case) and objectives. Part of requirements definition.

Scope Verification -
PMI's PMBOK Guide defines this as the process to ensure that all project deliverables have been completed satisfactorily. It is associated with acceptance of the product by clients and sponsors.

Sequencing Tasks -
A part of the scheduling process in which the tasks are positioned serially or parallel to one another based on dependencies between them. Sequencing results in a task network.

Slack -
See Float.

Specifications -
Detailed statements of project deliverables that result from requirements definition and design. Specifications generally describe the deliverables in terms of appearance, operational constraints and quality attributes. Specifications are the basis for acceptance criteria used in scope verification and quality control. In some organizations and industries, specifications may be qualified as requirements specifications and design specifications. See Requirements.

Spiral Development Approach -
A project life cycle strategy in which prototypes and models are used early in project life to define requirements and design the product. Commonly used when the product being developed is new (as in Research & Development and e-commerce) and the clients do not have a concrete understanding of their requirements and design attributes.

Stakeholder -
Anybody and everybody with a stake in the project - clients, sponsors, performers, the general public and even the family and friends of direct participants can be considered stakeholders. Not to be confused with the guy that holds the stake when the vampire slayer slays the vampire.

Statement of Work -
A description of the scope of a project centered on the major deliverables and constraints.

Straw man -
A tentative decision or solution put forth as a point of reference for detailed critical analysis.

Sub-contractor -
A group or individual providing products or services to the project. Commonly, sub-contractors are considered to be vendors. However there is a growing understanding that any internal group that provides products or services (e.g., an internal technical writing department) is a sub-contractor to the project manager. Of course in this broader usage, the agreement between the parties is not a legally binding contract but it is a contract nonetheless.

Subject Matter Expert (SME) -
An expert in some aspect of the project's content expected to provide input to the project team regarding business, scientific, engineering or other subjects. Input may be in the form of requirements, planning, resolutions to issues and/or review of project results.

Sub-task -
A breakdown of a task into the work elements that make it up. A task must be broken down into at least two sub-tasks for a meaningful decomposition.

Successor -
A task or milestone that is logically linked to one or more predecessor tasks.

Task -
A piece of work requiring effort, resources and having a concrete outcome (a deliverable). A task may be of any size (a project is a very large task). Sometimes the term is used to denote a piece of work at a particular level in a Work Breakdown Structure (WBS) hierarchy e.g., a phase is broken into a set of activities, and an activity into a set of tasks. Except for this hierarchical usage, activity is synonymous with task.

Task Dependency -
A relationship in which a task or milestone relies on other tasks to be performed (completely or partially) before it can be performed. Also referred to as a logical relationship.

Top-down Estimating -
Approximating the size (duration and cost) and risk of a project (or phase) by looking at the project as a whole and comparing it to previously performed similar projects. The comparison may be made directly using "analogous estimating," through an algorithm as in "parametric estimating", or from the memory of estimating experts.

Variance -
The difference between estimated cost, duration or effort and the actual result of performance. In addition, can be the difference between the initial or baseline product scope and the actual product delivered.

Vendor -
An organization or individuals providing products or services under contract to the client or to the project performance group. Also called outside contractors or sub-contractors.

Work Breakdown Structure (WBS) -
A hierarchical task list created by decomposing the project based on the breakdown of the product into components and the breakdown of the project process into increasingly detailed tasks. The WBS is depicted as a tree diagram (or hierarchy chart) or as a list in outline form with detailed items subordinated to higher-level items.

Work Package -
A task at a low level of the Work Breakdown Structure at which project accounting is performed. Usually a week or so in duration and performed by an individual or small work group.

With thanks to ProjectManagementWorks for this glossary

I've really been enjoying reading the 3-part article by Larry Peterson "Living Projects" – having earned my stripes as a software development project manager I am well aware of the conflict between the theory and practise of planning and scheduling a project from start to finish and the realities of software development.

The development of the Agile method of project management was the software developers' response to years of being forced into a waterfall method for their projects, and I have much sympathy for them (having been one for many years myself).

But methods such as Agile are something different from what Larry is advocating when he refers to Living Projects. His view is that projects should be "organic" – not exactly to have a life of their own but to be able to grow, develop and evolve for success in the same way as living species.

Many complex projects involve a cultural change as well as new systems, services or products and when changes are required to how we have always done things, or viewed things, it is almost impossible to predict how that should happen in advance. It might involve establishing new working relationships, or altering existing ones, and those affected may be resistant to the change.

But as a complex project progresses it becomes easier to see how solutions can be found for the changes that personally affect people. So a project that is adaptable and can grow and develop over time will lead to a more successful outcome.

And just as young livings beings (animals and humans) make mistakes, learn and grow into more successful adults so projects (given the funding and support) should be allowed to make mistakes to come out at the end with a better result. Instead, in business, mistakes are usually seen as failure rather than an opportunity to learn and improve.

If the stakeholders and project manager do have the foresight to understand that mistakes can be a route to growing, developing and improving, then those involved in a project must also have the commitment and ability to respond in an agile way to changes in the project environment (more about Agile next time). Then a project can be invested with vitality and achieve genuine success.

It seems that focusing on the successes of the past to learn and grow, just as living systems do, is more beneficial to the outcome of a project than focusing on the mistakes and problems, which only leads to a culture of blame. So maybe if more of us viewed our projects as living organisms then the successful evolution of project management might be more assured.

I recently came across a few of definitions of the Agile methodology which I thought worth sharing. Of course, many people would provide different definitions and the definitive description can be found in the Agile Manifesto but if you haven't got time to read that right now here goes:

"An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with "just enough" ceremony that produces high quality solutions in a cost effective and timely manner which meets the changing needs of its stakeholders" (Scott Ambler)

"Simple, iterative processes, which emphasise creativity and collaboration." (John Rusk)

"A system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors." (James Bach)

Agile Project Management was originally a method created for software developments projects that was more aligned to the realities of how software is actually developed, but it has now been adapted so that it is suitable for use in many other industries.

One of its core principles is adaptability so rather than attempting to anticipate risks and control or avoid change, as is more typical in traditional project management methodologies, agile projects adapt to changing requirements throughout the whole of the project lifecycle. The desire to anticipate and control issues that were not part of the original project specifications or requirements is usually driven by an attempt to keep costs within some defined boundaries or to maintain a pre-defined schedule.

These are still two of the fundamental constraints of any project so how does agile project management satisfy these constraints of budget and schedule?

It is the Agile Method's very flexibility that ensures projects can be delivered on budget, on schedule and on scope because the project team work closely with the client throughout the project, delivering work regularly in stages in order to elicit feedback. By delivering small packets of work, any changes that become necessary have a lesser impact on the budget or schedule because they are made incrementally and based on an earlier work packet that has already been approved.

In more traditional projects the process or product is often so far progressed before the client has the opportunity to provide feedback that its impact on budget and schedule is much greater.

Agile is an iterative framework where the team deliver incremental tasks and continuously receive feedback, learn from it and adapt to ensure the client finds the end result satisfactory.

For those more used to a traditional way of managing projects there are plenty of project management training courses available both online and instructor-led to get you started on becoming agile.

Managing a global project presents a unique set of challenges apart from the obvious ones of different physical locations and time zones. There are also likely to be cultural issues that extend far beyond language barriers; as well as issues of efficiency, administration and reporting.

Many large companies have a worldwide presence and it is common for project managers based in the company headquarters to have the responsibility of leading projects using teams from different countries and cultures. Managing such geographically and culturally diverse projects effectively requires an understanding of the communication challenges and cultural barriers that must be overcome in order to build a successful multi-cultural team with a single common goal.

The reasons for using teams in different parts of the world are almost always based on economic decisions – quite simply it is less expensive to employ teams in certain parts of the world. Sometimes there might be specific skills that are only available in one country but this is a rarer reason to use overseas teams for projects.

And it is not just multi-cultural teams working with language and culture issues that can have problems - seemingly minor differences in working practices can also affect the outcome of the project as can teams with a common language based in different parts of the world. But generally the most significant barriers to project success have been identified as diverse geographic location, time-zone range and cultural and language differences.

So experienced global project managers know that the following differences have to be managed appropriately:

• Location
• Language
• Time
• Cultural

But just how can the risks associated with these differences be managed most successfully?

Communication

Effective communication is the most important tool in a global project manager's toolbox. Right at the outset, communicate with everyone involved in the project to explain the reasoning for assigning tasks to teams in particular locations (use cost-benefit analysis, if appropriate) to prevent ill-feeling between teams. Rivalries and different agendas may exist between different groups and these relationships must be managed to minimise their impact on the overall success of the global project.

Email, telephone calls, instant messaging, internal blogs and forums are all tools useful for day-to-day communication, but it is also important to schedule regular video/conference calls to discuss concerns and problems. These calls should be quite distinct from progress reporting in order to encourage frank discussion about the project in a less formal atmosphere. An experienced global project manager will ensure this distinction is well-understood to avoid situations where problems are not raised because they might indicate lack of progress.

The format and frequency of both the informal communication and the formal progress reporting should be established at the beginning of the project. Depending on the size and complexity of the project and the number of teams involved different reporting may be required at local and global levels.

Never underestimate how important it is for the global project manager to clearly define expectations for individual tasks as well as the overall project work and to provide detailed feedback on all completed tasks that clearly states what was done well and what wasn't. Failure to do so can lead to misunderstandings and result in unsatisfactory work which will be exacerbated due to the global nature of the project.

Time Zone Constraints

It is not unheard of for local teams to work on the same time-zone as the global project manager but disregarding the personal lives of the team members in this way is likely to be counter-productive in building a committed team. Far more effective is setting a common time window when all members are available at their workplace for either scheduled communications, such as conference calls or regular reporting updates, or simply for impromptu communication when everyone can be certain to receive a quick response to any query.

Cultural Issues

Understanding cultural differences is a two-way process aimed at helping everyone involved in the project to understand the expectations and attitudes of each other to reach the ultimate goal of a successful project. Clarifying different attitudes to areas such as quality, cost and time is an important first step. It will help to build trust and loyalty between the global project manager and the local teams which will in turn encourage honesty and accuracy when progress is reported.

Obtaining accurate progress information can be one of the most difficult things to achieve in a global project where local bosses may encourage an attitude of never delivering bad news. Then no matter how hard the global project manager tries to encourage frank discussion this can be difficult to achieve.

Motivation

Methods of motivating individuals vary significantly in different cultures but it is vital for the global project manager to understand what motivates a local team and, just as importantly, the local manager's approach to motivating the team. It is not unusual for a local project manager to have a completely different approach to motivating a team so a global project manager may be encouraging frank discussion and accurate progress reporting whilst the local project manager uses a carrot-and-stick approach that discourages admission of problems. This can be a particular difficulty for global project managers and local teams that have never worked together before and who have not developed trust in each other.

Responsibility for motivating a local team may well be seen as a local level task but where it impacts the success of a global project – most particularly through the failure to acknowledge problems and accurately report progress - then this is an issue for the global project manager.

Managing global projects presents a specific set of challenges that require specific project management skills and experience to overcome. There are inherent difficulties in working with disparate teams from different cultures but the economic advantage in doing so means that global projects are here to stay for the foreseeable future.

I have been debating recently with some colleagues about whether project managers need to have in-depth business knowledge of the business area in which they are managing projects. By in-depth we specifically meant having previously worked in the business itself before becoming a project manager.

In fact, there are some organisations that use certain employees as project managers from time to time but mainly they fulfil some other role. Clearly the business knowledge of those people must be seen as an advantage when managing projects. Or is it as simple as that? If I was being cynical I might suggest that those organisations only occasionally need project managers and it is easier (not to mention cheaper) to simply temporarily transfer someone from an existing role than to employ a contractor.

I wonder what those employees feel about it? Maybe it provides a welcome change from their regular job, or, indeed, a chance to try out the role of project manager without committing to re-training.

But can it actually be a hindrance to have relevant business knowledge – can a project manager remove himself from the coal face and look at the bigger picture? Can he/she effectively communicate with stakeholders and senior management from the overall project perspective without being biased towards the “workers” in the project team?

Or does business knowledge, in fact, enable the project manager to communicate more effectively with everyone on the project from the junior team members to the most senior stakeholder?

Perhaps the answer is “it depends”… it depends on the project management skills and personality of the individual project manager and it most certainly depends on the business area itself. The industry where the answer is most obvious is perhaps in IT where a knowledge of IT itself is always a benefit.

I have recently been considering some of the traits and behaviours that successful project managers exhibit. For a project to be successful it obviously needs someone at the helm with the right project management skills and experience to guide the project and the team from the initiation phase right through to a successful completion all within the time and budget allocated and, of course, within the defined scope. There's no arguing with that, but a project also has to deliver what the client actually wants because it is the client's perception of progress and their opinion of the final deliverable that will give a project the stamp of approval, or not.

Unfortunately in many projects the documented requirements or scope may not actually be what the client wants.

There can be situations where the client has not, and will not, make their full requirements clear and yet the project manager is expected to start the project with only a sketchy idea of the needs of the client and, worse, the expected benefits that the completed project will deliver.

Depending on the industry there are many project managers out there shouting now - surely every client knows what they want and must provide documentation before the project starts? But equally there are just as many project managers who recognise this scenario of vague requirements and difficult clients.

Why do these sorts of awkward clients crop up and what can the project manager do to improve such a situation?

Firstly, try and understand the client – their apparent unwillingness to fully document their requirements may stem from a lack of experience and understanding of what the project is all about and what it's benefits will be. But if you are to deliver a successful project then you need to work closely with the client. This may require a certain amount of diplomatic hand-holding, advice and guidance but without this effort on your part the project is doomed from the start. Try not to think of the client as awkward but simply inexperienced.

Secondly, you must help and encourage the client to define the requirements accurately. This may require you to make suggestions about what you think is needed and maybe even write some, or all, of the requirements documentation. You may not consider writing requirements the job of a project manager but on many projects this is the only way to get them done.

Thirdly, no matter what pressures you are under do not start any serious project work until the requirements are documented and signed off by the client; doing so will simply waste time and effort on tasks that may not actually be needed. If there are some initial pieces of work that you know will be needed to lay the foundations of the project work then this could be started but anything more, and certainly not a full schedule of work, must be held off until client approval is obtained. Hopefully, by working closely with the client in the early stages of the project you will have developed a rapport that will enable approval to be easily obtained.

Let me know if you have any suggestions of your own on how to deal with awkward clients …….

I have previously written an article about the importance of a project manager asking in-depth questions at the outset of a project and how knowing which questions to ask and, more importantly, how to elicit clear, detailed answers is critical to the success of a project. The article lists 20 questions all project manager should ask but recognises that this is just a starting point and a project manager should aim to get into the habit of asking searching questions about every aspect of a project from initiation right through to the final delivery stage.

But, of course, asking searching questions of often easier said than done – it takes a certain amount of tact and diplomacy to approach senior executives with a list of questions and project managers can often feel that continued, detailed questioning reflects less a desire for the project to be a success than of the project manager’s own lack of understanding. There will certainly be some senior managers who see it this way but if you explain the importance of the questioning, hopefully, the response will be different.

But a project manager should also recognise, with tact, that elusive answers are often the result of a lack of full understanding on the part of the people expected to know the answers. There may not be enough detail in the answers simply because nobody understands the area well enough but no-one will admit it!

It could also be that people do not know exactly what is expected of them so supplying examples about the type of answer expected may help to define your expectations as the project manager.

One of the areas that most commonly cause problems in projects because of a lack of documented detail is the assumptions that have been made. By their very nature they are difficult to elicit from people because of the very fact that they are rarely considered or thought about. And whether assumptions are made about areas of responsibility, business knowledge or what the business objectives and expected benefits of a project are, all assumptions are likely to create real problems within a project as it progresses.

So developing a questioning nature is a very useful project management skill and if you make an effort to explain the importance of a seeming barrage of questions and tactfully assist people to provide detailed answers it is likely to lead to more consistently successful project delivery, which is bound to have a positive effect on your career.

I was recently reading some project management articles for inspiration when I came across one about project management in a development environment. Naturally, having an IT and a project management background I just assumed the article would be about software development. After all what other type of development is there?

Well it didn’t take me long to realise the article was actually about building housing developments and the particular skills and experience a project manager needs for those types of project. But that got me thinking about the similarities and, perhaps more importantly the dis-similarities between IT development projects and any other type of project.

Fans of the Agile method of running software development projects (and I count myself one of them) like to assert that the method is suitable for many other types of projects but let’s take building a housing as one example for comparison.

Certainly with software you can plan a bit then produce something to show to the stakeholders – it may be a prototype or one small component of the overall software package. Often these prototypes or stage products in an IT project can look quite impressive (note the word look as they are often not very substantial when put to the test). And the feedback they generate can then be used to make modifications and improvements to the next stage of development and delivery.

But how in practise would this approach work when building a house – I have images in my mind of a cardboard house painted to look like brick but somehow don’t think it would look that impressive. Or maybe build just one room with proper construction materials - somehow I am not convinced. The arguments for the Agile method would still hold true – the client could see the bricks, windows and internal finishes of the single room but in practise (to have delivered it rapidly) it probably would need to be demolished and rebuilt with solid foundations and a proper roof. That might not be too bad if the one and only next stage was the whole house but that isn’t quite how Agile projects work – they are iterative – and the analogy of building first one room, then two, then three and so on, demolishing each in between is laughable.

So I am a fan of Agile but only for certain types of projects – for some projects a more traditional, yet iterative method is still studied on many project managers courses .

In small, relatively simple projects it is not uncommon to find the project manager using a set of spreadsheets to manage the project schedule, the budget and the scope of the project. If the project involves just one internal department and a small project team using spreadsheets often avoids the necessity for stakeholders to get to grips with a project software package they are unfamiliar with. In business spreadsheets are frequently used for many purposes so everyone will be familiar with their capabilities.

Spreadsheets are readily available, simple to use and understand and a convenient way to share data between the client, the stakeholders, the project manager and the project team. The basic data can be used to generate project schedules and reports, and will even provide the option of connecting to a database to retrieve additional information.

Spreadsheets have many advantages but because they are under the control of individuals, they are not so well-suited to complex projects involving departments across an organisation and externally where it is important to have a single, central data repository and a controlled suite of reports and metrics. Indeed their very flexibility and ease-of-use can be counter-productive, encouraging individuals involved in the project to update worksheets, re-format them and modify them to add their own data. The central, common set of data can, over time, become lost in a variety of personalised worksheets and uncontrolled versions making it difficult to be certain of the accuracy of the data.

But, more importantly, spreadsheets lack the controls that are required to prioritise tasks, manage key decision points and effectively handle milestones in a project particularly with respect to changes to the schedule. That is the main reason you will not find them recommended on a professional project managers course.

So, spreadsheets can be, and are, used for project management in small, simple projects, which are well-defined, but for larger and/or more complex projects they do not offer the controls and standards required to manage and report the project status accurately across a large organisation.

In this APM Project Management Qualification (BoK7) podcast, Paul and John discuss procurement. This podcast is ideal for anyone doing one of the APM PMQ project management courses and aims to address the following assessment criteria:

• Explain the purpose, typical content and importance of a procurement strategy
• Differentiate between different methods of supplier reimbursement (including fixed price, cost plus fee, per unit quantity, and target cost)
• Differentiate between different contractual relationships
• Explain a supplier selection process

A procurement process is used by companies in the acquisition of goods and services. This will usually have a defined procurement strategy document and include details on selecting suppliers, setting up contracts and management of those contracts.

Because the procurement strategy document is a standard project document it needs to be in place at the start of a project as it is an important factor at the same time as considering the business case of a project.

Typical parts of the procurement strategy documentation are:

Would it be better to produce the required goods within the organisation or would it be more efficient or cost-effective to use an external producer/suppler. This decision can only be made when the specification of the product is fully understood.

There is a wide choice of contractual agreement types fro the single contract between the client and supplier to more complex agreements between the client and a main contractor and between main contractor and sub-contractors.

These are the payment terms and the way in which the goods or services will be paid for. This could be as simple as a fixed-price method for a clearly specified product through to much more flexible arrangements where an innovative new product is being developed by the supplier for the client.

Large organisations will usually have an established process to help in the selection of the right suppliers, most usually through a competitive tender process where several suppliers provide costs for the required product/service. The aim being for the organisation to acquire the product or service at the most competitive price.

This should be a regular, ongoing process throughout the term of the contract to confirm that both supplier(s) and client are complying with the terms of the contract which they have agreed.

This is important in any type of strategy in order to learn lessons about what went well and what did not; in order to improve the process for future projects.

This podcast is just part of the Parallel Learning System for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses.

SEE THE TRANSCRIPT BELOW:

Introduction:

Welcome to a Parallel Project Training APM Project Management Qualification podcast based on the APM body of knowledge seventh edition. You should be using this in conjunction with our e-learning, podcasts and potentially a tutor-led course. For more information please visit www.parallelprojecttraining.com

Paul Naybour:

Hello welcome to another parallel project training podcast we're on to procurement for the APM PMQ with Paul Naybour and John Bolton.

Hello, John

John Bolton:

Hello everybody.

Paul:

Last chapter. By now the guys are hurray. Guys and girls.

John:

If this takes two minutes it’s because we've had a long day. Yeah, well. It's quite a big topic, though so let’s crack on

Paul:

By completing this subsection you will be able to understand the learning objectives:

• Explain the purpose of a procurement strategy. We need to get that clear, because it causes confusion
• Differentiate between the different types of reimbursement method.
• Differentiate between the different types of contractual relationship
• Explain the supplier selection process.

So, let's talk about procurement strategy first. What is a procurement strategy I think this is the thing that I see causing the most blanks. Also called procurement plans. So basically,

John:

I don't think they do I think if you could say procurement plans, a lot of people they think about supplier selection.

Paul:

Yes, and they get confused. Because strategy is a is a document written early in the project, about how you're going to procure those goods and services.

John:

I think it's a bit more profound than that actually because. Let's say I write a business case. And I'm going to build a bridge. I could if I was a bridge building company. Let's take a different example. Let's say, I'm a construction company. And I'm going to move into a new headquarters. Yes. Right. I could decide to use my own staff to fit the building out and then move us in. Or I could hire a consultancy firms do it for me,

Paul:

Or, you could just lease the building? Or you could build a building.

John:

Let's just worry about how I'm going to fit the building out. Right. Okay. So we've already acquired the building. It's a building. So now I've got to fit it out. I've got to make it fit for purpose for my people. Yeah, I'm going to move my staff in there. But because I'm a building company, I could decide to do all the building work, lay all the carpets, do all the partitions, offices, everything myself. I could use my own staff to do that. Or I could hire somebody else to do it.

Paul:

Or I could just go into a serviced office.

John:

Or, I could hire somebody else in to do it. Okay.

So I've got a choice between using my own people, which would be make it myself. Or I could buy those services in, right. I will talk about service office in a sec. But let's just keep it simple. There's two options. One is where I make it and one is where I buy it. So why would I make it myself it’s because it might be a bit cheaper. I've got more control. I haven't got such a long lead time. So I'm going to go to 10 dodge got a design and get on with it. So there's lots of advantages do it myself. Or if I go to tender I might get a better job done. I haven't got to tie my people up doing fairly mundane work as they might see it.

So there's choices to be made. Now. those choices are fundamental to what project you've got because if you decide to do it yourself, you've got to go and buy all the materials, do all the plans. If I get a consultancy in to do it, a prime contractor, they'll just it.

So now I've got very different contracts. All I'm doing is managing them. Yes. And what they do, I'm not managing my people and how they do it. So the procurement strategy side kind of fits between the business case and the project management plan. Because when you write the project management plan, you've got a very different project. So you kind of go down one limb or the other. And to me, that's the essence of a procurement strategy. And now, if you talk about Yes, we can have a serviced office. If your requirement is a new office, yeah, then yeah, I mean, that might be another form of buying it in. So yeah,

Paul:

So I actually think it goes back to the business because, you know, in the business case, we show different optionss. So some of those may be different procurement option. You know,

John:

That's right or I might decide to do multiple contractors or I might decide to do prime contractors.

Paul:

Before we can get on with the planning of the project. We need to decide what procurement approach or procurement strategy is going to be - a fundamental decision.

John:

That's right. So that document contains a few things. The first thing which is fundamental is whether we're going to make it or buy it.

And the second thing is going to be, are we going to contract people if we do? Yes, and you've very rarely just have one or the other is usually a mixture of the two. You might decide that you're going to do that on the basis of ascertain costs or fixed price or target costs are so it's going to be issues around how you're going to want to pay for it. Milestone payments, lump sums. What form of contract - JCT or NEC3 or whatever it's going to be. Or your own, or IPS.

So there's that procurement strategy kind of laying down the rules. And quite often organisations have these already. They have a way of a standardised way of doing things. And you just tune it.

It's also influenced by business rules as well, because the chances you know that one of your procurements parts of your procurement strategy might be that you make all your acquisitions through some sort of Credit Card, some sort of corporate credit card arrangement. Or you might have to go to three tenders. So there's, there's things that are stipulated to you. So the procurement strategy is a kind of composite of what the organisation wants you to do and how you're going to do this particular project. That's why it's a bit of a hybrid. That's why it doesn't live in the business case or the project management plan, really, because both documents…

Paul:

It’s usually actually written by a procurement specialist. Yeah, what I've done. Yeah, the procurement specialist to go this is the procurement strategy for this.

John:

They're quite popular in the oil and gas industry. And instead of a project management plan, you get a procurement strategy and a project execution plan.

Paul:

Remember, going to that talk by the guy from HS2. And he talked about the procurement strategy, the packages, the way we're going to package up those projects, right, and how the different contractors that they were going to appoint to the different packages. That was like really, really early in the project. So I think that's a really good description because it differentiates the procurement strategy - strategic document - with the bits that we're going to look at next, which are things like the options in terms of different contractual relationships that we can have.

John:

Yeah, so the strategy will say it is our intention to do fixed price only. One of our customers used to do ascertain cost then they went to a fixed price and now they’re back to ascertain cost. So I expect in a few years’ time they’ll go back to fixed price, but that's the kind of global decision that they've made.

Paul:

So different types of contracts relationship, we could adopt…let's do the different types of contract relationship next. So they’ve simplified this quite a lot. Yeah, they’ve basically said… let’s do the most common first.

John:

I've a bit of an issue about this because I think they've like they've really simplified, dumbed this down to a point where it’s meaningless in a lot of ways.

Paul:

The first option is to go to a prime contractor or, principal, or main contractor. Usually a large company, but this should then subcontract the work out and the prime or main contractor may or may not add that much themselves. So they may subcontract everything out, or they may add quite a lot of value themselves. So that's quite common in big projects, because that probably that one be, you know, that big project is too big for one organisation to take on and they need lots of subcontractors. And the client wants to one point of contact so they won't be able to go to one organisation say, right, you're running this project for us. You go away and make it happen.

John:

Yes. So I mean, just to summarise, you've got a client with a contract with a main contractor, and the main contractor intern contracts to subcontractors. So if you had to subcontractors actually you should have three contracts, you know, one main contract and two sub contracts.

Paul:

Yes. But you wouldn’t necessarily - as the customer - see those sub contracts though

John:

That's the problem - one of the problems is you have no direct line of sight with the people that are on the ground. You always have to go through the main contractor and legally, you can't sue a sub-contractor unless you have third party rights. So you know it can take a lot of the burden away from you because what's going to happen is that principle contract is going to integrate all the works everything, they're gonna make sure that bricklayers aren't tripping over the plumbers and electricians are coming in before the plasterer and all that sort of stuff.

Paul:

The advice I heard is if you've got one of these contracts then “eyes on hands off”. So you keep an eye on what's going on. You let the main contract to get on with doing their job as you appointed them to manage that contract. So don't start telling subcontractors what to do.

John:

You might need some decent reporting though. Just to make sure they are on track because otherwise if you have no line of sight with the subcontractors they could be telling you black’s white and you don't know any different so you need quite a good, really good reporting anyway but, even more so in that instance.

Paul:

So then to overcome those disadvantages what you can do is have direct relationships with one or more suppliers single or multiple contractors so people also call this a hub and spoke. So I'm in the spoke and there's loads of people around the hub but now I'm doing the role of the prime contractor. I'm sort of coordinating all those different contractors together so this is a bit like Grand Designs you know where they got the plumber and the electrician and the guy doing the wall and the roof and he's on the phone all the time trying to, you know, put the plumbing guy back because the guy who's doing the plastering hasn't arrived you know.

John:

The first time I did our kitchen I did it the hub and spoke – I don’t want to call it hub and spoke - but anyway, with multiple suppliers. So I got the guy who did the work top because we didn't have any money. It was cheaper. So I managed it all myself and I took the risk of making sure the floor was level so that when they put the worktop in he didn't moan about the floor being unlevel right so, but the next time I did it, I did it with the prime contractor. A kitchen fitting company came in and did it all. They charged me a lot more, but probably, arguably, a better result.

Paul:

I had a kitchen fitted once and the kitchen fitters left their order in the kitchen overnight, and they been paid like £300 - £400 to fit the kitchen and I'd been charged like 1,500 quid for kitchen fitting.

John:

Well, that's the problem.

Paul:

Whoa, I should just employ those guys directly.

John:

Yeah, exactly. But I did the prime or principal guy from the shop in the town. What occurred to me was he had a bigger book than I. He just had more people that he knew.

Paul:

But they knew that if he wasn't happy they weren't going to get any more work.

John:

To be fair, he had more buying power as well. But he didn't use that buying power to reduce my price he used it to reduce his cost

Paul:

For his car! Did he have a nice car?

John:

He did. Yeah, he had a Lotus Cortina.

Paul:

So the advantage is you get more flexibility. So Terminal 5 I think was done this way. So they acted as the hub. And they pulled in the different resources as and when they needed. It gives you more flexibility, but you do have to be a lot better. You have to be more on it. You have to be much more - like you - making sure the floor’s level. And if there's any disputes between those different suppliers, you're the one who's got to fix them.

John:

Well, I mean, when you're thinking about this as well, you need to think about it from a different point of view. These two are not different depends who you are. Because if you're the project manager managing multiple suppliers, you might be doing that on behalf of a main contractor. So the Hub and Spoke is no different to prime contractor. It just depends who you are. So the only thing you're adding to a hub and spoke model is the prime contract between you and the client. That's the only difference. So anyway…

Paul:

So that moves us on to payment rates. So there's different types of payment. And I think people get confused about this, because each of those different types of contracts will probably have multiple payment forms in them - probably some that we call fixed price components where you've agreed, say, a certain amount for your kitchen. And then they'll have a day rate for extras. So within a contract, well, there’s schedule a rate so that's paying so much per unit.

John:

That's not in the book - not anymore. You didn't want it in there so I took it out. And it doesn't appear in any of the indicative content. Any of that. That’s what I'm saying ...

Paul:

Okay.

John:

Okay.

Paul:

So right, what should we do then let's just go quiet and see if I can edit in.

Paul:

So that moves us on nicely talk about the different types of payment that you might see in a contract. Any one contract might have multiple payment mechanisms. So the typical ones, you'll see are fixed price. I think everyone knows what a fixed price is. fixed price fixed scope. Yeah, except it should be firm price.

John:

Woah, really? There was a silence there.

Paul:

A firm price contract is what most people mean by fixed price. Our firm price means that fixed price with a firm scope, fixed actually means it's fixed to some form..

John:

No, no, no, no, no, no. Firm price is firm. Nothing ever changes – nothing. Fixed price is the same as a firm price, except for the things that can change. So in a fixed price contract, you can have inflation. It can be indexed against certain... So fuel prices, consumables. So firm price and fixed price are different. But I've never seen a firm price contract.

Paul:

People usually use him to mean the same thing.

John:

Anything over about a year in duration, you're mad because of inflation and anything can happen to the commodity prices. So I think firm price from the point of view of being one end of the continuum - it's not in the syllabus, anyway. So I think when we talk about fixed price, what we really mean is, there's a reasonably fixed price for reasonable fixed scope of work and any changes will incur extra cost.

Paul:

So next one's cost plus fee. So basically, you pay all my costs, plus an agreed fee. And that fee includes my profit. So implies some form of open book relationship. So you know what my costs are. So I have to send you timesheets or something like that.

John:

The thing is cost not price, so I'm paying your cost. Whereas before I was paying a fixed price so I don't see your costs under a fixed price. Cost plus is typically where they do the scheduler rates. We decide what components we're going to do, but when it actually comes to buy them, I pay you what you've actually paid. So if you want 40 metres of concrete, we estimated that was going to cost five grand. But then it actually turns out to be £3,800. I pay you £3,800 plus an agreed fee, wherever your profit fee is.

Paul:

And are we going to percentage and fixed fees?

John:

Well, they don't differentiate. But we could, I mean, that confuses a lot of people because you can have cost plus percentage fee so I'll pay you 1,000 pounds – sorry - I'll pay your cost plus 10%,. Or I could pay you your cost plus 1000 pounds. Which is slightly different. So cost plus fixed fees. Not really. I might just charge you a design fee. So you might charge me cost plus design fee.

Paul:

Yes percentage is more common, isn't it? Per unit quantity - that's like carpet fitting. So you pay for the quantity - each square metre you have you pay so much per unit.

John:

We used to call that time & materials. So your everyday work we pay an amount of money but it's price, it's not cost. So we pay you your fee for that one day's work. So we pay you for your time & materials.

Paul:

Yeah, it isn't usually quantity though - the output quantity, so it's usually per metre or per square foot.

John:

I think it could be either.

Paul:

Target cost is where you agree a target – we’re going to pay you a million pounds. And then if you underspend the cost I will share the saving and if you overspend we'll share the pain.

John:

Or you might have incentives around that as well. So you've got some target in mind that you're both trying to achieve. And that's the good thing, because you're both working towards the same target because the pain or gain will hit both of you.

Paul:

Correct. And differentiate between different types of contracts we’ve done. For the supply selection process - how did you get into contracts? So most people have met this before. And we've got five steps but there's about 20! Like issue an invitation to tender, get the quotes back, tenders back, off the suppliers. Review those quotes, bids back and then award the contract to the successful supplier. That's actually a vast simplification of a 20 or 30 step process.

John:

Well, I think it can be. I mean, it also can be many years coming – if you’re spending a billion pounds I think, the only way this works, is because it's principles based The only way this works is to describe the principle and let people adapt to their own local conditions. Because every organisation you come across has got a different way of doing this. Do we have three suppliers or five tenders? Have bidders conferences or not? How do we do weighting criteria? You know, so there's a whole bunch of suppliers.

Paul:

Sector-specific as well.

John:

You might get bound up in the European Union's procurement regulations, and there's usually anti-competitive law, and the US has got different laws again.

Paul:

I expect the best advice is if you're going to do a major or significant procurement, go and talk to the procurement specialist because in the UK, certainly, (I’ve only just discovered this actually) the procurement has personal liability for the process having been followed properly. And they can be personally under European law.

John:

Yes. For European procurements. Yes. That’s right. It's custodial sentence as well. You can't do things like breaking it up into two small chunks to get under the limits. It was 200,000 euros, isn't it? 200,000 euros for services and about 1.5 million euros for capital. There's a whole load of other boundaries for service contracts.

Paul:

In practice, most people will get a procurement specialist.

John:

That’ll be a key point in strategy as well. You see, the procurement strategy will raise the fact that you are liable to go through these processes of which you're not in control.

Paul:

Yeah, it's another interesting point, you know about the three-point accountability thing? So best procurement practice is you have a requester, who's a technical person who asked for the work. There's a procurement specialist who place the contract and a finance person who checks and pays the invoice. So you have those three different departments involved in procuring and paying for work. It just means there's less chance of things go wrong. less chance of corruption. Less chance of fiddling the books.

John:

They call it separation of duties.

Paul:

So you'd have that principle of three.

John:

Well, I think you know, great. Good idea.

Paul:

Good. Thank you, John.

In this APM Project Management Qualification (BoK7) podcast, Paul and John discuss risk and issue management. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain each stage in a risk management process (such as identification, analysis response, and closure)
• Explain proactive and reactive responses to risk (such as avoid, reduce, transfer or accept and exploit, enhance, share and reject)
• Explain the benefits of risk management
• Explain the key aspects of issue management

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

Below is a transcript of this podcast:

Introduction

Welcome to a parallel project training APM project management qualification podcast based on the APM body of knowledge seventh edition. You should be using this in conjunction with our elearning podcasts, and potentially a tutor led course. For more information, please visit www.parallelprojecttraining.com

Paul

Hello, welcome to another Parallel Project Training podcast with John Bolton. Hello, John. Hello and Paul Naybour. Oh, we're doing the PMQ and we're doing risk and issue management today. Deep joy. So we've got quite a big section here. Quite a lot of assessment criteria.

John

This was the longest podcast in the box. So this lasts 47 minutes

Paul

So explain the stage in the risk management process such as identify analyse, plan, response and closure, explain proactive responses to avoid reduced transfer and accept exploiting enhance, share and reject, explain the benefits of exposure and explain the key aspects of issue management and contingency. So as we start with this definition, a risk event is

John

well, yeah, a risk event is an uncertain event or set of circumstances that should occur or they occur would have an effect on the achievement of one or more of the project's objectives. That's the prime guide definition. Okay. There is a slightly different glossary definition. Okay, what's the glossary? Say it doesn't talk about risk events as much it talks about just it says something more generic. The risk is the potential of an action or event to impact on the achievement of objectives,

Paul

potential action or event. Yeah. Okay. So they're all events that might have an impact on achievement.

John

Yeah, I mean, I think people talk about the word event as if it's meaningful, I think it's just just a noun,

Paul

or an adjective, whatever it is, to the key thing that can be opposite. They can be opportunities or threats, right. So you're looking at both, which confuses some people sometimes because generically, we talk about risks being bad things, but we don't tend to write down on opportunities are very rarely academic,

John

which is, but then, you know, interest rates could go up as well as down. I have a blog about that fuel prices forgot as well as down. They want to talk about that or not really. Okay. No, I mean, well, we need to mention it, because it could be part of, but it's not ostensibly part of the syllabus. Yeah. You know, they don't talk about risks. Positive risks in here are explicitly Yeah, although they do talk about the responses as being exploiting heartshare or reject, which in the pram guide on opportunity on so we talk about those as well.

Paul

So risks can have causes background facts, it make them happen. So that's called change or political uncertainty, economic uncertainty, or technology or something. And that cause introduces an uncertain event, which has an impact on time, cost and quality usually, or achievement of the overall objectives for the period.

John

So I mean, how is our problem with going down the cause? root, you know, so you can they might rain tomorrow? Because of global warming? That's a fact. Yeah. But I mean, it could cause a global warming is more likely Pratt was the rain. Warning. Yes, exactly. So what's the cause? So close to this, because I've got diesel,

Paul

diesel, and go back and back and back back, but you just try to identify a manageable root cause? So Ben, well, it's

John

a specificity of, isn't it? It's, it might rain, tomorrow's facts, but it might rain when we've got the roof off the building. Yes, that's a risk.

Paul

Yes.

John

So that's something tangible I could do something about the corner. It's only any use to you if there's actually it's meaningful due to the fact we're working outside in February, a rain

Paul

tomorrow,

John

we might have bad weather while we've got the roof of the building. It's while we've got the roof of the building. That's the key bit. Yes. So we haven't got enough resources. That's fact you know, most people haven't. Yes, yeah. So we haven't we haven't we know, we know. We're short of people. Therefore, there's a risk that I won't have my expert on the for a week in June to review my document of risk, and that's the risk.

Paul

And so that means your project might be delayed. That's why Guess what? A good the benefits of risk management. Well, it's demonstrates professionalism, you got sound process in place, means you can calculate the contingencies properly. You know what you're doing about those risks? And it builds a culture that actually lets you take risk,

John

where things go wrong, they're stone they because you're proactively doing something about it. Yes, but but also So it has the has the effect of labelling people to do things. It's an enabling thing rather than a restrictive thing.

Paul

Yes. So risk isn't necessarily bad.

John

No, because where there's where there's muck, there's brass.

Yeah, exactly where there's opportunity risk you get no

better. Exactly, exactly. So, you know, the only way you avoid all risk is sort of lying in bed in the morning. Wait to die. Yeah. sighs you have to avoid the risk, you avoid the

Paul

risk. Yeah. So the process we're going to follow is slightly simplified, identify what those risks are, assess the significance of race plan, what you do by the wrist and close might actually find most people are understand this now. Mostly, they've done it for health and safety perspective.

John

Yeah. And

Paul

we're, we did talk about health and safety earlier. Here, the difference is that we're looking at the impact of time, cost and quality, rather life and accident. So we're going to identify what those risks are, assess them plan what to do about them, and close out the risks.

John

I think it's a shame that they've sort of diluted the health and safety aspects of this a bit because yes, in my experience, a lot of our customers Health and Safety, Health is very important. So I don't want anyone to run away with the idea that we're dismissing that

Paul

now it's mandated requirement,

John

we are talking about project risk here, not kind of such as life and limb.

Paul

Yeah. And so the difference is, this is discretionary. You don't have to understand what your commercial risks are. If you don't, you'll just lose money and grow our business but you do the Law Society says you need to manage your health and safety risks. It's a mandatory thing everybody has to do. So, working through that process, the first terminators identify understand what those risks are. And we've listed out some techniques brainstorming SWOT assumption analysis, interviews, prompt lists, checklists, are slip swatting, they're by mistake. And we're going to talk through each of these are quite obvious, really well,

John

they are I mean, I think people know what a brainstorming session a capture assumption, I suppose the the assumptions analysis might be a bit trickier. My Way think, and assumptions are risks, really? Because I'm assuming I've got five bricklayers, therefore there's a risk. I haven't. Yeah, that's fine. I'm assuming the customer is going to do that for therefore there's a risk they don't.

Paul

Yes. So assumption that you have any uncertainty about

John

sales guys never using let the bid managers put risks in the proposals. Why? Well, because they used to say, well, the customer might think is risky, they want to buy it. But you know, so as descriptions in AD square that circle, so what assumptions in here you have assumptions, pages and pages of assumptions. But basically, I mean, but sometimes you have to make assumptions as we move forward, Tony? Yeah. So you know, I'm assuming that, you know, with the, you know, the server's gonna be delivered on the right day or something, but, you know, essentially, we used to convert that into

Paul

assuming when the server rise, it will run software that we've written.

John

You know, I used to, yeah, so assumptions, we used to turn them into risks, just tell everybody go through them and put them under risk. Because that way they do get managed. Yeah. brainstorm interviews is like a one to one, isn't it? Probably just a good promise, the pestle, you know, do a pestle analysis a good list? Yeah. And then a checklist is a more definitive version of a problem list is where specific actions are identified. So you see, those were things like display screen assessments in the health and safety space. But also, you know, you see him on procurement has the has the has the supplier potential supplier got a clear, you know, credit history, or they got a record of ccjs have they got this okay? So you go and take and if they take all of those then you're at you're sort of happy doesn't mean they're any good, but you've gone through the checklist.

Paul

So from there, we build our risk log or risk register.

John

Yeah, usually got, you know, like a normal Excel spreadsheet type thing. Identification description. In fact, everybody I know uses Excel.

Paul

Do ya? Some people have databases? Yeah,

John

this was big columns and other big database system.

Paul

So then we've got this long list of risks. The next step is which are key risks and most people are happy with this probability impact grid now we look at how likely the risk is impacts gonna be and

John

very common. high probability high impact risk there's one of these on the news the other night was was was watching one of those Brexit things and also face Laura, what's her name? Coons Berg had a risk recipe I wasn't gonna I can't remember it was exactly but yeah, they one of these. So where were the main risks? So they were they were appearing on this

Paul

site, a set of generic sort of templates for infographics. And it had all these in it. Like you have become a member David Wilson invented this thing with a different waiting Yeah, it was this idea that thing get to know that old Yeah.

John

So the pig the pigs all right is a sort of visual training aid. It's a bit rubbish when it actually use one.

Paul

Well, you just code it into a lookup table on your Excel spreadsheet. Yeah.

John

But you just it becomes illegible after about half a dozen on there.

Paul

No, no, sorry, it calculates the colour. So you can build it into Excel so that when you put the high medium low, it will calculate whether it's red, Amber green. Oh,

John

I know. Yeah. But I mean, all you're doing is just yeah. Yeah, but I mean, this actual grid. Yeah. As good as training. And if you've got a workshop with a bunch of people getting to put risks on posters and stick them on the wall, usually is a column and is really yeah, they you normally have a long tabular thing that you can saw.

Paul

Yeah. So next step is take your most significant risks and come up with responses. That's right. Most people will just talk about mitigation here. So we have to just talk a little bit about that, because mitigation is a simplification of the APM

John

view of the world. Well, mitigation is like a collective noun. Yeah, for all of these things, right. So to mitigate a risk, you can accept it, avoid it, transfer or reduce it. That's right. So mitigation is not a valid thing to be talking about.

Paul

Yeah. So for exam mode, we need to talk about accepting the risk is basically saying, Well, I know what that risk is, I'm just gonna live with it. Yeah, I've done I've done all the reasonable stuff that I can to minimise that risk. So eventually, I think you do you end up accepting everything? Yes.

John

I think a lot of us could accept because by definition,

Paul

yeah. And business.

John

Well, the point is, once you've accepted something, you have to provide a contingency.

Paul

Because because they happen rarely see, that's why

John

irrespective of how remote it might be, or unlikely it might be due

Paul

to what happened. And that's where insurance and PII insurance and all that sort of avoid, avoid my favourite actually changed the scope. So that that risk can no longer happen.

John

We're used to stuff called traco ethylene traco. trike,

Paul

oh trike. Yeah. For cleaning.

John

Yeah, yeah, it gives off equipment and mustard gas when you warm it up.

Use a dip. Copper don't use that anymore

while they stop using it because it was a bit dodgy. And so they kind of avoided any risk of it was quite a global that was that was. Yeah, that's pretty nice. Yeah, that was. And so what they did, they introduced a different degreaser. Yeah. Which of course wasn't quite as good. Yeah. So they've already won risk. But they introduced another one. Yeah, that's an example of a secondary risk. Yeah. But avoiding is where you just change what you're doing change the scope, or change the process or

Paul

Yeah, transfer, give the rest of somebody else who's better able to manage your risk looking at somebody else's? Yeah, usually through insurance, an example of transfer or contracting.

John

I don't know. I think transfer is really hard. Because you transfer you don't insurance only transfers, the impact doesn't matter. The

Paul

probability, you only transfer you can only transfer the impact, he cannot transfer the likelihood, if the risk still happens, is transferred to a subcontractor. But the vistal you transfer I think, like if you transfer the risk to a subcontractor if something goes wrong, it's still you're still your fault. So you just replace a kind of digital delivery delay risk with a reputational risk. Yeah, it works if you give it to someone who's better able to manage it than you.

John

Yeah. But it's still like,

Paul

yeah, it's still like, they might have more skill and competence to manage that risk. They might though. Yeah.

John

So that's why that's, that's why you subcontract? Yes. Because there's a risk we can't do it. Therefore get someone that can.

Paul

Yeah, he's done it before. He's got like last Friday's Yeah. Reduce is the closest to what people mean by mitigate. So he takes some action to reduce the likelihood of doing a survey or pilot study or feasibility study. Or you reduce the impacts more tickets reduce the impact. To reduce, you know, it's gonna rain. So wear a coat. Put us put a cover up or something.

John

Yeah, yeah. So if you got to take the roof off the building in February, you're going to offer time? Yes. So reduce him post likelihood. No impact.

Paul

Yes. The impact, correct. Sorry, I was wrong.

John

Then you got opportunities. And these are in to some degree there. The other? Yeah, the adverse, are they so reject his way? So Trevor, we don't bother with it. Yeah. Quite why we need to write that down is beyond me. But anyway, enhance where you you actually try and enhance the probability or the impact

Paul

separately to reduce

John

by doing something? Yeah. So you actually take action to enhance it? Yeah. exploited is where we don't don't do any action. We just take the take the opportunity to take it when it comes. Okay. So there's no cost involved in in house. Yes, they just had to happens or it doesn't same. exploit,

Paul

exploit.

Okay, exploit is different from enhance.

So that's the same as Except to them what exploit?

John

exploit is the same? Well, hold on, let's start again. accept, accept and reject. They go together. Yeah. Yeah. So accept and reject. They're those. If I enhance and reduce, they're the same. Yeah, share, and transfer, they're the same. So avoid an exploit.

Paul

Okay? So we don't avoid it. We just say, Oh, that's a good rest. Let's just go for it.

John

I don't think they're opposites. Yeah, we've had this conversation before, avoid is where you do something differently to stop it happening. exploit is where you do exactly the same as what you were going to do. And wait for it to happen. Yeah. So they're not always opposites. But three of them are, but yeah, so in, you know, in a, in a practical sense, if, if I'm building a new station, and I decide there's an opportunity to put up, pop up coffee shop on it, and get some rent from it, then I might, might exploit that, and just rent it out and cost me nothing. On the other hand, if that space needed some water, or some power, or drainage or whatever, then I might have to do some more grant more enabling works to make it happen. So I'm doing the same thing, except now I'm doing some work to make it happen, rather than just letting it happen naturally. Good.

Paul

So next step is to response. So actually making this happens a lot, I think. So you caught your plan, you put it in this register, and they goes, Oh, that's a really good recipe. Let's put that in the bottom drawer and forget about it. Yeah. So response means actually going out and buying that insurance policy or subcontracting this workhorse, right.

John

That's the thing that's the mistake people make is they think that doing that is contingency, but it isn't buying PCs part of your budget, isn't it? Yeah, actually spend money. So it's golden is doing a prototype, if I decide if I decide I'm going to put some drainage in for that pop up shop. Yeah, all of a sudden, it said work back into my car, and I'm gonna spend it actually

Paul

committed to doing it. That's right. So it's

John

no longer kind of is no longer optional. And enclosure

Paul

is about keeping all the records up to date as in.

John

Yeah, well, it's just about tied in keeping it keeping your shipshape, really. But if the project the project could the risk unnaturally close? So if, if you've got, if you've had the roof of the building and put it back again, then although there's no risk is that yeah, it's like most construction jobs, all the risks are happen before you get to damp proof course. Okay, because it's all about ground condition winds, it's all about, you know, sort of in a lost civilization or, you know, not having a proper, you know, kind of soil, sort of constituency. So, some risks can naturally just drop off. Yes. Others, you get to the end of a project, and you might find if you've identified others, so, if you've built a new build a new building, you realise there's a risk that the flooding, you might need to tell somebody. Yeah, this used to be called closed it? No, it's called monitor monitor.

Paul

Yeah. So I think what they're trying to get out here is when when a phase is like you're saying, when a phase is finished, you can close out the risks associated with that phase. Yeah. And realise the savings. Of course,

John

the point about a close risk is that if there was any contingency associated with it, it gets relinquished. Yes. That's why closures quite important. Yes.

Paul

Yes. So let's talk about contingency. We mentioned it a few times, like so what's your definition of a contingency? Same as yours?

John

I think I hope go on. Well, you when you do probability impact grades, you work out what the probability is. Yes. And the impact? Yes. And that allows you to come up with a figure. Yes. And that figure in pounds is what your contingency is. So the consequence of that is, if it's not on the risk log, there's no contingency for it. Yes, that doesn't mean something could still go wrong, just because it's not in your log. But I've got a I've got a risk that I've identified, I've worked out what my contingency budget is. Alongside that I need a contingency plan. So I need to know what's going to happen if that risk occurs, no matter how unlikely it might be. So that's why it essentially every every risk on a risk log eventually is accepted. Yes. Because, but but you can't just accept it. Accept that

Paul

you have to have some money in the bank, and you have to know what you're going to do. Because it might be really important to you contingency plan is all your team might win the lottery. That's right. So what's your contingency plan if they do?

John

retire,

Paul

or recruit consultants, so you might have to put some agency staff to backfill, that's your contingency plan. So you work that out in advance? Yeah. Well, how much money would you need to set aside for that much plan? Well, the chances of your team winning the lottery blooding? Low Yeah, so not so much. So you write about we need to take counts both the cost of the contingency action, but also the likelihood of slack contingency actually

John

happening, and it's the way insurance works. That's why car insurance things. People say all the insurance was really cheap. Well, that's probably because they consider it to be a really low risk. What's the chance of me getting well

Paul

continued kidnapped in another class if you continuously plan to Lewis cabins?

John

Yeah, that's right. It's like insurance. You'd never don't need it till you need it. No. But that's contingency. So the the obvious question is, well, what do you do about the risks that you haven't identified? That just okay, just pop up in front of known unknown, although actually they're not risk their issues. So what happens to the issues that occur that you never predicted? Yes, the unknown unknowns, and that's called manage reserve.

Paul

Yes. Okay.

John

I, neither neither the contingency or the management reserve are held by the project manager. I

Paul

don't know. That's different from different organisations. Yeah. organisations give the country a little bit of pm some a little bit.

John

Sometime. Yeah, I have problem with giving the project manager the contingencies, they tend to spend it. They'll spend it on things other than things supply chain. Yeah, the dangers continues to get. So the good practice, go all the suppose a recommendation that the ideal solution, I suppose, is where the sponsor holds the contingency, and gives it to the project manager on the on the risk event occurring. Yeah. But that's a bit overly bureaucratic and limiting for the project manager on the contractual relation here might be bigger. I mean, certainly, if you're a supplier, that might be the case. I know, big con, some big contracts have relied on that. When they were they've said to the supplier don't build any contingency. And if it goes wrong, we'll give you them. We'll give you the money.

Paul

Yeah.

John

But by the way, if it's not on your log, you pay for it.

Paul

Yes. So I'm gonna have a logbook, we had that once, guess how many risks we had in the log gone. 500 500. Just to make sure that everything was on the log, yeah, we spent six weeks creating a generic log of risk is always different. It's always interesting that you put pressure on one point because you think that's going to solve the problem. And you create a disincentive to do something else.

John

I went to do a health check on a project up in London once for the government department to remain nameless, and the project managers out I've got 417 or something risks. And I said, I said I don't think I'm managing the

Paul

contract. They said yes, I say whatever. Why don't blame me for not telling them. Yeah, that's that's not the best plan. Really, that's not the best. Yeah, the best reason for doing it. That's the problem. I will not talk about problems of risk. But that's the problems I've seen the risk is when you build it into a contract, it changes the behaviour. Yeah, does people behave in a commercial way rather than because the project deliver cover their backside? That's what they do. So definition of issues, an issue is something that has a problem that's now or in the near future, that's going to breach our tolerances. tolerances, it's going to exceed our expected budget. Yeah. agreed with the

John

tolerances, your wiggle room, needs to be

Paul

in require support from the sponsor to resolve. So they're no longer than certain. Yeah, almost certainly going to happen. Yeah. But they're not insignificant, they're not. So it says the project manager is responsible for the day to day management of the project. This is not day to day issues. This is stuff that's beyond the data, why

John

the way the syllabus is read, or the way the book implies it is these are the things that they can't deal with. Yes. So it's like something's gone wrong. Our family best but actually to melt, some new legislation comes in. That's right. Or whether or not whether or not I've added on the risk or not is irrelevant. because it'd be sorted out. I've never seen this coming. Yeah.

Paul

You know, if you're a project manager, you're going to keep tabs on all the parliamentary legislation, it's going to be introduced by the government tomorrow. In our like, it's not, it's not your job,

John

like, so. issues, really, I mean, and that's why in here, they talk about issue escalation. So I think the key point here for me is issues. Risk Management is prospective. Yes. So it forces you to think about the future and what might go wrong. issue management is here now it's reanimated? Yes. So the project managers got to be quite tuned into what's going on. Yeah. Because you got to spot these things early enough to be able to do something about them and, and actually deal with them straight away. And and that's why the relationship between the project manager in the sponsor is quite important because sometimes issues bubble up, you know, like, I was doing a job and the contractor went out of business. You know, we turned up on a Monday morning, everything was locked up. padlocked up there's a security guard, Stan. Yeah, yeah. You know, you haven't got time to mess about you've got to get a meeting done quickly sorted. You know? So I suppose there's a low tolerance for a lot of documentation around a lot of issues. It usually happens afterwards. But, you know, issue management's usually done through minutes of meetings or, you know, emergency meetings or

Paul

Yeah, I've actually best place to track issues is on the progress report. Yeah, cuz they're the things you actually want to talk to a sponsor. That's right, your progress. That's why I like raid logs.

John

Yeah, you know, risks, assumptions, issues and decisions. Not so right about the decision bit, but keeping them all in the same place. The good thing about risk logs is risk, because risks are not yet happened. There's a probability associated, that probability is always less than 100%. Okay, issues 100%. Yes. So there's that. Yeah, actually, when you look at a risk log and look at an issue log, they're very similar. You can lock people up to saying the same, but the only difference is issues. 100% probability, yeah.

Paul

Little code that says this issue is

John

yes. Because now an issue. And then you've got you've got traceability that as well. Yeah. Yeah. But anyway, that's a bit sort of

Paul

cool. So we talked about contingency, we did benefits of issue management and escalation, our fitness true benefit is that it enables the sponsor to take the decisions of sponsor should be taking, and the project managers take decisions the project manager should be taking. So it's, it means that you can ask for the support or the sponsor to resolve issues that are beyond your remit. And if I think back in my career, I wish I had known about this when I was a junior PM, because I used to carry everything on my back. I, you know, I felt responsible for the whole pie. And I didn't realise that actually, if someone has said to me, Paul, you need an issue management process that you can escalate issues up the chain, they're beyond your remit. I think I'd been more successful and I've had a better career. Not I was unsuccessful. But I just think it's a really useful mechanism.

John

Well, the trouble is, you see, if you sort of take it on yourself, everyone will just get used to taking as far as they won't away didn't tell me. Yeah. And then you got to get yourself to blame everything. I

Paul

call it monkey management.

Key management's a monkey shoulder.

Yeah. And everybody just wants to dump the monkey on you. Yeah. So you just take everybody's monkeys. And

John

by the same token, no, no, senior persons kind of thank you for waiting outside their door every morning or like, Oh, well, that's why today, you

Paul

know, another thing has gone, you know, it's not day to day. So that's why I like this definition of issues or things that are significant. You can't

John

know. So that's why the boundary is quite important. Because, you know, if you are incompetent, you'll have more issues when you Yes, and that become that's what gets thrown up into stark relief. Yeah, quite quickly. Yeah. Because you're always staying outside to go I've got another problem Mirko deal with it. Yeah.

Paul

That's why I think stick them on your monthly report. That's the place to sit down and talk about the issues, you know, less their companies going out of business or something. Good. And we talked about contingency planning. Excellent. Thank you, john.

John

Good

We hope you enjoyed this podcast and found it informative. To find out about our training courses elearning or tutor led course please go to www.parallelprojecttraining.com

In this APM Project Management Qualification (BoK7) podcast, Paul and John discuss earned value. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain why a project manager would use earned value management
• Interpret earned value data (including variances and performance indexes)
• Explain the benefits of using interpretation of earned value data

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

Below is a transcript of this APM PMQ podcast:

Introduction

Welcome to a parallel project training APM project management qualification podcast based on the APM body of knowledge seventh edition. You should be using this in conjunction with our elearning podcasts, and potentially a tutor led course. For more information, please visit www.parallelprojecttraining.com

Paul

Hello, welcome to this Parallel Project Training podcast. Today we're looking at our favourite topic earned value.

John

Yes, hello, Paul – love earned value.

Paul

This is quite a big change in earned value for this syllabus. But anyway, let's go through the assessment criteria. Explain why project managers should use earned value, interpret and value data including variances and performance indices, expand the benefits of interpreting and value and expand the role of contingency planning and projects. So we're not doing any, we don't have to do the sums of calculating Earned Value anymore.

John

No, no. I mean, basically there is this new form of torture called interpret interpret. Yeah, so they give you a diagram and go or give you some numbers and you have to figure out what's going on. Yeah. You have to sort of synthesise, and you have to you have to look at those numbers and kind of read into them what could be going wrong on a particular project?

Paul

What you do quite often in a project environment Anyway, you go to a progress meeting. And someone hands a report to you as you go in the door.

John

Yeah, but I mean, if you got it if you've got a CPI of point eight, yes. I mean, interpret that. What does that mean? Well, that means that we're overspending on costs, we're really efficient. But that could be the result of billions of different reasons, you know, so I'm not, you know, we can go through few of them. But there might be many reasons why that's happening. Yeah. So there's not a definitive kind of List of these. But the essence of it is, is that you're working out some sort of, if you figure out your own value, right, that's what

Paul

Explain why a project manager should use earned value. Let's do that first

John

Okay, well, the principle is that you can't tell how well your project is doing simply by comparing what you've spent with what you thought you were going to spend. So you need another measure. So you need a third axis on your graph. So the curve on your graph, which is progress, progress is calculated. So the third the third act, the third curve is earned value. And that's calculated by taking the budget completion, multiply it by the percentage complete. Yes. So if you've got a war that's worth three grand, and you're two thirds of the way through, you've got 2000 pounds worth of earned value, putting it very crudely. So you plot those figures, you plot how much you spent, how much Earned Value you've got, and you compare the actual span of the plan costs with your own value, and that gives you indices and indexes and variances. It works on the basis that the only really good answer is your own budget, and you've delivered stuff according to the budget. So if there are no variances on earned value or actual costs, so that's the principle. So the consequence of that is that any deviation is bad. Yeah, even if it's positive,

yes.

Paul

Is that we're not necessarily good.

John

It's difference is a deviation. Yes,

so that a deviation positive or negative is not in itself a good thing. However, I thought would be finishing early is probably better than finishing it. No, no, I don't know. I don't agree with you. I don't I have a real problem. I

Paul

remember the slowdown that

John

yes, if you will. Okay, so let's, let's think about that. Then I've got two people on site. One's building the roof and one's building the walls. I mean, how old? Yeah, all right. I don't want the bridge deck delivered before the piers for the whole project, but I don't want the top of the rocket finished before the bottom of the rocket, because I don't know where to put it.

Paul

Yeah. Okay. So at

John

each level, and also don't forget, you're spending money early. So there's this rush to burn money. Yeah. Where's the actual fact it smooths out your

Paul

cash flow? I mean, generally, people will say that if it's if the whole

John

planning the whole planning cycle is predicated on starting as soon as you can, yes. Which is not always a great idea.

Paul

So let's go back a little bit and talk about these measures that we do. So there's basically two sets of measures of variances honour. So when a variance what we do is look at what our earned value is, we compare it to what we should have spent our actual cost. And what we plan to spend our planned planned cost as planned costs, what we should have spent actual costs what was actually spend, so we end up with cost variance, and we end up with a schedule variance, and those should be zero. So basically, we've spent what we expected and we've delivered what we expected and then the A set of measures our performance indices, and now we do exactly the same. But we compare earned value to the actual cost and earned value to the planned cost, but we do as a ratio. So they were looking for the measures to be one to one means one plan. greater than one means were ahead of plan or delivering more efficiently, less than one means we're behind plan or delivering less efficient. So we were just talking about is, ideally you want to be on plan, in terms of delivery. And in terms of

John

progress. I mean, I think the other thing is that, you know, you see people coming up, I've got a CPI of naught point seven or 1.7. Okay, and they're going “really clever aren't I really good”? Quick? So 170% efficient? Yeah, you're gonna ask a few questions. Yeah, Don't forget you see if you're if you fit that means you got to finish early. Yes. And under budget? Yes. Well, the business of the time, no snow, the business has set aside all that money to pay for your project. Okay. So they have no, they have to spend it elsewhere. Yes, yes. Yes. So your business has held back all that money in New York coming in? Why?

Paul

Jesus nicely under forecasts? Yeah. So from those performance indices, we can then do a forecast. And that forecast sort of projects, our current cost performance and current scheduled performance. And so we can turn around to the business and say, I'm currently a little bit ahead. And I think that I might finish this project a little bit ahead, or I'm currently slightly over budget. forecasts.

John

Nothing wrong with being early a bit under budget, you know, no one's gonna moan about that. Yeah, or being a bit late. But over budget, it's not the end of the world. But it's too late to realise at the end of it,

Paul

so that's right. That's a sackable offence

John

to be one to be one month away from the end of them. And then finally, your budget got to be Yeah, it was. Yeah, yeah. That's, that's 90% of the way through realises another 90%. ago.

Paul

Yeah, that's, that's all for life. So. So that's the fork. So basically, from these measures, we can we can do some forecasting,

John

but when you interpret the data, they're either going to give you a graph, I think, I don't know. I mean, whatever data on it. Yeah, it depends on how exactly. SPI CPI No, you know, given those No, you don't do the calculation says

Paul

SPI equals and a CPI.

John

So also quite quite what the answer the question is, oh, God only knows,

Paul

because I think you just play it absolutely straight back. So in my SPI is 1.1. Yeah, that means my head of plan, my CPI is naught point eight. That means I'm overspending for what I've delivered.

John

That's not the question they ask you, though. That's it. They don't ask you that. They say you've got a CPI of naught point eight. Explain what might be going wrong on the project. I'm running late here, though. But that's so why

Paul

I don't have enough data to answer that question. So yes, that'd be running late for a number of reasons.

John

Yeah. Well, but that's what it says in the sample paper.

Paul

Okay, well,

John

okay. So again, some of the people that are listed exactly the people that listen to this need to understand how to answer that. Okay, well,

Paul

I'd say, I could be running late for a number of reasons scope, because

John

I might not be able to get resources this way. So may have, it's a comparison between the CPI and SPI as well. So you look at both of them together. Okay. Because just saying I'm late, because you can't really tell much from that and help with that. Actually, yeah. Because there isn't, there are things that you can deduce from the relationship between the CPI and the CPI. So if you're, if you're spending too much, but you're late, you're probably inefficient, yes. Which means that the people are working odd and spending a lot of money. They're not getting anywhere. Yes. So you might find that there's lot of rework or incoming materials, not very good. scope is poorly controlled. But conversely, if you're early, so I were what was the last one over budget and late, you can be under budget and early. Right. So what that means is really that you're, you're very efficient, you could probably afford to slow down a little bit if you needed to. Or, you know, you might want to re estimate the project, because you're kind of you're kind of doing too well,

Paul

on the most common one I've seen is you really liked. We're not spending enough.

John

Yes, that's right.

Paul

So the team you have is been efficient, because they're delivering more value than cashing in. But you just haven't got enough result.

John

enough resources. So there are

Paul

some, it's, you could say this is indicative of that sort of situation, you know, yeah. And I suspect we'll do it.

John

We'll do in the course as well there. Yeah. I mean, if you if you read if you read our material, there are some parts. Project one, two and four. Yeah, there's there's four examples. There's, there's four main examples of the interpretation. But yeah, when you say the question is, it's a bit you know, without the data, it's very difficult to be definitive. So you have to realise or more generic answers I can see that will develop over time. Well, yeah, once once the examiners work out what he

Paul

earned value and values measure those three things, the planned cost, that what we've actually spent and our progress in terms of earned value then comparing them and you can compare them as variances differences or distractions from they can forecast what your end is going to be. And you can do some sort of arm waving indicative interpretation or waving of mostly around how efficient your resources you know, are you put in is, is the I put enough money in to get the progress you want or is more money going in the progress you've achieved? Brilliant. Excellent. Okay, john.

We hope you enjoyed this podcast and found it informative. To find out about our training courses elearning or tutor led course please go to www.parallelprojecttraining.com

In this APM Project Management Qualification (BoK7) podcast, Paul and John discuss stakeholder management. This podcasts aims to address the following APM PMQ assessment criteria;

• Describe how resources are categorised and allocated to a linear life cycle schedule
• Differentiate between resource smoothing and resource levelling

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast Michelle and Paul discuss scheduling. This podcasts aims to address the following APM PMQ assessment criteria;

• Describe ways to create and maintain a schedule (including critical path and Gantt charts)
• Differentiate between critical path and critical chain as scheduling techniques

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Paul and John discuss stakeholder management. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain the relationship between stakeholder analysis, influence and engagement
• Explain the importance of managing stakeholder expectations to the success of a project

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Paul and John discuss estimating. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain the approaches to producing estimates (including parametric, analogous, analytical and Delphi)
• Explain the reasons for and benefits of re-estimating throughout the project life cycle

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Michelle and John discuss the project management plan. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain the relationship between the deployment baseline and the development of a project management plan in linear and iterative life cycles
• Explain the importance of producing a project management plan
• Describe the typical contents of a project management plan

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Michelle and John discuss information management. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain an information management process (including collection, storage, curation, dissemination, archiving, and the destruction of information)

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Jan and John discuss business case and investment appraisal. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain the importance of a business case throughout the project life cycle
• Explain what is meant by benefits management (including identification, definition, planning, tracking and realisation)
• Explain investment appraisal techniques used by a project manager (including Internal Rate of Return (IRR) and Net Present Value (NPV))

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Paul and Jan discuss change control. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain different stages of a typical change control process (such as request, initial evaluation detailed evaluation, recommendation, update plans, and implement)

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, John and Jan discuss requirements and configuration management. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain how to establish scope through requirements management processes (such as gather, analysis, justifying requirements, ad baseline needs)
• Explain how to manage scope through configuration management processes (such as planning, identification, control, status accounting, and verification audit)

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Paul and John discuss scope management. This podcast aims to address the following APM PMQ assessment criteria;

• Explain how to define scope in terms of outputs, outcomes and benefits (including use of product, cost and work breakdown structures)

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Paul and Jan discuss the conflict and negotiation. This podcasts aims to address the following APM PMQ assessment criteria;

• Describe the characteristics and benefits of effective teams and teamwork
• Explain factors which impact on the leadership of virtual teams
• Explain factors which influence the creation, development and leadership of teams (using models such as Belbin, Margerison-McCann, Mysers-Briggs, Hackman, Tuckman, Katzenbach and Smith)

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Jan and Paul discuss leadership. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain how leadership impacts on team performance and motivation (using models such as Maslow, Herzberg and McGregor)
• Explain why it may be necessary to change leadership styles to effectively support the management of a project

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, John and Paul discuss the conflict and negotiation. This podcasts aims to address the following APM PMQ exam assessment criteria;

• State sources of conflict within a project
• Explain ways in which conflict can be addressed (such as the Thomas Kilmann Conflict Mode Instrument)
• Explain how to plan and conduct negotiations (including ZOPA, BATNA, and 'Win Win')

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Paul and Jan discuss the communication. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain the benefits, to a project, of a communication plan
• Explain the relationship between stakeholder analysis and an effective communication management plan
• State factors which can positively or negatively affect communication

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Paul and John discuss project life cycles. This includes look at the differences, phases and reviews in linear, iterative and hybrid life cycles. This podcasts aims to address the following APM PMQ assessment criteria;

• Differentiate between linear, iterative and hybrid life cycles
• Explain why projects are structured as phases in a linear life cycle
• Explain the differences between a project life cycle and an extended life cycle

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Jan and Michelle discuss the project environment. This podcasts aims to address the following APM PMQ exam assessment criteria;

• Describe the functions and benefits of different types of project office (including project / programme / portfolio management office (PMO), embedded PMO, central PMO and hub and spoke PMO).
• Explain why aspects of project management governance are required (such as the use of: policies, regulations, functions, processes, procedures and delegated responsibilities.

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Paul and Jan discuss project roles. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain the role and key responsibilities of the project manager
• Differentiate between the responsibilities of the project manager and the project sponsor throughout the project.
• Describe other roles within project management (including users, project team members, the project steering group / board and the product owner)

This podcast is just part of the Parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, online e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Jan and John discuss organisational roles within projects. This podcasts aims to address the following APM PMQ assessment criteria;

• The difference between types of permanent and temporary organisation structures (including functional, matrix and project)
• Explain the way in which an organisational breakdown structure is used to create a responsibility assignment matrix

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, John and Paul discuss regulation in projects. They talk about the impact of regulation on projects, including working conditions, risk management and governance.

This podcasts aims to address the following

In this APM Project Management Qualification (BoK7) podcast, Jan and Michelle discuss the project environment. This podcasts aims to address the following APM PMQ assessment criteria;

• Explain tools and techniques used to determine factors which influence and impact projects (including PESTLE, SWOT, and VUCA)
• Explain the impact of legal and regulatory environment on projects (such as the impact on working conditions, risk management, governance and sustainability)

This podcast is just part of the parallel learning system for the APM Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Michelle and Jan discuss projects, programmes and portfolios. They discuss the difference between project management, programme management and portfolio management, and the way they fit in an organisations strategic goals.

This podcasts aims to address the following APM PMQ assessment criteria;

• Differentiate between project management, portfolio management and programme management
• Outline the relationship between programmes, projects and strategic change
• Describe situations where the use of programme management may be appropriate

This podcast is just part of the parallel learning system for the APM PMQ Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this APM Project Management Qualification (BoK7) podcast, Paul and John discuss projects and business as usual. They look at the characteristics of a project, and explain how projects differ from the business as usual activities in an organisation.

This podcasts aims to address the following APM PMQ assessment criteria;

• Differentiate between projects and business as usual (BAU)

This podcast is just part of the parallel learning system for the APM PMQ Project Management Qualification. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this podcast the Parallel team discuss the following assessment criteria:

Outline the purpose and benefits of project progress reporting

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

Studying for the APM PFQ will enable you to:

• apply the fundamental principles of project management including monitoring and tracking project progress

• successfully deliver benefits to your organisation through well-managed projects

• gain a recognised qualification to enhance your career prospects as a project professional

• develop the behaviours and leadership skills needed to become a successful project manager

Find out more about the wide range of professional Project Management Qualifications available at www.parallelprojecttraining.com

In this podcast the Parallel Team discuss the following assessment criteria: state the purpose of: decision gates, post project reviews, benefit reviews and project audits

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for novice project managers or people working in project orineted sectors who want a better understanding of the processes, tools and language of project management.

At the end of the APM PFQ course, you will be able to apply the fundamental principles of project management in your everyday project environment. You will also be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects

This internationally recognised qualification will also enhance your career prospects as a project professional.

If you are seeking a Project Management Qualification find out more at www.parallelprojecttraining.com

In this APM PFQ podcast the Parallel team discuss the following assessment criteria:

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers leading to an internationally recognised qualification that will enhance your career prospects as a project professional.

If you are seeking a Project Management Qualification find out more at www.parallelprojecttraining.com

In this APM PFQ podcast the Parallel team discuss the following assessment criteria:

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

If you are considering a Project Management Qualification to boost your career prospects find out more at www.parallelprojecttraining.com

In this APM PFQ podcast, the Parallel Project Training team discuss the following assessment criteria:

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

Studying for this accreditation will equip you with the practical skills and knowledge to successfully deliver benefits to your company through well-managed projects. It will also help you to develop the behaviours and leadership skills needed to become a successful project manager and enhance your career prospects as a project professional with an internationally recognised qualification.

If you are considering studying for a professional Project Management Qualification find out more at www.parallelprojecttraining.com

In this podcast the Parallel team discuss the following assessment criteria:

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management
• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects

• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

This internationally recognised qualification will also enhance your career prospects as a project professional.

If you are seeking a Project Management Qualification find out more at www.parallelprojecttraining.com

In this podcast the Parallel team discuss the following assessment criteria:

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management including identifying and managing risk

• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

This internationally recognised qualification will also enhance your career prospects as a project professional.

In this podcast the Parallel Team discuss the following assessment criteria:

outline options for resource optimisation (including resource levelling and resource smoothing)

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management including:

• • Defining the business case
  • Establishing scope
  • Drawing up a plan for project delivery
  • Identifying and managing risk
  • Monitoring and tracking project progress
  • Controlling change

• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

This internationally recognised qualification will also enhance your career prospects as a project professional.

In this podcast the Parallel team discuss the following assessment criteria:

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

The APM PFQ is an internationally recognised qualification will also enhance your career prospects as a project professional.

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management including:

• • Defining the business case
  • Establishing scope
  • Drawing up a plan for project delivery
  • Identifying and managing risk
  • Monitoring and tracking project progress
  • Controlling change

• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

In this podcast the Parallel Team discuss the following assessment criteria:

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

This internationally recognised qualification will enhance your career prospects as a project professional.

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management including:

• Defining the business case
• Establishing scope
• Drawing up a plan for project delivery
• Identifying and managing risk
• Monitoring and tracking project progress
• Controlling change

• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

In this podcast the Parallel team discuss the following assessment criteria:

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

This internationally recognised qualification will enhance your career prospects as a project professional.

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management including:

• • Defining the business case
  • Establishing scope
  • Drawing up a plan for project delivery
  • Identifying and managing risk
  • Monitoring and tracking project progress
  • Controlling change

• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

In this podcast the Parallel team discuss the following assessment criteria:

1. Define the term ‘communication’

2. outline the advantages of different communication methods (including face to face, physical and virtual).

3. outline the disadvantages of different communication methods (including face to face, physical and virtual).

4. outline the contents of a communication plan.

5. explain the benefits, to a project manager, of a communication plan.

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

This internationally recognised qualification will enhance your career prospects as a project professional.

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management

• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

In this podcast the Parallel team discuss the following assessment criteria:

Outline the stakeholders of a project management plan

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

This internationally recognised qualification will enhance your career prospects as a project professional.

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management including:

• • Defining the business case
  • Establishing scope
  • Drawing up a plan for project delivery
  • Identifying and managing risk
  • Monitoring and tracking project progress
  • Controlling change

• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

In this podcast the Parallel team discuss the following assessment criteria:

Read this blog post Deployment baselines for linear and agile projects for what is a deployment baseline and how to use it in linear and agile projects.

Read our Guide to Project Management Qualifications to find out more about all of our project management training courses that will enhance your career prospects as a project professional.

In this podcast the Parallel Team discuss the following assessment criteria for the APM Project Fundamental Qualification:

Explain why establishing success criteria is important at the start, during, and at the handover of a project

The APM Project Fundamentals Qualification (PFQ), formerly known as the APM Introductory Certificate, is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of project management.

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

This internationally recognised qualification will enhance your career prospects as a project professional.

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management including:

• Defining the business case
• Establishing scope
• Drawing up a plan for project delivery
• Identifying and managing risk
• Monitoring and tracking project progress
• Controlling change

• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

In this podcast, the Parallel team discuss the following assessment criteria;

The APM Project Fundamentals Qualification (PFQ) is a widely recognised qualification developed by the Association for Project Management, the chartered body for project professionals. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of the project management environment.

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management
• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

In this APM Project Fundamentals Qualification (BoK7) podcast, the Parallel team discuss project roles. This podcasts aims to address the following APM PFQ assessment criteria;

• Outline project management roles and responsibilities (including the project sponsor, project manager, project governance, project team members, end users, product owner and the project management office)

The APM Project Fundamentals Qualification (PFQ) is a qualification developed by the Association for Project Management, the chartered body for the project profession. It is a practical course for people new to working on projects and who need a better understanding of the processes, tools and language used in a project management environment.

This internationally recognised qualification will also enhance your career prospects as a project professional.

If you are seeking a Project Management Qualification find out more at www.parallelprojecttraining.com

In this podcast the Parallel team discuss the following assessment criteria:

The APM Project Fundamentals Qualification (PFQ) is a widely recognised qualification developed by the Association for Project Management, the chartered body for project professionals. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of the project management environment.

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management
• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

In this podcast the Parallel team discuss the following assessment criteria:

describe why PESTLE analysis might be used by a project manager

The APM Project Fundamentals Qualification (PFQ) is a widely recognised qualification developed by the Association for Project Management, the chartered body for project professionals. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of the project management environment.

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management
• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

In this podcast the Parallel team discuss the following assessment criteria:

The APM Project Fundamentals Qualification (PFQ) is a widely recognised qualification developed by the Association for Project Management, the chartered body for project professionals. It is a practical course for new project managers or members of project teams who want a better understanding of the processes, tools and language of the project management environment.

Read our Guide to Project Management Qualifications and find out more about our project management training courses at www.parallelprojecttraining.com

At the end of the APM PFQ course, you will:

• Be able to apply the fundamental principles of project management
• Be equipped with the practical skills and knowledge to successfully deliver benefits to your organisation through well-managed projects
• Gain a recognised qualification to enhance your career prospects as a project professional
• Develop the behaviours and leadership skills needed to become a successful project manager
• Confidently sit the APM Foundation Project Fundamentals Qualification (PFQ) examination

Find out more about all of our training courses for project managers at www.parallelprojecttraining.com

In this video we give you a sneak peak at our new BoK7 elearning - including our Moodle page, our elearning videos and podcasts.

Find out more about all of our training courses for project managers at www.parallelprojecttraining.com

This is a samples lecture from the APM Fundamentals course from Parallel Project Training.

In this section we look at how we can manage uncertainty in the project.

What's Included In This Section?

Define:

• Definition – project risk and risk management
• Project risk management process
• Use of risk register

Read our Guide to Project Management Qualifications and find out more about a formal qualification based on this podcast at http://www.parallelprojecttraining.com/distance-learning/apm-project-fundamentals-qualification.

This is the first part of the APM Fundamentals case study. You can follow Jayne as she manages to project, establishing roles and responsibilities and deals with the challenges along the way.

Read our Guide to Project Management Qualifications and find out more information about a formal qualification based on this podcast at http://www.parallelprojecttraining.com/distance-learning/apm-project-fundamentals-qualification.

Project Roles

Management structures by which projects operate including the roles and responsibilities of the different players involved.

What's Included In This Section?

Roles and responsibilities of:

• Project manager
• Project sponsor
• Project steering group/board
• Project team members
• Project management office (PMO)
• End user

Read our Guide to Project Management Qualifications or for more information on a formal qualification based on this podcast visit http://www.parallelprojecttraining.com/distance-learning/apm-project-fundamentals-qualification.

Project Life Cycle

Many projects follow a structured lifecycle, in this section we look at the APM life cycle and the benefits of using a life cycle.

What's Included In This Section?

• Definition of a project lifecycle
• A discussion of the project phases
• A discussion on the reasons for structuring projects into phases

Read our Guide to Project Management Qualifications and find out more about our a formal qualification based on this podcast at http://www.parallelprojecttraining.com/distance-learning/apm-project-fundamentals-qualification.

In this section we look at the impact of the project environment or context on the way a project is planned and executed.

What's Included In This Section?

• Define the term project environment
• Define the components of the PESTLE acronym

Read our Guide to Project Management Qualifications and find out more about a formal qualification based on this podcast at http://www.parallelprojecttraining.com/distance-learning/apm-project-fundamentals-qualification.

Portfolio and Programme Management

In this session we discuss the role of portfolio and programme management in the delivery of projects.

What's Included In This Section?

• Definition – programme management and portfolio management
• Relationship of programme management and portfolio management to project management

Read our Guide to Project Management Qualifications and find out more about a formal qualification based on this podcast at http://www.parallelprojecttraining.com/distance-learning/apm-project-fundamentals-qualification.

This podcasts is part of the APM Fundamentals of project management, the APM fundamentals course.

An introduction to the Fundamentals of Project Management from the Association for Project Management.

What's Included In This Section?

• What is the APM Fundamentals in Project Management?
• Who will benefit from this course?
• What resources are available to you?
• What is the structure and format of the exam?

Read our Guide to Project Management Qualifications and find out more about a formal qualification based on this podcast at http://www.parallelprojecttraining.com/distance-learning/apm-project-fundamentals-qualification.

Parallel Project Training are proud to launch an on-line fundamentals of project management course based on the study guide written in partnership with the Association for Project Management. This course gives practical and effective advice on how to manage projects and is ideal for those who are new to thinner project management career. The course package includes

The course is available with and without the online APM Project Fundamentals Exam.

Parallel will be offering a £50 discount on the course for the first 3-months.

Read our Guide to Project Management Qualifications and find out more about a formal qualification based on this podcast at http://www.parallelprojecttraining.com/distance-learning/apm-project-fundamentals-qualification.

• describe advantages and disadvantages of earned value management
• perform earned value calculations and interpret earned value data

This podcast is just part of the Parallel learning system for the APM Qualifications in project management. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

14.1 explain the purpose, typical content and importance of a procurement strategy,

14.2 distinguish between different methods of supplier reimbursement (including fixed price, cost plus fee, per unit quantity, target cost),

This podcast is just part of the Parallel learning system for the APM Qualifications in project management including APM PMQ. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this podcast we introduce the APM project management qualification (APM PMQ) which was formerly known as the APMP. The podcasts includes

• Discussion on the changes in the course syllabus from the 5th edition to the 6th edition.
• A discussion of the assessment criteria for the qualification
• Exam hints and tips based on the course guidance notes
• An introduction to the parallel project learning system.

You can visit our website for more information on these project management courses

In this podcast discuss the differences between project, programmes and portfolios. In particular how these three are related to each other and examples of each. The APMP (now known as the APM PMQ) assessment criteria covered in this podcast include

• 3.2 differentiate between project management and portfolio and programme management,
• 3.3 outline the characteristics of programme management and its relationship with strategic change,
• 3.4 explain the challenges a project manager may face working within a project, programme or portfolio.

You can visit our website for more information on these project management courses

In this podcast discuss the different types of legislation that are relevant to project management. This includes legislation on Health and Safety, Employment regulations, Contract law and regulations and environmental legislation. This is a new part of the APMP syllabus (now known as the APM PMQ) but is highly significant for many project managers. The APMP assessment criteria covered in this podcast include

• 3.8 explain the importance of relevant legislation applicable to projects (such as health and safety , environmental, employment, contract, data protection, freedom of information)

This podcast is just part of the parallel learning system for the APM Project Management qualification (APMP). This approach includes a wide range of learning resources included a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this podcast discuss the different types project organisation that can be adopted to deliver project and the advantages and disadvantages of each. We also discuss the working practices of each type of organisation and which would be appropriate in different circumstances. The APMP assessment (now known as the APM PMQ) criteria covered in this podcast include

• 1.1 differentiate between types of organisation structures highlighting advantages and disadvantages of each (including functional, matrix, project)

This podcast is just part of the parallel learning system for the APM Project Management qualification (APMP). This approach includes a wide range of learning resources included a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this podcast discuss the differences between projects such as building a new shopping centre and business as usual operating a shopping centre. The podcasts includes

• 3.1 distinguish between projects and business as usual {BAU}

You can visit our website for more information on these project management courses

In this podcast discuss the importance of a project context (or environment) to the success of a project. It explains why project managers need to understand the contest within which the project is delivered and how a different context can affect the way in which the project is delivered and success evaluated. The APMP assessment criteria (now known as APM PMQ) covered in this podcast include

• 3.6 describe how environmental factors affect projects(including the sector, geography and regulation),
• 3.7 explain tools and techniques used to assess a project's context (including PESTLE, SWOT)

This podcast is just part of the parallel learning system for the APM Project Management qualification (APMP). This approach includes a wide range of learning resources included a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this podcast is about scope management and requirements. Scope is defined in terms of products a project produces and the work required to produce it. However, the products and their complexity are often defined by the requirements. If the requirements change then the products change too. In this podcast we discuss the linkages between requirements definition and scope management. It is important to recognise that the two are closely inter-related and understand the linkages between the two. The APMP assessment criteria (now known as APM PMQ) covered in this podcast include

• 9.2 explain how to manage scope through, requirements management processes (such as capture, analysis, justifying requirements, baseline needs), configuration management processes (such as planning, identification, control, status accounting, audit and verification)

This podcast is just part of the parallel learning system for the APM Project Management qualification (APMP). This approach includes a wide range of learning resources included a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this podcast is about the role of the business case in the project lifecycle. Why we have a business case, who owns it and what does it contain? The APMP (now known as APM PMQ) assessment criteria covered in this podcast include

• 10.1 explain the purpose of a business case and its importance during the project life cycle,
• 10.2 describe who has authorship and approval of the business case

This podcast is just part of the parallel learning system for the APM Project Management qualification (APMP). This approach includes a wide range of learning resources included a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

10.10 explain estimating techniques (including analytical, comparative, parametric, three-point, PERT formulae), 10.11 explain the reasons for and benefits of re-estimating through the project life cycle and the concept of the estimating funnel

This podcast is just part of the Parallel learning system for the APM Qualifications in project management, including APM PFQ and APM PMQ (previously known as APMP). This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

10.12 describe stakeholder management processes,

10.13 explain the importance of managing stakeholders expectations

This podcast is just part of the Parallel learning system for the APM Qualifications in project management, such as APM PFQ and APM PMQ (previously known as APMP). This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses

In this podcast is about benefits management and how it fits into the project lifecycle. Benefits management is a fairly new topic for many project managers and organisations. It is important to track the benefits projects deliver, but at the same time it can be difficult to follow up with benefit after the project has disbanded. Not lease because everyone is now working flat out on the next project. The APMP (now known as APM PMQ) assessment criteria covered in this podcast include

• 10.3 explain benefits management (including success criteria and key performance indicators and their uses in measuring project success)

This podcast is just part of the parallel learning system for the APM Project Management qualification (APMP). This approach includes a wide range of learning resources included a printed study guide, on-line e-learning, a tutor lead study group and a wide range of project management courses