How to Suffer Successfully

How to Suffer Successfully, is the title of chapter four in Alain de Botton’s first book of philosophy, How Proust Can Change Your Life. The same idea is the theme of The Adversity Paradox by J. Barry Griswell and Bob Jennings.

The Adversity Paradox is full of inspiring examples of people who have suffered major adversity and have used the experience to improve their capabilities and gone on to outstanding success. The knowledge they gained from overcoming obstacles has played such a crucial role in their success trajectories that they now consider adversity to be an invaluable friend.

De Botton takes a more philosophical view and recognises there are ‘bad sufferers’ and ‘good sufferers’. Bad sufferers learn nothing from their adversities and react to them by engaging defence mechanisms that compound the problem such as rage, delusion and arrogance. Successful sufferers, including those identified in The Adversity Paradox, use their adversity to gain a better understanding of reality and by rising to the challenge, create a better future for themselves and others.

Whilst no sane project manager would chose to suffer sufficiently to produce their version of Proust’s In Search of Lost Time, only the most naive would expect their project to run without a problem. Projects and their attendant stakeholders are a potential source of much grief and suffering, all be it at a lower level of intensity; schedule slippage test failures, cost overruns and accidents to name a few.

As identified by de Botton, bad sufferers try to hide the problems, blame others and learn nothing. Ethical and effective project managers accept their suffering and use the experience to grow their knowledge and capabilities. Quoting Proust, “Griefs, at the moment when they change into ideas, lose some of their power to injure.”

No one likes a project that fails! However, it is only when you are experiencing the pain of failure, the opportunity to learn from the failure opens up. By using the opportunity to maximise the lessons learned, you minimise the potential for similar problems in the future. The cost of the failure is the coin by which future gains are purchased. The difficulty is developing the level of understanding needed to really achieve valuable lessons learned; finding the ‘cause of the cause’. The second more complex challenge is ensuring the lessons learned are transferred to the organisations store of knowledge and available for others to use and thereby avoid unnecessary pain and suffering.

De Botton suggests being a ‘good sufferer’ does not entail subscribing to the Romantic cult of suffering for its own sake, rather making practical use of the occasions when suffering is unavoidable to create new insights and grow in capability or knowledge. Our addition to this basic idea for the practicing project manager is to then make sure the lessons learned are effectively distilled, recorded and made available to others for the future benefit of the organisation and the profession.

Complex Decision Making Explained

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.

The Effective Management of Time in Complicated Construction Projects

The CIOB is finalising the publication of ‘The Guide to Good Practice in the Effective Management of Time in Complex Construction Projects’ with a public consultation period planned before Christmas leading to publication in 2010.

The primary purpose of this Guide is to set down the standards of project scheduling necessary to facilitate the effective and competent management of time in construction projects by defining the standard by which project schedules will be prepared, quality controlled, updated, reviewed and revised in practice.

Before embarking on the guide, the CIOB conducted a survey between December 2007 and January 2008 of the state of time management in a range of UK construction projects. The outcome of the survey was surprising. On simple construction projects, the range of outcomes (late, on time, early) were more or less the same regardless of the use or non-use of effective time management processes.

However, as the projects became more complicated, the difference between projects with an effective time management system and those without became significantly more noticeable. Projects with a well defined time management system were far more successful than those without!

The definition of simple and complicated derived from this study is:

• Simple Projects comprise those in which construction has the following characteristics:
  • design work is completed before construction starts;
  • single building or repetition of identical buildings;
  • less than 5 stories high;
  • without below-ground accommodation;
  • carried out to a single completion date;
  • without phased possessions or access;
  • with services not exceeding single voltage power, lighting, telephone, hot and cold water and heating;
  • a construction period of less than 9 months;
  • with a single contractor; and
  • with less than 10 sub-contracts.
• Complex Projects comprise those in which construction comprises, one or more of the following characteristics:
  • design work is to be completed during construction
  • more than one building
  • more than 5 stories high
  • with below-ground accommodation
  • with multiple key dates and/or sectional completion dates
  • with multiple possessions or access dates
  • with short possessions
  • with services exceeding single voltage power, lighting, telephone, hot and cold water and heating.
  • accompanied by work of civil engineering character
  • a construction period greater than 12 months
  • with multiple contractors
  • with more than 20 sub-contracts

