Stakeholder

Methodologies define a step-by-step process for delivering projects. Each methodology will describe each step in adequate depth, so that the project team understands what has to be done to deliver their project. This is quite different to a standardised knowledge framework such as the PMBOK® Guide (for more on this see: PMBOK -v- Methodology).

By using the same steps for every project the organisation undertakes risks and uncertainty are minimised and there is likely to be an overall saving of time and effort on projects.

Defining ‘your’ methodology

The key steps to follow are:

• Define what it is that you want from your methodology, the type of content it should contain and the way in which it will be used.
• Create a set of specific requirements. Some options include defining:
  • How much of the project lifecycle needs to be incorporated
  • How much detail should be included? What practical templates and examples are needed to help to complete the step quickly and easily?
  • Should it follow one of the worldwide project standards such as the PMBOK® Guide?
  • Can/should the system be easily customised suit all project types and sizes?
• Determine the best methodology to use:
  • Review the methodologies used currently by your organisation and compare them to your requirements to see if there is a good fit.
  • Review the commercially available methodologies to see if there is a good fit.
  • Select the option with the best fit to your requirements
• The best methodology is still only likely to have a 90% fit (or less), this is normal. Make sure you can customise the remaining elements to meet your requirements.
• Ensure adequate flexibility for the range of projects in your organisation.

Implementing the methodology

The key steps are:

• Create an Implementation Plan supported by a change management plan. Implementing a methodology is a significant organisational change.
• Run the implementation as a change management program, including customising the methodology for your environment. Stakeholder engagement is vital to the overall success of the initiative.
• Train the users and support staff in the methodology and ensure ongoing support.
• Ensure the methodology is followed.
• Start improving the methodology (for more on measuring and improving the organisations project management maturity see Mosaic’s OPM3 home page).

Improving the methodology

Processes are always capable of improvement. Observing the actual implementation of the methodology will define actions and outcomes within the following matrix.

Unauthorised, unproductive activities need to be stopped and authorised productive processes supported. The two zones for process improvement are refining or removing elements of the methodology that do not add value to the overall management of the project and incorporating unauthorised processes that are not in the methodology but that are being used add value.

The easiest and most important area for action is rectifying the unproductive processes already in the methodology. Care need to be taken to ensure the definition of ‘unproductive’ is understood. Most planning processes don’t produce anything and consume effort; superficially they can be classified as ‘unproductive’. In reality, effective planning contributes significantly to the efficient delivery of the project and its value to assist in the efficient execution of the work being planned is significant.

Excessively detailed planning though is usually counterproductive. Value judgements are needed to assess the point at which adding more detail or rigour becomes ‘planning overkill’ reducing the overall value of the process and conversely, how much detail can be safely removed from a planning processes to improve overall productivity before insufficient planning starts to cause problems.

Adapted from Firdman, H. E. (1991). Strategic information systems: Forging the business and technology alliance. McGraw-Hill, New York.

Adapted from Firdman, H. E. (1991). Strategic information systems: Forging the business and technology alliance. McGraw-Hill, New York.

Ensuring the methodology is seen as ‘productive’ is essential for it to be generally accepted and supported by your stakeholders.

Once the existing methodology is optimised and firmly in the ‘authorised and productive’ segment, the next area is to examine unauthorised processes that aid productivity and progressively incorporate these into your methodology. The ‘unauthorised and productive’ quadrant is where you find genuine innovation and opportunities for organisational gain.

Summary

No methodology works ‘out of the box’ they all need customisation and tailoring. However, the effort is worthwhile. OPM3 has demonstrated standardised processes that incorporate best practices can provide significant benefits to an organisation (see more on OPM3).

The challenge is balancing systemised processes with the need for adequate flexibility to deal with the circumstances of each unique project. An effective project management methodology needs core components, scalable components and optional components designed to meet the needs of your organisation.

Research by Dr. Brian Hobbs, University of Quebec at Montreal, Quebec, Canada published in a White Paper prepared for the Project Management Institute (PMI) highlights the precarious existence of the majority of Project Management Offices (PMOs). Approximately half of the PMO’s in existence are seeing their relevance or very existence questioned.

