Tag Archives: project typology

Taking the Myki (or should that be Mickey)?

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.

Project Management 2.0

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- Tradtional PM

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

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_Papers/P109_Thoughts_on_Agile.pdf


As readers of this blog and our published papers would know I have a passing interest in complexity theory and its application to project management. This seems to be an expanding area of interest world wide.

Last night I was at the PMI Canberra Chapter presenting a summary of my paper ‘Scheduling in the Age of Complexity’ [download the paper] – another good reception for the ideas but more importantly several people in the audience were involved in parallel lines of enquiry. Possibly of most interest is the ideas of Graham Durant-Law see his blog at http://www.durantlaw.info.

Another interesting development is a new publication from PMI, Exploring the Complexity of Projects written by Svetlana Cicmil, Terry Cooke-Davies, Lynn Crawford and Kurt Richardson [see: http://www.pmi.org/Marketplace/Pages/Default.aspx] A quick skim suggests this is a comprehensive round up of the current state of complexity theory in project management. More on this once I have had a chance to read it.

What is gratifying is seeing the confusion created by the so called ‘College of Complex Project Managers’ and Prof. David Dombkins receding rapidly into obscurity. Rather than the confusion caused by the ‘college’ treating large complicated programs of work as a synonym for complexity theory (as Dombkins did in the original College manifesto); thought leaders world wide seem to be:

The work on understanding complexity in project management has a long way to go and will undoubtedly be the subject of future blogs. Your contribution to the discussion will be welcome.

Complex Projects

Further to two earlier posts on the subject projects aren’t projects I have run across an interesting journal paper from Jon Whitty focused on Complexity.

A number of organisations are promoting the concept of ‘complex project management’; many other commentators, including me, feel complexity is a factor in every project. The elements of complexity theory include non linearity, emergence and unpredictability. In project management space, this translates to the interactions of people involved in and around the project to each other and to the project work (for more on this see A Simple View of Complexity in Project Management).

Jon’s paper reinforces the argument that projects have multiple dimensions and additionally projects and programs are quite different. Whilst there is likely to be a correlation between size and complexity, the two dimensions are not directly related! To read more see:

Projects aren’t projects – Typology

Following on from my first post on ‘projects aren’t projects‘; one of the more established ways of describing projects is a typology that maps the interaction of uncertainty and technical difficulty. Knowing both ‘what to do’ and ‘how to do it’; or more importantly knowing how much you know about these two elements. The typology was developed by Eddie Obeng in the Project Leader’s Secret Handbook.

Project Typology

Project Typology

The typology asks two questions:

  • Are you clear about what to do (the outcome to be achieved)?
  • Do you know how to do it (processes, methods, experience)?

Painting by Numbers
Traditional project management works well when both ‘what’s to be done’ and ‘how to do it’ are well understood by all key stakeholders including the client and the project team. Closed projects (panting by numbers) can be fully defined, estimated, planned, etc. There are low levels of uncertainty and ambiguity, risks are largely known and manageable. Value is largely achieved by delivering the requirements on time and on budget.

A typical software project of this type would be installing a software upgrade into an office where the same upgrade had been previously installed in several other locations.

Going on a Quest
In these projects, the objective is clear but the way to achieve the objective is uncertain. At the end of the day, success or failure is clear cut; the objective has been achieved (or not). The challenge is optimizing the way forward. Process and system improvement projects tend to fall into this category. The objective is to reduce processing time by 20% – this is easily measured on the completion of the project. The difficulty is knowing what’s the best way to achieve the objective. Improving the user interface, simplifying the work flow, speeding up network traffic and processing times or a combination? Ambiguity is low – we know what’s needed, uncertainty is high – we are not sure how to achieve it.

Before committing major resources to the main work of the project adequate time has to be allowed to prototype solutions and test options before a final design solution can be determined and then implemented. The project needs to be developed in phases with go/no go gateways as the design is firmed up. There are risks associated with any creative design process and most software projects are ‘quests’ requiring creative solutions to identified problems to achieve the desired objective.

Making a Movie
In these projects the tools and techniques are well known but the final outcome is uncertain. Only after the project is complete can the results be measured and the success or failure of the project determined. Most culture change projects and marketing projects (and making movies) are in this category. The tools to be used including: training, communicating, advertising, etc are well known and the traditional (if not optimal) mix of techniques understood for most situations. What no one can predict is if the ‘public’ will acclaim the final result, merely accept the final result or dump the final result.

Traditional project management is not enough in these projects; there is a continual need to measure results, feedback information and adapt the mix of activities to optimize the likelihood of success. The key value measurement is attempting to answer the question is it worth spending more or should we cut and run? Efficient stakeholder communication and relationship management is crucial. Whilst there will be some outstanding successes (block busters) and some total flops most projects in this category finish somewhere in the middle. The art is spending just enough effort to achieve an acceptable outcome – dealing with shades of grey.

Lost in the Fog
I actually prefer Prof. Rodney Turner’s version ‘a walk in the fog’. This project is a journey towards a desired new state. No one is sure of the optimum outcome, or how best to achieve it. The only option is to proceed carefully, stop at regular intervals to check exactly where you are and re-plan the way forward. Exactly the way you navigate through a thick fog. Both ambiguity and uncertainty are high.

Project management is about making sure at each ‘stop point’ the value achieved to date is locked in and then refocus on the next increment. Agile software development is ideal for this type of project. Each iteration builds new capability and value and the learning provides a platform for the next iteration of development.

Management is both easy and difficult. It is easy because there is no point in setting fixed plans (you have no idea what to plan). It is difficult because decisions on value and whether to stop or continue are subjective and need to be made in a collaborative environment of trust. Traditional measures of success such as on-time and on-budget are largely meaningless; typically there are no statistics to base this type of measure on. Consequently these projects are the realm of cost reimbursable contracts and partnerships; stakeholder relationship management, and a clear understanding of value are the only effective tools for building to a successful outcome.

Two final thoughts
The skills required of a project manager change from largely technical if the project is ‘painting by numbers’ to almost completely relational to manage a ‘walk in the fog’. For more on this see: Tapping the Power Lines and The Accidental Project Manager – The Getting of Wisdom

Both the client/sponsor and the project team need an understanding of the type of project and agree to configure the project management processes appropriately. The more uncertainty and ambiguity, the more important the project  client is to achieving project success!

More later.

Projects aren’t Projects

Project management is not a one-size-fits-all process or discipline. The PMBOK® Guide makes this clear in Chapter 1. There are at least 4 dimensions of a project,

  • its inherent size usually measured in terms of value;
  • the degree of technical difficulty (complication) involved in the work;
  • the degree of uncertainty involved in defining its objectives; and
  • the complexity of the relationships surrounding the project.

Project Size
The size of the project will impact the degree of difficulty in achieving its objectives but large projects are not necessarily technically complicated or complex. There are projects in Australia to shift millions of cubic meters of overburden from mine sites with expenditures rising to several $million per day but the work is inherently simple (excavating, trucking and dumping dirt), and the relationships in and around the project are relatively straight forward. The management challenges are essentially in the area of logistics.

Technical Difficulty (degree of complication)
Complicated high tech projects are inherently more difficult to manage than simple projects. The nature of the technical difficulties and the degree of certainty largely depend on how well understood the work is. The important thing to remember with complicated work though is that systems can be developed and people trained to manage the complications. The work may require highly skilled people and sophisticated processes but it is understandable and solvable.

The degree of uncertainty associated with the desired output from the team’s endeavours has a major impact on the management of the project. The less certain the client is of its requirements, the greater the uncertainty associated with delivering a successful project and the greater the effort required from the project team to work with the client to evolve a clear understanding of what’s required for success. This is not an issue as long as all of the project stakeholders appreciate they are on a journey to initially determine what success looks like, and then deliver the required outputs. Budgets and timeframes are expected to change to achieve the optimum benefits for the client; and the project is set up with an appropriately high level of contingencies to deal with the uncertainty. Problems occur if the expectations around the project are couched in terms of achieving an ‘on time, on budget’ delivery when the output is not defined and the expected benefits are unclear. Managing uncertainty is closely associated with and influences the complexity of the relationships discussed below.

Complexity = The People
Complexity Theory has become a broad platform for the investigation of complex interdisciplinary situations and helps understand the social behaviours of teams and the networks of people involved in and around a project. These ideas apply equally to small in-house projects as to large complicated programs. In this regard, complexity is not a synonym for complicated or large. It focuses on the inherent unpredictability of people’s actions and reactions to ideas and information within the network of relationships that form in and around the project team.

Size is straightforward and most organisations have processes for assigning more experienced project managers to larger projects. What’s missing is consideration of the other three aspects.

The last item, complexity is very much an emerging area of thought and discussion. For a brief overview see: A Simple View of ‘Complexity’ in Project Management  and for some practical considerations of the impact of complexity theory on scheduling see: Scheduling in the Age of Complexity. However, I expect it will be some years before ‘complexity theory’ and project management sit comfortably together.

Of more immediate interest is the interaction of uncertainty and technical difficulty. Knowing both ‘what to do’ and ‘how to do it’; or more importantly knowing how much you know about these two elements is critically important in establishing a framework to manage a project. Some ideas on this topic will be the subject of my next post.