Monday

Tag Archives: Scope Management

Scope for improvement 4

Posted on July 3, 2014 by | 2 comments

A couple of interesting things happened on the 1st July,  the first was being invited to a wonderfully old-fashioned business lunch by Ashurst Lawyers with Champaign and fine wines – a far too frequent event in these days of OH&S liabilities……  The second was attending the preview of the Bell Shakespeare’s interpretation of Henry V.  You may wonder what the connection is.

Henry V has a number of memorable speeches focused around battling insurmountable odds to overcome adversity…… ‘Once more dear friends unto the breach let us block the gap with [engineering] dead’,  ‘We few, we happy few, we band of brothers. For he to-day that sheds his blood with me shall be my brother …..’.  Stirring stuff given the character assassination most of the Plantagenet Kings suffer at the hands of the Bard. Which brings me back to the lunch.

Ashurst were launching the fourth report in the ‘Scope for Improvement’ series looking at the management and delivery of mega projects in Australia.  And unfortunately it really was a case of ‘once more dear friends……’  The title of the original 2006 report was derived from its major finding that scope was routinely omitted from tender documentation for mega projects.  The second report 2008 identified the consequences from scoping inadequacies. Survey participants attributed cost overruns (61%), delayed completion (58%) and disputes (30%) to scoping inadequacies. Further, scoping inadequacies had resulted in 26% of the $1 billion+ projects surveyed being more than $200 million over budget.  In 2006 and 2008 there was definitely ‘scope for improvement’; in 2014 the situation remains fundamentally unaltered.

The research for the 2014 report used a qualitative approach starting with discussions over lunch with some 130 executives (primarily from the organisations involved in the Australian Contractors Association), the discussions were documented and the emerging hypotheses tested in focused one-on-one interviews. This methodology has undoubtedly generated some interesting and important insights to the challenges faced by the major projects industry; but unfortunately the methodology prevents a precise trend analysis on this major area of concern. All we know for sure is it remains a major area of concern.

Probably the most telling insight in explaining the reason for the continuing omission of scope is the imposition of unreasonable time pressures to complete the work.  This pressure comes in part from the lack of any overall strategy on the part of the clients that defines the need for the project, meaning there is no ‘master plan’ to provide a framework for developing the project’s scope in a sensible timeframe.  This is a fundamental governance failure – very few mega-projects need to undertaken in ‘panic mode’.

The second insight is the effect of perceived ‘political imperatives’ that push governments and/or organisational executives to simply demand the work be accomplished in an unreasonably short timeframe. For some reason a completely unnecessary need for speed seems to have come to dominate executive decision making.  This demand for excessive speed will always drive up cost, increase risk and reduce quality.  This is equally true of a small $50,000 IT project as it is of a $multi-billion infrastructure project such as the National Broadband Network.

The only option to achieve excessive speed without compromising quality too much is to employ highly skilled people with direct experience of the work.  But as another section of the ‘Scope for Improvement’ report highlights, skills are in very short supply and only half the people in any group can be ‘above average’ – you simply cannot achieve ‘above average performance’ all of the time.

Certainly there will always be a limited number of projects where speed is an imperative, for most a combination of better strategic planning so the work is started at the right time and/or simply allowing adequate time will produce far better quality outcomes at a significantly reduces cost. Getting this balance right, and requiring management to have the right systems in place to avoid unnecessary ‘time pressures’ is a key governance imperative.

Simply having an immovable deadline is not an excuse. The London Olympics infrastructure was started ‘early’, properly resourced from the beginning, used appropriate procurement systems and finished a year ahead of the opening ceremony with no fatalities. Contrast the success of this project to similar ones in New Delhi and Rio de Janeiro where strategic decisions were not made at the right times, pressures to ‘increase speed’ developed and cost, quality and safety all suffered (or in the case of Brazil, are suffering).

The current ‘Scope for Improvement’ report identifies a range of solutions to this problem:

  • Clearly identify the project objectives.
  • Education on the importance of scoping.
  • Allow sufficient time allowed to prepare the scope
  • Employ sufficient personnel of the right quality to prepare the scope. Including providing adequate training for the personnel involved in preparing the scope.
  • Choose the right delivery model and the right method of describing the scope (performance based where appropriate).
  • Get the right people involved, with a collaborative process to obtain input from key stakeholders (including the end users).

