However, innovation in the public sector is less about new products and more about improving efficiency and quality of outcomes. Innovation can therefore not only be linked to technological innovation leading to “Product Innovation”, but it can involve internal organisational processes and structures leading for example to new approaches to client services – “Client service innovation” – or new approaches to reaching clients – “Marketing Innovation” – or new methods for transforming information – “Information Innovation” – and so on.

The Publin report D20 introduces the concept of innovation in the public sector as a “…deliberate change (in behaviour) with a specific objective in mind “Innovation and change share a common DNA and in the public sector innovation and change are linked to improvements and novelty in systems, processes and products that add value to the public by allowing them to be more efficient and effective. In other words, innovation in public sector organisations involves the successful implementation of change.

So what can the private sector learn from the experiences of the public sector about the challenge of changing organisational structures, processes and behaviours?

Innovation examples in the public sector include: the use of new technology; the drive towards public-centric processes with the view to deliver simpler services and greater convenience; or the empowerment of staff and the public to better engage and participate in the design and implementation of new policies/services. To enable all these innovations to be successfully delivered in the public sector organisations we need effective change management methodologies and approaches.

Many of the barriers to innovation are common to both the private and public sectors; resistance to change, risk adverse cultures; centralised structures, internal politics, etc.

Some of the lessons learnt from the public sector innovations are:

1. Promote collaboration and collaborative working cultures within and across divisions and departments by identifying clear accountabilities and mapping (sometimes even creating) the cross-organisational interdependencies that need to work in order for the desired outcomes to be achieved
2. Beware that ‘fear of failure’ stifles innovation and change in organisations: in fact successful change organisations tolerate failure as part of learning, and growing change capability
3. Articulate an all-encompassing vision of what the change initiative will accomplish and align all stakeholders behind the vision
4. Capture all the expected benefits and the changes in the organisation that will realise the benefits and then establish the right metrics to monitor and track benefit realisation following the end of the change initiative
5. Smart individual and group incentives are needed to instil the desired culture. The most successful of these are about recognition of efforts and achievements, rather than financial reward.
6. Finally, be careful what you measure and what you reward, as this it will strongly influence behaviours, sometimes in unintended ways.

CITI, over the last 25 years, has developed and practiced robust and effective change methodologies and tools that enable change initiatives to be delivered successfully.

One of these models is the Change Diamond that assists organisations to view change through its different and inter-related viewpoints generating robust projects, programmes, and portfolios designed to bring the expected benefits into reality.

The Change Diamond takes a holistic view of the change journeys that organisations initiate; it is relevant not only for changes that involve organisational systems, processes and structures (the “hard” aspect of change), but also the changes that are needed in behaviours and organisation culture (the “soft” aspects of change) to enable change to be successfully embedded and realised.

CITI has supported many clients, from public and private sector markets, to achieve maximum value from their change initiatives and investment designed to bring innovations into the market place or introduce major technological change to enhance value to customers. It has done so by developing their programme, project, and change management communities.

Some recent examples to indicate the depth of our experience and support we provide to our clients can be found here http://www.citi.co.uk/case-studies/public-services/

• Managers, steering groups, portfolio committees and sponsors – those who demand information in order to understand status and make decision about projects
• Project managers, planners and the project community who supply the information for analysis and repackaging to meet the needs of varied stakeholder groups.

The PMO must ensure that both groups are serviced but most importantly must ensure that the value of the PMO is firmly established. The challenge is that the interest levels of the two groups varies over time – something as simple as a change in the membership of a steering group or a move away from contractors to permanently employed project managers can have a significant effect on the relative energy levels. And that’s why PMO management is critically about political positioning and stakeholder engagement. Positioning is necessary so that the right stakeholders are accessible to the PMO. Engagement is necessary because the PMO must establish, maintain and build its value with the stakeholder groups.

When PMOs are established because of the senior management’s need to improve project performance or to regain control of the investment in projects, the PMO tends to be a ‘partner’ or ‘control’ type.

