21
Considerations for organizational adoption
This chapter covers:
•why an organization-wide method may be wanted
•who should be involved
•assessing the organization’s capability
•building and managing the method
•embedding and deploying the method
•consistency of use
•building and sustaining maturity
•examples of tailoring and embedding
21 Considerations for organizational adoption
This chapter builds on section 4.4 to provide more detailed guidance for those organizations which want to adopt PRINCE2 and, in particular, what to consider when:
•tailoring PRINCE2 to create an organization’s method (section 21.1)
•embedding the tailored method within the organization’s working practices and ensuring its widespread use (section 21.2).
21.1 Tailoring PRINCE2 for an organization
21.1.1Creating an organization’s PRINCE2-based project management method
21.1.1.1 Understanding the drivers and objectives for adopting PRINCE2
Before creating a project management method, it must be understood why an organization wants to do this. By understanding the drivers and objectives, it is more likely that a method will be created that meets the needs of the organization. For example, one typical driver may be to ensure projects comply with external standards, such as ISO 21500 or BS 6079, or bodies of knowledge such as from the APM or PMI (see section 2.6.1). It is possible, through tailoring PRINCE2, to create a method which complies with all these, as each of them also promotes tailoring.
Tip
Few organizations initially aim to build a project method for all their projects but this often becomes a long-term objective. If you are building a method for specific project types, try to write the method so that it could be used on any type of project. This makes adoption of the method by other parts of the business much easier.
Key message
The overriding objective for adopting PRINCE2 should be to improve business performance.
21.1.1.2 Deciding who to involve
The people involved in the development of a new method should have the right skills and experience; they may be in-house experts, consultants or a mix. The method they create must be acceptable to the users (stakeholders). A way of moving to a common method within an organization is to collect together some experienced and respected project managers to compare the way that they do things now, and ask them to agree an approach that appears to be acceptable to all; use recognized experts to facilitate discussions on contentious issues and, if necessary, recommend a solution. This will not only ensure that collective experience is harnessed but will also promote buy-in.
Creating a centre of excellence to manage both the development of a method and its ongoing improvement is a powerful way of ensuring momentum. For more information on creating a centre of excellence, see Portfolio, Programme and Project Offices (Cabinet Office, 2013).
21.1.1.3 Using maturity models
The increase in business performance through the effective use of project management methods across organizations has been demonstrated through the use of maturity assessments, which measure an organization’s capability to manage projects, programmes and/or portfolios. The higher the maturity an organization attains, the more effective and efficient it is in business terms.
Definition: Maturity
A measure of the reliability, efficiency and effectiveness of a process, function, organization, etc. The most mature processes and functions are formally aligned with business objectives and strategy, and are supported by a framework for continual improvement.
Definition: Maturity model
A method of assessing organizational capability in a given area of skill.
The benefits of using a maturity assessment include, but are not limited to:
•helping organizations decide what maturity level they must achieve to meet their business needs
•creating a reliable capability baseline against which improvements in performance can be objectively measured
•providing an objective assessment of strengths and weaknesses
•justifying investment in project management infrastructure
•providing validation of an organization’s maturity
•demonstrating service quality to support proposals to prospective clients
•reducing delivery costs and increasing benefits
•indicating what the next logical improvement steps are to improve project management performance.
One maturity model is AXELOS’s Portfolio, Programme and Project Management Maturity Model (P3M3). Table 21.1 shows the characteristics for project management taken from P3M3. At maturity level 2 each project has its own method, whereas at maturity levels 3 and upwards projects are managed using a common method. If an organization seeks to adopt PRINCE2 as its project management method, it needs to aim, in the first instance, for maturity level 3 or its equivalent. The detail in the model describes how the people in an organization would behave over the range of topics which comprise ‘project management’ at each maturity level. By using such a maturity model, together with PRINCE2, a design can be developed which defines what the organization’s method needs to cover.
Table 21.1 Characteristics of P3M3 project maturity levels
Maturity |
Characteristics |
Level 1: Awareness of process |
Does the organization recognize projects and run them differently from its ongoing business? (Projects may be run informally with no standard process or tracking system.) |
Level 2: Repeatable process |
Does the organization ensure that each project is run with its own processes and procedures to a minimum specified standard? (There may be limited coordination between projects.) |
Level 3: Defined process |
Does the organization have its own centrally controlled project processes and can individual projects flex within these processes to suit the particular project? |
Level 4: Managed process |
Does the organization obtain and retain specific measurements on its project management performance and run a quality management organization to better predict future performance? Level 5: Optimized process Does the organization run continual process improvement with proactive problem and technology management for projects in order to improve its ability to predict performance over time and optimize processes? |
Example: Project management and P3M3
If an organization has no commonly used project management method, each project manager has to define their own approach for each project. PRINCE2 can be used as the basis for this, as PRINCE2 can be tailored directly to suit each project. By taking this approach, an organization being assessed using the P3M3 would be rated as a maturity level 2 organization, in which each project is run with its own processes and procedures.
On the other hand, an organization which has a defined project management method, based on PRINCE2, would become at least a maturity level 3 organization, in which projects are managed to a common set of processes and procedures. Typically, the higher the maturity level, the better projects perform.
21.1.1.4 Pulling the elements of PRINCE2 together
Consistent terminology is important, as using words in a consistent way helps communication and understanding. The organization’s method should, as far as is realistic, reflect the terminology used in the organization. Problems will occur when different parts of the business use different terminology, neither of which may be wrong. For this reason, it is helpful to agree, in advance, the definition of key project management terms.
Tip
Make the creation of the glossary an early deliverable in developing the method as this will be a guide for the words to use in the rest of the method. Choose a baseline glossary such as PRINCE2 as the default and use it to create the organization’s own glossary. Change individual words if necessary, add to definitions to aid understanding and provide ‘also called’ alternative names in the glossary to help people relearn any new words. Update the glossary when necessary, amending or adding to it.
Example of changing the glossary
A retailer decided to adopt PRINCE2, but everyone in the organization understood ‘product’ to mean those items that the organization sells to its customers. Accordingly, the retailer decided to replace the PRINCE2 term ‘product’ with ‘deliverable’. Hence it created ‘deliverable descriptions’ rather than ‘product descriptions’.
Tailoring the processes, roles and product descriptions are closely linked. An activity in a PRINCE2 process is undertaken by a role to create a management product. Change any one relationship and the relationship between the others may also change. For this reason, it is advisable to start by tailoring the processes, changing them to reflect any new terminology and amending the process model and activity flows if necessary to reflect how the organization should operate. Detailed role and product descriptions can then be tailored to reflect the process changes. The processes requiring change will most likely include those related to directing a project and, in particular, relating to authorizing funding for projects or stages of projects; finance departments tend to have prescriptive ‘schemes of delegation’ defining who has the decisions rights relating to project authorization.
Tip
If the PRINCE2 process map is tailored, maintain a version-controlled copy, showing the inputs and outputs between processes. Link this to tailored versions of each PRINCE2 process. By doing this the integrity of the interfaces in the process model should be retained whenever any changes are made.
PRINCE2’s themes are drawn on from particular activities in the processes. Each organization has to decide how each PRINCE2 theme is reflected in its project management method. On individual projects, this is usually described in the PID, the relevant sections being the management approaches (for communications, quality, risk and change control), controls, and roles and structures. Having a defined procedure ensures these aspects are covered in a consistent way and saves each project manager having to define their own as they can refer to the organization’s approach.
Tip
Create one-page pocket guides or cards on important topics such as risk management to help people understand the key points.
Consider using checklists (like those in the Appendices to this manual) rather than having document templates for the management products.
Although PRINCE2 does not prescribe the use of any particular project lifecycle, it does require that one is used. Rather than each project manager designing their own, consider including one in the project management method, describing the purpose of each management stage and linking back to the PRINCE2 processes and themes. Standardizing the project lifecycle gives project managers a basis from which to tailor their own. It also enables the organization to have an overview of the progress of its portfolio of projects. Standardization of project lifecycles can go a step further and, rather than just describing a generic project, can be made to reflect particular types of project by including the specialist activities in the appropriate stages, such as for capability and product development, software development, construction, corporate mergers and complex change. For more on project lifecycle see the plans theme (Chapter 9).
After a method has been created, it needs to be managed and maintained. The method should therefore include guide(s), procedures or processes describing how it is managed, together with associated roles and product descriptions. The roles should include one to manage the overall architecture of the method, ensuring that the process model and its component parts work as a whole. Changing one component may impact other components, and so change control should be considered as part of this. Another role would be for the management of each component of the method; this would enable the method architect to have different people manage each component.
Tip
Maturity models often include a requirement to have a defined way of managing a method. For example, CMMI for Development (CMMI-DEV; Carnegie Mellon University, 2010) has two process areas at maturity level 3 covering this, called ‘organizational process focus’ and ‘organizational process definition’.
21.1.2 Creating tailoring rules and guidelines
As PRINCE2 has a tailoring principle, any method derived from it should also allow tailoring. This means that the method should include tailoring rules and guidelines. This may be covered in a few pages of text or may involve a lot of detail, describing if and how each element of the method could be tailored.
Key message
An organization may choose to limit the extent to which its project management method can be tailored by defining the following:
•What rules or guidelines are applicable to the organization?
•What degrees of freedom should each role holder have?
•Who ‘approves’ tailoring?
•Who can advise people on tailoring?
Example
A multinational company defined its project management method in processes. The method’s processes reflected the PRINCE2 processes, themes and templates (derived from PRINCE2’s product description outlines). Each of the method’s processes and product descriptions included guidelines stating how they could be tailored.
See section 21.1.3 for further examples.
As PRINCE2 can be used regardless of the complexity or scale of the project, organizations may consider rating their projects by complexity and providing guidance on how each category should be tailored. Table 21.2 illustrates a simple approach to categorizing projects and provides suggestions about how PRINCE2 could be tailored.
The aim is to help project practitioners decide what is ‘just enough’ project management in order to ensure project success.
The greater the complexity of the project, the more information that is generated. A project manager should ensure that the means of storing and distributing information is efficient and secure. For simpler projects, a log book and wall display may be sufficient, but for more complex projects, especially with distributed teams, information systems will need to be developed and rolled out.
An approach to complexity modelling may be found in Table 5.5 of Portfolio, Programme and Project Offices (Cabinet Office, 2013).
Tip
There are many ways to measure complexity. Most involve scoring a project against a number of criteria to assess the overall complexity of the project and which parts are the greatest source of complexity. One such model is the Delivery Environment Complexity Analytic (DECA), which was developed by the UK’s National Audit Office (NAO) to provide a high-level overview of the challenges, complexity and risks to delivery of a project, programme, policy or area of work.
21.1.3 Examples of how organizations have tailored PRINCE2
Example: Multinational company A
Modifying the process model
The company defined a project lifecycle, comprising five management stages, which was applied to all projects, and outlined the project management and specialist activities within each stage. The project management activities, defined in very brief documents, reflected the PRINCE2 processes and themes. PRINCE2’s directing a project process was tailored to be three separate processes:
•providing ad hoc direction
•authorizing the start of each stage and project closure
•suspending or terminating projects.
Four guide publications were created to support the method:
•a guide to the stages and gates, which describes the project lifecycle and includes criteria to be met at each gate, prior to starting each stage and to closing the project
•summary notes covering project set-up, benefits, schedule, finance, risk, issues, change control, project reviews, value management, quality and closing the project
•a guide for project sponsors, describing their role (equivalent to the PRINCE2 executive)
•a guide for decision makers, which comprised a board that made the actual decisions at stage boundaries and a supporting board that ensured there were sufficient resources to undertake the work.
Templates, supported by guides, were produced for the commonly used management products. PRINCE2’s PID was reflected in a single document which included the business case, project definition and plan.
Project milestones and reporting were via a company-wide web tool which included the risk, issues, change logs, key milestone dates, interdependencies and live financial feeds coming from the company’s accounting system for each project, stage and work package. The project tool was also the project register (over 2500 concurrent projects), listing which stage the project is in, the sponsor, the project manager, the RAG (red, amber, green) status and the project status (proposed, in progress, suspended, terminated or completed) as well as the highlight report.
Example: Multinational company B
Aligning with external standards
The company made an explicit decision to ensure its method complied with not only PRINCE2 but also CMMI-DEV, BS 6079 Part 1, ISO 21500 and the APM and PMI bodies of knowledge. Guides were produced to show how each was dealt with and used with customers and auditors as evidence that the method complied.
The PRINCE2 processes were reflected in a ‘direct and manage a project’ procedure, comprising identify a project, direct a project, initiate a project, control a stage, prepare for next stage and close a project. Authorize a project was a separate process. PRINCE2 ‘manage product delivery’ was reflected in a separate ‘manage work package’ process as this could also be used outside a project. Each management product had a template and product description with its own tailoring guidelines.
The PRINCE2 themes were dealt with as support procedures comprising benefits realization, planning, reporting, risks, issues, change control, stakeholders, communications, lessons and document management. They also covered areas outside PRINCE2, including induction, training, reviews/assurance, audit, quality, peer reviews, meetings and managing the method.
All procedures had flow charts, role summaries, tables of activities, clear responsibilities and accountabilities, checklists and tailoring guidelines with references (hyperlinks) to additional material (such as guides, standards, videos and tools) against the appropriate activities.
There were guide booklets on each topic as education sources and the most commonly needed were supplemented with single-page ‘pocket guides’. By separating out educational material from the procedures, the company was able to keep the procedures to a minimum size.
Example: Major infrastructure company
Ensuring scope integrity and quality
The company’s aim was to be ‘process light’, prescribing what products were needed, but leaving the choice and sequencing of activities to the project manager’s professional judgement. There was only one process in the method, which was related to a statutory requirement.
This project management method focused on a defined project lifecycle tailored for the company’s infrastructure projects with strong gating between stages. Each stage of the project included a list of the management and specialist products required to be created in that stage. All management and specialist products were predefined, with the product descriptions including applicability criteria which would drive the decision as to whether that product would be needed.
The project management team was supported by a set of directive handbooks which reflected the PRINCE2 themes, such as for risk management, managing gates, stakeholder management and planning. In addition, there were handbooks on sponsorship and the engineering process.
Example: Major communications company
An agile approach to tailoring
A major communications company developed its own PRINCE2-based project management method to replace 20 local methods across the company. The owners of the local methods all became part of the working group for the development of the new method; many had been having problems maintaining their methods due to lack of funds and time. The principles and high-level requirements were agreed by the group and from these a method architecture was developed. The method was designed and delivered using an agile way of working, which started with defining a minimum set of features (which included a glossary) and then agreeing the priority for the remaining features. These priorities were reviewed during regular team meetings and amended if necessary. Progress was measured against a burn chart of over 400 features comprising templates, procedures, guides and other products. After the first release, new features were delivered for use as soon as they became available.
21.2 Embedding PRINCE2 in the organization
21.2.1.1 Changing the way people work
The introduction of an organization’s project management method involves changing the way that people work, so that the outcome (in this case, widespread use of the project management method) can be realized, leading to a higher project success and enhanced business performance.
Current approaches to change management combine the psychological and engineering views of the world to create repeatable change methods, drawing on a wide range of tools and techniques. The application of different change methods has implications for the way organizations and their leaders regard change, the way they manage change and even the effectiveness of any change initiatives. At the heart of most change models is gaining the support of those who are required to change their ways of working. This involves:
•understanding the current situation (current state)
•identifying what changes are needed in the wider organization (future state)
•understanding the resilience of those who will be impacted by the change and their levels of resistance
•developing the necessary capabilities to meet the organization’s needs (roles, processes, systems, culture and behaviours)
•engaging those affected by the change and winning their support.
To gain stakeholder support, change management approaches should not just involve training, but may also include coaching, mentoring, stakeholder engagement, marketing and communications activities to embed a real understanding of the need for the change and the resulting benefits. Change is as much about managing people’s expectations and perceptions as managing facts.
Tip
Do not confuse ‘change control’, as described in the PRINCE2 change theme, with ‘change management’ as described in this section. Many proprietary methods and standards use the terms interchangeably.
21.2.1.2 Design of the future state
The design of the future state of a project management method should reflect the vision for how project management will work after the method is embedded. It should include the roles, processes, tools and behaviours relating to using the method itself and to any supporting organizational units. Projects should be perceived as part of the organization and therefore any processes, roles or approaches should align with those used in the rest of an organization. As project management is a form of governance it should explicitly link with the overall governance of the organization; embedding project management strengthens corporate governance. Common areas where this is apparent include the allocation of resources, the authorization of funding for projects, procurement of goods and services, audit, accounting and human resources practices.
The design of the future state not only incudes the tailoring of PRINCE2 (as described in section 21.1) but also the design of every other part of the organization which is needed to support project management.
For example, if the use of the method is mandated, an organization may create a special audit team to assess each project manager’s degree of compliance with the method; sanctions may be applied to those who do not comply. The auditors may need special training, checklists, knowledge and processes to support their work (see section 21.2.4 for an example). A less directive organization may have mentors and coaches to help the practitioners understand and use the method effectively; such coaches need to be familiar with the project management method, supporting techniques and how to tailor them.
Organizations will often support their project managers by implementing tools and systems to aid communication and reduce the administrative overhead. Such tools may be for planning and tracking, controlling changes, tracking risks and actions, and recording lessons. The PRINCE2 product description outlines include a number of such products. Unfortunately many proprietary tools use their own terminology and work flow which may not match PRINCE2 or an organization’s own terminology. Sometimes the terms can be changed but often not. In these cases the choice is to adapt the organization’s terminology to match the tool or choose an alternative tool. The decision depends on the value put on maintaining the chosen terminology or work flows. Experienced project managers should be able to cope with different terminology but people new to project management or from disciplines outside project management may have a problem.
The ‘future-state design’ may also be referred to as the ‘blueprint’. See Managing Successful Programmes (Cabinet Office, 2011) for more information.
Tip
The POTI model sets a high-level scope of what must be included and integrated in an effective future-state design:
P Processes, business models of operations and functions including operational costs and performance levels.
O Organizational structure, staffing levels, roles, skills requirements, organizational culture, supply chain and style.
T Technology, buildings, IT systems and tools, equipment, machinery and accommodation.
I Information and data required for the future business operations and performance measurement.
Tip
If embarking on a long-term roll-out of a project management method, do not forget to define what the interim states will be and make sure each is designed to work effectively while work continues towards the next one.
21.2.2 Consistently deploying the method
21.2.2.1 Ensure consistency across all impacted parts of the organization
The deployment of project management throughout an organization involves the roll-out of the project management method and supporting tools, together with the change management activities to promote the use of the method. Section 4.4 has already stated the benefits of the method being written and communicated in a consistent way. Such consistency also has to be applied to every other activity related to the implementation; for example, training content should reflect the concepts and terminology used in the method. Other activities associated with deployment may include communications, assurance, audit, mentoring and coaching.
As a large number of specialist products may need to be created in order to implement a project management method, the deployment strategy needs to be carefully thought through. Two alternatives are the ‘big bang’ approach and the incremental approach.
In the ‘big bang’ approach, the project management method and its supporting elements are activated for use on the same day; all plans focus on this go-live date. Such an approach may be suitable in a small or new organization, but the actual go-live date would be constrained by the longest lead element of the project and thus early benefits may be lost. There could also be teething problems on launch, unless full trials have been carried out. Trials would normally need to cover the questions: Does it work in practice? Does it work at scale? As the big bang approach focuses on a single go-live date, this could be managed as a project.
In most cases an incremental approach to rolling out the project management method and its supporting capabilities would be the most flexible and practical. By taking this approach, early benefits can be realized and the amount of change that users have to cope with at any one time reduced. It enables roll-out to be progressive, say geographically, so that deployment resources are not overstretched. In this case, the essential features required for launch would need to be determined, with other features rolled out as they become available. In some cases the plan may show interim states where the capabilities are used and bedded in before new capabilities are rolled out later. As the roll-out would require a number of projects and change activities, this would be better managed as a programme with tranches to reflect any interim operating states.
21.2.2.4 Track progress of the change
Whatever approach is taken, it is helpful to track the progress of the change effort during deployment and in the early operational period. Many change management techniques include change-tracking approaches. Maturity models can be used to assess progress of the roll-out for the whole of the organization or a sub-part.
Tip
If you are implementing a portfolio, programme and project management method, make sure they are designed to work together from the very start, sharing as much as possible in common and using the same glossary of terms. The chain of governance from corporate level through portfolio and programme to project needs to be explicit.
21.2.3 Building and sustaining maturity
If practitioners do not continue to use a project management method after the initial deployment, the effort and cost of creating it are wasted. A method needs ongoing active management if it is to benefit the business and help to continually improve business performance.
The creation of a method should not be an objective in its own right but just one component in a mix of capabilities aimed at improving business performance. Using a method requires people to be skilled and competent at their jobs; a method simply brings consistency in approach, where consistency adds value. The method should remain relevant to its users and so direct engagement should be encouraged through feedback and stakeholder involvement, such as in communities of practice and user groups.
Tip
If used, coaching and mentoring should be continued for as long as the practitioners find them valuable.
Tracking usage of the method can be hard; however, as most methods tend to be published on an organization’s intranet site, a simple ‘click’ count combined with analytics can provide a pattern of usage. Initially the use of the site should increase, but unless momentum is maintained, usage may drop off. Part of this may be because people can find what they need more quickly (fewer clicks) or need to refer to it less as they have learned the content. Tracking the quantity of feedback and any resulting changes to the project management method is indicative of user engagement.
Web site counts may be indicative of a method being used but they are not hard evidence. Evidence of the practices actually being used can be gleaned by quality assurance, project assurance and through audits. If a maturity model is used, the gradual progression of capability through the maturity levels is also evidence of improvement.
Many larger organizations create ‘communities of practice’, which have the aim of improving performance by knowledge sharing and creating a sense of community. These often have their own web sites, blogs, social media and events to motivate their members to contribute to the development of the profession. Some companies run internal conferences or actively encourage participation in external events and with professional associations. A community of practice can develop subject matter experts who take a leadership role on an aspect of project management and act as a focal point for advice; they may also own the relevant parts of the method, working with the overall method owner.
Just as maturity relates to the capability of an organization, ‘competence’ relates to an individual. The development of individual skills should be encouraged. This may be by only allowing individuals to manage projects if they have a ‘licence’ obtained through achieving a prescribed competence level (e.g. through assessment centres). Any gaps in competencies can be dealt with through additional training and development. The skills and competencies should be traceable to parts of the method, so that they can be used together seamlessly.
Training and development should reflect both the competencies and method if they are to be seen as relevant, particularly at lower levels. Experienced practitioners can be encouraged to act as mentors or coaches, ensuring the right behaviours and that use of the method does not become mechanistic.
Tip
Do not expect a project management method to run itself. Someone in the higher levels of the business should continue to sponsor it and someone, with resources, should have the responsibility for managing its ongoing development and use.
21.2.4 Examples of how organizations have embedded PRINCE2
Example: Major infrastructure company
Maturity-model-led
A major infrastructure company achieved a low score in a P3M3 maturity assessment, which reflected its actual performance. As a result the company decided to develop and deploy a single project management method, based on PRINCE2, to replace the eight methods currently being used. The new method was developed with the active involvement of the project management community. The method was piloted on one programme and feedback from its use was used to tune the method before further roll-out. Roll-out was then started, with each area deciding its own deployment approach to suit its circumstances; the only requirement was that the area had a plan.
A central implementation and deployment team monitored the roll-out and resulting performance. It held frequent question-and-answer sessions and managed the associated training. The team also attended project meetings and gate events to ensure they were being run in the ‘spirit’ of the method and not just the written word. This team stayed in place for 18 months until the method had been embedded. This organization achieved P3M3 maturity level 3 as a result.
Example: Major communications company
Incremental release and communications
A major communications company used agile methods to develop its own PRINCE2-based project management method, together with a programme management method (based on Managing Successful Programmes), which was required to replace 20 local methods across the company (see one of the examples in section 21.1.3). Features of the method were made available as soon as they were ready, being published on a platform used specifically for the method. This platform provided the material in both document and online formats. People were welcome to use any of the material and provide feedback to the designers. At the same time, two training courses were developed, one online and the other a workshop, which used the same concepts and language as the method. High-quality videos were also created and made available, as defined in a communications plan, which also included regular newsletters, tele-conferences, face-to-face presentations and blogs. The minimum feature set was available within 6 months with the full method completed within another 9 months, including training. Each area of the business, based around the original 20 local process owners, decided when and how to adopt and roll out the method in their areas, against an agreed plan. Over the first year the web site recorded more than 750 000 hits, progressively rising month on month.
Example: International IT company
Big bang and incremental roll-out
The PRINCE2 method for an international IT company was designed by a central team with some consultation. It was released in its completed state and rolled out on a geographic basis. The central programme management office (PMO) in the head office was accountable for the method, with each location having a local PMO to manage the roll-out and use of the method in their location.
Example: International company
Covert or overt?
The change manager in an international company found that there was a significant level of resistance to PRINCE2 due to perceptions of bureaucracy and, in some areas, a preference for their local standards. Although it was based on PRINCE2, the new method was designed without any explicit reference to PRINCE2 but reflected the features of the standards people wanted. As a result, a method was developed which had the support of the users, with little resistance to its roll-out. Later, guides were produced which explained how the method met the requirements of each of the source methods and standards. These were useful for engaging customers who had requirements to use a particular standard or method and for informing staff and contactors trained in those standards on how they were dealt with in the method.
Example: Major engineering programme
Harnessing success in one area to improve performance in others
A major system engineering programme had sufficient funds and senior support to develop its own programme and project management method, based on publicly available standards, bodies of knowledge and, for projects, PRINCE2. The brief from the programme director was for the method to be written in such a way that it could be used on other programmes and as a focal point for learning and improvement. Furthermore, the web site for the method and supporting materials should be available to anyone with access to the company’s intranet. One key benefit of having a standard method was that the PID need only refer to the appropriate part of the method, rather than describe everything in full; this resulted in a slim, single document reflecting PRINCE2’s PID, rather than multiple documents. The programme ran for more than 10 years, but within 3 years of it becoming available the method was used as the basis for an enterprise-wide programme and project management method, with very few significant changes.
Example: Organization A
Capturing and acknowledging feedback
The culture in a certain organization was not to provide feedback on anything as people felt that nothing ever happened as a result. When the project management method was launched, ease of feedback was built into the design of its web pages. Every page had a context-sensitive link to a feedback form; feedback appeared on the page, when posted, so the person giving the feedback did not have to say what page or item they were feeding back on. The method owner was able to post a reply, so anyone viewing the page could see all the comments and replies. The method owner, however, chose not to post a response straight away, but rather phone the person who gave the feedback to discuss their issue; often a lot more information was gleaned. The response to be posted on the site was also agreed. In many cases the improvements suggested were implemented within a day. This immediate and personal approach was soon recognized and the volume and quality of feedback gradually rose as direct relationships with users developed. Importantly, the method owner and team did not insist people use the web pages for feedback but accepted it in any form (such as verbal, scribbled note, email), anywhere, thereby helping to dispel the perceptions of ‘process’ and ‘bureaucracy’.
Example: Organization B
Using internal audit as change agents
The internal audit group of a company had always audited projects against its own checklists as the organization had no consistent project management approach. When the new project management method was launched, the method owner requested that internal audit use the method as the audit base. The audit lead was reluctant as use of the new method was not mandated by senior management. He did, however, find that the new method was more rigorous than anything he had and covered the requirements of a range of external methods, standards and bodies of knowledge. He asked that his auditors receive a full-day briefing on the method and created an audit guide. As a result, the company’s auditors used the same language and concepts as the method in their reports. Although the auditors could not prescribe how auditees responded to audit points, they were able to be helpful and point them to the relevant parts of the method.