Another area of the report that will be discussed in a later post is the interlinked topics of productivity, innovation and training. In the meantime, the Scope for Improvement reports can be downloaded from: http://www.ashurst.com/publication-item.aspx?id_Content=10561&langId=1

2 Comments

Posted in Governance, Scope Management

Tagged , , , , , , , , ,

Taking the Myki (or should that be Mickey)?

Posted on January 23, 2010 by | 3 comments

Myki is another $billion plus government IT project that is years late, $100s of million over budget and that has been de-scoped to the point where there is almost no point in continuing.

Mickey or Myki??

The city of Melbourne, Australia, desperately needs an updated public transport ticketing system. Several years ago a grand scheme was developed that became Myki. Myki was intended to be the key to city living; acting as a cash card, transport ticket and fulfilling a range of other useful functions for the citizenry.

Because of its wide scope, existing public transport ticketing systems in use around the world were deemed not acceptable; the Government needed a brand new special system designed for the unique needs of Melbourne.

Several years and $100s of millions later a majorly de-scoped Myki that is purely a public transport ticketing system may eventually be launched and actually work. The latest commitment made this week is for the system to be working by the end of 2010. This is identical to the commitment made mid 2009 after an earlier commitment for the system to be working by mid 2009 slipped.

I am sure there will be books written on this project and it may even contribute to the demise of the current Government at the elections next year but for now I want to take a quick look at some of the common governance failures Myki seems to have suffered from.

  1. The NIH problem – an amazing number of organisations seem to believe that the only acceptable solution is something developed exclusively for them. NIH = Not Invented Here; if it’s not NIH, it cannot be any good. Generally the arrogance associated with NIH is closely aligned with the pride before a fall.
  2. The internal SES problem. SES = Simple, Easy, Safe. This is a very dangerous and surprisingly common problem particularly in government and defence bureaucracies. To obtain funding approval, the bureaucrats promoting a project need to convince a risk shy decision maker (typically a Cabinet) that the project is simple and well understood, easy to implement and there are no significant risks to time, budget and performance parameters.
  3. The external SES problem. SES = Simple, Easy, Safe. To win the work, the successful contractor has to convince the client’s decision-making team, that the project is simple and well understood, easy to implement and there are no significant risks to time, budget and performance parameters and their bid can be relied upon.
  4. The intrinsic knowledge problem. SES can only flourish in an environment of ignorance. This may be wilful ignorance where people do not wish to hear or organic where senior decision makers simply do not know what they do not know. SES also needs an organisational culture that prevents more knowledgeable junior staff from properly informing their seniors of the real issues. Typically in these circumstances senior decision makers will take the advice of external advisers who have a vested interest in promoting their version of SES over the opinion of internal expert’s who are too junior.

The first interesting decision around Myki was the selection of the company to deliver the ‘project’. None of the organisations world-wide who had real, current knowledge of developing and installing ticketing systems were successful. They probably understood the challenges and issues and priced accordingly. The winning contractor and the government would appear to have happily accepted SES!

As a consequence of SES, everyone has continually talked about the Myki project, with a fixed timeframe and budget. As originally scoped Myki was a major program of work. Managed as a program with the progressive delivery of value by a series of carefully scoped projects the outcome may have been very different. However, accepting Myki as a program would have meant there could be no pretence of certainty concerning the overall timeframe or budget. The Government would have had to accept there was uncertainty (risk) and managed the overall program to create value for the tax payers and transport users.

This level of risk management maturity may be impossible in a political environment. The consequence though is cost overruns, time overruns and a major reduction in value through de-scoping. However, if proper value management systems were in place within a program management framework, many of the ‘bright ideas’ from Senior Ministers and bureaucrats that moved in and out of scope cold have been far more effectively assessed, managed and where they contributed value, implemented.

