Project Management @ ITWorx

Wisam Morsi and Ali Awni

The American university in Cairo, Egypt

Academic Editor: Hishamuddin Mohd Ali

Cite this Article as:

Wisam Morsi and Ali Awni (2015), “Project Management @ ITWorx “The MENA Journal of Business Case Studies, Vol. 2015 (2015), Article ID 605062, DOI: 10.5171/2015.605062

Copyright © 2015. Wisam Morsi and Ali Awni. Distributed under Creative Commons CC-BY 4.0

Abstract

This case provides an overview of project management practices at ITWorx, a leading professional software services company in the Middle East. ITWorx top management believes that many critical decisions that determine the success of a project are actually made before the project even starts. Projects are selected and managed as a portfolio to reflect the company’s strategy and future business directions. This case describes the project life cycle from opportunity to project, including resources allocation and acquisition to ensure the proper delivery of projects. The case also discusses typical reasons for project failure, and ITWorx’s approach for dealing with them.

Keywords: project management; software, project portfolio

Introduction

Wael Amin, ITWorx president, stared out his office window at ITWorx Free-Zone premises, Cairo, Egypt. It is spring time and he was arranging his thoughts for a lecture that he will be giving at the American University in Cairo (AUC) in the afternoon. As an AUC Alumni and a successful business leader, Wael was regularly invited as a guest speaker for an MBA class in the AUC to talk about Project Management at ITWorx.

Wael’s objective for the lecture is to present ITWorx project management methodology and how it influences the way projects are selected and run. His plan for the lecture is to start with an overview of the project management methodology at ITWorx showing the overall process for selecting projects, managing and distributing resources, and regularly tracking and evaluating the projects progress. He will discuss some of the reasons why a project might fail before, and will end the lecture with an open discussion to allow the attendees to ask questions and share their own experiences.

Backrgound: Company Overview

ITWorx is a professional software services firm in Egypt with more than 700 employees. Headquartered in Cairo, with development centers in Cairo and Alexandria, ITWorx has other offices in the Gulf region, namely the UAE, Saudi Arabia, and Qatar, and is represented in both Europe and USA. The company was founded in 1994 by two AUC Computer Science graduates, Wael Amin and Ahmed Badr, and Youssri Helmy, their third partner.

ITWorx mission as indicated on their website (ITWorx, 2011) is “to be our stakeholders’ trusted partner and agent of change.” ITWorx is driven by a strong corporate culture – a culture that stems from, and feeds back into, every individual in the company. In the company’s own words : “Everything we do is based on five core values that define who we are, how we perform, and what we aspire to: Innovation, Integrity, Quality, Agility, and Team-play.”

The company offers portals, business intelligence, enterprise application integration, and application development outsourcing services to Global 2000 companies. Furthermore, ITWorx serves governments, financial services firms, educational institutions, telecommunication operators, and media companies in North America, Europe, and the Middle East. In 2008, ITWorx became privately held, with financial backing from the EuroMena Fund, Venture Capital Bank and Proparco.

ITWorx structure is composed of two primary functions: Professional Services and Quality Management which provide together the business delivery focus. Alongside, there are several supporting functions for HR & Operations, Finance, MIS, Sales and Marketing (Figure 1); and geographic focus for two divisions: EMEA and North America.


Figure 1:  ITWorx Organization Chart


Project Management at Itworx

Many MBA students tend to narrow the scope of project management and limit it to managing individual projects successfully once they start. In reality, many decisions taken before a project starts determine the success or failure of the project. In the words of Wael Amin to the MBA project management class at The American University in Cairo (AUC): “Projects are often doomed to failure or very likely to succeed before they start. There are many situations where we receive a project and we know already that this project is not going to succeed or we know ahead of time that this project has a great chance of success.”

A lot of what determines those pre-project factors are part of the project management methodology; project selection to fit the business strategy and future direction of ITWorx and positioning resources and ensuring the required knowledge and skills are available to be assigned to the selected project.

The project management process in ITWorx starts way before the project starts. It starts with the strategic planning done every year. The company’s strategic objectives, mission and culture serve as the gauge upon which the opportunities are evaluated and the projects are selected.