Whilst PMOs have been popular since the middle to late 1990’s and new PMOs are being created at a relatively high rate; PMOs are also being shut down or radically reconfigured at a similar rate. As shown in the figure below most PMOs in existence today are rather recent creations. The sample suggests more than half the PMOs in existence today (54%) were created in the last two years and only 17% have been in existence for more than five years.

This data suggests a PMO often has only a short time to demonstrate its ability to fit into the organisations culture and create value before it is restructured or closed down. We have looked at some of the issues and challenges associated with PMOs in a Mosaic White Paper ‘PMOs’.

Based on years of observation, the key to achieving an effective start up for a PMO has more to do with the PMO’s management being able to effectively manage their key stakeholders, particularly in the executive suites than any methodology or reporting processes the PMO may import or develop. For more on this see the numerous papers we have published [paper listing]. The key message is technical competence is never going to be enough to justify the existence of a PMO.

I published a post on the PMI Voices on Project Management blog a couple of weeks ago; Is This Your Project Stakeholder?. The post outlined a scenario and provided two options for readers to respond to.

• Option one was to focus on stakeholders and value with an enhanced probability of technical failure (running late and being over budget)
• Option two was to focus on the ‘iron triangle’ of time cost and scope.

A surprisingly high number of comments from people in the IT industry chose ‘option two’ – just do the job, a focus on short term technical achievement. Whereas managers with a broader perspective tended to select option one for a range of reasons.

You will have to wait a few days for my second post outlining my views on the best answer and why (I have just finished writing it and its now being edited). So check the Voices blog ‘home page’ in a few days or follow my posts.

In the interim though I have to say I was amazed at the number of IT practitioners who still seem to believe IT is somehow disconnected from the overall business of the organisation. I would suggest 99% of IT projects involve changes to business processes and will never deliver their full value if the people working in the business don’t embrace the changes.

Further, I would suggest probably greater then 50% of all IT projects are specifically instigated to support a business initiative or change. Projects in this category are integral to the value creation process – if the IT project team alienate key stakeholders the whole initiative could easily fail to deliver value to the organisation and become a waste of time, effort and money.

I discussed stakeholders and change management a couple of weeks ago (see post) and the ‘Value Chain’ was covered last year (see post)

Based on the responses to the PMI blog, there’s still a lot of work to do to convince IT practitioners that being on time and on budget are not directly related to value. Value is created when people (ie, stakeholders) actually use the IT implementation to generate wealth.

When considering stakeholders, there are very few one-to-one relationships. Most stakeholders are, and have been, influenced by a range of relationships in and around your project, program and your organisation.

Change Management and Stakeholder Management

Stakeholder management is a key facet of organisational management where stakeholder management is often aligned with marketing, branding and corporate social responsibility (CSR) initiatives.

Similarly, stakeholder management central to change management and the ability to realise the benefits the change was initiated to deliver. The benefits will not be realised unless the key stakeholder communities accept and embrace the changes.

Project and program management also has a focus on effective stakeholder management. In a change initiative, the project and/or program undertakes the work to deliver the elements needed to facilitate the change but are only ever part of the journey from concept to realised value.

A typical evolution of a change initiative would flow along these lines:

• The organisation decides on a major organisational restructure and as a consequence initiates a change management process and appointed a change manager.
• The change manager develops the business case for the program of work and the executives responsible for the organisations portfolio management approve the business case and agree to fund and resource the program.
• The program manager sets up the program management team, established the program management office (PgMO) and charters a series of projects to develop the various deliverables needed to implement the change.
• The projects deliver their outputs.
• The program integrates the outputs with the operational aspects of the organisation.
• The organisation’s management make effective use of the new systems and processes.
• Value is created for the organisation and its owners.

The change manager is the sponsor and primary client for the program but the people who need to be convinced of the value of changing are the operational managers and their staff. If the organisation does not accept and use the new systems and processes very little value is generated.

Within this scenario, stakeholders in the operational part of the organisation, and particularly the managers will be key stakeholders for a range of different entities:

• They are stakeholders in the organisation itself and part of the organisational hierarchy.
• They are stakeholders in the change process being managed by the change manager.
• As end users of the new systems and processes they are also stakeholders of the program.
• As subject matter experts (SMEs) they are likely to be stakeholders in at least some of the projects.