This opens the question why? I would suggest the likely answer, transferable to any project and any industry, is in two parts; both related to stakeholders and communication.

The initial benefit of the process of developing the schedule on a complicated project is the insights the act of creating the schedule gives to the project management team. It is impossible to effectively communicate to the project team and other stakeholders what has to be done when if the project management group don’t have a very clear idea themselves.

‘Simple projects’ are small enough and routine enough to be mapped out in an experienced managers mind. The person intuitively knows what needs to be done. As the project becomes more complex the analysis and serial decision making inherent in the schedule development process creates insights, new information and allows the testing hypothesis until an acceptable solution is devised. At the end of the planning process, a way forward has been determined, optimised and agreed.

The greater benefit though is likely to be in the area of coordination and communication during the work of the project. No schedule is ever perfectly correct. But having an agreed schedule that everyone works towards achieving minimises coordination issues and as elements of the work occur out of alignment with the schedule, the schedule and the variance information provide the foundation for proactive discussion and decision making.

A final intangible benefit of having a schedule has been identified in new research by Jon Whitty. It would appear that simply having a schedule is important for the credibility of the project manager. The project manager’s managers expect the PM to have a schedule and consequently give more credibility to communications from the PM if the schedule is present.

The challenge facing both PMs and their managers as a consequence of these findings is to determine for their industry the difference between simple projects where minimal systems are needed and complicated project where not having a reasonably sophisticated system to help manage time, and other elements of the project, is a distinct liability.

It would seem size does matter! And the old saying ‘if you fail to plan, you plan to fail’ really only applies to the larger more complicated projects. 

Mosaic has developed a range of papers on the art and science of planning and scheduling available from Mosaic’s Planning and Scheduling Home Page.

Thoughts on Agile

Following on from a rather lengthy on-line discussion covering various aspects of the interface between the Agile software development methodologies and project management, we have developed a discussion paper that looks at how the two processes can be integrated.

The paper is a ‘work in progress’ aimed at business managers who are new to the concepts of Agile (ie, it is not intended as an Agile manual for IT professionals). Any comments will be appreciated.

The paper can be downloaded from: http://www.mosaicprojects.com.au/PDF/Thoughts_on_Agile.pdf

High Performance Project Management