Project Management Methodology

ITWorx mission is to be their stakeholders, mainly their customers, trusted partner. For ITWorx to establish their mission, they manage for project success and do what it takes to make the project succeed. Like any company, ITWorx have constraints on resources and budget, but the overriding concept is commitment to delivery. During 18 years in business, ITWorx did not have a project that went undelivered. Although this might have caused loses in some projects but it helped build ITWorx’s reputation on always delivering on their promises regardless of what it takes. This provides a differentiation strategy that allows ITWorx to justify their relatively high prices.

Throughout the years, ITWorx have learned that success parameters are predetermined long before the project starts. The actual project management efforts done after the project starts do not make as big as impact as all of the events leading up to the project. The primary driver is to take on projects that are thought to be successful. Once taken, work is done to ensure they are successful and when those projects run into problems, ITWorx react to this by working on solving problems to make sure those projects are back on track and are delivered as promised. Projects are selected in many cases to enable ITWorx to get into the door at a potentially strategic customer, or to gain a foot hold in new industry or application area.

In ITWorx, projects are managed as a portfolio rather than independent standalone projects. This affects the way by which projects are evaluated, selected and later managed and how budget is distributed and resources are assigned to different projects. The process starts with prospects or leads identified by the sales team which are then translated into opportunities. On continuous basis, feedback from sales channels is collected in the form of opportunities. ITWorx is a company that sells projects to customers. An opportunity is the possibility to do a certain project to a certain customer.

Sales data are collected from all countries having ITWorx sales presence (viz., US, Saudi Arabia, United Arab Emirates, Switzerland, Egypt, Qatar, and UK). These data are collected on a continuous basis to form the Opportunity Pipeline. Every day sales people discuss and negotiate opportunities with the clients and every week they have meetings with their managers (sales or country managers) to ensure the opportunity pipeline data is up-to-date. The collected data begins at a very high level including information about the business needs, the available budget and the project sponsor. Although the commercial team is split geographically, the delivery team is split by industry. Accordingly, the pipeline is then categorized by industry (Education, Government, Telco, and General Business) .

Once an opportunity becomes identified, the industry manager or the “Service Delivery Manager” (SDM) as named in ITWorx, starts elaborating with the sales team to get more data about it. From the estimated budget for the opportunity a high level resource estimate is produced (e.g., a million dollar project for a certain client requires 100 man-month efforts). This estimate is further broken down to the effort required from each role (skill level) including a project leader, a quality leader, a system engineer, a technical writer and a graphic designer. The ultimate objective at this phase is to produce high level estimates, resource requirements and possible timeline.

The SDMs then add the opportunity data to the overall portfolio data to map out the overall resource requirements and the expected timelines. This is done by all SDMs for all identified opportunities. For the active project list, the map reflects the resource allocation (% utilization), skill-set and timeline (when resources are released). Adding the opportunities outlook data to this map enables management to aggregate resources and forecast the need to adjust resource levels or to move resources out of some projects to work on new projects as they start. The management normally needs to have 90 days visibility of resource requirements to react if hiring is required. Existing projects and new opportunities are given weights and priorities based on the company’s strategic objectives and priorities defined during the strategic planning process (e.g., increase market share in certain markets, or penetrate new markets). Other factors used in priority setting are resource availability and projected profitability (at this point there are only guidelines about the costs for opportunities).

Using the weights and priorities and from the overall timeline and resources skill-set of the existing projects and opportunities, various resource demand scenarios are created based on certain criteria (e.g., opportunity realization, or other project completion) for resource predication in order to match demand vs. capacity and to decide on which opportunities to accept (different criteria produce different results). The SDMs might need to go back to the sales team and negotiate possible changes to the scope, resource, or timeline in order to accommodate for the project. Finally, a group of opportunities are accepted and the resource forecast is done identifying whether hiring or layoffs are needed and also the training requirements. For those accepted opportunities, SDMs respond back to the client with a proposal including the estimated costs and timeline. Until this point, the opportunity is not yet realized, but the objective is that by the time the contract is signed the right set of resources is available and ready to start the project.

