Skip to main content

Author: Abid Mustafa

How Many Projects Are We Delivering This Year?

Every year there is a mad scramble by most companies to secure budgets internally for projects they intend to do for the following financial year. Typically, companies are flooded with requests from various departments to deliver capabilities and benefits through a variety of projects and programmes. However, companies are acutely aware that there has to be a balance between the long wish list of things to do, and the organization’s actual ability to deliver them. Usually this leads to an onerous quest to estimate the number of projects and programmes that can be delivered in a single year. In the absence of a workable corporate planning process (one that provides a prioritization framework to validate whether the right projects should be done or not) this becomes a daunting exercise for executives and their senior management teams. The purpose of this article is outline a number of techniques which on their own or collectively can assist companies to overcome this dilemma.

Establish a project filtration standard.

Given the chance, business units will add anything to the company’s list of things to do. Items that would never qualify as project work are often added. Once all the business units have finished contributing, the wish list is usually very long and lacks detail. Trawling through such a list and deciphering every item is a tedious exercise. Furthermore, to discover that a significant proportion of items do not constitute project work is extremely painful, and quite frankly a waste of the company’s time! To minimize the inclusion of non-project items and to encourage sufficient detail to reduce protracted dialogues with the business units demands a project filtration standard to be established and communicated to the relevant parties.   At its simplest level, this could entail distinguishing between development work and operational work. In practice however, a more versatile standard is required to perform the filtration. This should consist of: a business case for the intended project work, its alignment with the corporate’s strategic objectives, project size (small, medium, and large) and high-level project information (sponsorship, scope, objectives, time lines etc.). If the filtration standard is implemented correctly, it should preclude items like “photocopier installation, exchange server memory upgrade, 10 employee desks” from appearing on the list. Additionally, short sentences to describe project work such as “ERP system is required because everyone else has one, and it will take 6 months to implement” will be actively discouraged and excluded from the list, unless sufficient detail is provided.

How much money is available to spend on projects?

Another technique that can be employed to restrain the company’s wish list is to impose an overall project budget for the company. The total budget can be divided into specific budgetary envelopes which the business units use to calculate project submissions. However, the value of the total project work submitted must not exceed the overall project budget, but individual envelopes can be exceeded. In practice, this requires strict rules to regulate negotiations between the various business units; otherwise there is a danger that whole exercise can become protracted.
A variation to this approach is to set a specific monetary threshold to admit project work into the company’s to do list. Therefore, if an item meets the threshold value, it is included on the list. Nonetheless, an overall cap on project spending is imposed to inhibit too many items from entering the list. Whilst both approaches are quick and dirty, they lack the intelligence to ascertain what really constitutes project work.

Use historical data to determine organization’s capability to deliver.

The two techniques described so far, are good at restricting the company’s wish list, but are quite poor at providing an indication as to how many projects the company can actually deliver. One technique that can help in this respect is to use historical project data to determine the organization’s current ability to deliver number of projects. The accuracy of this method is greatly dependent upon the quality of the project data: if the project data is incomplete, inconsistent, or contradictory, then it may be prudent to use procurement data to calculate just how many projects started, or stopped, in a given a year. However, even this may not be enough to provide an answer with certainty. If the quality of project data is too poor to provide a reliable figure, then benchmarking could be used to determine company’s delivery capability. However, benchmarking provides the industry figure as to what a similar size organization in a specific business area should be delivering. It is not a measure of how many projects the organization in question can deliver presently. In any case, both historical data and benchmarking can assist organizations to aim for the optimum number of projects they should deliver in a given year.

Use critical resource head count to estimate the number of projects.

An expedient method for fixing the number of projects is to base it on the number of critical resources used by the company to deliver project work.  The critical resources can be project managers, analysts, architects, designers, testers, trainers etc. All organizations have a finite number of resources and in the current economic climate; the tendency is to do more with less. Hence, resource sharing is imperative to deliver projects. So it should be quite straightforward to come up with a reasonable figure, which all parties can concur with. For instance, if there are fifteen project managers then it is reasonable to assume that they would not be able to deliver more than twenty medium size projects.

Intelligent planning

One of the ways to do more with less is to group projects into programmes and then manage the delivery to produce the requisite capabilities and benefits. The advantage of this approach is that the organization as a whole can focus on a small number of programmes in a given year. However, the greatest challenge facing such an approach is the organization’s maturity to plan and effectively collaborate. Provisions are also made for unplanned projects, or programmes, which can arise due to market conditions and regulatory edicts.

