PMO - ITM Platform | Projects Programs Portfolio

Why does ISO have two sets of standards on project management?

These two sets of standards are complementary, not interchangeable. There is one set for project management (21500) and another for quality management systems in the field of projects (10006). Neither of them is subject to certification. ISO 9001/2008 provides certification on issues corresponding to these standards.

Implement ISO-based project management with ITM Platform

Now we are going to explain the difference between both:

ISO 10006/2003: is not a set of standards on project management. It is a set of standards on quality management systems in projects. The purpose of these standards is to offer additional guidelines - not requirements - to companies that clarify issues related to technical management. ISO 10006/2003 focuses on the management system used to manage quality in projects and is very useful for strong parent companies that wish to adopt ISO 9001/2008 standards and obtain certification.
ISO 21500/2012: is a specific set of standards for project management. It offers a guide - not a series of requirements - and is therefore not subject to certification. ISO 21500/2012 focuses on project management, processes and management areas, and coincides with such bodies of knowledge as PMBOK. It is useful for companies that wish to standardize and improve their project management. It is interesting to note that the two sets of standards do indeed overlap at certain points - hence their complementary nature - regarding the manner in which a project should be managed (‘best practices’ under 21500 and ‘quality management system’ under 10006). By applying and putting these standards into practice, all project-related work undertaken by an organization can be significantly improved.

The most immediate effect of ISO in project management is an emergence of global standards in this market due to an international agreement on project management principles and guidelines; in other words, organizations and professionals that manage and run projects are now able to use the same concepts and structures in their contractual and working relationships with clients, partners, suppliers and other stakeholders. This is facilitating the expansion of project-based businesses worldwide. Hence, ISO-based project management provides companies with a strategic advantage.

Another very important effect can be found in employment-related issues, because project management teams can be created or assembled under a contract that will comprise the definition of a scope or certain requirements, a set deadline, a forecast cost, a geographic area and the stakeholders involved. This implies the involvement of professionals from numerous specialized field and nationalities, requiring swift and temporary collaborations between groups. The flexibility, effectiveness and efficiency of these groups will depend on knowing and applying the management processes agreed upon globally under the ISO international standards on project management. In this regard, the education and training of professionals in project management skills gains additional importance as this might now refer to such professional certificates as the PMP® from the PMI® based on knowledge of the PMBOK Guide (Chapter 3 of which coincides with ISO 21500 by over 90%). ISO-based project management is an executive advantage for professionals who manage projects.

ISO Standards 10006 and 21500 relate to international knowledge, such as PMBOK, PRINCE2 and ICB3.0 on project management. They are not subject to certification but have also been included in knowledge standards that are subject to certification, such as ISO 9001/2008 and the PMP® from the PMI®.

Other posts you may be interested in:

Receive the latest blogs directly into your inbox

The duties of a PMO include assessing and planning which projects to carry out, a task that usually becomes an exercise in reaching consensus and seeking balance. Let us look at a practical example. Let us suppose that our PMO starts preparing budgets a few months before the start of the next financial year. This preparation can be compared to crossing a ravine on a rope, just like a tightrope walker might do.

In one hand, the tightrope walker holds the list of projects to be carried out in the coming financial year, the economic assessment of those projects, the resources needed to complete them and the overall strategy of the company, etc.

In their other hand they hold the demand, comprising the ideas and needs of all the business units, which will have been previously established by the company’s steering committee through a process of strategic planning.

However, demand from business units does not tend to be organized but rather exists in the form of ideas that compete between one another in an incoherent fashion. When sponsors see that their wishes might not be met, this is usually compounded by their attempts to manage their own projects without support from the PMO.

In this article, we propose a system for surviving the project planning process that involves including the executive team in the project evaluation and selection criteria to thus seek consensus during the early stages of the process.
It basically revolves around a stage-based system that tries to isolate each one until a selection scenario can be reached.

Stage 1. Assess the project targets and assign weighting factors

This stage takes place prior to the project and its management per se. The goal is to extract targets or criteria from the strategic plan and assign a value or weighting to them. Various methods can be used to do this. For this article, we have chosen a method called “peer assessment”.

In turn, this process can be undertaken using a variety of media; either an application or a spreadsheet. Regardless of the medium used, we will obtain a value for the objectives and an order of priority. Below is an example result from the above-mentioned peer assessment.

The important thing to notice is not the correction from a content perspective but rather the composition of people who complete this assessment. The ideal scenario is one in which this is carried out by the steering committee. It will thus disassociate itself from the foundations underpinning the decisions ahead.