One strategy that ITWorx adopt to cater for fluctuation in demand and unconfirmed opportunities is to have some flexibility in the resource structure where employees are split into 70% permanent vs. 30% contracts staggered to help reduce the capacity when and if needed.

Once an opportunity is realized, it is then changed from an opportunity to a project. If hiring was required for some resources, it should be completed by the time the project starts. At this point, normal project management activities (for a single project) start. The first step is for the SDM to assign a project lead (project manager as named in ITWorx) who starts to form the project team and initiate the project. The team forming exercise and selecting resources for project takes into consideration how resources work well together and work well with the customer. Also, it takes into consideration the multi-valued competencies (PM/Tech, soft skills, experience in specific industry, experience with certain client, etc.). The project assessment criteria are decided based on the objective of the project. For ITWorx, the main objective of all projects is to deliver successfully. So the main focus of all project management activities is to deliver.

Alongside with the normal process starting with opportunities till they are realized to a project, ITWorx also works on building platforms, basic components that can be used to build systems or parts of other systems. ITWorx has initiatives to develop platform ahead of projects to solve most common problems faced throughout projects. Once a new project comes, this platform is used as a component and it’s open to be used with other components in the market. Licensing conditions/terms is a major element in deciding about using internal and/or off-the-shelf components. Resource requirements to build those platforms are also taken into account during the portfolio management process.

An ongoing activity in project management is tracking and control. This is done on several levels starting from normal projects tracking (monitoring & control) done by the Project Lead (PL), account tracking involving the view of all projects in a certain account which is done by the SDM and overall portfolio tracking where the top management keeps an eye over all projects in the portfolio to step in and take necessary actions when needed. Various monitoring tools are used for tracking in each level, yet all of them follow a consistent data collection and reporting methodology to facilitate rollup of data in reports to be presented to the top management. Example of tracking tools are score cards and bubble view. Score cards, see Figure 2, contain project list and summary of key measures collected from each project and reflecting the cost, schedule and quality indicator (e.g., defects density) along with the overall project status (RAG – Red, Amber, green). Bubble view, see Figure 3, can show various views, e.g., a view about forecasted gross margin (CPI)  vs. delivery dates where the bubble size represents revenue and bubble color represents profitability.

Once a problem is discovered, remedial actions are taken directly either at the level of PL, SDM or top management based on the nature of the problems and the level of decisions required for solving them. Remedial actions are often structural changes, e.g., changes to the structure of the project team, roles, or density of onsite vs. offshore.

The Project Life-Cycle

In this section we will go into the details of each step in the Project Management Process as done in ITWorx.

Create Opportunity Pipeline

The sales team starts by “Lead Generation” either directly or through channel partners. Initial contact is done with the customer until all information is collected to form an opportunity. At this stage, the information available is very high level and includes the need, the sponsor name and the available budget. These data are collected on a continuous basis to form the Opportunity Pipeline. Sales people discuss and negotiate opportunities with the clients on a daily basis and report back to their managers (sales manager or country manager) on a weekly basis to ensure the data in the pipeline is up-to-date.

Once the opportunity is identified, it’s further categorized by industry and communicated to the respective SDM through Change Point .

Study Opportunities 

The SDM receives the opportunities that are communicated from the sales team and start working on them. At this point, the opportunities are not yet confirmed  and the requirement from the SDM is to study them and propose a high level estimate of the effort and resources. This work is done in collaboration with the sales team to get more data about the opportunity. From the estimated budget for the opportunity, a high level resource estimate is produced as an overall man-month estimate that is further broken down to the skill/expertise level required from each role including a project leader, a quality leader, a system engineer, a technical writer and a graphic designer.

The opportunity at this stage is still not confirmed. When the sales raise the confidence of getting this opportunity to be 80%, the SDM starts working with the SQM and resource manager to do resource demand analysis.

Resource Demand Analysis

After an opportunity is confirmed, the SDM started using the forecasted resources and timelines and constructed the final mapping of the opportunities versus the existing project to aggregate the overall resource requirements. This resource forecast is also communicated back to other teams to do their respective resource demand analysis.

