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; What is ChPP, and why might someone want to become chartered? The application process What is different with the new version of the Chartered Standard. An introduction to technical knowledge and professional practice.   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.

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: Meeting Requirements: By clearly defining the business requirements at the outset and staying focussed on those requirements even when changes occur and risks arise, the end result will meet the client's needs. Client Satisfaction: Project management provides the tools and techniques to help deliver projects that not only meet the client's needs but are on time and on budget which naturally leads to client satisfaction. Flexibility: By incorporating change management processes into the running of the project and anticipating the need for changes, there can be the opportunity for flexibility in the client's requirements without risk to the project's success. Minimising Risks: Risk Management is an integral part of project management and, as such, risks can be anticipated and dealt with easily as they are not unexpected. Schedule: The detailed plans and schedules that are part of all good projects enable you to pre-empt scheduling conflicts and over-runs and deal with them by either modifying the project tasks or agreeing a revised schedule with the stakeholders. Controlled Costs: Perhaps one of the greatest benefits of controlled and organised project management is that you can spot problems with escalating costs before they become a major issue. You can then deal with them relatively easily because you have the detailed information to do so. Efficiency: Well trained project managers have learnt from the accumulated knowledge of projects that have gone before as well as those they have personally been involved in. They know what works well and what does not. Quality: Efficient projects that treat quality control and quality management as an inherent part of the project process result in higher quality end products. Communication: Everyone involved in the project, from team members, right through to the client will be kept well-informed of progress, change and risks. Good communication is a vital for a successful project. Team Motivation: When everyone involved in a project can see (from the plans, schedule and reports) what has been achieved, and by whom, then this will motivate all members of the team. They will get the recognition they deserve for a job well done. 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: Let their voices be heard. Listen to their opinions and concerns and act on them whenever possible. If you don't agree with their opinions then explain why and take their concerns seriously (even if you think they are trivial, they are clearly important to the project team member). Talk to the team members in person on a regular basis and not just at scheduled meetings or brainstorming sessions. If you are in the same building and can talk face-to-face then don't phone or send an email. Help each team member to gain new project experience – push them outside their comfort zone a little by giving them additional tasks and responsibilities that will increase their confidence. Be flexible about when their working day starts and end – recognise that the team members have a life outside work. As long as every team member is in the same location for a core number of hours every day, and that tasks are completed on-time, a little flexibility can make a big difference in motivating a project team. Encourage the team to work together, to learn from each other and to be a sounding board for bouncing new ideas off each other. Discourage competitiveness between team members – of course competitiveness between other organisations can be good for motivation, but within the team it will simply lead to a divisive and "me-centred" attitude. Help each team member to develop professionally by encouraging them to attend professional project management courses. If traditional off-site training is not an option then look into e-learning and podcasts that will enhance their project management skills. Encourage creativity and innovative thinking by giving the whole team the opportunity to get together for informal sessions that are not concerned solely with the current project. Use it as an opportunity to come up with ideas for the next project. Don't let a blame culture become established either within the project team or within other departments involved in the project. Encourage acceptance of a problem or mistake and move on to finding ways of resolving it. But don't forget to make sure everyone has learned a lesson for next time. Buy coffee and doughnuts every once in a while for the whole team. Everyone loves a treat! 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: Agenda: Write a detailed agenda and send it out to all participants before the meeting so they have time to read it and gather any information they may want to bring along. Purpose: Inform everyone of the objective of the meeting in advance and tell them again at the start of the meeting. Remind people during the course of the meeting if the conversation is losing direction. Agreement: At the end of each agenda item do a quick summary and seek everyone's agreement on the issue. Distractions: If issues are raised that are not on the agenda then you must defer them to another meeting and stay focussed on the purpose of the current meeting. Domination: Don't allow one individual to dominate the discussions. If necessary, interrupt anyone who is doing this and remind them of the need to allow everyone the opportunity to speak. Opinions: Many people are unwilling to speak out at meetings but actively encourage opinions from all participants in order to get a broader view on all the issues being discussed. Boredom: The signs of boredom are easy to spot and start to crop up as meetings approach an hour long. Keep the meeting to no more than an hour wherever possible to prevent tedium setting in. Actions: Draw up an action plan during the meeting showing who is responsible for each action raised and the date by which it must be completed. Summary: Summarise what has been achieved at the end of the meeting (and if you have followed these steps then you will have achieved something). Minutes: It is important to have a written reminder of what was discussed, agreed and accomplished at a meeting so send out the written minutes and action plan as soon afterwards as possible.

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.

