programme management - a overview · programme management – an overview ... project management as...
TRANSCRIPT
Paper presented at African Rhythm Project Management Conference 22 – 24 April 2002, Johannesburg, South Africa Hosted by: Project Management Institute of South Africa (PMISA): www.pmisa.org.za ISBN Number: 0-620-28853-1
PROGRAMME MANAGEMENT – AN OVERVIEW
Elmar Roberg
©Business Transformation Services
1 Introduction Project management can with some justification be called the oldest profession (rather than that other one). However, as a formal profession, it has been late in putting onto paper what it does and how this is done. The last decades have seen the establishment of numerous local national societies with, in some cases, the active support of government. The Australian government, for example, has recognised the importance of project management as a profession and has contracted the Australian Institute of Project Management to first define project management as a competency and then to vet prospective immigrants who claim to have project management skills.
The last fifteen years or so, has seen an explosion of books, courses and interest in the profession. Specifically, in IT, there has been a strong move in that direction. This can be clearly seen in the makeup of the various associations, where membership out of the IT has risen from an insignificant minority into a large force.
No doubt, the integration of IT into enterprise operations proper has had no small influence.
Some notable associations, such as the PMI (Project Management Institute), have gained acceptance to the point where its influential PMBOK (Project Management Body of Knowledge) has become the de facto standard for describing project management, to the extent where standards setting organisations such as ISO and IEEE/ANSI have adopted PMBOK as overprints.
As project management matures, a slow metamorphosis is also occurring in the role that it is playing in enterprises. There is no question that traditional projects and project management will always be with us, however, if project management is a good idea (and it is), then it should be capitalised on elsewhere.
The paper is intended to describe how project management can be used in the future to assist enterprises to become more effective.
1.1 Programme vs. Project Management
Programme Management is still a relatively new concept, and there is thus no commonly accepted definition for the term. For example, the PMBOK contains a vague definition that a program is “a group of related projects managed in a coordinated way. Programs usually include an element of ongoing activity.”
The UK CCTA (Government Centre for information Systems, Central Computer and Telecommunications Agency) describes Programme Management as “The coordinated management of a portfolio of projects to achieve a set of business objectives”.
Other definitions of programme management are
• A mega-project (extremely large project – this is often used in a USA context – for example, the “man-on-the-moon” project, or the Manhattan Project to develop the atomic bomb, the Channel Tunnel project, etc.);
• The management of any multi-project organisation;
• The management of many projects for one customer;
• The management of a portfolio of projects with a view to implementing corporate objectives;
• The coordinated support, planning, prioritisation and monitoring of projects to meet changing business needs.
Project management has been described as one of the oldest disciplines even if it has only been formalised as a management practice in the last decades. Almost all people act in one or more projects on a daily basis – even the baking of a cake is a simple project.
However, not all projects are successful in themselves, and often, projects do nothing towards achieving some grander objective. Sometimes, they may even counteract these greater objectives.
For example, a bookselling chain may decide that over the next 5 years, it will reengineer itself from being a “brick-and-mortar” enterprise with shops scattered in shopping malls around the country to a “click-and-deliver” enterprise that has no shops, no stock, no warehouses, any longer. Clearly, many projects will need to be undertaken to achieve this change. Considering the changes in technology that will occur over the 5-year period, some of these projects may need to be refocused or even cancelled as a new direction emerges, or becomes clearer.
The example mentioned is especially pertinent, since, if this strategic initiative had been initiated in 2000, when e-business was the way of the future, by the end of 2001, management would have been having serious doubts about the viability of the strategy. The uppermost questions in their minds would likely be: do we cancel everything and write off what has been done to date? What do we do about the structural changes that have already been made to the organisation? How do we explain this cost to our shareholders? Is there anything that we can salvage from what has been spent already?
Traditional project management, with its focus on delivering a well-defined scope by a given date, within a given cost at a requisite level of quality is singularly ill-equipped to deal with such questions. In any event, more aware project managers would have seen the writing on the wall and waited with bated on the flurry of strategic (re)planning exercises as to what their own futures would be. The more proactive might already be out looking for greener pastures.
The author believes that programme management is a newly developing practice that has as its primary focus the end goal(s) and will aim to address exactly the problems described above.
The purpose of the programme management is to capitalise on the strengths of different groups whilst minimising their weaknesses, exploiting skills and diverse areas of expertise as it aims to support the business strategy of one or more enterprises (the customer and suppliers). All motherhood and apple pie? True, but there actually is some substance.
A programme may be made up of a portfolio of related projects, or for that matter, a portfolio of programmes. For example, a large corporate could have many programmes – each focusing on the particular initiatives of a business unit, with all of these in turn being managed as a programme at the corporate level.
1.2 Redefining “Success”
A project is typically characterised by focused objectives that need to be met under stringent conditions. Expecting the project manager and team to also take an outwards view, that considers broader issues than just those described in the project charter can often be unreasonable.
This has been borne out by many studies that show, consistently, that a very large percentage of projects are not successful.
The Gartner Group suggests that only 25% of projects deliver the intended benefit. Furthermore, many projects are cancelled well after the original time and money budgets have been spent in full. Their findings are supported by the Standish Chaos Report, CSC-Index, numerous independent studies and university research projects.
Success should be seen in an enterprise-context. An enterprise might introduce new products or services that it wishes to take to market. Some of these may be extremely successful, resulting in large increases in turnover and profit, whilst and others may not be. The important thing is to identify which is which and then terminate or phase out the less successful products or services – or to see them as a necessary intermediate stage to another new product or service. Even so, an IT project portfolio should be allowed to be made up of a similar mix.
For example:
• Projects that develop systems supporting key functions of the enterprise and affect the viability of the enterprise as a going concern must be completed successfully against predefined criteria.
• On the other hand, a project that explores a new business opportunity may be allowed to “fail” once it has shown that the enterprise should not enter into the proposed area of business, or if it has shown what the conditions are under which it should enter – a case in point, would be the business of e-business.
The key issue is that one needs to break the “one size fits all” mentality, which insists that a project is only successful if it is completed on time, on budget, comprising the defined scope and at the requisite quality. The fact is that this is not always achievable:
• A project that addresses the need to achieve a result within a specific window of opportunity may be forced to revise scope, cost and even quality if that window of opportunity is not to be missed or suddenly closes.
• Similarly, an R&D type project will be considered to have been successful when the answers to a number of questions have been obtained. This has always been implicit objective of the under-utilised “disposable prototype” life cycle.
• On the other hand, the redevelopment of a core system (so-called “mission critical”), will only be considered successful if the key issues of quality and scope have been addressed successfully.
Projects are supported by project offices, whilst the programmes are supported by a programme office, or Programme Management Office (PMO).
2 Programme Management in the Business Context
2.1 The Need for Programme Management
The Dot.Com madness appears to have come to an end, thankfully. However, a new paradigm in business is here to stay: what is referred to as the “new economy”. The myth is not in that the processes of business are changing, but that “old economy” enterprises will not be able to adapt. The fact is that they are adapting and are allowing the “young upstarts”, using “foolish” capital to learn the lessons on their behalf.
Some things are certainly a hallmark of this new economy: speed; and uncertainty – about what works, what doesn’t; about who will be successful, who won’t; about how quickly it must take place; about what the end result must look like. As it was put in the 27 August 2001 edition of BusinessWeek “Along with being faster-growing, the New Economy is more exposed to the forces of volatility.” As the article goes on to say “no denying, there was plenty of froth. But the boom was founded on something real.”
Traditional project management has always anticipated and even required a high degree of predictability.
The sad truth is, some things are predictable and some things are not.
A quick survey of failed projects will almost always show predictability (or the lack of it) as having being a factor in that failure.
In traditional project management, we expect to start off with a firm Project Charter, developed by the customer that provides us with a firm baseline1. We then respond by developing a project plan that dots the i's and crosses the t’s, so that there is a contract in place that says exactly what is going to happen – blow by blow.
A project manager’s success is measured on how well that plan is executed and the enemy is the “variance”. Too much under-run indicates sloppy planning, too much overrun indicates a project manager who is not in control – in any event, the project manager is shown to not be “in control”.
1 Even the term baseline implies a solid, immovable starting point.
As a consequence, a whole body of knowledge has developed and been bedded down to make project management almost (but not quite) a science. We can employ computers with predefined algorithms that can do a lot in determining schedules, smoothing personnel work profiles, calculating risks and so on2.
The new “e” project management paradigm places much greater emphasis on innovation, collaboration, decision-making, knowledge management, “fuzzy” rather than accurate planning, and exploration. At the same time the projects, if anything, are larger whilst being more like R&D and at the same time mission critical. And this occurs in a turbulent business and technological environment where the key to success is speed.
All of this begs the question whether the traditional project manager will be able to “re-skill” (or more pertinently, adapt to the new mindset). In fact, techniques like Balanced Scorecards are probably more appropriate than what the traditional project manager may be used to.
In a landmark article (if the reader will overlook the excessive use of acronym and jargon), Seely and Duong posited in the June 2001 edition of the Project Management Journal that personality type was a major determinant in project manager selection for success, depending on the class of project. This supports the point that we are seeing a new dimension in the management of projects.
And, since programme management has to do with the enterprise, it needs to be aligned with enterprise, rather than departmental or divisional strategy.
2.2 Programme Management and Business Strategy
2.2.1 Values
Values describe what the key people in the enterprise consider to be most important. They are typically hierarchical in the sense that if adherence to a lower value compromises a higher value, then the higher value automatically has greater say.
Values determine the ethics of the enterprise.
2.2.2 Vision
Simply stated, vision is a perceived future reality that describes where the enterprise sees itself at some time in the future. It is perceived in that it is imaginary. It is future in that it does not yet exist. It is a reality in that the enterprise expects it to be so at the time envisioned.
The enterprise vision gives rise to a mission.
2.2.3 Mission
Simply stated, mission is what an enterprise does to achieve the vision. Strictly speaking, this would be the first step of strategy setting.
This then gives rise to multiple goals and objectives.
2.2.4 Goals, Objectives
Simply stated, goals are specific things that must be achieved if the mission is to be successfully accomplished (the quest to achieve the vision). These goals must map directly to various components of the mission, and must be concrete and measurable.
These may be defined in more detailed as objectives to be met by specific dates, and so on. Clearly, it is at the level of objectives and even goals where traditional project managers would feel more comfortable.
In fact, one of the early definitions of a “good” objective a la MBO (has a firm date, scope, cost, and is tangible, measurable, achievable) is about as close to the definition of a project as to being the same thing!
2 It is possibly because of the largely intangible nature of IT projects and high human content, that the use of technology and science in IT project management has been more of a challenge than a help.
Levels of Project:
Strategy Strategic Initiative Super-programme
Programme Sub-programme
------------------------------ Super-project
Project Sub-project Mini-project
2.2.5 Balanced Scorecards
Balanced scorecards is a technique that may be very effectively employed to drive the strategy implementation.
2.3 The Role of the Programme Manager
Clearly, the programme manager would not be in a position to set the business strategy. This is the task of the executive of the enterprise. Since the programme manager is not currently a typical member of this group3, he would not typically play an active role in strategy setting.
His role then should be to take the enterprise strategy and convert the strategy into a cogent set of projects (or sub-programmes) that will achieve the strategy.
Since, as with most project-related activities, this programme management is a leadership role, primary skills would include the ability to
• Discover the vision if it has not already been set
• Quantify and qualify the vision into a strategy, if this has not already been done, so that it is able to be implemented and measured
• Articulate this vision and strategy to stakeholders (note that we have suggested that these first three would not typically be the role of a programme manager – however, if no one else has done it he would have to do so, since the programme manager should typically be able to do “strategic thinking”)
• Motivate through buy-in and other stakeholder management activities, to ensure that appropriate levels of resources are allocated
• Ensure the effective deployment of the resources in the attainment of the vision
• Maintain the appropriate level of buy-in to ensure that resource allocation is not jeopardised
• Communicate on the progress towards attainment of the vision
• Make adjustments to the programme or project portfolio as required by changes in strategy or environment
• Provide oversight and mentoring to the project managers that lead the strategy-implementation projects.
The programme manager should typically take over where the strategic planner has left off. One day, as the Meta Group suggest, we may even see the enterprise programme manager actually being the owner of the enterprise strategy. Who knows, maybe future management books will even describe Jack Welch of GE as the first new-breed programme manager!
Will there be project manager who do not report to the programme manager? No question. There will continue to be projects that have the purpose of refining some aspect of operations, or that result from legislation changes or some other cause. These projects will continue to recognise the enterprise strategy, but not be driven by it.
3 Some research groups, notably the Meta Group, see this changing. They envision the time when enterprise programme management will be represented at the highest levels. However, for most of us, we shouldn’t hold our breath – since the Chief IT Officer or CIO is still struggling to make himself heard on the board in most enterprises.
3 Programme Management Office (PMO) Today, we may recognise two main models of PMO: the Centralised Management and Coaching models.
In both models, the PMO
• Maintains the IS/AD (information systems / application development) organisation’s repository of reusable artefacts such as project plan templates, estimating models, components, deliverable templates, and so on.
• Helps institute architectural standards.
• Collects and disseminates best practices (note that the standards and practices will probably be domain-specific).
• Monitors adherence to practices (through health checks, managing peer reviews and audits).
• Performs project close-out activities, including the collection of metrics such as project cost, size, quality, user satisfaction; so that these can be used to refine the enterprise project management model.
3.1 PMO Structure
3.1.1 Centralised Management PMO
This approach deals with issues of direction and control. The PMO makes decisions as to priorities, objectives, staffing and the allocation of resources.
The matters typically under its control include:
• Scope assessments
• Resource allocation
• Verification of time, budget, risk and impact assumptions.
The PMO is accountable for the allocation of enterprise resources to those projects that most closely fit the enterprise strategic objectives.
Note also in the accompanying diagram, that the Programme Management Office, interacts primarily with domain-specific programmes, although it might interact directly with some projects – for example, where a new method is being pioneered, or specific and unusual objectives are to be achieved, or a new area of business is being embarked upon, or a project that has a very high profile within the enterprise.
Clearly, this is a good approach when the enterprise process maturity levels are low (for example, an equivalent to CMM4 levels 1 or 2; or SPICE5 levels 0, 1 or 2).
4 CMM is a framework that describes the process maturity of a software organisation. It was developed on behalf of the US Department of Defence by the Software Engineering Institute at Carnegie Mellon University. The CMM, or Capability Maturity Model, describes 5 levels of capability maturity. The key characteristic of level 2 is that project management is performed as a discipline across all projects in the enterprise. Even at latest count, the majority of software organisations are still found to be at level 1. A diagram summarising the CMM model may be found at the end of this paper. 5 CMM is basically an American initiative, and whilst the scheme is used internationally, SPICE was created as the ISO equivalent. SPICE and CMM are fundamentally synonymous, with the major variant being the addition of a level 0, which describes a software organisation that does not have any formal processes in place at all.
Centralised Programme Management Office
Project managers, Project Priorities, PSPG, Methodologies, Support, Management Interface
e - business programme
… programme
ERP programme
Proj … Proj … Proj … Proj … Proj … Proj … Proj … Proj …
Centralised Programme Management Office
Project managers, Project Priorities, PSPG, Methodologies, Support, Management Interface
e - business programme
… programme
ERP programme
Proj … Proj … Proj … Proj … Proj … Proj … Proj … Proj … Proj … Proj … Proj … Proj … Proj … Proj … Proj … Proj …
The major problem when there is no effective and obvious enterprise executive management buy-in is that projects will ignore the PMO and “do their own thing”. As a consequence of enterprise executive management failure then, the value of the PMO is negated and the approach is tainted with disrepute.
3.1.2 Coaching PMO
The Coaching PMO acts mainly in the role of trainer, consultant/mentor and a source of information on project processes. The PMO may typically assist with project set up and close-out reviews, but it does not act in a directive role.
Since this variant has purely an informing and mentoring role, it is likely to be relatively ineffective where process maturity is low and project managers have a high degree of autonomy combined with little consistent direction from enterprise executive management.
One can thus conclude, that unless there is a drive from elsewhere to ensure that there is a consistent architecture, including the interaction and exchange of ideas, methods, techniques and tools between projects (i.e. there is intrinsically a high level of process maturity), this approach is not likely to be successful.
3.1.3 Hybrid PMO
Clearly, there are other models that fall between the two described above.
Whilst an enterprise should develop a model that works best for it in its given competitive environment, it is clearly better to start off with a model that is more clearly defined and that is based on a working model elsewhere.
3.1.4 Getting Started
A good principle to live by is to always start off at a known point and then move forward from there. Map readers will always locate their present position first (“you are here”), before attempting to chart the course to some future destination. If one is not at a good starting position, then a good approach is to first determine the delta to the “good starting position”, correct that first, then start.
For example, if there is insufficient enterprise executive buy-in, then that must be obtained first. If one wishes to adopt the coaching model and there is likely to be resistance from existing projects, then this resistance needs to be broken down first, or the approach should only be implemented for new projects.
3.2 PMO Activities
The following is a list of the types of function performed by a Programme Management Office: • Monitoring and reporting project progress across the enterprise • Publishing project management guidelines • Standardising project approaches • Ensuring the use of approved methodologies • Collecting, analysing and reporting on project metrics • Maintaining database of suitable metrics to improve estimating and control • Standardising project reporting • Assisting project managers with project estimating and scheduling
CoachingPMO
PM services, methods, training, mentoring, Reuse
Start & closure etc
Proj …
Proj …Proj …
Proj …
Proj …
Proj …
Proj …
CoachingPMO
PM services, methods, training, mentoring, Reuse
Start & closure etc
Proj …Proj …
Proj …Proj …Proj …Proj …
Proj …Proj …
Proj …Proj …
Proj …Proj …
Proj …Proj …
DesiredOutcomes
UndesiredOutcomes
PastExperience
PastExperience
EventsEvents
ConditionsConditions
FactorsFactors
CurrentMethodsCurrentMethods
PoliciesPolicies
InfrastructureInfrastructure
ConstraintsConstraints
Maturity ofTechnologyMaturity ofTechnology
DesiredOutcomes
UndesiredOutcomes
DesiredOutcomes
UndesiredOutcomes
PastExperience
PastExperience
EventsEvents
ConditionsConditions
FactorsFactors
CurrentMethodsCurrentMethods
PoliciesPolicies
InfrastructureInfrastructure
ConstraintsConstraints
Maturity ofTechnologyMaturity ofTechnology
• Performing functional portfolio management (for example, by sizing systems using a metric such as function points, profiles can be composed of how the enterprise is supported by systems, what the maintenance cost per normalised system is, even assist with determining what the budgeted headcount should be)
• Offering project management expertise to troubled projects • Developing and offering project manager and skills-oriented training (as required on projects) • Supplying skilled project managers to the enterprise (including developing criteria for project
manager selection and allocation to project type) • Tracking cross-functional, inter-project dependencies • Performing enterprise portfolio management (e.g. recommending cost-saving or productivity-
focused projects when the metrics indicate that such initiatives should be embarked upon) • Ensuring the project objectives are aligned with corporate strategy • Measuring achievement of strategic objectives • Creating and monitoring project contracts (ensuring that the necessary approval is received, that
projects do not continue without proper approval and so on) • Performing project health checks (as opposed to, say, ISO audits – though the PMO could
participate in scheduling and supporting audits and the certification process)
The above list should be enhanced with any additional items which should then be allocated on the basis of accountability (who ensures that it is done), responsibility (who does the work), who references (is informed about it) and who provides input.
This list can then form the basis for budgeting and sizing the Programme Management Office.
3.3 Evolution of the PMO
As discussed elsewhere in this paper, there are significant mindset, or paradigm, changes that need to take place before we can say that we have successfully reengineered the role of programmes in an enterprise.
We have also alluded to the CMM and SPICE models that consider the development and maintenance of software. Clearly, these models are valuable, but they are not inclusive enough: they focus almost completely on the development and maintenance of software, with some reference to systems (which by definition have software as one component amongst many others). The human interaction, or “person-capability”6 is largely ignored.
CMM and SPICE7 were developed on the basis of an IT paradigm, which saw applications developed as software, largely separated from the hardware and operating software, which could be regarded as interchangeable platforms. The hardware and operating software was the commodity and the difficulty was to produce the application software.
In the early days of computing, even the computer programs were part of the hardware.
Then we had a long period where software was separated from the hardware almost totally.
6 The SEI has tried to fill this gap by producing the P-CMM (People Capability Maturity Model) 1n 1995, but it does not appear to have enjoyed the same level of penetration as the process model. 7 At the beginning of 2001, SPICE was still undergoing “sea trials” and one chapter of the standard had not been approved.
Figure 1: A system as an interacting whole
Since then, microprocessors have made it possible to embed computing power into almost every device and connect them via networks so that analysis and control may be performed in real time. Since much of this software was been embedded as so-called “firmware”, it has made it more difficult to separate the software out of the system as a set of components that can be independently developed and tested.
In a typical business enterprise, the hardware and software connection may not be as close (though, if the systems are e-enabled, this is questionable), but the business process-software integration is tight.
For example, an enterprise that does business on the Internet will typically combine ERP (enterprise resource planning), CRM (customer relationships management), SCM (supply chain management) and other technologies whilst outsourcing some of its technical infrastructure to ISPs (internet service provider), ASPs (application service provider) and the like. It is hard to see where the hardware / operating software / middleware / application software / business process split actually occurs.
Thus, we suspect that CMM and SPICE are likely to start attracting criticism for being inapplicable or inadequate to deal with the complexities of systems.
However, keep in mind that CMM or SPICE will still be valuable and useful when the major objective is developing largely stand-alone software applications.
CMM has also been a useful model to describe how an enterprise may make the transition to the integrated programme management concept we have described above.
The Meta Group describes the progress through to the achievement of an EPMO (Enterprise Programme Management Office) as also being in 5 stages to the point where success is no longer a consequence of heroics but is systemic.
According to Meta, at the beginning of 2000, 80% or more of enterprises could be classed at level 1. By achieving consistency in traditional project management core competencies the enterprise would be reclassified to level 2. Level 2 is described as a stabilising stage.
Enterprises would move to level 3 because of a desire to improve performance by focusing on high payoff practices in the core project management competencies. Thus, level 3 could be described as refining and honing to achieve smooth running. This is likely to be a traumatic time for most project managers as the individual choice in tools and practices will be restricted to ensure that practices can be institutionalised.
Level 4 would see the establishment of localised Programme Offices (or Thematic Programme Management Offices) that combine related projects and allow the rationalisation of priorities and objectives, closer alignment with business unit objectives and communication with related Programme Offices. At the same time project-related practices will have become institutionalised to the extent where it is possible to optimise individual practices and have the benefit accrete to the enterprise as a whole. Managing risks is still a major focus area.
At level 5, the PMO is integrated into the business to become a corporate competency. The focus has changed from managing risk to managing value. The EPMO is able to apply “risk entrepreneurialism”, which means being able to speedily exploit environmental opportunities to the benefit of the enterprises.
This process is shown in more detail at the end of this paper.
The model is interesting for a number of reasons: • As with the CMM, the implication is that one cannot skip levels. • Also similar to CMM (which suggested that automation of software development processes was
not really feasible until CMM level 3 had been reached), attempting to institute a Programme Office prior to PMO-CMM level 3 is likely to be met with failure.
• It is large enterprises that would receive the major benefit of going all the way. • It remains to be seen how quickly enterprises can negotiate the levels. Carnegie-Mellon
University’s Software Engineering Institute, which was originally contracted by the US DoD (Department of Defence) to develop a model to evaluate the capability of software developers, has been able to follow the implementation of its model and has found that it takes approximately 27 months to move from level 1 to 2, and 19 months to move from level 2 to 3.
• The reasons for this time constraint are illustrated by two concepts: the speed of adoption of innovation; the “cycle of learning” or what we might call the journey of the professional (see diagrams at the end of this paper). Simply stated: old ideas die hard, and it takes time to develop competence.
• New methods are emerging that place a lot more control into the hands of developers (so-called “light methodologies” like x-treme programming, adaptive development, and so on). This is fine when one is still dealing with the cream of developers (after all, no one has yet been able to disprove de Marco and others’ research indicating the enormous differential between the strongest and weakest developers with regards to productivity (10:1) and quality (1:25)). How will one be able to replicate these successes in enterprises that are made up of predominantly “average” staff? Almost monthly one reads of the predicted shortfall of developers all over the world in years to come.
Peter Drucker keeps reminding us that the corporation as we know it, is only 120 years old. In fact, even “management” is a very young profession (some 50+ years old). He also tells us that the present structure is unlikely to survive for much longer. He speaks of flatter structures that are more dependent on information, on sharing, on collaboration. We often think of the present structure as having existed “for ever” and thus that it will continue to exist forever.
Some are comparing the information age to the invention of the steam engine and application of electricity. If so, then the changes to society and the way we do business are as likely to be as dramatic. The major difference is that information is invisible and subject to interpretation.
Jack Welch (CEO of General Electric) has shown, in practice, how such a new enterprise can work, by continually reinventing GE. The problem is, whenever the changes in GE are discussed, Jack Welch’s name is mentioned. This begs the question: how repeatable is the GE experience? How many Jack Welch’s are there out there? Would another, lesser mortal, be able to duplicate the successes?
The answer is probably that there was only one Newton, one Einstein. What they did was to make us aware of what is out there, and chart the course, so that “lesser mortals” could build on their vision. But, the lesser mortals have to rely on the science, on colleagues a lot more than their own personal ability.
But it is quite likely that enterprises will ultimately have no alternative but to adapt if they wish to continue to be successful.
Thus it seems we are once again faced by another one of life’s dichotomies – you must, but you can’t. Well, who said business was easy?
4 Success drivers Whilst we have described some of the factors that will drive the success of a Programme Management Office initiative, there are also others that need to be considered.
4.1.1 Principles
Principles are statements that are always true. In a general sense, principles are typically closely related to values, in that values should flow out of principles.
In an IT context, the IEEE, one of the major standards-setting bodies in the world, has commissioned a study to identify the principles of software development.
The initial results of the first two stages of the study (stage I was to draw up such a list; Stage II to have it reviewed by the top practitioners in the world; and Stage III to invite members of the IEEE Computer Society to review the list) identified the following principles that had a consensus of more than two thirds: • Invest in understanding the problem. • Since change is inherent in any software project, plan for it and manage it. • Since uncertainty is unavoidable, identify the uncertainties and manage them. • Minimise component interaction (the age-old factors of high cohesion and low binding). • Tradeoffs are inherent to any software project, they should be made explicit and documented.
• Design should be improved by studying prior solutions to the same or similar problems.
There was high consensus (more than 60%) for the items listed above. The following did not experience the same degree of consensus (the last items in the list could therefore be reasonably excluded from being “principles”): • Complexity should be controlled with multiple levels of abstraction & perspectives • Software should be produced in a stepwise fashion • Software artefacts should be defined rigorously • Flexible software processes should be established • Quality should be managed throughout the life cycle as formally as possible • Quality objectives should be set for each deliverable • A disciplined approach should be implemented and improved continuously • Software should be built with and for reuse • Quantitative measurement should be applied in decision making
Whilst one might disagree with the list, it does provide a useful starting point.
4.2 Standards
Standards provide quantifiable implementations of principles and are most effective when they are few and domain-specific.
A good example is the 10 Commandments. One reason they have stood the test of time is that there are only 10 and they articulate first principles – they can continue to be true in any society and age.
A software standard typically consists of a set of processes, activities, and tasks designed to be tailored in respect of software projects. Tailoring involves the deletion of non-applicable processes, activities, and tasks. Addition of unique or special processes, activities, and tasks should typically be dealt with by providing for this in the contract or project charter and be confirmed in the project plan8.
Compliance with a standard is defined as the conformance to all the processes, activities, and tasks selected in the tailoring process for the software project. The performance of a process or an activity is complete when all the required tasks have been performed in accordance with the pre-established criteria and the requirements specified in the contract (or project charter) and confirmed or elaborated in the project plan.
Standards are mandatory practices that are often designated in ISO terminology by the words “shall” (describing binding provisions between two or more parties) and “will” (describing declarations of purpose or intent made by one party).
Standards should be supplemented by recommended practices and guidelines. Recommended practices are usually designated in ISO terminology by the word “should”.
Finally, good practices are usually designated in ISO terminology by the word “may”.
4.2.1 Practices
In 1995, a team of the most notable software personalities in the USA was assembled and designated as the Airlie Software Council. They produced a summary of what has become known as the 9 “best practices” and 9 “worst practices”. In turn, this developed into a list of the 16 critical software practices for performance-based management.
The 16 practices are grouped three areas of project integrity, construction integrity and product stability and integrity. Each practice needs to be formally recognised in the processes, activities and tasks that have been defined for different system solution domains.
8 Where there is a contract, it should lay out in unambiguous terms what the responsibilities of each party are and what the outcomes are to be. Within an enterprise, it is not typical to have contracts between project sponsors and other management groups and projects. The contract would typically focus on the relationship between the customer and supplier. Instead, a Project Charter would authorise a project manager to consume enterprise resources to achieve a designated outcome and a Project Plan would describe how the project manager would achieve this.
Project Integrity 1. Adopt continuous programme risk management 2. Estimate cost and schedule empirically 3. Use metrics to manage 4. Track earned value 5. Track defects against quality targets 6. Treat people as the most important resources
Construction Integrity 7. Adopt life cycle configuration management 8. Manage and trace requirements 9. Use system-based software design 10. Ensure data and database interoperability 11. Define and code interfaces 12. Design twice, code once 13. Assess reuse risks and costs
Product Stability and Integrity 14. Inspect requirements and design 15. Manage testing as a continuous process 16. Compile and smoke test frequently
4.2.2 Processes
Processes that are specific to the application domain (the environment in which the system is to operate, and the aspects that it is to address) and the solution domain (the environment in which the system is to be developed, and how it will work) need to be developed and devolved.
One, largely discredited approach, has been to buy a so-called “big-M” methodology. A decade ago, there were many of these and sold with questionable results. The successful ones have changed into “process repositories” which allow practitioners to begin with a format and build on that.
Another approach – especially where the domain involves emerging technology and business (e.g. CRM, SCM, e-business) might be to make a process, based on the experiences of practitioners and pilot that approach before rolling out aspects of it to other projects.
4.3 Management Direction, Control and Support
4.3.1 Management Approach
Gartner Group has suggested three classes of project, in addition to “must-do projects” (projects that have no value in themselves, but have to be done. For example, projects required to conform to legislation.)
The main aim of Cost-focused projects is to reduce operating expenses. For example, when two systems are combined into one, thus reducing maintenance load, expertise requirements, duplication, and so on.
Productivity projects aim to improve efficiency in addition to driving down costs.
Opportunity projects form the basis for true competitive advantage. They would include implementation of new technologies or methods (e.g. an ERP or CRM system).
Gartner further suggests that the risk and rewards increase for each of the three classes. In addition, a balanced portfolio of projects should represent a ratio of 65 : 30 : 5, for each of the three. For the sake of management, must-do projects should be classed with opportunity projects.
Finally, Gartner suggests that different management methods should form the basis for each of the classes: • Rule-Based; Go/Stop: cost-focused projects should be managed by IS/IT project managers,
according to clear guidelines, operated by the sponsor, project manager and relationship manager, setting out how and how often projects are reviewed, and how they are approved to continue or
cancelled when the business case has weakened. Cancellation or objectives redefinition in this context would be seen as an acceptable outcome, and not failure.
• Reassessment and Resurrection: productivity projects could be IS/IT-managed, but they would require active support and buy-in of a business manager, since they will inevitably impact on business processes. Whilst it is less likely that these projects would be cancelled (how does one handle a partially-implemented business process change?), management should focus on reassessing needs and benefits, then reshaping the project to recognise these perspectives. Phasing of deliverables, change control and critical reviews are thus a key aspects of this class of project.
• Active Business Management: opportunity projects should be managed by a business manager. They are focused much more on people and process issues than on technology. As was experienced with many ERP projects, the problem with such projects being managed by the business is that many managers are not capable as project managers, nor do they have the time to focus on the project (after all, they have the existing business to run). A happy medium must thus be found, where, for instance, the business manager maintains accountability, but has a professional project manager who sees to the day-to-day activities. Reviews can be the monthly for smoothly-running projects to daily action planning sessions for projects that are in trouble. There is also usually a window of opportunity for these projects and they are thus typically time-critical.
It should be evident how a Programme Management Office can support the different classes of project.
4.3.2 Qualities of the Project Manager
Whilst there has always been a lot of anecdotal evidence of what the qualities of a “good” project manager are, and there has been empirical research to describe what these qualities might be, the problem solution is still an unsatisfactory one. For example, if one had to find a project managers who conformed to all the criteria, one would be searching for a being that does not exist in the human plane.
What does appear to be undisputed is that the project manager will have a great influence on a project’s chances of success.
The IPMA (International Project Management Association) has developed a list of attributes that it uses to certify project managers. Whilst being a good start, the list has been criticised as being unrealistic and does not take into account the nature of the project domain.
Some pointers do exist out of research that has been done: one example is the IPMA list, viewed in context; another is the research that has been done in terms of the influence of personality type (for example, Jungian temperament, or the Myers-Briggs Type Indicator) on project manager style and a recently-published research project that has considered different types of project manager in different domains and the set of criteria that determine success or failure in a given situation.
In any event, there needs to be a process that ensures that a junior, ill-equipped project manager is not assigned to a high profile, large, complex and difficult project.
4.3.3 Project Management Process
PMI (Project Management Institute), whose PMBOK (Project Management Body of Knowledge) has been widely circulated and adopted as a standard by many influential bodies, describes five project management processes that are fundamental to project success: Initiating, Planning, Executing, Controlling and Closing.
In addition, it has described nine knowledge areas: project integration management, project scope management, project time management, project cost management, project quality management, project human resource management, project communications management, project risk management and project procurement management.
There clearly many differences that set Software, or IT project management apart from “traditional” project management. However, there are many similarities, and where these similarities exist, the emphasis should be on tapping into the existing knowledge base, rather than reinventing the wheel. What’s more, more effort should be put into identifying and exploiting these similarities.
4.4 PMO vs. PO Tasks
The following table summarises some of the typical activities, and where they should reside
Task PMO PO Align project objectives to enterprise strategy
Day-to-day project management
Assigning resources to projects
Developing project plans
Developing project charter
Reporting to enterprise steering committee
Coordination between projects
Coordination inside projects
Project / stakeholder communication
Establishment of enterprise-level standards, policies, etc
4.5 Typical PO Activities
Cleland defines a Project Office as “a collection of project functions that serve managers in the performance of their duties. It relieves project managers of routine, critical functions whiles establishing consistent and uniform practices in the functions performed. It may also serve as a central repository that “contracts out” to line organisations.”
The table below summarises the typical activities that could be found within a PO. Area Service Project planning Maintain methodology framework and domain variations
Create templates Store lessons learned Maintain metrics database Lead sizing workshops Consult on estimation
Auditing Create checklists for each milestone Perform reviews (soft audits) Advise on rectification of audit issues Maintain corrective action logs Coordinate external audits
Project Control Support change control (maintain logs, classify, follow up, perform statistical analysis) Verify closure of issues Manage time sheets Assist with progress analysis and do report (and perform consolidation for multiple projects) Assist with progress reporting
Project Team Support Support teambuilding exercises Do mentoring and coaching
Skills Development Assess project requirements personal attributes Influence training and hiring Participate in performance evaluations Assist with training and continuous learning
Process Maintenance Maintain PM methodology Identify general process training requirements Maintain Policies, Standards, Practices and Guidelines for PM Institutionalise PM
Tools Conduct needs assessments Evaluate tool adequacy and compatibility with project needs Manage selection and acquirement of new tools Coordinate tool training Provide 2nd-line support on tools
Executive Support Participate in projects priority setting
Participate in cross-project resource allocation Consult to executive management on PM
Risk Management Conduct ongoing risk assessment, and quantification Assist with mitigation planning Assist with risk tracking and risk closure Assist with contingency planning
Communication Assist with communication plan Create communication items for 2nd line (+) stakeholders Conduct stakeholder communication events
Documentation Maintain MRC (master records centre) Follow-up storing of documents Ensure that critical documents are baselined and signed off
Scheduling Assist with preparing project schedules Review schedule progress
Cost Assist with budget preparation Quality Management Prepare QA/QC plans
Support testing activities Maintain test records
Project office function descriptions often include tasks like • Collecting status data for the purpose of progress and status reporting • Project status analysis and distillation • Writing of status reports • Performing risk management activities
Take care in what is taken away from (specifically IS and to a lesser extent IT) project managers. Unlike most other industries (e.g. construction, engineering, etc.) where there are many tangible deliverables that may be relatively easy to measure, and there is a firm basis of science underlying the making of the deliverables (e.g. the principles of bridge building, including the strength of materials, etc.), IS projects are largely intangible – the deliverable products cannot easily be measured (mostly, one observes the reaction of the product in different circumstances and then draws calculated conclusions as to the quality, completeness and readiness of the product). It is generally accepted that it is impossible to test most software products fully and completely.
Very often, digging into the detail is the only way the project manager will arrive at a realistic opinion of the status of the project. Even if “science” is used in the calculation of, say, an earned value graph, the fact is that much of the data that the graph is based on could be suspect.
Thus, one should be careful about which tasks are handed over to a third party, such as a project office, as opposed to what should be done by the project manager himself. However, he may obviously be assisted in doing this by the project office.
5 The Future of the PMO Clearly, there is a period of transition which mega-project management/ programme management will need to bridge until acceptance of the concept becomes widespread, sufficient levels of expertise are achieved and the profession has matured.
What is one to do in the interim?
Aside from these practical aspects, there are also some other challenges: for example, an enterprise enters into an outsourcing agreement with a vendor, but does not have the programme management skill internally, nor does it wish to appoint such a position as permanent staff, because the activity will not be ongoing. Making use of programme management resources from the outsourcer is likely to lead to a conflict of interest.
The answer may lie in the construction and engineering industries. There, specialist concerns that do project management as their core line of business are commonplace.
References to Selected Works Dinsmore, Paul C. 1999. Winning in Business with Enterprise Project Management. New York: Amacom.
ISBN 0 8144 0420 0.
Frame, J Davidson. Project Management Competence: Building key skills for individuals, teams and organisations. San Francisco: Jossey-Bas Publishers. ISBN 0 7879 4662 1.
Wysocki, Robert K. 2002. Building Effective Project Teams. New York: John Wiley & Sons. ISBN 0 471 01392 7. This book has an extensive coverage of personality and other soft factors that influence successful project teams. A disadvantage is that it relies heavily on assessment tools that must be purchased from the USA. Significant are the classification of projects and the competence level required per class.
Elmar Roberg, President of the Computer Society of South Africa, CSSA. Elmar Roberg is President of the Computer Society of South Africa, and outgoing VP: Projects and SIGs, PMISA. He is also Chairman of System Crafters Guild (Pty) Ltd. Elmar has over 30 years of experience in the IT industry, more that 25 of which have been spent as a project manager, mentor, consultant and teacher.
The
diag
ram
atte
mpt
s to
com
bine
the
esse
ntia
l el
emen
ts o
f pro
gram
me
man
agem
ent.
Alon
g th
e to
p ar
e th
e di
ffere
nt a
reas
of c
ompe
tenc
e th
at n
eed
to b
e ad
dres
sed
from
a p
roje
ct
man
agem
ent p
ersp
ectiv
e.
The
side
sum
mar
ises
the
diffe
rent
sta
ges
of th
e sy
stem
s en
gine
erin
g lif
e cy
cle
(whe
re a
sys
tem
nee
d no
t nec
essa
rily
be m
ade
up o
f tec
hnol
ogy
and
softw
are)
. Th
e fro
nt s
umm
aris
es th
e “g
over
nanc
e” m
easu
res
that
mus
t be
appl
ied
or b
e in
pla
ce.
A P
rogr
amm
e M
anag
emen
t Fra
mew
ork
Policies
Standards
Procedures
Guidelines
Life Cycles
Practices
Techniques
Tools
Measures
Policies
Standards
Procedures
Guidelines
Life Cycles
Practices
Techniques
Tools
Measures
Inte
grat
ion
Mgt
Scop
e M
gtTi
me
MgtC
ost M
gtQ
ualit
y M
gtHR
Mgt
Com
mun
icat
ions
Mgt
Ris
k M
gtPr
ocur
emen
t Mgt
Inte
grat
ion
Mgt
Scop
e M
gtTi
me
MgtC
ost M
gtQ
ualit
y M
gtHR
Mgt
Com
mun
icat
ions
Mgt
Ris
k M
gtPr
ocur
emen
t Mgt
Requ
irem
ents
Arch
itect
ure
Deta
iled
Desig
nCo
nstru
ctio
nIn
tegr
atio
nTe
stin
gIn
stall
atio
nOp
erat
ion
Retir
emen
t
Requ
irem
ents
Arch
itect
ure
Deta
iled
Desig
nCo
nstru
ctio
nIn
tegr
atio
nTe
stin
gIn
stall
atio
nOp
erat
ion
Retir
emen
t
Prog
ram
me
Man
agem
ent F
ram
ewor
k
PMI P
MB
OK
Pro
ject
Man
agem
ent P
roce
ss
Initi
atin
g P
roce
sses
Initi
atio
n
Cor
e P
roce
sses
Sco
peP
lann
ing
Sco
peD
ef'n
Cos
tB
udge
t
Sch
edD
ev't
Cos
tE
stim
Act
ivity
Dur
Est
Act
ivity
Seq
u
Res
ourc
eP
lann
ing
Act
ivity
Def
'n
Qua
lity
Pla
nnin
gO
rgP
lann
ing
Sol
icit'
nP
lann
ing
Ris
kQ
uant
if'n
Pro
curm
tP
lann
ing
Ris
kR
esp
Pla
nnin
g
Ris
kId
ent'n
Sta
ffA
cqui
s'n
Com
mun
Pla
nnin
g
Faci
litat
ing
Pro
cess
es
Pla
nnin
g P
roce
sses
Pro
j Pla
nE
xecu
t'n
Info
Dis
trib
'n
Sol
icita
t'n
Con
trac
tA
dmin
Qya
lity
Ass
urS
cope
Ver
if'n
Sou
rce
Sel
ectio
n
Tea
mD
ev'm
t
Faci
litat
ing
Pro
cess
es
Exe
cutin
g P
roce
sses
Initi
atio
nPer
form
Rep
ort'g
Sco
peC
hg C
tl
Qua
lity
Con
trol
Cos
tC
ontr
ol
Ris
kM
onito
r &
Ctl
Sch
edul
eC
ontr
ol
Faci
litat
ing
Pro
cess
es
Con
trol
ling
Pro
cess
es
Ove
rall
Chg
Ctl
Clo
sing
Pro
cess
es
Con
trac
tC
lose
-out
Adm
inis
trC
losu
re
Pro
j Pla
nD
ev't
Ris
kM
gt P
lan
Ris
kA
sses
sm
SEI C
MM
(Cap
abili
ty M
atur
ity M
odel
)
1In
itial
The
proc
ess
is c
hara
cter
ised
as
ad h
oc, a
nd o
ccas
iona
lly
even
cha
otic
. Few
pro
cess
es a
re d
efin
ed, a
nd s
ucce
ss
depe
nds
on in
divi
dual
effo
rt an
d he
roics
.
2R
epea
tabl
eBa
sic
PM p
roce
sses
are
est
ablis
hed
to tr
ack
cost
, sc
hedu
le a
nd fu
nctio
nalit
y. N
eces
sary
pro
cess
di
scip
line
is in
pla
ce to
repe
at e
arlie
r suc
cess
es o
n pr
ojec
ts w
ith s
imila
r app
licat
ions
.
3D
efin
ed
Proc
ess
for m
gt &
eng
inee
ring
is
docu
men
ted,
sta
ndar
dise
d, in
tegr
ated
in
to a
std
s/w
pro
cess
for t
he o
rg. A
ll pr
ojec
ts u
se a
n ap
prov
ed, t
ailo
red
vers
ion
of th
e or
g’s
s/w
pro
cess
.
4M
anag
ed
Det
aile
d m
easu
res
of th
e s/
w pr
oces
s an
d pr
oduc
t qua
lity
are
colle
cted
. Bot
h s/
w pr
oces
s an
d pr
oduc
ts a
re q
uant
itativ
ely
unde
rsto
od &
con
trolle
d.
5O
ptim
isin
gC
ontin
uous
pro
cess
impr
ovem
ent i
s en
able
d by
qua
ntita
tive
feed
back
from
the
proc
ess
and
from
pilo
ting
inno
vativ
e id
eas
and
tech
nolog
ies.
Pred
icta
ble
Proc
ess
Qua
ntita
tive
proc
ess
man
agem
ent
Sof
twar
e qu
ality
man
agem
ent
Con
tinuo
usly
Impr
ovin
g Pr
oces
s
Def
ect p
reve
ntio
nTe
chno
logy
cha
nge
mgt
Pro
cess
cha
nge
mgt
Rqm
tsm
gtP
roje
ct p
lann
ing
Pjt
rack
ing
& o
vers
ight
Sub
cont
ract
mgt
Qua
lity
assu
ranc
eC
onfig
urat
ion
mgt
Dis
cipl
ined
Pro
cess
27
Std
Cons
iste
nt P
roce
ss
Org
pro
cess
focu
sO
rg p
roce
ss d
efin
ition
Trai
ning
pro
gram
me
Inte
grat
ed s
oftw
are
man
agem
ent
Sof
twar
e pr
oduc
t eng
inee
ring
Inte
rgro
upco
-ord
inat
ion
Pee
r rev
iew
s
19
1In
itial
The
proc
ess
is c
hara
cter
ised
as
ad h
oc, a
nd o
ccas
iona
lly
even
cha
otic
. Few
pro
cess
es a
re d
efin
ed, a
nd s
ucce
ss
depe
nds
on in
divi
dual
effo
rt an
d he
roics
.
1In
itial
The
proc
ess
is c
hara
cter
ised
as
ad h
oc, a
nd o
ccas
iona
lly
even
cha
otic
. Few
pro
cess
es a
re d
efin
ed, a
nd s
ucce
ss
depe
nds
on in
divi
dual
effo
rt an
d he
roics
.
2R
epea
tabl
eBa
sic
PM p
roce
sses
are
est
ablis
hed
to tr
ack
cost
, sc
hedu
le a
nd fu
nctio
nalit
y. N
eces
sary
pro
cess
di
scip
line
is in
pla
ce to
repe
at e
arlie
r suc
cess
es o
n pr
ojec
ts w
ith s
imila
r app
licat
ions
.
2R
epea
tabl
eBa
sic
PM p
roce
sses
are
est
ablis
hed
to tr
ack
cost
, sc
hedu
le a
nd fu
nctio
nalit
y. N
eces
sary
pro
cess
di
scip
line
is in
pla
ce to
repe
at e
arlie
r suc
cess
es o
n pr
ojec
ts w
ith s
imila
r app
licat
ions
.
3D
efin
ed
Proc
ess
for m
gt &
eng
inee
ring
is
docu
men
ted,
sta
ndar
dise
d, in
tegr
ated
in
to a
std
s/w
pro
cess
for t
he o
rg. A
ll pr
ojec
ts u
se a
n ap
prov
ed, t
ailo
red
vers
ion
of th
e or
g’s
s/w
pro
cess
.
3D
efin
ed
Proc
ess
for m
gt &
eng
inee
ring
is
docu
men
ted,
sta
ndar
dise
d, in
tegr
ated
in
to a
std
s/w
pro
cess
for t
he o
rg. A
ll pr
ojec
ts u
se a
n ap
prov
ed, t
ailo
red
vers
ion
of th
e or
g’s
s/w
pro
cess
.
4M
anag
ed
Det
aile
d m
easu
res
of th
e s/
w pr
oces
s an
d pr
oduc
t qua
lity
are
colle
cted
. Bot
h s/
w pr
oces
s an
d pr
oduc
ts a
re q
uant
itativ
ely
unde
rsto
od &
con
trolle
d.
4M
anag
ed
Det
aile
d m
easu
res
of th
e s/
w pr
oces
s an
d pr
oduc
t qua
lity
are
colle
cted
. Bot
h s/
w pr
oces
s an
d pr
oduc
ts a
re q
uant
itativ
ely
unde
rsto
od &
con
trolle
d.
5O
ptim
isin
gC
ontin
uous
pro
cess
impr
ovem
ent i
s en
able
d by
qua
ntita
tive
feed
back
from
the
proc
ess
and
from
pilo
ting
inno
vativ
e id
eas
and
tech
nolog
ies.
5O
ptim
isin
gC
ontin
uous
pro
cess
impr
ovem
ent i
s en
able
d by
qua
ntita
tive
feed
back
from
the
proc
ess
and
from
pilo
ting
inno
vativ
e id
eas
and
tech
nolog
ies.
Pred
icta
ble
Proc
ess
Qua
ntita
tive
proc
ess
man
agem
ent
Sof
twar
e qu
ality
man
agem
ent
Con
tinuo
usly
Impr
ovin
g Pr
oces
sC
ontin
uous
ly Im
prov
ing
Proc
ess
Def
ect p
reve
ntio
nTe
chno
logy
cha
nge
mgt
Pro
cess
cha
nge
mgt
Rqm
tsm
gtP
roje
ct p
lann
ing
Pjt
rack
ing
& o
vers
ight
Sub
cont
ract
mgt
Qua
lity
assu
ranc
eC
onfig
urat
ion
mgt
Dis
cipl
ined
Pro
cess
27
Std
Cons
iste
nt P
roce
ss
Org
pro
cess
focu
sO
rg p
roce
ss d
efin
ition
Trai
ning
pro
gram
me
Inte
grat
ed s
oftw
are
man
agem
ent
Sof
twar
e pr
oduc
t eng
inee
ring
Inte
rgro
upco
-ord
inat
ion
Pee
r rev
iew
s
19
The
Met
a G
roup
PM
O -
CM
M
Ent
erpr
ise
/ Ind
ustry
Inte
grat
ion
with
bu
sine
ss
Val
ue m
anag
emen
t, B
usin
ess
cont
inui
ty p
lann
ing,
P
rocu
rem
ent m
anag
emen
t, O
utso
urci
ng &
con
tract
m
anag
emen
t, P
M c
entre
of e
xcel
lenc
e5
Inco
rpor
’d
Mul
tiple
bu
sine
ss
units
Dyn
amic
mic
ro-le
vel
chan
ge
Pro
gram
me
proc
ess
man
agem
ent,
Pro
ject
inte
grat
ion
man
agem
ent,
Pro
ject
per
from
ance
man
agem
ent,
Ven
dor
man
agem
ent,
PM
car
eer p
ath,
Sta
ff pe
rform
ance
m
anag
emen
t, C
usto
mer
rela
tions
hip
man
agem
ent,
Con
tinge
ncy
man
agem
ent,
Com
mun
icat
ions
man
agem
ent
4M
anag
ed
Acq
uirin
g ne
w p
roje
ct m
anag
ers
1 In
itial
Sin
gle
proj
ect
Sta
bilis
e pe
rform
ance
Pla
nnin
g, E
stim
atin
g, T
rack
ing,
Ris
k id
entif
icat
ion,
Sch
edul
e m
anag
emen
t, B
udge
t/ co
st m
anag
emen
t, S
cope
m
anag
emen
t, P
rogr
ess
repo
rting
2S
tabl
e
Mul
tiple
pr
ojec
tsS
tatic
mac
ro-le
vel
chan
ge
Pro
ject
man
agem
ent m
etho
dolo
gy, S
kills
man
agem
ent,
Pro
ject
man
ager
trai
ning
, Ris
k m
anag
emen
t, C
hang
e m
anag
emen
t, S
taff
reso
urce
man
agem
ent,
Env
ironm
ent
reso
urce
man
agem
ent,
Con
flict
/ Iss
ue m
anag
emen
t
3D
efin
ed
Effe
ctiv
e Sp
anSt
rate
gic
Infle
ctio
n Po
ints
Key
Pro
cess
Are
a Co
ncen
tratio
nsM
atur
ity
Leve
l
Ent
erpr
ise
/ Ind
ustry
Inte
grat
ion
with
bu
sine
ss
Val
ue m
anag
emen
t, B
usin
ess
cont
inui
ty p
lann
ing,
P
rocu
rem
ent m
anag
emen
t, O
utso
urci
ng &
con
tract
m
anag
emen
t, P
M c
entre
of e
xcel
lenc
e5
Inco
rpor
’d
Mul
tiple
bu
sine
ss
units
Dyn
amic
mic
ro-le
vel
chan
ge
Pro
gram
me
proc
ess
man
agem
ent,
Pro
ject
inte
grat
ion
man
agem
ent,
Pro
ject
per
from
ance
man
agem
ent,
Ven
dor
man
agem
ent,
PM
car
eer p
ath,
Sta
ff pe
rform
ance
m
anag
emen
t, C
usto
mer
rela
tions
hip
man
agem
ent,
Con
tinge
ncy
man
agem
ent,
Com
mun
icat
ions
man
agem
ent
4M
anag
ed
Acq
uirin
g ne
w p
roje
ct m
anag
ers
1 In
itial
Sin
gle
proj
ect
Sta
bilis
e pe
rform
ance
Pla
nnin
g, E
stim
atin
g, T
rack
ing,
Ris
k id
entif
icat
ion,
Sch
edul
e m
anag
emen
t, B
udge
t/ co
st m
anag
emen
t, S
cope
m
anag
emen
t, P
rogr
ess
repo
rting
2S
tabl
e
Mul
tiple
pr
ojec
tsS
tatic
mac
ro-le
vel
chan
ge
Pro
ject
man
agem
ent m
etho
dolo
gy, S
kills
man
agem
ent,
Pro
ject
man
ager
trai
ning
, Ris
k m
anag
emen
t, C
hang
e m
anag
emen
t, S
taff
reso
urce
man
agem
ent,
Env
ironm
ent
reso
urce
man
agem
ent,
Con
flict
/ Iss
ue m
anag
emen
t
3D
efin
ed
Effe
ctiv
e Sp
anSt
rate
gic
Infle
ctio
n Po
ints
Key
Pro
cess
Are
a Co
ncen
tratio
nsM
atur
ity
Leve
l
Met
a Gr
oup
Inc,
200
0
Com
paris
on o
f Mod
els
CM
M
Peo
ple-
CM
M
SE-C
MM
B
erke
ley
Met
a In
itial
Th
e pr
oces
s is
cha
ract
eris
ed a
s ad
ho
c, a
nd o
ccas
iona
lly e
ven
chao
tic.
Few
pro
cess
es a
re d
efin
ed, a
nd
succ
ess
depe
nds
on in
divi
dual
effo
rt an
d he
roic
s.
Key
focu
s fo
r im
prov
emen
t: di
scip
lined
pro
cess
es
Initi
al
Focu
s on
inst
illing
bas
ic d
isci
plin
e in
w
orkf
orce
act
iviti
es
Perf
orm
ed In
form
ally
Ba
se p
ract
ices
are
per
form
ed
Ad-H
oc
No
form
al p
roce
dure
s or
pla
ns.
Activ
ities
poo
rly–d
efin
ed a
nd
estim
ated
. No
syst
emat
ic c
olle
ctio
n or
use
of P
M d
ata.
Unp
redi
ctab
le
proc
esse
s w
ith p
oor c
ontro
l. In
cons
iste
nt u
se o
f PM
tool
s an
d te
chni
ques
. Su
cces
s us
ually
bec
ause
of p
erso
nal
hero
ics.
Initi
al
Acqu
iring
new
pro
ject
man
ager
s K
ey fo
cus
for i
mpr
ovem
ent:
Stab
ilise
perfo
rman
ce
Rep
eata
ble
Basi
c PM
pro
cess
es a
re e
stab
lishe
d to
trac
k co
st, s
ched
ule
and
func
tiona
lity.
Nec
essa
ry p
roce
ss
disc
iplin
e is
in p
lace
to re
peat
ear
lier
succ
esse
s on
pro
ject
s w
ith s
imila
r ap
plic
atio
ns.
Rqm
ts m
gt. P
roje
ct p
lann
ing.
Pj
track
ing
& ov
ersi
ght.
Subc
ontra
ct
mgt
. Qua
lity
assu
ranc
e. C
onfig
urat
ion
mgt
K
ey fo
cus
for i
mpr
ovem
ent:
Stan
dard
con
sist
ent p
roce
sses
Rep
eata
ble
Form
al p
ract
ices
are
impl
emen
ted
re
late
d to
wor
k en
viro
nmen
t, co
mm
unic
atio
n, s
taffi
ng,
perfo
rman
ce m
anag
emen
t, tra
inin
g,
com
pens
atio
n Fo
cus
on id
entif
ying
prim
ary
com
pete
ncie
s an
d al
ign
wor
kfor
ce
activ
ities
with
them
.
Plan
ned
& T
rack
ed
Com
mitt
ing
to p
erfo
rm
Plan
ning
per
form
ance
D
isci
plin
ed p
erfo
rman
ce
Trac
king
per
form
ance
Ve
rifyi
ng p
rform
ance
Plan
ned
Info
rmal
and
inco
mpl
ete
proc
esse
s.
PM p
robl
ems
are
iden
tifie
d bu
t not
do
cum
ente
d or
act
ione
d. P
M d
ata
colle
ctio
n an
d an
alys
is is
info
rmal
. Pa
rtial
reco
gniti
on a
nd c
ontro
l of P
M
proc
esse
s. In
divi
dual
her
oics
stil
l pl
ays
larg
e ro
le.
Focu
s on
team
s: s
treng
ths
gain
ed in
pr
evio
us p
roje
cts
are
repe
ated
. New
sc
enar
ios
tend
to re
vert
back
to le
vel
1.
Stab
le
Plan
ning
, Est
imat
ing,
Tra
ckin
g, R
isk
iden
tific
atio
n, S
ched
ule
man
agem
ent,
Budg
et/ c
ost m
anag
emen
t, Sc
ope
man
agem
ent,
Prog
ress
repo
rting
K
ey fo
cus
for i
mpr
ovem
ent:
Stab
ilise
perfo
rman
ce
Def
ined
Pr
oces
s fo
r mgt
& e
ngin
eerin
g is
do
cum
ente
d, s
tand
ardi
sed,
inte
grat
ed
into
a s
td s
/w p
roce
ss fo
r the
org
. All
proj
ects
use
an
appr
oved
, tai
lore
d ve
rsio
n of
the
org’
s s/
w p
roce
ss.
Org
pro
cess
focu
s. O
rg p
roce
ss
defin
ition
. Tra
inin
g pr
ogra
mm
e.
Inte
grat
ed s
oftw
are
man
agem
ent.
Softw
are
prod
uct e
ngin
eerin
g.
Inte
rgro
up c
o-or
dina
tion.
Pee
r re
view
s K
ey fo
cus
for i
mpr
ovem
ent:
pred
icta
ble
proc
esse
s
Def
ined
Kn
owle
dge
and
skills
ana
lysi
s,
wor
kfor
ce p
lann
ing,
com
pete
ncy
deve
lopm
ent,
care
er d
evel
opm
ent,
com
pete
ncy-
base
d pr
actic
es,
parti
cipa
tory
cul
ture
. Fo
cus
on q
uant
itativ
ely
man
agin
g or
g gr
owth
in w
orkf
orce
cap
abilit
ies
and
esta
blis
h co
mpe
tenc
y-ba
sed
team
s.
Wel
l-Def
ined
D
efin
ing
a st
anda
rd p
roce
ss
Tailo
ring
the
stan
dard
pro
cess
U
sing
dat
a Pe
rform
ing
the
desi
gned
pro
cess
Man
aged
Pr
oces
ses
have
bec
ome
mor
e ro
bust
an
d de
mon
stra
te s
yste
mat
ic p
lann
ing
and
cont
rol.
Mos
t PM
pro
blem
s ar
e id
entif
ied
and
docu
men
ted
info
rmal
ly. P
M d
ata
is
colle
cted
and
use
d ac
ross
the
orga
nisa
tion.
Dat
a is
ana
lyse
d an
d tre
nds
anal
ysed
and
sha
red.
In
tegr
atio
n of
cro
ss-fu
nctio
nal t
eam
s.
Def
ined
Pr
ojec
t man
agem
ent m
etho
dolo
gy,
Skills
man
agem
ent,
Proj
ect m
anag
er
train
ing,
Ris
k m
anag
emen
t, C
hang
e m
anag
emen
t, St
aff r
esou
rce
man
agem
ent,
Envi
ronm
ent r
esou
rce
man
agem
ent,
Con
flict
/ Iss
ue
man
agem
ent
Key
focu
s fo
r im
prov
emen
t: St
atic
m
acro
-leve
l cha
nge
Man
aged
D
etai
led
mea
sure
s of
the
s/w
pro
cess
an
d pr
oduc
t qua
lity
are
colle
cted
. Bo
th s
/w p
roce
ss a
nd p
rodu
cts
are
quan
titat
ivel
y un
ders
tood
&
cont
rolle
d.
Man
aged
M
ento
ring,
team
bui
ldin
g, te
am-
base
d pr
actic
es, o
rg c
ompe
tenc
y m
anag
emen
t, or
g pe
rform
ance
al
ignm
ent.
Focu
s on
con
tinuo
usly
impr
ovin
g
Qua
ntita
tivel
y C
ontro
lled
Esta
blis
hing
mea
sura
ble
qual
ity
goal
s D
eter
min
ing
proc
ess
capa
bilit
y to
ac
hiev
e go
als
Inte
grat
ed
PM p
roce
sses
are
form
al. A
ble
to
cond
uct m
ultip
le p
roje
cts
conc
urre
ntly
. Stro
ng te
amw
ork
cultu
re. P
M tr
aini
ng fu
lly p
lann
ed,
prov
ided
to e
ntire
org
anis
atio
n.
Inte
grat
edPM
proc
esse
sfu
lly
Man
aged
Pr
ogra
mm
e pr
oces
s m
anag
emen
t, Pr
ojec
t int
egra
tion
man
agem
ent,
Proj
ect p
erfro
man
ce m
anag
emen
t, Ve
ndor
man
agem
ent,
PM c
aree
r pa
th, S
taff
perfo
rman
ce m
anag
emen
t, C
usto
mer
rela
tions
hip
man
agem
ent
Qua
ntita
tive
proc
ess
man
agem
ent
Softw
are
qual
ity m
anag
emen
t K
ey fo
cus
for i
mpr
ovem
ent:
cont
inuo
usly
impr
ovin
g pr
oces
ses
met
hods
for d
evel
opin
g pe
rson
al a
nd
org
com
pete
nce.
O
bjec
tivel
y m
anag
ing
perfo
rman
ce
In
tegr
ated
PM
pro
cess
es fu
lly
impl
emen
ted.
Ef
ficie
nt p
lann
ing,
man
agin
g,
inte
grat
ing
and
cont
rol o
f mul
tiple
pr
ojec
ts. D
ata
is s
tand
ardi
sed,
sto
red
in a
dat
a ba
se fo
r effe
ctiv
e an
alys
is
and
proc
essi
ng. C
olle
cted
dat
a is
us
ed to
ant
icip
ate
and
prev
ent
adve
rse
prod
uctiv
ity a
nd q
ualit
y im
pact
. Bas
is fo
r fac
tual
dec
isio
n-m
akin
g is
est
ablis
hed.
Cus
tom
er re
latio
nshi
p m
anag
emen
t, C
ontin
genc
y m
anag
emen
t, C
omm
unic
atio
ns m
anag
emen
t K
ey fo
cus
for i
mpr
ovem
ent:
Dyn
amic
mic
ro-le
vel c
hang
e
Opt
imis
ing
Con
tinuo
us p
roce
ss im
prov
emen
t is
enab
led
by q
uant
itativ
e fe
edba
ck
from
the
proc
ess
and
from
pilo
ting
inno
vativ
e id
eas
and
tech
nolo
gies
. D
efec
t pre
vent
ion.
Tec
hnol
ogy
chan
ge m
gt. P
roce
ss c
hang
e m
gt
Opt
imis
ing
Pers
onal
com
pete
ncy
deve
lopm
ent,
coac
hing
, con
tinuo
us w
orkf
orce
in
nova
tion.
Con
tinuo
usly
Impr
ovin
g Es
tabl
ishi
ng q
uant
itativ
e pr
oces
s ef
fect
iven
ess
goal
s Im
prov
ing
proc
ess
effe
ctiv
enes
s
Sust
aine
d C
ontin
uous
impr
ovem
ent o
f PM
pr
oces
ses.
Pr
oble
ms
asso
ciat
ed w
ith a
pply
ing
PM a
re fu
lly u
nder
stoo
d an
d ad
dres
sed
to e
nsur
e su
cces
s. P
M
data
col
lect
ed a
utom
atic
ally
, is
anal
ysed
to id
entif
y w
eak
spot
s. T
his
info
is u
sed
to im
prov
e PM
pr
oces
ses.
Inno
vativ
e id
eas
are
purs
ued
vigo
rous
ly.
Each
team
mem
ber i
s in
volv
ed in
im
prov
ing
PM p
roce
sses
. Pro
ject
te
ams
are
dyna
mic
, ene
rget
ic a
nd
fluid
.
Inco
rpor
ated
Va
lue
man
agem
ent,
Busi
ness
co
ntin
uity
pla
nnin
g, P
rocu
rem
ent
man
agem
ent,
Out
sour
cing
& c
ontra
ct
man
agem
ent,
PM c
entre
of
exce
llenc
e K
ey fo
cus
for i
mpr
ovem
ent:
Inte
grat
ion
with
bus
ines
s
Zach
man
Fra
mew
ork
for E
nter
pris
e Sy
stem
s A
rchi
tect
ure
The
Zach
man
Fra
mew
ork
for E
nter
pris
e Sy
stem
s Ar
chite
ctur
e of
fers
a u
sefu
l cla
ssifi
catio
n m
echa
nism
that
can
be
used
to s
how
how
the
diffe
rent
arte
fact
s in
an
ente
rpris
e fit
toge
ther
and
rela
te to
eac
h ot
her.
In a
dditi
on, i
t can
be
a us
eful
tool
for a
rchi
tect
s an
d re
view
ers
to e
stab
lish
whe
re th
ere
are
gaps
in th
e w
ay th
e en
terp
rise
is d
escr
ibed
in a
mod
el. E
very
hum
an la
ngua
ge c
onta
ins
only
6 a
nd e
very
on
e of
the
6 in
terro
gativ
es (w
hat,
how
, whe
re, w
ho, w
hen
and
why
), ou
t of w
hich
que
stio
ns m
ay b
e co
nstru
cted
to o
btai
n an
swer
s to
all
the
ques
tions
abo
ut th
e en
terp
rise.
The
Cha
sm in
Inno
vatio
n
Payo
ffR
isk
Early
Ado
pter
s
Early
Maj
ority
Late
Maj
ority Lagg
ards
2.5%
13.5
%34
%34
%16
%
Eve
rett
Rog
ers:
Diff
usio
n of
Inno
vatio
n(1
962)
Geo
ffrey
Moo
re: C
ross
ing
the
Cha
sm(1
991)
Ste
ve M
cCon
nell:
Afte
r the
Gol
d R
ush
(199
9)
Inno
vato
rs
Bra
nd n
ewpr
actic
es
SW-C
MM
Wat
erfa
ll LC C
ode
& F
ix“M
oder
n”SE
Pra
ctic
es
Hig
h
Low
The
char
t des
crib
es th
e ty
pica
l ado
ptio
n of
ne
w te
chno
logy
and
pra
ctic
es. B
rand
new
pr
actic
es a
re ty
pica
lly a
dopt
ed b
y th
e in
nova
tors
and
som
e ea
rly a
dopt
ers.
Mos
t of
thes
e (e
arly
ado
pter
s) ty
pica
lly w
ant s
ome
evid
ence
of t
he p
ract
ices
as
prov
en b
efor
e th
ey w
ill co
mm
it. A
fter s
ome
time
(and
the
rese
arch
indi
cate
s th
at it
will
ofte
n be
a
cons
ider
able
tim
e –
thus
the
“gap
” or “
chas
m”)
the
early
maj
ority
will
pay
atte
ntio
n to
ap
proa
ches
like
CM
M to
gui
de th
em a
nd
actu
ally
ent
er in
to th
e jo
urne
y of
con
sist
ent
and
regu
lar i
mpr
ovem
ent.
At th
e sa
me
time,
th
e la
te m
ajor
ity w
ill st
ill be
stu
ck in
the
“old
” w
ays,
whi
lst t
he la
ggar
ds w
ill st
ill be
cod
ing
and
fixin
g (n
o pr
oces
s at
all)
. R
esea
rch
indi
cate
s th
at th
e tim
e fo
r lag
gard
s to
“cat
ch u
p” is
abo
ut 1
5-18
yea
rs!
The
inte
rest
ing
thin
g is
that
whi
lst t
he p
oten
tial
for p
ayof
f is
high
with
bra
nd n
ew p
ract
ices
, but
lo
w fo
r the
cod
e an
d fix
app
roac
h (e
.g. i
t cos
ts
1000
0X to
fix
a pr
oble
m th
at is
foun
d af
ter
goin
g liv
e), r
isk
is o
bvio
usly
hig
h w
ith b
rand
ne
w p
ract
ices
(the
y ar
e as
yet
unp
rove
n an
d pr
one
to fa
ilure
s). H
owev
er, r
isk
is a
lso
high
w
ith th
e co
de a
nd fi
x ap
proa
ches
. Th
e qu
estio
n is
, why
wou
ld o
ne g
o fo
r an
appr
oach
that
offe
rs lo
w re
turn
(pay
off)
and
high
risk
? Th
e an
swer
may
lie
in th
e ab
ility
of
peop
le to
ado
pt n
ew a
ppro
ache
s –
the
so-
calle
d le
arni
ng c
urve
. Th
e ne
xt d
iagr
am e
xpla
ins
why
this
sho
uld
be
so. T
he c
rafts
man
is fa
r mor
e ab
le to
see
the
bene
fits
and
low
er ri
sks
of “m
oder
n pr
actic
es”.
Sadl
y, it
see
ms
man
y pe
ople
nev
er m
ake
the
trans
ition
from
adv
ance
d be
ginn
er to
cr
afts
man
.
The
Jour
ney
of th
e Pr
ofes
sion
al
Inco
mpe
tenc
e
Com
pete
nt
Skill
Unco
nsci
ous
Cons
ciou
sC
ogni
tion
W E
dwar
ds D
emin
g
Know
ledg
eCo
mpr
ehen
sion
Appl
icat
ion
Anal
ysis
Synt
hesi
s
Eval
uatio
n
Blo
om’s
Tax
onom
y of
Cog
nitiv
e E
duca
tion
Goa
ls
Novi
ceFo
llow
s ru
les
blin
dly
Adva
nced
Beg
inne
rPa
ys s
ome
attn
to s
ituat
iona
lel
emen
ts. S
ome
influ
ence
of
expe
rienc
e.
Goa
l orie
nted
rath
er th
anru
le o
rient
edCr
afts
man
Not
aw
are
of s
kills
.M
atur
e, p
ract
iced
un
ders
tand
ing
Expe
rt
Hub
ert &
Stu
art D
reyf
us
Inco
mpe
tenc
e
Com
pete
nt
Skill
Unco
nsci
ous
Cons
ciou
sC
ogni
tion
W E
dwar
ds D
emin
g
Know
ledg
eCo
mpr
ehen
sion
Appl
icat
ion
Anal
ysis
Synt
hesi
s
Eval
uatio
n
Blo
om’s
Tax
onom
y of
Cog
nitiv
e E
duca
tion
Goa
ls
Novi
ceFo
llow
s ru
les
blin
dly
Adva
nced
Beg
inne
rPa
ys s
ome
attn
to s
ituat
iona
lel
emen
ts. S
ome
influ
ence
of
expe
rienc
e.
Goa
l orie
nted
rath
er th
anru
le o
rient
edCr
afts
man
Not
aw
are
of s
kills
.M
atur
e, p
ract
iced
un
ders
tand
ing
Expe
rt
Hub
ert &
Stu
art D
reyf
us
The
acco
mpa
nyin
g di
agra
m is
a
com
posi
te o
f the
thou
ghts
of
• W
Edw
ards
Dem
ing
(cre
dite
d w
ith
bein
g on
e of
the
“fath
ers”
of t
he
Japa
nese
mod
ern
indu
stria
l re
volu
tion)
: the
Bos
ton
squa
re
desc
ribin
g th
e in
terre
latio
nshi
ps o
f co
gniti
on a
nd s
kill.
•
Dre
yfus
& D
reyf
us: T
he p
rogr
ess
step
s fro
m n
ovic
e to
exp
ert.
• Bl
oom
’s T
axon
omy:
the
stag
es o
f le
arni
ng.
Thus
a n
ovic
e w
ill s
oak
up k
now
ledg
e,
whi
ch h
e do
es n
ot k
now
wha
t he
shou
ld
do w
ith, a
nd th
us fo
llow
s ru
les
blin
dly.
He
can
thus
be
clas
sifie
d as
unc
onsc
ious
ly
inco
mpe
tent
. As
he b
ecom
es a
n ad
vanc
ed b
egin
ner,
he s
tarts
see
ing
the
rela
tions
hip
of th
e kn
owle
dge
he h
as
gain
ed a
nd h
ow h
e or
oth
ers
appl
y it.
He
thus
bec
omes
con
scio
us o
f his
in
com
pete
nce
in u
nfam
iliar t
errit
ory.
As
he
appl
ies
the
new
und
erst
andi
ng h
e ha
s ga
ined
, he
is a
ble
to a
naly
se a
s ye
t no
t exp
erie
nced
situ
atio
ns a
nd d
raw
co
rrect
con
clus
ions
. He
star
ts b
ecom
ing
cons
ciou
sly
com
pete
nt.
With
a g
reat
dea
l of e
xper
ienc
e an
d ap
plic
atio
n of
wha
t has
bee
n ga
ined
, the
ex
pert
is a
ble
to s
ynth
esis
e th
e ex
perie
nces
, som
etim
es in
com
plet
ely
unre
late
d ar
eas,
to c
ome
to c
ompl
etel
y ne
w c
oncl
usio
ns. T
he e
xper
t is
able
to
mak
e th
e co
rrect
dec
isio
ns o
n th
e fly
, w
ithou
t act
ually
bei
ng a
ble
to e
xpla
in
why
.