PMO - ITM Platform | Projects Programs Portfolio

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.

Receive the latest blogs directly into your inbox

Organizational structures are one of the core elements that fall into consideration when measuring the influence of environmental factors in project management: they can seriously affect resource availability and determine the style of project management.

Although in the real world each company follows its own idiosyncratic organization, tradition has three types of organizational structures, which we illustrate with graphic examples -some real, some generic.

With ITM Platform your organization can adapt to any organizational structure, try it now for free.

Functional structure

Functional structures are a classical hierarchy structure in which each employee has a clearly-defined superior. At the highest level, the company is organized according to a function-based approach (accounting, engineering or production, for example). Members of the workforce only respond to a superior from their own department and so look for a direct line of communication between the lower and higher levels. Each area can be subdivided into more specific functional units. Each department undertakes work and activities on a project independently, with the projects framed by the functional areas of the organization. Within this type of structure, projects requiring various different departments tend to encounter greater difficulties during development as they cut across the organizational structure and no specific position is recognized for the project manager.

Projectized or project-based structure

Example of organizational structures: Simplified model of projectized organizational structure with 3 projects on vertical axis

A simplified model of projectized organizational structure

In this case of organizational structure, the organization has a similarly hierarchical approach with limited interaction across its sections. However, projects are assigned to a fully equipped team and to a project manager, who occupies a high rank within the organizational chart and has subordinates report to him. In fact, it’s not uncommon for project teams to be consolidated into departments headed by a project manager.

It’s easy to see that this is a very simple (even simplistic!) organizational structure with powerful limitations, like the severe issues in knowledge transfer across projects. Whenever this structure is adopted, it’s important to also implement functional algorithms designed with the intent of negotiating trade-offs between projects. As these compete for limited financial and non-financial resources, scenario-based project prioritization can help strike the best balance for the organization based on objective data.

Matrix structure:

Example of organizational structures: matrix organization

Matrix organizations combine the vertical (functional) axis with the project (horizontal) axis

Among all the organizational structures, matrices are very common in service providers and fast-growing organizations that manage multiple projects at the same time. Matrices have commonalities with both functional and project-based structures, and depending on the exact balance of one over the other there can be three types:

Weak matrix structure: this is very similar to a functional organization, with the role of project manager as a coordinator or facilitator; in other words, this person both helps and coordinates, meaning they are unable to take personal decisions but can interact with all the functional areas involved in the project.
Balanced matrix structure: project managers have with greater autonomy than in a weak matrix structure but who is not given full authority over the project, especially its funding.
Strong matrix structure: this shares many characteristics with projectized organization because it has a full-time project manager and administrative team without that necessarily changing the functional structure. Project managers have full authority over their projects and act at the same level as those in charge of the functional areas.

Choosing organizational Structures

In spite of the fact that matrix structures are highly correlated with more mature organizations, it’s important to be unbiased about which organizational structures might be a better fit for each situation. In certain organizations with a lean approach to management a purely project-based structure may work perfectly. In the end, the nature of the activity, objectives, corporate culture and the demands of new customers will have a strong say over which structure should be chosen.

Receive the latest blogs directly into your inbox

One of the main functions of the CIO is to estimate and plan projects that will take place in the near future. And this, for some management positions requires pure reflection and strategic vision, from the CIO. Which represents an extra capacity of creating consensus and balance among the C level.

Let’s suppose that the organization where you work is proactive and start budgeting for the following year a few months before it begins. Say that the CIO has the task of drawing up a list of projects that will be implemented next year. In addition, of course, to value that list economically, plan the resources available, align it with the overall company strategy, etc.

"For the CIO it becomes a test of ability to search for consensus and balances"

The demand will have to be considered, which shall consist of the ideas and needs of all other organizational units.

Many of you will agree with me that the demand for business units do not usually come in an orderly manner.

This scenario, repeated year after year, can be relieved or hindered depending on organizational culture factors: the more mature ones will have orderly processes tabulated that will make this process, in theory, a path of roses. But this is not always the case, right?

The proposal we are making in this article to survive the planning and budgeting processes, which is to link the rest of the management team with the criteria for project evaluation and selection in order to find consensus in the early stages of the process.

Basically, it is articulated through a weighting system in stages, trying to isolate each one of them until it reaches a stage of selection. Let's look at it in more detail.

Phase 1. Assess business objectives in the planning and budgeting