Accountability - The obligation to report on one's actions.   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: Nothing is as easy as it looks. Everything takes longer than you think. Anything that can go wrong will go wrong. If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. Corollary: If there is a worse time for something to go wrong, it will happen then. If anything simply cannot go wrong, it will anyway. 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 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, 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

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 APM fundamentals study guide written by Parallel Project Training in partnership with the APM. Twenty bite-size video lectures presented by the authors of the APM fundamentals study guide. Eighteen reflection exercises in which you consider how to apply the principles to your projects. Twenty five podcasts which you can download and listen to as you travel.  Twenty four case study episodes in which you watch a new project manager apply the principles of project management to her first project.  One hundred and four sample multiple choice questions to check you progress with the course. A full sample exam paper. An on-line tutor support via our study group. 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 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 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 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

In this podcast is about explains the different types of investment appraisal that can be done to calculate the viability of projects. The techniques examined are Payback, Net Present Value (NPV) and Internal Rate of Return (IRR). More importantly in this podcast we discuss why project managers should be interested in these calculations and the impact a project can have on the economic viability of a project. The longer it takes and the more it costs the more difficult it is the justify the funding. The APMP (now known as APM PMQ) assessment criteria covered in this podcast include 110.4 explain the use of payback, Internal Rate of Return and Net Present Value as investment appraisal techniques. The examination questions will not require calculations to be performed 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 information management. Project generate masses of informations. In this podcast we explore the different types of project information and how they can be stored and distributed during the project. This includes the preparation of an information management plan for the project. Its this important? Well think about how much time you spend trying to find the right information for your project. The APMP (now know as the APM PMQ) assessment criteria covered in this podcast include 10.7 explain the purpose of the project management plan and its importance throughout the project life cycle, 10.8 describe the typical contents of a project management plan, 10.9 outline the authorship, approval and audience of a project management plan 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.7 explain the purpose of the project management plan and its importance throughout the project life cycle,10.8 describe the typical contents of a project management plan, 10.9 outline the authorship, approval and audience of a project management plan   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

11.1 explain the process for creating and maintaining a schedule, 11.2 describe different techniques used for depicting a schedule (including network diagrams, critical path analysis, Gantt chart, milestone chart),    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

11.4 explain categories and types of resources (such as human resources, consumable and re-usable equipment, materials, space), 11.5 describe how resources are allocated to a schedule, 11.6 differentiate between resource smoothing and resource levelling   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

11.7 explain what is meant by budgeting and cost control   This podcast is just part of the Parallel Learning System for the APM qualifications for project managers, 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 project management courses that will boost your career prospects and lead to internationally recognised accreditation.

12.1 explain each stage in a risk management process (such as initiate, identify, assess, plan and implement responses), 12.2 compare the responses to risk in terms of risk as a threat or opportunity (such as avoid, reduce, transfer or accept)   This podcast is just part of the Parallel Learning System for the APM qualifications (APM PFQ and APM PMQ) for project managers. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and project management courses that will boost your career prospects and lead to internationally recognised accreditation.

12.4 distinguish between risks and issues, 12.5 explain the advantages and disadvantages of risk and issue escalation   This podcast is just part of the Parallel Learning System for the APM qualifications (APM PFQ and APM PMQ) for project managers. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and project management courses that will boost your career prospects and lead to internationally recognised accreditation.

13.1 define quality management, 13.2 define quality planning, quality assurance, quality control and continual improvement, 13.3 describe the benefits of the quality management process   This podcast is just part of the Parallel Learning System for the APM qualifications (APM PFQ and APM PMQ) for project managers. This approach includes a wide range of learning resources including a printed study guide, on-line e-learning, a tutor lead study group and project management courses that will boost your career prospects and lead to internationally recognised accreditation.

In this podcast discuss the different roles in a project organisation including the sponsor, project manager, users, team members and suppliers. In particular we discuss why each of these roles is important for the success of the project. The APM PMQ  (previously known as APMP) assessment criteria covered in this podcast include: 4.3 explain the role and key responsibilities of the project manager, 4.4 differentiate between the responsibilities of the project manager and project sponsor throughout the project life cycle, 4.5 describe other roles within project management 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 functions that a project office in a project environment. This includes the different levels of project office support from basic admin to strategic PMO support to the portfolio manager. The APM PMQ (previously known as APMP) assessment criteria covered in this podcast include 4.6 describe the functions and benefits of different types of project office (including project support office {PSO}, enterprise project management office {EPMO}, project services or centres of excellence) 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