PMBOK - ITM Platform | Projects Programs Portfolio

This is the third article in a series devoted to the 10 areas of knowledge covered by PMBOK since its 5th edition. Read more on the two articles already publishedon project integration:

The areas of knowledge are listed by importance

The areas of knowledge recognized in the PMBOK are practical subdisciplines that can be described as a set of methodological component, the sum of which covers the total domain of project management expertise. In contrast with the six phases of a project, the areas do not follow a cronological logic, but are rather sorted by importance. That explains the fact that project integration, almost a meta-area of knowledge that extends across all the rest, appears first and not last. Without component integration, there is no project beyond its parts. In other words, integration is a necessary condition for the existence and survival of a project. We're not even talking about results, efficiency and success.

That's where the next area of knowledge comes in. Now that a project exists, we want to do something specific with it. Project scope management allows to properly fulfill the two most basic conditions for a project to yield the result expected:

The project includes all the work needed
The project excludes everything that is not strictly necessary

In other words: while integration consists in giving life and sustaining a project as a complex artifact, scope management controls the causal relationships between project components and the final result. If the idea of a project starts with the final results, scope management includes all the causal factores that explain that future state.

The benefits of proper scope management are self-evident: by following the processes included in the area, the project manager will increase the chances of success and facilitate a clear work structure for the project team.

Due to the causal nexus implicit in the notion, scope can refer to:

Product scope : functional requirements to be delivered to the client.
Project scope, a broader term that often extends to include product scope. Project scope refers to the "how" (the means) rather than to the "what" (the product), and includes all the piececs that need to be take into account throughout the project lifecycle, including risks and management alternatives.

Project scope management

Project scope co-depends from the two other variables in the famous triangle: time and effort. The three variables exert a reciprocal influence, so that (at least theoretically) a larger scope can be tackled with a longer time devoted to the project or with a larger number of resources devoted to it.

The processes included in this area are thus tools to define the scope triangle with the maximum accuracy. Beyond the creation of a scope management plan, the processes include:

Requirement collection
Scope definition
Creation of a Work Breakdown Structure(WBS)
Scope validation

Of course, as we'll see in coming articles, risk management has an enormously important role in scope protection: it forsees possible situation that may alter it, and design mitigation responses.

Fine-tuning the scope definition

An accurate definition of the project scope improves time estimates, the efficacy of budgeted costs and the resources needed, forming a baseline against which all subsequent performance metrics and monitoring activities will be tracking. At that stage the scope also connects with the important area of project communication, which is vital to prevent the scope from gradually expanding.

Project Scope Statement

This detailed statement includes the following:

Objetives
Project scope and qualities
Project requirements, conditions or delivery capacity
Limits
Results
Acceptance criteria
Budget
Initial organization
Initially defined risks
Programmed milestones and important dates
Cost estimates

Work Breakdown Structure

This logical method to decompose the work needed into its smallest possible pieces is vital. Starting from the scope statement, it groups all tasks in a diagram and enables the work of creating a detailed gantt chart with dates, estimated costs, required resources, and possible change scenarios.

WBS can easily become the soul of the planning process - the whole team participates in its definition so no level or task are left behind.

WBS Dictionary

Project scope management consolidates around this imperative document, which contains both the statement and the WBS and extends to a detailed description of work packages with their objectives, assignments, dates, acceptance criteria, assumptions, assigned resources and dependencies.

This instrument of permanent consultation shows the different relationships between work packages and consolidates the scope baseline.

Recommendations

Beware the kitchen sink syndrom!

One of the clichés in project management but unfortunately an invariably common risk, scope creep is also known as "Kitchen sink syndrome". Projects are particularly vulnerable to scope creep when they are large and/or innovative. In the latter case, for example, it's understandable that some of the basic requirements in the WBS may become black boxes with more complexity than initially estimated.

Realism is no time waste

That's the reason why an extraordinary effort to compile realistic requirements can avoid so many problems later down the road. It might seem counterintuitive to spend hours trying to properly understand the dimensions of a secondary area within the project - but if major areas have dependencies with it and as a consequence the critical path is accepted, a delay in the project start will surely be compensated with better time control throughout the execution.

Descriptive and permanent communication with the project team and stakeholders substantially supports scope management. Don't think that it's a waste of time to talk to a technician about apparently nimble aspects of her routine: it may help you steer the complexity of your project with dexterity.

Control, control, control

Project monitorization requires the adoption of tools that immediately identify deviations with estimated times. If you lack visibility of the time your team members are devoting to their tasks, or if your financial management is not properly connected with the project advance you will immediately benefit from ITM Platform advantages.

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

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.