Executive threshold to sponsor projects and programmes.

Lastly, one of the biggest constraining factors is how much time executives can devote to project sponsorship. Typically, executives have their schedules full with strategic, operational, management, financial and commercial responsibilities. Finding time to sponsor projects in additions to these responsibilities is a struggle for the best of executives.  Most likely, executives will not be able to commit beyond one or two major projects and programmes. Therefore, using executive attention to measure the organization’s ability to deliver is an extremely useful technique.

In conclusion, a selection of any techniques listed above can be employed to calculate the organization’s ability to deliver within a defined budget. However, this is merely a temporary solution. A more permanent solution necessitates such techniques to be integrated into the company’s corporate planning process. Only then, will the company be able to accurately determine its capability to deliver a specific number of projects and programmes each year.

Don’t forget to leave your comments below.


Abid Mustafa is a seasoned professional with 18 years’ experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programs and projects. Currently, he is working as a director of corporate programs for a leading telecoms operator in the MENA region.

Introducing the Project President

At crucial moments, well-timed executive decisions to steer projects and programmes are often in short supply.  Subsequently, issues are left unresolved, key milestones are missed and the overall project delivery is delayed.  Whilst it may appear that executive indecision is the main culprit behind the delay , it not the primary cause.
The root cause lies in how executive leadership is exercised in project steering committees.  Normally, such committees are organized to encourage executives to provide guidance to project teams and participate in the resolution of issues amongst other responsibilities. However, this is usually done in a pluralistic manner as leadership is collectively shared amongst the executives. Figure 1.0 below shows a typical project hierarchy that consists of a project steering committee that has four C- level executives.

AdibSept281

Figure 1.0 A typical Project Steering committee that exercises pluralistic leadership

In practice, this works fine for issues that are clear-cut to solve, as executive consensus is normally reached. But for more complex issues, executive agreement is at best painstakingly slow and more often than not, issues are deferred for the CEO’s input.  The input can be either in the form of guidance consisting of principles, or a definitive decision thereby putting to rest any executive misgivings about solving the issue. Usually to obtain the CEO’s input requires the PMO together with the Project Sponsor to compete with other departments for a time slot with the CEO (predictably this can be an arduous wait, as CEOs are extremely busy people). The ensuing delay can very quickly bring the organization’s flagship project/programme to a complete halt, escalate costs, and squander opportunities to address competitors.
Another drawback of pluralistic leadership is that most solutions negotiated are often diluted to appease other executives. In the end, a compromise solution is reached, which neither addresses the problem, nor helps the project move forward. Its only achievement is that all the executives concur—not whether the solution is right, or wrong. Such resolutions render projects steering committees ineffective, deter Project Managers and Sponsors from escalating issues, and promotes a culture of indifference.
Yet, by making a small but significant change in the structure of the project steering committee, the aforementioned problems that plague traditional steering committees can be avoided. By the creation introduction of a ‘Project President’ in the steering committee, where the CxOs are demoted to subordinates, can engender an efficient mechanism to deal with issues quickly. Figure 1.1 below shows this new appointment of the Project President in relation to other executives.

AdibSept282

Figure 1.1 The Project President and the Project Steering committee

To enable the Project President to discharge his/her responsibilities, the CEO must delegate all the powers related to project work. This implies that that the Project President must be able to overrule CxOs, interfere in their respective domains (within valid reason) and have a free rein to implement, or revoke decisions. As a consequence, the CxO’s are relieved of their collective leadership and the leadership is solely handed over to the Project President. In this new structure the CxO’s play an advisory role in decision making, whereby taking decisions is exclusively at the prerogative of the Project President. It also means that the Project President’s scope of work and stewardship encompasses all projects and programmes, and is not limited to one, or two initiatives i.e. the Project President may preside over several steering committees.
In the launch phase of the company, the CEO is the person entrusted with executing the role of the Project President. But soon after launch, the CEO usually hands over this responsibility to the CxOs collectively, without nominating a successor with all the powers of the CEO. Invariably, this pluralistic leadership exercised by the executives leads to the all too familiar problems mentioned earlier.
In practice, the best candidates amongst the CxO to perform the role of the Project President are the Chief commercial officer (CCO), Chief Operations Officer (COO) and the Chief Project Officer (CPO). However, the COO and CCO can become too pre-occupied with their day to day duties, and may not have enough time to execute the duties of the Project President. Therefore, the CPO is the natural candidate for this role, but in many organizations the CPO lacks the mandate and the support of fellow executives.
If company’s really want to improve their performance in the execution of initiatives and reduce time to market then they should take a serious look at restructuring project steering committees.  By appointing the right person to play the role of the Project President, delivery of projects and programmes can be vastly improved.