Nothing to do with the projects. Simply extract the objectives and criteria of the strategic plan and assign values.

There are several methods to do this. In this case we have chosen the "pairwise comparison". Although we might have used the "ask the boss" or any other more orthodox methods.

With this method (either executed in an application or in a spreadsheet) we will obtain an assessment of the objectives, putting one over another, which is what we want at the end.

This is an example resulting from the previous comparison between pairs.

The key to this process is not so much the correction from the point of view of content, but rather the composition of the people who made this assessment: for a CIO concerned about the alignment of IT with the business and the subsequent support of the organization projects, it would be essential that this step is performed by the steering committee. This will be allow him to be personally detached of the foundation of future decisions.

In large organizations, this process can be repeated by business units which will not necessarily prioritize objectives in the same way.

Phase 2. Assess projects against these targets

The next step is to make comparisons of the value contribution of each project to each of the business goals.

In this case, we decided to use a qualitative method with Harvey Balls, where projects are rows and columns objectives. Here we say if the project adds value to the goal or not so much.

As in the previous case, these evaluations provide a "base 100" scoring for projects. But the key here is that the projects are not valued in relation to themselves, but are weighted by the prior evaluation of the objectives.

The result would be something like this:

Phase 3. Selected projects

Now it will be easier to select projects that may or may not be undertaken, with budget constraints according to value creation criteria.

In conclusion:

The work life of the CIO could be greatly simplified:

Because it has implied other directors in valuations, especially the one related with objectives and criteria.
Because it provides a scientific and professional decision-making support system.
Because it encourages the rest of the organization to have a cross-company and objective view of the initiatives

This short article aims to offer a proposal to focus strategic planning of projects in a solid form and strengthen the role of the CIO in organizations. We encourage you to leave any thoughts in the comment box below.

Receive the latest blogs directly into your inbox

Sometimes we think of project management offices as control centres of hours, tasks and people. ITM Platform suggests a more open, distributed and value-generating PMO.

Let’s make no mistake, control is important. But there are many ways to practice it, and responsible control is the best of them when it comes to project management.

The PMO should add value "to the steering level" with consolidated information and "towards the organization" with methods and tools.

Commonly, PMOs in organizations arise when there is an increasing feeling of a lack of control at the top management, cost rises and above all, deadlines are violated systematically. Then someone says "we need a PMO" when he really thinks "I do not trust my project managers and I want to control them".

The PMO (Project Management Office) often go through different maturity stages, but asides from the situation in which yours is in, the PMO should add value "to the management level" with consolidated information and “towards the organization” with methods and tools.

To add value to the steering level is easy to conceive but not that easy to accomplish: realistic economic assessments, deadlines respected, milestones delivered in a timely fashion, decision-making support about the portfolio.

Look at something as simple as a roadmap monitoring of portfolio:

Or, as more advanced, a dashboard with KPI:

The key to achieving valuable information is precisely to provide “top-down” mechanisms so that each participant (either a project manager, responsible for a task or team member) can do its job and that this information constitutes the aggregate information which later will be key elements to provide analysis information.

Here are some examples:

1. Controlling working hours

Do not sell the idea of control of the person, but instead, control of the whole project. Estimate hours and provide a report of each member, which will serve to improve their estimates to load balance resources necessary to make outsourcing decisions, move schedules and of course, on how the project is progressing in economic terms.

Remember that Earned Value gained, for example, is heavily nourished with reported hours, which is a main point of connection between reality and the system.

2. Project templates

If a PMO can contribute in something, it is corporate experience. When two projects look alike, take advantage of the elements that are common in both, such as tasks, documents, risks and people key to its success.

3. Communication

A PMO should facilitate communication between project members. Channelling it will lead to a bottleneck; instead, provide intelligent mechanisms allowing people to talk share knowledge in a socialized organization.

4. Tracking progress

In ITM Platform, reporting progress of project tasks and can be done at two levels: project and task. That is, a project manager may report the progress of all tasks, some or project as a whole. A responsible person for a task may report the progress of what has been entrusted.

Which is the key to the success of the PMO in this regard? Let each person take responsibility and the system will automatically build a consolidated monitoring mechanism.

In conclusion, through this article we wanted to show how it is possible that a PMO put focus on higher level functions without giving up responsible control.

If you need help in modelling and implementation of the PMO, count on our certified partners /en/partners