In the case of large organizations, this process can be repeated by each business unit, with the possibility of different priorities being established for the same objectives or even different objectives.

Stage 2. Assess the projects according to those objectives

The next step will be to compare the value contributions made by each of the projects to each of the business objectives. This stage can be undertaken in parallel to the stage described above or even disregarding it entirely.

In this example, we have used a qualitative method with ‘Harvey Balls’, in which the rows are projects and the columns are objectives. We can therefore decide whether the project contributes more or less towards achieving the objective.

As in the previous case, these evaluations offer a series of ‘base 100’ scores for the projects. However, the key here is that the projects are not assessed on their own merit but are rather weighted according to the previous objective assessment.
Following these corrections, the result would be something like this:

Stage 3. Project selection

Thanks to the previous stages, selecting which projects to carry out will now be a much more objective and simpler process based on budget restrictions and the application of priorities to the value contribution criteria.

In this example, the star project - the most costly and the one contributing the greatest value individually - could actually be rejected because it provides less (35%) than the sum of other more modest projects (52%), the total cost of which is also lower.

In conclusion, being organized and using the right systems can provide numerical and real data rather than intuitive ideas.

By working in the manner described above, the life of a PMO can be greatly simplified:

Because management has been involved in the assessment process, especially of the objectives and criteria.
Because the decision-making method used is scientific and professional.
Because it stimulates the rest of the organization into adopting a cross-cutting and objective approach to the initiatives, which will also be better assessed.

This article offered a way of focusing the strategic planning of projects in a more robust fashion and strengthening the role played by the PMO within an organization.

Receive the latest blogs directly into your inbox

One possible definition of schedule would be a list of items or processes in a project that also includes their planned start and completion dates.
The schedule only includes information about the time allocated to the project and to each one of its stages. It does not include any other characteristics related to the project planning, such as the scope, the cost, the resources needed, etc.

How is a schedule visually represented?
A number of different schedule types exist depending on how they are visually represented. The most common are described below.

Gantt Chart
This is probably the most frequently used graphical representation of a schedule. It consists of representing the tasks as bars along a timeline that is created along the X axis.
Its main advantage is the ease with which the start and end dates of each project can be seen, as well as their duration and overlaps with other tasks.

Also in its favor is the fact that most employees are used to using them, meaning that only a short learning period is required to be able to use them efficiently.

Pert Chart
This representation of a schedule does not consider a timeline but only the tasks and the relationships that exist between them.

Each task is usually represented as a box containing the constituent processes. The boxes are structured in a time-based sequential order in which they will be completed and according to relationships of causality.

In other words, the tasks to be completed first occupy the boxes located furthest to the left. The tasks that follow in time occupy boxes located further to the right.

The use of arrows enables relationships of causality and dependency to be created between the processes. A task has a relationship of dependency or causality with those tasks from which it receives an arrow.

Milestone Schedule
A milestone is an important event in the development of a project. Hence, not all tasks are milestones. Key project delivery dates, important meetings or any other event related to company activity that is particularly important are usually considered as milestones.

It may comprise an image obtained from the simplification of others, especially a Gantt chart, or it may be produced independently.

Baseline and Updated Schedule
This is a benchmark schedule. After the schedule for a project has been drafted, it is approved by the company steering committee. This is the schedule that will serve as the benchmark or baseline for project oversight. A new schedule will be drawn over this one in real time, usually in a different color, to represent the tasks as they are completed. This facilitates rapid comparison between the planned schedule and the real schedule.

Regardless of the type of schedule you prefer, using modern software that is based in the cloud and synchronized to all your devices will help you know the status of your company’s projects at all times, thereby ensuring proper schedule compliance.

At ITM Platform, we work to offer you the best project management tool that adapt to your needs and at more than competitive prices. What are you waiting for? Try it now!

Author: Juan José Delgado Community Manager & Blogger of ITM Platform

Receive the latest blogs directly into your inbox

The life cycle of a project comprises the set of phases into which a project is organized from start to finish. A phase is a set of inter-related project activities that generally concludes with delivery of a partial or complete product. Some simple projects only require one phase while other, more complicated projects require a significant number of phases and sub-phases.

ITM Platform allows you to reuse and adapt the most appropriate life cycles with project templates, try it now for free.

The life cycle of each project is defined by the phase model used in each case and this is usually determined by the organization, industry or even technology required for the project. It would be impossible to provide a generic description of the phases for all types of project. However, reference is sometimes made to a generic life cycle structure that consists of the following phases:

• Project Start

• Organization and Preparation

• Completion of Work

• Project Close