Each SDM perform resource demand analysis to validate the resource demand vs. existing capacity within their respective accounts. If the demand can be fulfilled from within the account, the SDM updates the internal resource map to reflect the timeline expected for the opportunity. If the internal account resources will not cover the resource demand, the SDM raises request to the Resource Manager (RM). The resource request contains information related to number of resources, roles, required technology, experience (no. of years), non-technical competencies, advanced degrees requirement, duration (limited or permanent), start date and allocation %.

Alongside, some projects are finished and some resources are required to be released from their accounts. This is done by sending Release forms to the RM with all information related to the released resources. The RM receives all resource requests and release forms from all accounts. This forms the overall resource pool that is managed by the RM.

When a resource request is received, the first step for the RM is to try matching the resource requirements from within the available resource pool. If this is not directly matched, the RM starts looking into different accounts looking for the possibility to get the required resources internally.

The RM search through the utilization of all resources and start negotiating with the SDMs to fulfill the requested resources. If no resources are available, the RM works with the SDM and the sales team and tries negotiating different parameters (e.g., resources, start date, and duration extension) in an effort to fit in the opportunity using existing resources. The following step is to run various resource demand scenarios for resource predication based on different criteria in order to match demand vs. capacity and to decide on which opportunities to accept (different criteria produce different results).

In general, conflicts around resources are addressed by the RM using the following criteria:

Confirmation – the percentage of confidence of the opportunity (this is consulted with the sales)

Start date

RM own experience and negotiation with the requestors

Escalation to higher management – the strategic objectives are then used to give priority to one opportunity over the other or even over existing projects

If the opportunity is selected and all efforts to fulfill resource requests internally didn’t work, the RM starts the process for hiring the required resources. Hiring request is raised to HR with the number of resources (consolidated from the received resource requests) and the detailed information about them. The HR involves the requesting accounts’ SDMs in the hiring process to interview the candidates before they are hired. Further, the training requirements for existing resources is also defined and sent to the training manager to arrange for them.

Generate Proposal

For the confirmed opportunities, the SDM assigns one of the PLs to start doing more detailed estimates to submit in a proposal to the client. Based on the size and scope of the opportunity, a team including a Technical Lead, Quality Lead and Business Analyst might be formed to pull together a formal proposal . As needed, the proposal team engages with the customer to clarify more data regarding the requirements in order to produce accurate estimates. The produced estimates include all resource types needed to deliver the required work. This includes resources for project management, development, quality, technical writing, business analysis and graphics as needed. Once resources estimates and timelines are produced and verified with respective teams, the SDM works with the assigned PL and proposal team to finalize the proposal and send it to the sales team who do the pricing based on the estimated resources and then commit it to the client.

Assign Required Resources

Once the opportunity is realized , it is changed to a project and the SDM assigns a PL to manage the project. The first step for the PL is to form the project team. At this point, all resources requested from various teams are officially assigned to the project based on the estimates previously done. At this stage, the project is officially started and the PL initiates the project.

Initiate Project & Form Project Team

Sometimes, the PL assigned to manage the project is not the one who did the estimates during the proposal stage. In other cases, the information provided during the proposal stage is not enough to do accurate estimates. In both situations, the assigned PL might need to assess the previous estimates and re-estimate if needed. The PL starts by reviewing the available requirements with the TL. The PL can engage with the customer if any questions are raised during the review. Afterwards, the TL produces the WBS for the development tasks along with the estimates and the dependencies.
The same exercise is done with the quality team and other teams involved, where a list of tasks, estimates and dependencies are provided.  This information is used by the PL as a basis to create the project schedule and start project execution . Doing this re-estimation usually helps in predicting project results. A CR is created with the new estimates. This CR is normally used for internal processes, but in some cases, it is available to submit it to the client to set the expectation and/or take approvals.

Tracking & Control