Partnership PMOs are involved in establishing strategic direction by advising on the enterprise project portfolio. They are responsible for determining the ‘do-ability of candidate portfolios, they monitor portfolio performance and maintain a view on the project capability and capacity of the organisation. These PMOs are led by a senior manager, and are staffed by people competent in project management, but not necessarily by ex-project managers. They tend to be more reactive than ‘guidance’ PMOs and are ‘demand side’ driven.

Control PMOs focus on information management, being the preferred conduit for project status reporting to senior management. Often regarded as ‘objective; by senior management and ‘hostile’ by projects, they concern themselves with project variance reporting, can be interventionist, performing project audits. They usually have functional specialists included in the staff and they often have some authority assigned to them.

When the PMOs are established because the project management community decides that project managers need to spend more time doing value added work or because project managers want to do things better, PMOs tend to be ‘admin’ or ‘guidance’ types.

Administration PMOs focus primarily on the collation of data, reporting on aggregated data and information handling. It supports individual projects and is mostly passive in operation, but can undertake asset-audit style reviews. These are typically staffed by administrators.

Guidance PMOs are set up as centres for excellence and as change agents within the project community. They are staffed by process specialists, and are proactive in influencing project performance. They tend to provide or enable training and development of project managers as well as undertaking value-adding reviews of projects. This type of PMO sometimes owns pools of project managers for assignment to projects.

If you would like to explore the positioning of your PMO further then call us for a meeting to discuss your needs.

• Requirement defects account for 56% of re-work in projects
• Globally, $250 billion of annual waste is traced to poor requirements
• In the United States, about $200 billion is spent on software development (2008)
• Also in the US, $46 billion is spent on fixing software requirements errors.

Taken together, the last two of these points suggest that 25% of all spending on software is related to requirement errors.

Use the floodlight model to identify and control your project requirements

Problem: either we have some challenge that we need to address (e.g., “We are not selling as many product X than we need to do”) or we have identified an opportunity in the market (e.g., “The 30 to 45 age group is not being addressed by anyone in terms of …”).

Requirements: whichever of these is the case, we take this ‘problem’ and describe it in terms of a set of positive business requirements that describe things that we need to happen; e.g., “We need to identify more customers for product X from …”.

Solutions: a single set of requirements is likely to have a myriad of potential solutions. In the floodlight model, these potential solutions are those that fall within the pool of light cast by the problem floodlight on the conceptual ‘stage’ of all possible solutions.

Constraints: luckily, we don’t need to worry about all the solutions, as limits will be placed on us by the constraints imposed. Viewing the constraints as a spotlight, the pool of light that is the intersection with the problem floodlight illuminates the candidate solutions.

Typical constraints include:
Budget or price – the amount the sponsor is willing to spend on developing the solution
Time – the amount of time that is available to us to provide a solution
Resources – the number and type of resources we have available to us and, in terms of people, what skills and experience they have
Architectures – Processes and standards the solution must comply with to integrate with preset infrastructure and policies
Regulatory – what must be considered to remain conformant
Physical limits – such as a fixed amount of office space for a new call centre (solution).

In simple terms, constraints may be challenged by the business analyst, but typically are less negotiable than acceptance criteria. Looked at another way, imposing unnecessary constraints restricts our solution opportunities, which may mean we will not get the ‘best’ solution that we could have.

Acceptance criteria: acceptance criteria set out the conditions that the proposed solution must satisfy. They need to be measurable and described in solution terms. The acceptance criteria come from and describe the desired changes in the business’s operating model and, therefore, should be stated and owned by the business. Analysts are critical to the process of eliciting and specifying acceptance criteria and assessing the cost-risk implications.

The acceptance criteria spotlight completes the floodlight model and further restricts what are acceptable solutions. The intersection between all three lights identifies those solutions that meet the constraints and satisfy the business criteria.

The key difference between acceptance criteria and constraints is that acceptance criteria are negotiable, and they are necessarily owned by the owner of the solution, whereas constraints may be owned by others.

Part of the value of establishing the acceptance criteria is that they form the basis for final acceptance of the solution by the business owner. The subtext is that ‘if the solution satisfies the acceptance criteria, the business will accept the solution, and manage the impacts to deliver the value’.