In one respect change management is stakeholder management. Therefore, in a change management initiative, stakeholder management should be an integrated process coordinated at the change manager’s level. All of the organisational elements working on the change need to coordinate their stakeholder management efforts to support the overall outcome. Confusing and mixed messages don’t help anyone.

But this is just one typical business scenario. When considering stakeholders, there are very few one-to-one relationships. Most stakeholders are, and have been, influenced by a range of relationships in and around your organisation. Consequently, focusing on a simple one-to-one view is unlikely to provide the best outcome for anyone.

Effective stakeholder management requires a mature organisational approach. One approach to developing this capability is the SRMM (Stakeholder Relationship Management Maturity) model described in my book. Stakeholder Relationship Management: A Maturity Model for Organisational Implementation. I will outline the SRMM model in a later post.

Complex decision making is a vital project management skill; required not only by the project manager but also by the project’s sponsor and client / customer among others.

Some of the key areas involving complex decisions include risk management, many aspects of planning (particularly optimising choices) and dealing effectively with issues and problems in a range of areas from scope and quality to cost and performance.

There is an underlaying assumption in project management (derived from traditional scientific management) that decisions will be based on a rational assessment of the situation to optimise outcomes. Unfortunately this is not true! As complexity increases assuming a ‘rational decision making paradigm’ becomes increasingly unrealistic. Human decision makers become ‘predictably irrational’.

Understanding the built in biases and ‘predictable irrational’ decision making processes used by people confronted with complex decisions can help managers requiring optimised decisions to craft strategies to minimise suboptimal outcomes. But where can busy project managers access this information?

I have just finished reading the most amazing paper on the subject that canvases the whole spectrum from risk aversion to behavioural economics in a practical, easy to read format; and it is free!

Behavioural economics and complex decision making: implications for the Australian tax and transfer system has been written by Andrew Reeson and Simon Dunsttall of the Australian national science agency, CSIRO. The report was commissioned by the ‘Henry Review’ into the Australian taxation system and is published on their web site. Whilst you can safely skip the last section which focuses on applying the knowledge to our tax system. The preceding 7 sections are focused on how people make complex decisions in any sphere and are just as relevant to complex project decisions as to complex investment and taxation decisions.

You can download this free resource from the review panel’s website: download the paper (a copy is also on the Mosaic web site on the assumption the Government site is temporary and will close once the Henry Review has reported: download from Mosaic).

If you find the report useful and you don’t live in Australia, you can buy the next Australian you meet a beer; it was his or her taxes that paid for this amazingly useful report. I know I will be keeping my copy handy for a very long time to come.

I have been involved in a series of posts on both my SRMM Blog (see post) and the PMI Voices on Project Management blog (see post) that have stirred up sections of the agile software development community.

Despite the Agile Manifesto focusing on providing excellence to stakeholders, many Agilists seem intent on advocating their rather extreme view of agile including no documentation, little planning or architectural design and less control. The mantra is ‘give the software developers free reign and you will get better software’. Whilst this may be true (although I somehow doubt it in anything but the smallest and simplest projects) it ignores the needs of the project’s key stakeholders.

Most IT projects exist to enhance the capability of the organisation. Consequently the software development is only one part of an overall project to change the organisation, deliver new capabilities or similar. In these typical circumstances, the IT component needs to meet predetermined requirements; any change in the IT capability delivered requires changes in other parts of the project. In fact the best IT solution may turn out to be an unacceptable business solution.

Meeting the needs of the businesses key stakeholders demands discipline and communication not just within the ‘scrum’ or XP team but to the customer’s managers. This needs at the very least a minimum of documentation to prove the IT team and its immediate customers understand their scope of work and other constraints and know how they will achieve the outcomes needed to support the business. Adequate documentation and effective communication are essential.

This post is not suggesting a return to Waterfall or other heavily documented software development process (they don’t work very well anyway – refer the Standish reports) but rather for an appropriate level of documentation to meet the genuine needs of senior management stakeholders. Saying ‘trust me’ is not enough and is not good stakeholder management.

Identifying the key stakeholders, assessing their requirements and expectations and then managing these key relationships so the stakeholders realistic expectations can be realised definitely involves up-front planning and effort, needs tools and methodologies such as the Stakeholder Circle® and involves on-going monitoring and control but is, I would suggest, worth the effort. Your project is unlikely to be seen as successful if the stakeholders expectations are not realised!