Don’t forget to leave your comments below.


Abid Mustafa is a seasoned professional with 18 years’ experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programs and projects. Currently, he is working as a director of corporate programs for a leading telecoms operator in the MENA region.

How to Determine PMO’s Identity

The establishment of PMOs is a daunting task that requires great wisdom and perseverance. What is of paramount importance for the PMO’s success and longevity is to make the management of executive interests an intrinsic feature of PMOs, while weaving them into the very fabric of the project organization. This implies that the design and construction of the PMO must happen organically, i.e., the structure of the PMO cannot be imposed or rushed, but must develop naturally. However, in practice, there is a strong impulse to simply ‘cut & paste’ PMO solutions. This is often done without a correct understanding of the problems affecting projects and possessing an inaccurate assessment of executive views on role of the PMO. In most cases, PMOs are established based on an arbitrary executive instruction. The purpose of this article is to explore techniques on how to analyze and assess what executives really want from PMOs.

The most important facet in the establishment of the PMO is to clearly recognize what role the executives want the PMO to play. Some conventional approaches rely on questionnaires that ask executives to respond to pre-defined roles for PMOs, i.e., ‘Would you like the PMO to play a supporting or directing role in project management?’ Views captured in this manner are then debated and the majority view is taken to determine the role of the PMO (although sometimes the CEO’s decision is invoked to expedite a conclusion). By taking this approach, discussions are not very productive as they are framed within an artificial and somewhat imposed context that is often disconnected from the current problems of the company. The identity of the PMO that is synthesized from such a process is usually prone to vagueness and diffidence.

To avoid such outcomes, it is important to understand the background of executives and their past interactions with PMOs. The two matrices presented below enable one to accurately identify PMO competencies, map their maturity and accommodate the interests of the CxOs. Figure 1-1 is a simple matrix that highlights the exposure of executives to PMO functions.

Abid11

Figure 1-1 Past Executive interactions with PMOs denoted by ‘x’

In this particular example, the overwhelming PMO experience for many of the executives includes exposure to executive meetings, followed by launch office and business processes activities. Important inferences can be drawn from this information. Both the CCO and COO come from a program delivery background, whereas the CPO (Chief Project Officer) has more of a project/program support background. Hence, this could be a potential source of conflict between executive management. Another point of contention might be the drafting and monitoring of business processes. Utilizing matrices such as this highlight the disposition of CxOs toward PMO functions and can help mitigate sources of conflict.

However, to define a PMO’s identity, it is not sufficient to scrutinize executive experiences with past PMOs. Instead, the CxOs must be encouraged to think about the role of the PMO within the context of their present work environment, which must be related to the execution of initiatives. A second matrix described in figure 1.2 below can be used to illustrate this point.

Abid1

Figure 1-2 Present-day executive requirements for PMO (denoted by ‘x’)

In this example, few executives see the need to align initiatives with the company’s strategy or manage a portfolio; even though this is regarded as vital for ‘doing the right things’ and is normally considered as industry best practice. Rather, the focus for the majority is on program delivery, monitoring operational KPIs and task force work. Hence, a clear conflict of interest awaits the CPO with his or her peers. Oddly enough, there is also no mention of the PMO performing one of its core activities that is the standardization of project methodology, tools and standards, i.e., ‘doing things right.’ Again, a matrix such as this can be used to identify what CxOs would like their PMO to do. It is recommended to use such a matrix after the CxOs have either struggled to deliver a particular initiative (one that involves all of them), or they have repeatedly encountered project/program failure.

So here’s the challenge: how does one make the CxOs cognizant about the importance of PMO’s core competencies, while at the same time, not alienate one’s personal dispositions? This conundrum cannot be resolved by simply taking a majority decision on what the PMO should or should not be doing, as this will prompt some executives to merely pay lip service and withhold their wholehearted support for the more important initiatives.