Most project methods are aware of this, and many provide documents and approaches in recognition of it, but although clever they are often not clear, and often contribute to the confusion. CITI’s mission model, used since 1992 and identified by thousands of project and business managers as the major contributor to the successful delivery of change.

By creating and relating seven distinct perspectives, the mission model – called by many the ‘hourglass’ – allows each to be identified with great clarity. There is no longer the temptation or the need to include products and scoping statements in the objective; benefits and the problem statement are clearly distinguished one from another, and risks are always and intimately linked with the initiative.

It is impossible to prevent discussions on what would count as a solution during a project initiation workshop, nor stop worries, perceived threats and constraints from inhibiting analysis. The hourglass, however, allows for this tendency, and, by giving ‘safe parking’ for ideas and fears, and by encouraging a dynamic and iterative analysis of the purpose, value and scope of a project, the right people are able to engage with the crucial right-hand items, the problem, the objective and the benefits before settling on what the project will deliver.

The perspectives are linked by arrows, which graphically suggest how the elements are interrelated; Linking the products to impacts validates the scope; mapping the scope to the objective proves the consistency and coherence of the solution; and by deriving the critical success factors directly from the objective establishes two-way confidence in the ‘rightness’ of the project strategy. Each perspective thus contributes to a powerful self-righting vision of what needs to be achieved to make the project and the change a success.

CITI developed the change diamond to structure the different facets of projects and change, linking value to costs, strategy with operations , and delivery to adoption, so that the investment of effort, time and money is channeled into the realisation of benefits not producing outputs – and thus focused on delivering effective and valued change.

The ‘change’ lifecycle is separated into three stages:

• The first stage is to make the change wanted – this is the fundamental step of engaging stakeholders, establishing the value and aligning the outcomes with the values and needs of the business. From this come the benefits and business cases, the enterprise portfolio and the translation of the deliberate strategy to the emergent or delivered strategy.
• The second stage is to make the change happen. Though much of the cost arises in the delivery side of the diamond, much of the really important work in structuring the organisation to achieve the benefits is done during this step. For many IT-intensive organisations, the management focus and urgency of making the delivery overwhelms the attention needed by the change process leading to its neglect – which is the cause of real difficulties later in converting the project deliverables into valued outcomes. The change diamond draws attention to change governance concerns that are often overlooked. Experience shows that by giving the change agenda primacy during this stage; reversing the common approach of defining the project and its strategy from an analysis of deliverables, tasks and resources and instead using the temporal and logical needs of the change to shape the way the project is planned and executed yields far better results.
• The third stage, and the one least well addressed by many change processes, is making the change stick. Though this is where the value of the investment is returned, it commonly receives the least senior management attention. Making it stick means passing the baton on from informed teams heavily involved in delivering the change – whether as members of the project or as part of the change agency – to business-as-usual individuals with considerably less participation to date. ‘Tacking on’ benefits realisation to the end of project delivery is an unsafe and uncertain process. The change diamond illustrates the linkages that can and should be established, and the impact on the flow of governance of the delivery and adoption processes of focusing on realising the value of project investment.

With change, the governance models need to be sensitive to individual power bases and the associated politics, to timing and the sequencing of impacts on the organisation, and capability. The interaction between product lifecycles, project lifecycles, and the dynamics of change means that the governance framework is a layered set of policies, processes, procedures, tools and templates.

The separation of concerns and the close linking together of the decisions and actions are the inspiration behind CITI’s ‘M-Model’. The ‘M’ graphically depicts the progressive and varying levels of governance interaction necessary to ensure the execution and control of the investment process ensuring that business change remains connected to the strategy, while allowing the expertise and capability of the organisation to be brought to bear on its delivery.

The layering and linking of the portfolio, project, product, and change local governance functions and structures are used as a route-map to illustrate who, how and when decisions and their consequences are or should be transmitted through the business and change community.

The model strongly supports the identification and separation of processes and procedures into governance and execution documentation, clearly delineating between decision and action. It also highlights why and how assurance processes and stage gates are so valuable. They are the essential management interventions that connects the cost-driven processes – project delivery – with the management and delivery of value by managed, directed change.