In most aspects of life the long term enjoyment of real freedom required a significant measure of self discipline. The agile extremists may do well to consider this and focus on meeting the needs and expectations of all of the stakeholders involved in their work.

This blog is going to try and link project and program management with change management and benefits realization.

As a start, the only point of undertaking a project or program is to realize some form of value. Benefit realization! To realize value, three elements need to be brought together:

1. There needs to be a new product or process created (an artifact);
2. People within the organization need to make effective use of the artifact to deliver a service;
3. The service as delivered needs to be accepted and used in the ‘market’.

The role of Strategic management and Portfolio management is to determine what services are likely to be accepted or needed by the market; a new shopping centre, an improved insurance package or simply a more efficient process to deliver information. These decisions will depend on the objectives of the organization, and is not the province of this blog.

The generally accepted role of project management is to create a unique product, service or result (an output) and the role of program management is to manage a group of related projects to achieve an outcome more efficiently than if the projects had been managed in isolation. Neither of these processes achieves real value in themselves. The realization of sustained value is achieved by the organization using the program’s outcome effectively over many months or years.

The Scope of Change Management

Projects and, to a greater extent, programs can realize some benefits, partially in the design and delivery of their respective outputs. Early benefits realization is frequently linked to ‘soft’ elements in the range of deliverables such as developing effective training, managing the transition to operations and ensuring a proper support framework is developed. Achieving these elements require the project/program team to really understand the requirements of their stakeholders. However, as demonstrated by the cost/benefit graph, benefits realization should continue for years after the program is finished and closed.

The extended timeline for value realization has important ramifications for organizational change management. Each project is an intense burst of change and the program absorbs these changes and has additional change effects of its own. These ‘activity related changes’ will include beneficial and negative impacts on a range of associated stakeholders. Some changes are disruptive caused by the execution of the work, learning curves, etc. Some changes positive caused by the improvements the projects and programs were initiated to deliver. Achieving a successful project/program outcome requires the effective management of these stakeholder communities, but the stakeolder management activity is essentially tactical.

The critical requirement to deliver sustained value is the organizational culture change needed to actively embrace the program’s outcomes and make valuable use of them. Embedding a culture change into an organization is a 2 to 3 year process as the change migrates from ‘new and threatening’, to ‘accepted (but the old way are still fondly remembered)’ to the ‘established old way’ things are done around here. This type of long term organizational change can only be accomplished by the organization’s line management supported by senior management. This is the realm of the program sponsor and executive management!

These ideas also have important ramifications for effective stakeholder management:

• Project level stakeholder management is relatively short term and focused on minimizing opposition to the work whilst ensuring necessary organizational support is in place to deliver the project’s outputs effectively. This is essentially tactical in nature.
• Program level stakeholder management has a wider view that needs to engage with the organizations strategic vision to ensure the program’s outcome is optimized to the changing circumstances within and around the organization. The key issue here is identifying and responding to changing stakeholder requirements, needs and expectations/perceptions over time; so as to optimize the value of the ‘outcome’ the project was established to deliver.
• Organizational level stakeholder management needs an even broader and longer term view focused on the strategic needs of the organization and its long term relationship with both internal and external stakeholders. Sustained value creation requires both the organizations internal staff and its external customers to jointly perceive the programs ‘output’ as valuable to them and also to perceive the organization favorably so they together maximize its use:
  • For a new shopping center with a 20 year lifespan this translates to retail tenants being willing to rent space and the ‘public’ seeing the shopping center as a ‘good place to shop’.
  • For a new call centre management system this translates into the call centre staff seeing the system as efficient and easy to use and clients of the business perceiving the system and staff as friendly, efficient and effective so they are happy to make repeated use of the system.

Conclusions

Change management and stakeholder management are closely aligned. Effective stakeholder management is essential for successful change management.

Change management and stakeholder management must start as soon as the project or program are initiated but should continue well after the project/program are completed.

The on-going organizational component of change management supported by strategic stakeholder management is critical if the real value of the outputs/outcomes created by the projects and program are to be realized.

Benefits realization is a line management responsibility starting with the project sponsor. All project and program managers can do is ensure their deliverables are crafted to facilitate and encourage benefits realization.