While there is no one solution, every company is different and the interplay of CxOs varies from organization to organization. Therefore, it is important for the one charged with the responsibility of establishing the PMO to do their utmost to define the PMO competencies and chart their respective evolution, in the best interest of the company. This means that all the interests of the CxOs—no matter how miniscule—must be accommodated. Furthermore, many competencies take a great deal of time to develop and mature. Consequently, the CxOs have to be informed and persuaded about the availability of such competencies. For instance, in figure 1.2, portfolio management, or program delivery, cannot be instigated unless the PMO possesses a sound project methodology. CxOs must be won over on the value of this truth, as opposed to just being told.

In summary, to ‘cut and paste’ PMO solutions, or to convince CxOs about the implementation of best practice PMO methodologies, is a recipe for failure and extremely expensive! Instead, a great deal of time and effort needs to be invested to cultivate the right PMO identity, with continued executive support. Unfortunately, this is an arduous journey and there are no shortcuts on the way.

Don’t forget to leave your comments below.


Abid Mustafa is a seasoned professional with 18 years’ experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programs and projects. Currently, he is working as a director of corporate programs for a leading telecoms operator in the MENA region.

What Constitutes a Good Project Management Office Road Map?

Once the PMO’s identity is successfully crafted, the focus gravitates towards the definition of the project methodology, staff certification and the evaluation of automation tools. Occasionally, efforts are invested in charting the evolution of processes based on the standard PMO maturity model.  The brave amongst the PMO cadres go further and delve into the political quagmire of establishing ground rules for project ownership. While all of these activities are commendable they do not—in their sum—constitute a PMO road map.

The PMO road map is much more than a compilation of the above activities compressed into a schedule. A good road map will address several areas for development and deliver core competencies over a period of time. An effective timeline should span 2 years, or 8 quarters and must deliver tangible benefits to the organization at regular intervals. What follows is a synopsis of the basic elements that should be the cornerstone of a road map to establish a PMO.

PMO Transformation

It’s important to bear in mind that the PMO will have to pass through a number of stages, before it becomes a fully fledged department that functions in accordance with PMO’s mission and vision statements. Initially, the journey will commence from the instillation of service culture within the team, followed by the company wide acceptance that the PMO is a service base department. In other words, individual relationships with other Business Units (BUs) have been substituted with agreed OLAs, buttressed by the PMO team. Furthermore, each BU request is prioritized (according to a set of frame works agreed upon with the executives) and processed in a professional manner based on existing capacity. At the end of the journey—depending very much on the mission and vision statement—the PMO should be widely recognized as a center of excellence, or a consultancy— or perhaps both. The transformation of the PMO from a handful of individuals, to a fully operational department should be clearly represented on the PMO road map. 

Service Portfolio

Without a doubt, a successful PMO will offer a range of services which business units can rely on time after time. Business units may subscribe to services such as project support, project delivery, portfolio management, executive reporting, PMO BOT(Build Operate Transfer), business processes, change management, quality assurance, etc.  From the outset, the capability to deliver and support such services will not be in place. This means that services have to be introduced gradually and the PMO road map should clearly highlight this, as well as, all of the associated dependencies. If there is an urgent requirement to provide a particular service—especially one that is not ready—the PMO may contract vendors to provide the service in the interim period. Again, this should be included in the road map.

Project Methodology

The core competency of any PMO is a sound project methodology that serves as the mainstay for efficient program delivery and effective portfolio management. However, it takes time to develop a robust methodology with associated templates and tools. Furthermore, a certain level of maturity which varies from company to company is mandatory before program delivery can start and a given set of projects/programs can be treated as portfolio management. Therefore the PMO road map ought to clearly indicate as to when it would have the capability and the capacity to support this. The former is grounded in processes, roles and responsibilities, and governance; the latter hinges on skills and competency. As a cautionary note, it is extremely beneficial to include project targets such as by quarter 3 the PMO will support x number of projects, or have delivered y number of cross-functional business programs.

Certification

PMO certification can be divided into two parts; processes and manpower. ISO, OGC and PMI are the preferred choice for many companies when it comes to certifying PMO processes and project methodology. On the manpower front: PRINCE2, PMP, Six Sigma, AIM and other certifications are essential to demonstrate the PMO’s ability to deliver proposed services. The certification path for the PMO processes and manpower ought to be incorporated in the road map and aligned with PMO transformation, service portfolio and project methodology.

Automation