During the execution of the project, each PL is totally focused on the project scope and they tend to be driven by project success. It’s the duty of the SDMs, the Quality Assurance team and the Organization Performance Team to make sure that project execution is continuously driven by organization success in alignment with ITWorx standard processes and quality initiatives like CMMI and Lean . This is normally done through continuous tracking and control of the projects at various levels in the organization (project level, account level, process level, and top management level). The lowest is on the project level, where the PL performs project monitoring and control for the project activities through all project phases. The PL has regular status updates from the project team, normal issues and risks are resolved directly by the PL. The project status is reported weekly to the customer and to the SDM. Special reports are communicated weekly to the SDM including the project budget information (CPI, SPI, etc…), the issue log and any risk. Alongside with those regular reports, the PL has regular meetings with the SDM to discuss the project progress and any action required from the SDM.

The second level of tracking is on the account level, where the SDM have a consolidated view of all projects in the account and monitor if there is an issue that requires SDM action. Regular meetings are done with each PL as described above and also regular meetings are done with the sales team to discuss actual project progress, client feedback and concerns and possible opportunities.

Alongside, the quality assurance team performs regular process audits on the project and account levels to make sure that all activities comply with ITWorx standards and quality initiatives. Any unjustified deviation from the process is reported and followed up till it is cleared. This ensures a coherent way of project delivery and continuous improvement through organizational learning.

The organization performance team at the top level of tracking and monitoring, aggregates the data for all portfolio components with focus on cost, cash flow demand, resource demand, milestones and deliverable. Those reports are then presented to the top management in some forms like a score card or bubble views. The top management uses those reports to keep an eye on the overall performance to be able to anticipate trends and issues and engage in the suitable time to take necessary actions.

Reasons for Project Failure

After going through the project management process as done in ITWorx, Wael Amin always makes sure to go through the main reasons that might lead to project failure. Those sometimes reflect a flaw in the way project management should be done.

Unqualified Resources

When we talk about qualified resources we don’t mean skilled or unskilled, but we mean if their skill-set is well suited for this specific project. From this perspective, resources might need to have either vertical business knowledge of specific industry or specific technical knowledge. One of the main reasons that cause project to run into problems is when it doesn’t have the right set of resources.

Several factors result on having unqualified resources;

–   Accepting a number of projects that exceeds the available resource capacity, this being in general or for specific industry or technology.

–    Competition that attract skilled resources and limited budget that doesn’t allow HR to face this competition.

Proper resource planning (resource demand management and resource allocation) should take place to avoid assigning unqualified resources to projects.

Project Timelines

Very often there are cases where customers come in with very aggressive deadlines for projects whether because of poor planning on their behalf or due to changes in market conditions where they realize the need to have a project or an initiative launched by a specific date. Those should be exceptional cases, yet if this is common for most of the projects then there is a serious problem with the estimation and planning processes.

Projects with aggressive deadlines put a high pressure on everyone and normally they need very skilled managers to monitor closely the progress, quality and risks of those projects and be able to maneuver with resources and budget to get them successful.

It’s not advisable to have many projects in the portfolio with tight deadlines. Sometimes it is useful to turn down opportunities of this nature in order to save the whole portfolio.

Scope Creep

Changes to the project scope can happen either when the clients change their mind or when the analyst doesn’t capture all the client requirements correctly before the project starts.

Normally, proper information gathering needs to take place during the pre-sales activities to allow for appropriate estimation of the associated effort, and hence, accurate planning and realistic proposals.

When the opportunity is realized and projects starts, change management process need to be strictly followed to control the scope of the project and to avoid scope creep or cost overruns.

Improper change management reflects back on both resources and timelines. A project might starts with reasonable timeline and qualified resources, but when new requirements are uncovered after the project starts, the project becomes in a situation where it lacks qualified resources and/or have a tight deadline.

Bad Estimates

As mentioned before, it’s essential to do proper data gathering during opportunity creation and proposal phases. But sometimes, even when this is done, there is still a problem with the estimates. It’s also essential to have the right set of resources to do the project estimation. Estimation differences start to show as a result of having the resources who work on the estimates different from those who will do the actual work.