Effective project and program governance is not about eliminating risk, this is never possible; it’s about understanding and managing risk. One of the key conclusions in my paper The Meaning of Risk in an Uncertain World was that the client bears the ultimate risk for any project, if the project fails, the client pays the costs. Contracts rarely provide protection against the consequences of a fundamental failure!

The first critical step in effective and ethical program and project governance is to fully understand the parameters of the work (see: Eddie Obeng’s typology in Projects aren’t projects – Typology), and then managing the risks and delivery mechanisms appropriately. My prediction is the post-mortems on Myki will show root cause of most of the issues was a treating a ‘Walk in the fog’ program to resolve a problem as a simple ‘Painting by numbers’ project. If this prediction holds true it will demonstrate a fundamental failure of governance.

Watch this space for more…… in the meantime I have applied for my Myki card and do expect to use it sometime in the not too far distant future.

3 Comments

Posted in Stakeholder Management, Value

Tagged , , , , , , , , , , , , , , , , , , , , , , ,

Project Management 2.0

Posted on September 27, 2009 by | 5 comments

Project Management 2.0 (PM 2.0) seems to be going the same way some Agile anarchists are trying to take software development which is essentially not to do project management and hope a group of people with good will and good luck will create something useful.

Not doing ‘project management’ is a really good idea if you and your client have no idea what’s needed, when its required, or how much budget is available. Journeys of exploration can be fun and can be highly creative but are nothing to do with managing projects.