Automation here does not imply the purchase and implementation of a project tool such as MSP, or an enterprise portfolio management application. Rather, automation is the complete mechanization of the PMO and its integration with other corporate systems such as ERP, CRM, Business Intelligence (BI), etc. As one can appreciate, an automated PMO is not going to be forged overnight. In fact, it is correct to insinuate that such an endeavour can only be implemented in phases; prudently mimicking the maturity of PMO process, project methodology and people. This more than likely suggests, the time line for the road map will not be met.

Communication

One of the most neglected and overlooked aspects of the PMO is the active advertisement of its services and benefits to all employees of the organization. Again a staggered approach to marketing the PMO may initially include a CEO’s memo, followed by frequent publication of PMO newsletters, brochures, web casts etc. Again the PMO road map must factor in PMO communication.

Other elements can be included in the road map but the ones outlined in this article should suffice as a beginning. The road map should be logically arranged to show the availability of different services and the key dependencies to support them. Once a road map is in place it is relatively easy to construct a detail plan, set employee objectives and win over skeptics about the merits of the PMO.

Don’t forget to leave your comments below.


Abid Mustafa is a seasoned professional with 18 years’ experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programmes and projects. Currently he is working as a director of corporate programmes for a leading telecoms operator in the MENA region.

ISO 9001 Certification for PMOs: Is it Worth it?

Many PMO directors consider ISO 9001 certification for their PMO at some point. Some embark on the ISO 9001 certification path because it is customary to do so, especially in organizations that are focused on product or service excellence. Other PMOs opt for ISO 9001 accreditation to win kudos amongst departments responsible for initiating for project work. Whatever the case maybe only a few PMO directors develop a strong rationale for undertaking such an endeavour.

Before PMO directors contemplate ISO 9001 certification, it is important to understand what ISO 9001 constitutes and how it can benefit PMOs. ISO 9001 is an international quality management standard that is geared towards improving the quality of product and services, through the implementation of key processes and the utilization of measures to determine the operational effectiveness of such processes.

ISO 9001 certification should not be confused with the certification of the PMO’s project methodology. The later is a completely different discipline, and in many ways is less challenging then ISO 9001 certification. ISO 9001 certification requires the PMO to possess more than just a project methodology. PMOs—at a minimum—must establish a quality policy and have a quality manual, interface with major HR and procurement processes, and continuously solicit customer feedback and constantly measure customer satisfaction. In addition to project management culture, the PMO must be orientated towards a service culture and imbue its staff to be service driven.

On comprehending what ISO 9001 entails the PMO director should be scrupulous about the business justification for undertaking accreditation.  If the emphasis of the PMO is to deliver products and services to external customers or to bid for prestigious contracts— which is usually applicable to PMOs residing within professional services— where quality is an essential prerequisite in the RFP process, then ISO 9001 is definitely worth pursuing. Another reason may be that the PMO is prone to unproductive processes, suffers from escalated costs and is plagued with low staff morale. Engagement in ISO 9001 certification process will increase the performance of the PMO and instill confidence in its staff.

However, if the PMO is mature, quality conscious and value driven, then ISO 9001 will add little value. In such cases, the PMO can administer its own audit of its processes, governance model, and roles and responsibilities. Any gaps that may materialize can be swiftly addressed to enhance PMO’s performance. Going through ISO 9001 in this case would be expensive and probably highlight similar gaps to those discovered during the internal audit.

There may be instances, where the PMO director is motivated to undertake ISO 9001 as a means of demonstrating the PMO’s value to the company by making it the center of project excellence. This should be avoided at all costs. Instead the PMO director must show value not through ISO accreditation, but through the delivery of tangible benefits for the company. Through these delivery efforts, repeatedly and successfully, the PMO will be automatically recognized as the center of project excellence throughout the company.

Last but not least, those who opt for ISO 9001 should be prepared for the long haul i.e. ISO 9001 accreditation is relatively easy to obtain but difficult to keep. After the euphoria of accreditation, many PMOs struggle to keep their ISO credentials, as periodic surveillance audits disclose a litany of non-compliance items. To reduce non-conformities PMO directors often end up spending more money— through hiring consultants to bridge gaps and extra staff to produce records— than anticipated, thereby undermining the whole ethos of ISO 9001 and end up with a worthless piece of paper.

Don’t forget to leave your comments below.


Abid Mustafa is a seasoned professional with 18 years’ experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programmes and projects. Currently he is working as a director of corporate programmes for a leading telecoms operator in the MENA region.