This generic life cycle structure should not be confused with the Project Management Process Groups defined in PMBOK. The generic structure of the project life cycle is a generic model relating to the organization of project phases and not the organization of processes established by the PMI. Neither should it be confused with the product life cycle on which the project is based. This is a generic life cycle model that can be used as a benchmark, especially when wishing to communicate project progress to people who are less accustomed to this type of management.

In practice, there is no one perfect way to organize phases for all types of project. Although some standard models exist in certain industries, projects can vary significantly between one another. Some projects will only have one single phase, while others may consist of two, three, four or even more.

Regardless of the number of phases within a project, they all possess similar characteristics:

• Each phase is focused on a specific task.

• Phases are usually aimed at producing a deliverable that must be available at the end of the phase

• The end of a phase closes with a review of the deliverable and sometimes with approval of that deliverable

Organizations and the various methodologies and industries have gradually defined more or less standard project life cycle models. This standardization is accompanied by the necessary adaptation by each team to each project. The life cycle greatly depends on the nature of the specific project and the style adopted by the project team or organization. To correctly manage the established standards and necessary adaptation to the specific needs of each project, organizations use such tools as ITM Platform to allow them to reuse and adapt the most suitable life cycles by using templates or base projects with specific project phase structures as a benchmark.

Receive the latest blogs directly into your inbox

The success of projects is key to any company, but even more so to those where the outturn account depends on projects. Programming, design, construction and consultancy companies and, generally-speaking, any company that undertakes projects for its clients must pay significant attention to the profitability of each project.

This article offers an analysis of the main factors influencing project profitability. This is a complicated topic and no sweeping generalizations should be made. Hence, these factors must be adapted to the specific circumstances surrounding each organization, sector and client.

Zoom into your projects while maintaining a global vision of your entire project portfolio with ITM Platform, try now for free!

1.- Define the scope

The first and major issue affecting project profitability is linked to discrepancies between what should be included or excluded from the scope of a project. Clients tend to consider a broader scope than project leaders and this difference in perception often leads to problems and conflicts that eventually affect project profitability.

Spending the necessary time to define and share the scope of a project is a key factor in project profitability.

2.- Estimate the effort

There can occasionally be little time to provide a client with a commercial offer for the project. This can lead to hasty estimations based on similarities between the project in question and others carried out in the past. As a result, the risk of mistakes is very high and should be reduced by breaking down the tasks involved and producing a bottom-up estimation to confirm that the overall estimation is in line with the work that needs to be done.

This estimate should include as much detail as possible on the profiles needed for each activity.

A good estimate will avoid project cost deviations.

3.- Plan slowly

The break-down of tasks and their estimation should be undertaken as part of careful planning of the work to be done. The organization of activities and their inter-relationships may result in the need for additional tasks or certain tasks being completed after others, which can lead to additional project costs.

Optimistic planning will mean the client has hard-to-meet expectations about the delivery date and this will eventually affect the cost.

4.- Choose the right team

The project team is a key piece of the puzzle in transforming project estimates and planning into reality, thereby meeting client expectations and maintaining the appropriate level of quality. Scrimping on resources may be more expensive in the long run. Using under-qualified personnel with no experience or little motivation may be cheaper to begin with but this can very easily become a negative factor for profitability when having to do the same work more than once, wasting time on ensuring people are clear on what needs to be done or learning how they need to do it.

High-productivity teams are capable of significantly increasing project profitability.

5.- Identify risks

All projects have some sort of risk that must be analyzed and assessed. Some risks may be unlikely while others may have a minimal impact on the project, meaning that highly significant corrective actions to counteract such risks would be unnecessary.
Those risks with the greatest exposure, i.e. those whose impact and likelihood are average or high, should be managed and may require specific actions to guarantee project profitability.

It might even be necessary to establish a safety margin in the cost to be paid by the client depending on the degree of uncertainty and the risk posed by the project.

6. Analyze profitability at the start

While considering all the aforementioned factors, project profitability should be analyzed before the project begins. It is possible that, for commercial reasons, projects with little initial profitability will sometimes need to be undertaken in the hope that the client will contract other services in the future. At any event, this fact and the level of profitability to be expected from the project should be ascertained.

Only by ascertaining the expected profitability will we be able to manage it.

7.- Foster communication by the team and with the client

Communication within the team and communication with the client are key to project profitability.

If the team communicates quickly and smoothly, it will be possible to identify any problems in time and any confusion or misunderstanding that could ruin a project will be avoided.

Communication with the client will enable expectations to be properly managed and the client to understand and collaborate on any stumbling block that may arise.

8.- Record data and manage them