Wikipedia (retrieved 27/9/2009 from: http://en.wikipedia.org/wiki/Project_management_2.0) lists the following differences between PM 2.0 and ‘traditional’ project management.

PM 2.0 -v- Traditional PM

Whoever wrote this has absolutely no idea what good traditional project management looks like and has probably never worked on a successful major project. Good traditional project management differs from this highly subjective and biased list in many ways:

  • Control is not centralised, authority and responsibility are devolved to the appropriate management levels.
  • All good project management is based on collaboration.
  • All good project management requires open access to the plan both as an input to its creation and to know what needs doing during delivery.
  • Access to information is vial when and where needed.
  • Open and effective communication is critical.
  • Project are,  by definition, separate management entities – a holistic approach (ie, not doing projects) is called general management.
  • Tools, see: A fool with a tool is still a fool, and you need the right tools for the right job. Amateurs try to do jobs with inappropriate tools. Easy to use and flexible are fine if you know exactly what you are doing, it is a recipe for wrong information and wrong decisions if you don’t.

The table is correct in so much as project management involves a degree of top down planning. Project management is about delivering a required output to the specifications requested by the client. The product or service is a failure if it does not meet the quality requirements set by the customer; which may include time, cost and scope parameters.

It is also correct in respect of the implied structure – projects work because there is an implied structure that sets a framework for collaboration. If you don’t know who is doing what it is nearly impossible to collaborate. Even Wikipedia and Linux have structure in their collaborative frameworks.

I have emphasised good project management throughout this post. Bad project management involves excessive attempts to ‘control the future’, lack of stakeholder involvement, excessive bureaucracy, and many other problems. These traits are bad management full stop.

One comment on the Wikipedia article is important though: PM 2.0 is good for small jobs. This is consistent with a survey of construction projects in the UK undertaken by the Chartered Institute of Building, focused on time management, which found that on ‘simple projects’ there was no difference in performance between those projects with a properly developed and managed schedule and those without. The same proportions finished early, on time and late.

However, as soon as the projects became ‘complex’; there was a marked difference in performance. Projects with effective schedule control performed significantly better than those without, and the bigger/more complex the project, the more significant the difference. ( I will put up a post on the CIOB’s work and its new practice standard for scheduling in a few days).

The CIOB’s findings and a closer look at many of the blogs and comments on both PM 2.0 and Agile seem to fit this trend. I would suggest two conclusions could be drawn:

  1. If the work is small, simple and easy to understand there is no need for much in the way of traditional project controls. Knowledgeable people know what needs to be done and can just get on with the work.
  2. If the required output is not capable of being determined by the client and the objective is to ‘create something wonderful’ it is very difficult to apply too many project management techniques – basically you don’t know what needs to be planned, costed and scheduled, etc. Time and cost are secondary to creativity and the exploration of problems.

In both of these circumstances traditional project management may not be appropriate. In fact I would question if either circumstance is actually a project given the definition of a project is to produce a defined product, service or result that meets the needs of a customer.

The challenge for senior organisational management is recognising the threshold where PM 2.0 and ‘free form Agile’ cease to be appropriate and more traditional forms of project management are needed. Traditional project management does not mean ridged control, the type of project influences what’s needed (see: Projects aren’t projects – Typology) but appropriate systems do help optimize cost, time and quality to deliver client satisfaction.

This does not mean dumping the new ideas, rather melding them into an improved project management process. Agile software development fits in nicely to ‘rolling wave’ planning. Similarly some aspects of PM 2.0 can really help enhance team communication and collaboration. Used wisely, these ideas and technologies simply help improve the way projects work to deliver quality outputs to their clients. This change is really no different to the shift from faxes and carbon copy paper to emails. Good project management has always adapted to use improvements in processes and technology to improve the quality of service provided to the project’s clients. This next wave of improved technologies should be no different.

However, be wary of the zealots suggesting the ‘old ways’ don’t work and should be abandoned and use examples of really bad project management to prove their point. This is even more important if the zealots also advocate employing them to solve all of your problems for a fee. Management fads come and go – modern project management has been generally successful in achieving positive outcomes for well over 50 years now and continues to evolve and improve. For further comment see Glen’s post on: Herding Cats

5 Comments

Posted in Agile Ideas, General Project Management, IT Project Management, Project Typology, Stakeholder Management, Value

Tagged , , , , , , , , , , , , , , , , , , , , , ,

The Scope of Change

Posted on July 26, 2009 by | 3 comments

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.

3 Comments

Posted in Change Management, Scope Management, Value

Tagged , , , , , , , , ,

Value is in the eye of the stakeholder

Posted on March 28, 2009 by | 10 comments

The only purpose of undertaking any business activity is to create value! If undertaking the work destroys value the activity should not be started.

The Value Chain

Any value proposition though is ‘in the eye of the stakeholder’ – this is rarely solely constrained by either time or cost. Effective value management requires an understanding of what is valuable to the organisation and the activity to create value should be focused on successfully delivering the anticipated value.

The chain of work starts with a project or similar activity initiated to create a new product, service or result. However, the new output by itself cannot deliver a benefit to the organisation and the project manager cannot be held responsible for the creation of value. The organisation’s management has to make effective use of the output to realise a benefit. It is the organisations management that manages the organisation and these people need to change the way the organisation works to realize the intended benefit. The role of the project team in value creation is to ensure their output has all of the necessary characteristics and components to allow the organisation to easily adopt the ‘new output’ into it’s overall way of working (eg, effective training materials).

The outcome from making effective use of the output is expected to create a benefit – however to realise a benefit, the outcome needs to support a strategic objective of the organisation. If the outcome is in conflict with the organisations strategy, value can still be destroyed. Strategic alignment is not an afterthought! The processes to initiate the project should have as a basic consideration its alignment with the organisations strategic objectives.

Assuming strategic alignment is achieved, the realised benefits should translate into real value. The challenge is often quantifying value – the concept of ‘value drivers’ helps. Value drivers allow the benefit to be quantified either financially or by other less tangible means.

In the current economic climate, organisations are finding operating capital in short supply. Therefore a new process to accelerate the billing cycle can be measured at several levels:

  • The output from the activity to develop the new billing process is simply the new process – this has no value.
  • Once the organisations management starts using the new process the measurable outcome is a reduction in the billing cycle from (say) 45 days to 32 days.
  • The benefit of this reduction in the billing cycle could be a reduction in operating capital needs of $500,000.
  • The value of this reduction is $500,000 at 12% interest = $60,000 per annum.
    The above example may also trigger additional value by allowing the capital to be redeployed into another profit generating activity, improving customer relationships, etc.

Once the whole organisation is aware of the value proposition, decisions to de-scope the initial work to meet time constraints and/or cost constraints can be made sensibly.

  • A decision to de-scope the project to achieve a 2 week saving in time that results in a 6 week longer implementation period (eg, by reducing training development) is clearly counterproductive.
  • Similarly a decision to de-scope the project to avoid a $5,000 cost overrun that changes the reduction in the billing cycle time from 13 days to 6 days will result in a halving of the capital saving and a cost increase to the organisation of $30,000.

The challenge is identifying and communicating the value drivers to all levels of management involved in the activity so that valuable decisions are made in preference to knee jerk gut reactions focused on short term, easy to measure metrics. Value is created by meeting the strategic needs of the organisation’s stakeholders – this requires careful analysis and understanding of who they are and what are their real requirements; ie, effective stakeholder management.

For more ideas on the realisation of value, see the work by Jed Simms at: http://www.valuedeliverymanagement.com/

For more on effective stakeholder management see: http://www.stakeholder-management.com

10 Comments

Posted in Change Management, Stakeholder Management, Value

Tagged , , , , , ,

Defining Project Scope

Posted on November 21, 2008 by | Leave a comment

If a project’s client cannot ask for what it needs, the project team is highly unlikely to deliver what’s wanted!  A key element in effective project stakeholder management has to be asking enough questions to ensure everyone understands what the project is to deliver.

On Thursday 20th November 2008, I was privileged to attend the launch of a new report,  ‘Scope for Improvement 2008’, focusing on the issues of scope definition in major Australian construction projects. The total value of projects surveyed was approximately AU$60 billion with an average project value of AU$360 million.

The 2008 survey has shown a slight deterioration from the initial 2006 survey, in the overall performance of the industry in developing adequate project scoping documents. The 2008 findings also show inadequate scope specification is now an endemic problem in Australia with a growing trail of budget blowouts, delays and disputes.

The worry is the construction and engineering industries are generally seen as being far more mature in their project management practices then most other sectors of the project management industry and Australia has one of the more advanced industries world-wide. The key findings from the report, outlined below, are a salient lesson for anyone involved in defining the scope for a project:

Key Findings and Recommendations of the report:

The present situation:

  • There is a high prevalence of deficient scoping in Australian construction and infrastructure projects with over 50% of projects being inadequately scoped prior to going to market.
  • Scoping inadequacies are being discovered far too late with 64% of deficiencies only being discovered during execution.
  • The consequences of poor scoping are significant: 61% of project experienced cost overruns, 58% delays and 30% contractual disputes.

The main factors contributing to poor scoping:

  • Lack of experienced and sufficiently competent personnel with 83% of projects reporting adverse effects. This is to an extent explainable by the construction boom of the last few years but compensating factors such as increased time and/or contingencies do not seem to have been allowed.
  • Insufficient time to prepare the scope documents.
  • Inadequate definition of project objectives by the principal resulting in subsequent changes to the scope and corrections to the scope documents.
  • Lack of consultation with end users, insufficient clarity of objectives and a lack of understanding of why the project is required and the benefits the project will produce.
  • Insufficient research to understand the environment the project will be executed within.

Practical steps for successful scoping:

  • Industry needs to think and act differently.
  • Clearly identify project objectives.
  • Identify and bring together all relevant stakeholders and end users for the project and maintain their involvement in the scope definition process.
  • Set realistic timeframes and budgets for developing the scope requirements (and the overall project).
  • Interface the proposed project with related projects and existing infrastructure.
  • Identify and establish a core project team early.
  • Empower a project leader with appropriate and clear authority and accountability.
  • Clearly describe the project objective and requirements once identified.
  • Choose the right approach for scope description (performance criteria, detailed specification, etc) and choose the right contract delivery model that aligns with the scope – risk needs to be properly apportioned.
  • Check the overall contract package for consistency.
  • Involve the tenderers / project management team in getting the scope documents right.
  • Capture the value from a successful bid in the final contract.
  • Resolve scoping issues and disputes under a contract.

The research was conducted by partners at Blake Dawson with support from the Australian Constructors Association and Infrastructure Partnerships Australia. A full copy of the report can be downloaded from http://www.mosaicprojects.com.au/Resources.html#Construction

Leave a comment

Posted in Scope Management, Stakeholder Management, Value

Tagged , , , ,