This difference in estimation is ideally solved by anticipating the resources that will work on the project and assign them to do the initial estimates. When this is not handy, proper estimation methodology and possible contingencies need to be added to account for difference in skills and possible lack of information.

Resource Commitment

For some projects, you might have all the previous reasons for failure completely avoided. Yet, the project still faces problems during execution. One possible reason for this is the resources commitment and whether they are passionate and enthusiastic to the work they are assigned to do in the project or not.

Dealing with this problem is dependent on both the leadership style and the organizational culture. If the employee satisfaction is highly appreciated and taken care of, usually resource commitment is guaranteed.

Intra-project competition

Sometimes decisions to accept a new project might affect existing projects. This in general causes competition over available resources.

Managing intra-project competition is the focus of the portfolio management process. Portfolio management should allow proper assessment of new projects and their effect on existing projects. It also provides the information that supports the decision of whether to accept those new projects and how to balance the whole portfolio based on the overall organizational strategy.

Projects Tracking & Control

Different project methodology (agile, waterfall, etc…) requires difference amount of tracking and customer feedback. With proper tracking and control mechanisms, organizational leadership will have visibility over all projects in the portfolio and can interfere at the correct timing to solve anticipated project problems. The proposed solutions need to take into consideration the remaining projects in the portfolio so that they are not affected or the effect is calculated and acceptable. If the management performs tracking without proper control they might fail to react to problems in a timely manner which might cause the project to fail.

Risks & Contingency

In general, both organization risks and project specific risks need to be clearly identified and managed. Having proper risk planning helps the organization to become agile and to always be on top of the situation.

Conclusion

Students at the MBA Project Management class at AUC are always impressed with the way Wael Amin presents project management at ITWorx. Most of them expected to get the focus on project management tools and the details of how individual projects are managed and tracked. Instead, Wael presented how projects are really managed even before they start. He presented this in a very interesting story like form starting from the prospects and how leads are formed, how they are prioritized according to the overall company’s strategic objectives, how resources are managed and assigned to different projects, how conflicts between projects are resolved when they arise and how the upper management keeps an eye over all the projects running and interfere when and as needed to get the projects back in track.

ITWorx is actually applying the theories and methodology of project portfolio management and is working as a mature project management organization rather than a traditional one (see Exhibit 1).
PLs normally focus on project scope and individual success in a “Projecticized” organization way. On the other hand the top management and portfolio managers (SDMs) focus is on the overall organizational success. This focus is enforced through various teams and supporting tools used to track and control project management for organizational success.

There is a strategic initiative to implement a PMO (Project Management Office) at a central top level to help ensure a balanced view and organizational focus instead of having a distributed control in the account level. This initiative was put to the back burner due to the turmoil associated with the revolution. Yet, it was revived again and planned to take place in 2013.

With the turmoil that was ensued the revolution, business continuity became a challenge to ITWorx. Wael talked about their attempt to build flexibility in resources to face market fluctuations. Some approaches taken were; training to ensure multi-skilled resources that can be used in various types of projects, the adoption of cross-testing where developers perform testing.

Building resilience in the organization and the ability to survive is a continuous challenge for ITWorx in which it has succeeded many times.

Exhibits   

Exhibit 1 – Project Portfolio Management

Traditional project management is, by and large, a process whereby each project is approved and managed independently. In this arena, the focus is on a single project and the triple constraint—scope, time, and cost—of that project separate from other projects. Typically, the project manager is responsible for evaluating the performance of the project. At times, given the importance of the project, the project might be evaluated or reviewed at the executive level, but this review is still conducted in isolation of other projects.

In mature project management organizations, there is a pre-defined process for selecting projects and a uniform process for evaluating their success. The selection decisions, and the periodic evaluations, are made in light of the enterprise’s business goals and strategies. Evaluations are conducted regularly and are based on standardized procedures. The emphasis is on ensuring that each project contributes to the overall organizational success. The project must continue to support business goals even if there are major changes in the project requirements. Organizational planning impacts the projects by means of project prioritization based on risk, funding, and the organization’s strategic plan. Organizational planning can direct the funding and support for the component projects on the basis of risk categories, specific lines of business, or general types of projects.