I have just seen some information on a 2007 survey undertaken by the PMO Executive Council (part of the Corporate Executive Board: http://www.executiveboard.com/). This snapshot survey, Attributes of a High Performance PM - 2007, found very little correlation between project management certification and project management effectiveness, or the number of years a person has been in project management roles and project management effectiveness.

The survey found the drivers for project management effectiveness were behavioural attributes such as problem solving and the ability to relate effectively with key stakeholders. Whilst many people may initially want to disagree with these findings, they are consistent with many other trends and on reflection quite logical.

Firstly, the survey did not look at the PM’s track record, merely the time the PM had been in project roles. It is reasonable to assume highly effective PMs will have a relatively short PM career and then move on and up the organisational hierarchy. Less effective PMs are likely to stay in their PM role focused on process and technology.

Secondly, whilst PM credentials such as PMP remain very effective tools in the job market; passing your PMP does not make you an effective project manager (see more on PMP). The PMP knowledge framework gives you the knowledge to be an effective project manager. Being effective requires you to become a competent project manager.

Competency has three aspects, knowledge, skills and behaviour:

• what you know,
• your ability to apply the knowledge (essentially personality traits) and
• your willingness to use the skills effectively (essentially behavioural traits).

Qualifying project managers based on behavioural competencies is in its infancy. The Australian Institute of Project Management (AIPM) has recently moved its professional certification program (RegPM) from a procedural view of competency (eg, do you have a project schedule – the artefact?) to a behavioural view of competency (how effectively do you manager the schedule on your project?). This is ground breaking work.

PMI have adopted a different, but similar approach in their program management certification (PgMP) with a 360 degree review testing how effective the candidate is in the workplace. These trends have a long way to go but are likely to be the next step in project certification.

Of more direct interest in the short term is the demonstrated link between how effectively a project manager engages with his/her key stakeholders and high performance outcomes. These skills are a core element in a number of workshops we run including Successful Stakeholder Management and The Science and Art of Communicating Effectively, and are supported in part by our Stakeholder Circle® methodology and tool set.

Learning how to apply the skills in the workplace though is not quite as simple as attending a workshop or buying a set of tools. Soft skills are very hard to acquire and use. My feeling is they are called ‘soft’ because they change shape and texture depending on the environment they are being applied within. The calculations for EV or CPM are universal; the best way to engage a senior stakeholder is totally dependent on the culture of the organisation. Some elements remain consistent (eg, the need for an effective relationship) but the way this is achieved varies.

Developing these advanced skills that are the attributes of high performance project managers requires context sensitive coaching and mentoring rather then formal courses (see: Executive PM Coaching & Mentoring). Ideally organisations seeking to develop high performance PMs will move beyond certification towards implementing internal mentoring systems – it’s the best way to ensure they are contextually relevant.

However, where we differ from the survey findings is that we believe certifications such as PMP are still relevant. Passing a PMI credential such as PMP or CAPM (see more on the PMI credential framework) is a positive demonstration of the initial knowledge component of competency; it’s just that knowledge alone is not sufficient.

Achieving this next level of high performance PMs will also require organisational competence in at least two domains. Process competence measured by tools such as PMI’s OPM3® framework and relationship management maturity measured by tools such as my SRMM® framework.

These are definitely interesting times for our profession.

Agitating Agile

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.

Short termism -v- long term survival

Since being elected a Fellow of the Australian Institute of Management earlier this month, I have been receiving an interesting flow of new information. Two items in today’s reading are the results of an AIM survey that indicates 51% of managers believe that ‘short termism’ is a major issue of concern, 63% thought companies had a relatively short life span and 15% of company board members and CEOs surveyed were not confident their organisation would be in existence in 5 years time (source: AIM Surveys).

Contrast these views with the approach taken by one of Australia’s largest and oldest companies, BHP Billiton. BHP is preparing to spend $15 billion in South Australia to add an open-cut phase to its existing Olympic Dam underground mine. This development will involve digging more than 1 million tonnes of dirt a day for six years, before getting a dollar back. Certainly the production capability at the completion of the development in 16 years time will be massive. The ultimate aim is to boost annual uranium production at the mine from 4,500 tonnes a year to 19,000, copper from 235,000 tonnes to 750,000 and gold from 100,000 ounces to 800,000. Silver, produced as a by-product, will rise from 800,000 ounces to 2.9 million a year. At current prices that works out to annual mineral production valued at $6.2 billion (source: Forbes Asia Magazine dated July 13, 2009).

This raises two interesting thoughts. Firstly BHP must have immense confidence in the ability of its project and program managers to consistently deliver over the next 16 years. There is no easy exit point in the project – the pit needs to be 300 meters deep before encountering any of the ore body (the first six years work) and then there is the need for a series of expansions over the following 10 years to reach maximum output.

The second is the relationship between BHP and its stakeholders. The level of trust needed to accept the investment of $15 billion over 6 years in anticipation of a payback in later years is enormous. The only way this level of trust can be developed is through a long term process of effective stakeholder management linked to a track record of successfully delivering value (ie, keeping your promises).

I would suggest there are some interesting lessons to be learned from juxtaposing these two items. What do you think?

The Scope of Change

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.

PMI Launches the PMI Agile Community of Practice

The Agile Community of Practice is dedicated to raising awareness of Agile practices and techniques among PMI’s members. Its focus will be on building an emerging knowledge base using wikis, blogs and discussion threads. Plus additional resources include articles, tools and techniques, links to Agile project management literature and more. During the launch, membership is free to PMI members.

For more information see: http://www.pmi.org/GetInvolved/Pages/PMI-Specific-Interest-Groups.aspx

The collaborative management paradigm inherent in Agile – a new frontier

The Agile software development methodology has a fascinating range of ideas that can provide valuable learning’s to traditional project managers and in the wider sphere of stakeholder management.

Over the last few months I have been publishing a series of posts on this topic on the PMI Voices on Project Management blog. The key posts with a brief summary and links are:

Agile: The Great Debate
An overview of the Agile software development methodology and its impact on project management.

Creating Trust in Agile
Managing upwards, the trust and communication needed for Agile to succeed.

The Role of Agile Advocates
Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements.

The Gentle Art of Managing Agile
Applying the PMBOK to managing Agile projects.

Learning From Agile
The importance of customer engagement and going ‘light and lean’.

I invite you to read these posts and think on your project management and/or stakeholder management practices.