Data are key to project management. Feelings and anecdotes in management may provide a comfortable or negative sensation of progress and advancement, but only objective and recorded data will be able to provide the information needed for efficient management. Recording data may lead to conflict with the project team, the members of which tend to focus on activities they consider to be productive.

It is essential for the team to understand the importance of tracking information and undertaking data entry on a regular basis and without unnecessary effort.

9.- Track profitability at all times

Tracking project profitability is not an issue that should be left until the end, once the project has finished: it should be undertaken constantly, regularly checking project status to date and taking any necessary steps when unforeseen deviations or circumstances are identified.

If they are identified quickly and a timely response is given, we will be able to correct any problems and return to maximum profitability.

10.- Project deviations

Small deviations at the start of a project tend not to be considered seriously in the hope that the project will get back on track as time goes by. However, recovery from such initial deviations is usually a very complex task that is hard to achieve.

Furthermore, these deviations are often the symptom of a larger problem, meaning it is important to project them into the future and gain a clear picture of the situation.

The Earned Value technique is a very useful tool for making project status projections.

11.- Learn from mistakes and successes

If we properly record the most relevant data from our projects, we will be able to analyze what really happened and what the specific factors were that meant certain projects achieved greater profitability than others.

We should learn from both our mistakes and our successes, being able to identify those we should correct and improve upon as well as those we can repeat and encourage.

12.- Use the right tools

For all these reasons, it is important to use the right tools (without generating a high cost for the project) that will enable swift and efficient project management, help estimate and plan, record and analyze data, and allow the team to work comfortably from anywhere.

Receive the latest blogs directly into your inbox

Projects are carried out within an organization whose culture, style and structure influence the way in which these projects are carried out. Project managers should be aware of this reality and adapt to the environmental factors of the organization where the project is developed.

Improve the information systems that support your projects with ITM Platform

It’s worth beginning with a caveat: the environmental factors of a project should not be confused with considerations of the environmental impact of an organization's activities, which are especially important in the case of public works or industrial activities that could result in chemical waste or other forms of pollution. While these assessments are limited to certain areas of activity and are highly regulated in most developed countries, environmental factors always exist in each and every project: from a small-scale internal project to a macro-project of hundreds of millions of dollars in budget.

The notion of environmental factors in a project is much more general, referring to all circumstances surrounding the project during its execution. Thus, we can consider environmental factors as all the conditions that are beyond the direct control of the project team and that influence positively or negatively on the project. All these conditions must be considered in project management and vary significantly in type and nature depending on the organization.

As a reference, the main environmental factors that can affect project management can be classified into three categories; organizational, human resources and technological systems.

Environmental factors inherent in the organization

Shared vision, mission, values, beliefs and expectations of the organization
Culture, structure and organizational governance
Availability and geographical distribution of facilities, resources, infrastructure and materials
Industry or government standards that affect the organization
Internal standards, policies, methods and procedures

Human Resource environmental factors

Existing human resources, skills and knowledge
Personnel management, motivation systems and incentives
Perception of leadership, hierarchy and authoritative relationships
Organizational risk tolerance
Project stakeholders and organizational stakeholders

Technological environmental factors

Operational environments and company authorization systems
The formal and informal communication channels established in the organization
Available databases
Project management information systems

In addition, the environmental factors of a project can be classified as internal and external factors. While internal factors will be stable for each organization independent of the project, external factors are more susceptible to change and require superior analytical attention from the project manager. For example, the location of the project in a country where it has never been worked will expose itself to an unknown regulatory environment, generating many risks in terms of legal feasibility, the labor framework, etc.

It is essential that each organization knows which of the internal factors act as limiting conditions and which are the drivers of the projects. It is appropriate that this analysis be shared.

In project management, it is possible to influence those factors that are closer and more directly related to management, such as resources or project management information systems, but it will be more difficult to affect the more general cultural and environmental factors or external to the organization. For example, although it may seem that organizational culture is a flexible factor and can be easily shaped, it is necessary to always consider the inertia produced by resistance to change and how such culture is not an abstract idea, but is part of the daily practices of all members of the organization.

Changing environmental cultural factors that are more detrimental to effective project management can be a much longer and more expensive decision than to just support such management with new information systems. In turn, the adoption of new information systems can serve as a catalyst from which to modify the behavioral aspect of human factors, influencing the corporate culture from its base.

In all cases, the project manager must be aware of these factors and act accordingly, including the project risks to the detrimental environmental factors over which the project manager cannot exercise any control and communicating to all his team the importance of being alert about signals indicating the emergence of the risk or the change in environmental circumstances.