In a portfolio management, the relationship of a portfolio and its component can be illustrated by Figure 4.

Figure3:  Portfolio, Programs and Projects – High Level View.
Source: Adapted from PMI, The Standard for Portfolio Management
 

A portfolio is a collection of projects or programs and other work that are grouped together to facilitate effective management of that work to meet strategic business objectives. These components of a portfolio are quantifiable; that is, they can be measured, ranked, and prioritized.

Portfolio management is the centralized management of one or more portfolios, which includes identifying, prioritizing, authorizing, managing, and controlling projects, programs, and other related work, to achieve specific strategic business objectives. It includes the processes for identifying the organizational priorities, making investment decisions, and allocating resources.

A program is defined as a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside the scope of the discrete projects in the program. A project may or may not be part of a program but a program will always have projects.

Program management is defined as the centralized coordinated management of a program to achieve the program’s strategic objectives and benefits. Projects within a program are related through the common outcome or collective capability. Program management focuses on the project interdependencies and helps to determine the optimal approach for managing them.
The project life cycle generally consists of a concept phase, a planning phase, an execution phase, a monitoring and controlling phase, and a closing phase. However, the portfolio management life cycle is broader and has a different focus. It consists of identifying enterprise opportunities, selecting the projects to help fulfill these opportunities, planning and executing these projects, and continually assessing the benefits of these projects to organizational success. In many ways, project management is a subsidiary component of portfolio management as it focuses on the planning and execution of the specific selected projects of the portfolio.

The project portfolio management guidelines further emphasize monitoring each project regularly to assess the project’s contribution to the organization’s strategic goals. This active monitoring enables corrective actions to be taken if it is noted that a project is no longer contributing to corporate needs, as originally planned. If corrective actions are insufficient in remedying the project performance problem, the project might be terminated.

The primary benefit of a PPM system is that only the right projects will be selected and/or continued. Thus, the projects in the pipeline will be fully aligned with the strategic business goals of the enterprise.

The PPM process will probably impact the project activities by requiring that all projects and programs follow a consistent data collection and reporting methodology. Additionally, such organizationally consistent PPM procedures will provide the upper management with a detailed and informed view of all portfolios in progress.

Usually project management activities are conducted by a project team, while the portfolio management activities are conducted by the upper management of the organization

The aggregation and rollup of data across portfolios are primarily focused on cost, cash flow demand, resource demand, milestones, and deliverables. Since the basic data for these project attributes exist in quantitative form, the summarization is usually a simple summation across time and/or across a portfolio.

Projects, programs, and portfolios have different approaches. Table 1 shows the comparison of project, program, and portfolio views across several domains including change, leadership, management, and others.

Table 1:  Comparative Overview of Project, Program, and Portfolio Management [PMBOK, 4th Edition]

(adsbygoogle = window.adsbygoogle || []).push({});

References

1.    ITWorx website [Online], [Retrieved 2011], http://www.itworx.com 

2.    Institute, Project Management. “Chapter 1 – Introduction”. The Standard for Portfolio Management, Second Edition. Project Management Institute. © 2008.

3.    Institute, Project Management. “Chapter 1 – Introduction”. A Guide to the Project Management Body Of Knowledge (PMBOK® Guide), Fourth Edition. Project Management Institute. © 2008.

4.    Institute, Project Management. “Chapter 7 – Project Cost Management”. A Guide to the Project Management Body Of Knowledge (PMBOK® Guide), Fourth Edition. Project Management Institute. © 2008.

5.    Rad, Parviz F., and Ginger Levin. Project Portfolio Management Tools and Techniques. IIL Publishing. © 2006
Google Scholar

6.    Kerzner, Harold. Advanced Project Management: Best Practices on Implementation, Second Edition. John Wiley & Sons. © 2004, Chapter 7
Google Scholar

7.    Kendall, Gerald I., and Steven C. Rollins. Advanced Project Portfolio Management and the PMO: Multiplying ROI at Warp Speed. J. Ross Publishing. © 2003. Chapter 14

 

Shares