Archive for the ‘Case Study’ Category

Research Featured in Harvard Business Review

Donnerstag, Juli 26th, 2012

After 2 years of researching ICT projects the on-going research has been picked up by the Harvard Business Review and is on the cover of their September 2011 issue.

„Why your IT projects may be riskier than you think?“

By now, I collected a database of nearly 1,500 IT projects – in short we argue that the numbers in the hotly debated Standish Report are wrong, but their critics don’t get it quite right either. We found that while IT projects perform reasonably well on average the risk distribution has very fat tails in which a lot of Black Swan Events hide. 1 in 6 IT projects turned into a Black Swan – an event that can take down companies and cost executives their jobs.

Enjoy the read!

More background reading on the HBR article can be found in this working paper.

Integrating the change program with the parent organization (Lehtonen & Martinsuo, 2009)

Dienstag, April 28th, 2009

DSC02128

Lehtonen, Päivi; Martinsuo, Miia: Integrating the change program with the parent organization; in: International Journal of Project Management, Vol. 27 (2009), No. 2, pp. 154-165.
http://dx.doi.org/10.1016/j.ijproman.2008.09.002

 

Lehtonen & Martinsuo analyse the boundary spanning activities of change programmes.  They find five different types of organisational integration – internal integration 1a) in the programme, 1b) in the organisation; external integration 2a) in the organisation, 2b) in the programme, and 3) between programme and parent organisation.

Furthermore they identify mechanisms of integration on these various levels.  These mechanisms are

  Mechanism of integration
Structure & Control Steering groups, responsibility of line managers
Goal & content link Programme is part of larger strategic change initiative
People links Cross-functional core team, part-time team members who stay in local departments
Scheduling & Planning links Planning, project management, budgeting, reporting
Isolation Abandon standard corporate steering group, split between HQ and branch roll-out

 

Among most common are four types of boundary spanning activities – (1) Information Scout, (2) Ambassador, (3) Boundary Shaping, and (4) Isolation.  Firstly, information scouting is done via workshops, interviews, questionnaire, data requests &c.  Secondly, the project ambassador presents the programme in internal forums, focuses on quick wins and show cases them, publishes about the project in HR magazines &c.  Thirdly, the boundary shaping is done by negotiations of scope and resources, and by defining responsibilities.  Fourthly, isolation typically takes place through withholding information, establishing a separate work/team/programme culture, planning inside; basically by gate keeping and blocking.   

Failure at the Speed of Light (Hickerson, 2006)

Samstag, April 25th, 2009

[Hot stuff! Not because it is fresh or hot of the press, no but surprisingly "Failed Projects" is the most read category on this blog this year with more than 700 readers, runner-up is "Critical Success Factors" and it is catching up quickly. ]

DSC02123

Hickerson, Thomas B.: Failure at the Speed of Light – Project Escalation and De-escalation in the Software Industry, Master of Arts in Law and Diplomacy Thesis, Tufts University, Medford, Massachusetts, 2006.
http://fletcher.tufts.edu/research/2006/Hickerson.pdf

 

Hickerson analyses three case studies – (1) California’s Department of Social Securities implementation of the California Automated Child Support System (CACSS), (2) Denver International Airport, and (3) FBI’s Virtual Case File.

Firstly, CACSS was planned and started in 1992, the tender went to Lockheed Martin for $75m with a go-live in December 1995.  The whole project was cancelled in 1997 after direct expenses of $100m were incurred.  A new version of the system started development in 2000 and finally went live in June 2008 (see this news snippet) and it is online here.

Second case is the Denver International Baggage Handling system.  This case is infamous to the extend that it made it on wikipedia, the full GAO report can be found here.  In short: BAE won the tender for $193m.  The system development had so many problems that in order to open the airport an alternative manual handling system was installed, which came at a price ticket of only $51m; at the time of opening the airport (Feb 1995, 2 years behind schedule anyway) the delays caused by the baggage handling system were estimated to be $360m.  Before United axed the system it cost about $1m per month in maintenance.

Third case is the FBI’s Virtual Case File.  The project started in 2001, quickly reached the typical 90% complete.  After 4 years the solution was replaced by a commercial off the shelf software and another 3 months later the project was cancelled altogether after $607m were spent.

 

Drawing from Social Justification Theory, Agency Theory, Approach Avoidance Theory Hickerson argues that ‚Internal inadequacies in dealing with external threats‘ was the main reason for the failures.  In case of DIA some project factors contributed to the failure such as the investment character of the project, long-term pay-offs, large size of the pay-offs, resources seen as plentiful, setbacks seen as secondary.

Apart from project factors psychological factors contributed to the failure of these cases, e.g., personal responsibility, ego importance, prior success and reinforcement, irreversibility of prior expenditures.  Thirdly social factors were responsible, such as the responsibility for failure, norms for consistency, hero effects, public identification with the course of action, and job insecurity.  Fourthly, structural factors played a role, e.g., political support, institutionalisation, and bureaucracy.

 

What were the tipping points that tipped the projects into escalation?

  • Change in top management support
  • External shocks to the organisation
  • Change in project champion
  • Organisational tolerance for failure
  • Presence of publicly stated resources
  • Alternate use of funds
  • Awareness of problems
  • Visibility of costs
  • Clarity of failure & success criteria
  • Organisational procedures of decision-making
  • Regular evaluation of projects
  • Separation of responsibility for approving and evaluation projects

What needs to be done to prevent escalation?

  1. Strict timeline
  2. Clear acceptance criteria
  3. Daily meetings between CIO and Managers
  4. Adherence to baseline requirements

Human Effort Dynamics and Schedule Risk Analysis (Barseghyan, 2009)

Dienstag, April 21st, 2009

DSC02127

Barseghyan, Pavel: Human Effort Dynamics and Schedule Risk Analysis; in:  PM World Today, Vol. 11(2009), No. 3.
http://www.pmforum.org/library/papers/2009/PDFs/mar/Human-Effort-Dynamics-and-Schedule-Risk-Analysis.pdf

Barseghyan researched extensively the human dynamics within project work.  He has formulated a system of intricate mathematics quite similar to Boyle’s law and the other gas laws.  He establishes a simple set of formulas to schedule the work of software developers.

T = Time, E = Effort, P = Productivity, S = Size, and D = Difficulty
Then W = E * P = T * P = S * D, and thus T = S*D/P

But and now it gets tricky S~D~P are correlated!

The author has collected enough data to show the typical curves between Difficulty –> Duration and Difficulty –> Productivity.  To schedule and synchronise two tasks the D/P ratio has to be constant between these two tasks.

 

Barseghyan then continues to explore the details between Difficulty and Duration.  He argues that the common notion of bell-shaped distributions is flawed because of the non linear relationship between Difficulty –> Duration  [note that his curves have a segment of linearity followed by some exponential part.  If the Difficulty bell curve is transformed into the Diffculty–>Duration probability function using that non-linear transformation formula it looses is normality and results in a fat-tail distribution.  Therefore Barseghyan argues, the notion of using bell-shaped curves in planning is wrong.  

Why Software Projects Escalate – An Empirical Analysis and Test of Four Theoretical Models (Keil et al., 2000)

Montag, Januar 12th, 2009

DSC01459

Keil, Mark; Mann, Joan; Rai, Arun: Why Software Projects Escalate – An Empirical Analysis and Test of Four Theoretical Models; in: MIS Quarterly, Vol. 24 (2000), No. 4, pp. 631-664.

The authors describe that: "Software projects can often spiral out of control to become ‚runaway systems’…".  Keil et al. define escalation behaviour as constantly adding resources to the project.  Thus escalated projects typically overrun their schedule and budget.  The authors describe the case of the Statewide Automated Child Support System (SACSS) of California’s Dept. of Social Services.  The project was started in 1992 with a projected budget of USD 75.5m and a go-live date in 1995.  The project escalated and did cost an estimated USD 345m and was finally terminated in 1997 without any deliverables in place. 

Based on a large scale survey of IS-Auditors Keil et al. found that 30-40% of all software development projects show some degree of escalation.  Then the authors analyse four different theoretical models how to explain escalation – (1) Self-Justification Theory, (2) Prospect Theory, (3) Agency Theory, (4) Approach Avoidance Theory.

Self-Justification Theory – SJT is grounded in Feistinger’s cognitive dissonance, most easily self-justification can be characterised as a retrospectively rationalising behaviour which is found to violate internal or external beliefs, attitudes, or norms.  As the wikipedia article on SJT describes it self-justification typically manifests in two forms internal SJT or external SJT.  Internal SJT strategies are changing the violated attitude, downplaying or denying the negative consequences; whilst external SJT strategies are all sorts of external excuses from bad luck, to lack of competencies.  Keil et al. argue that two effects are relevant for escalation behaviour – social and psychological self-justification.  Whilst psychological self-justification is a strategy to overcome dissonance, social pressures increase the need for self-justification, e.g., saving your face.

Prospect Theory – Kahneman & Tversky’s Prospect Theory and their Cumulative Prospect Theory describes decision-making under uncertainty and risk.  Keil et al. argue that Prospect Theory explains escalation behaviour, because the theory postulates that when choosing between two adverse events, deciders are seeking greater risks.  Commonly this is also referred to as ’sunk cost effect‘.

Agency Theory – Jensen & Meckling’s concept of principal-agent relationships covers many examples of principals delegating decision competencies or execution of tasks to agents.  A principal-agent relationships turns sour (aka principal-agent problem) when goal incongruence and information asymmetry create a constellation of imperfect contracting and monitoring.  In general terms – the agents maximise their self-interest at the expense of the principal.  Simplest real-world example – the software integrator who you hired to do most of your work never wants your project to finish.

Approach Avoidance Theory – Rubin & Brockner’s concept of approach avoidance which is described that every approach vs. avoidance decisions is driven by the iconic little angel vs. little devil.  In the case of escalated projects, these forces either encourage persistence or abandonment of the project.  Three factors explain why projects are not terminated – (1) size of reward for goal attainment, (2) withdrawal costs, and (3) goal proximity.  Keil et al. argue that especially the third factor ‚goal proximity‘ creates a completion effect which is explained by the need for task closure.  They argue that this is a better conceptualisation of escalation symptoms than the sunk cost effect, aka throw good money after bad money.  They describe that completion effects pull an individual towards the goal whilst sunk cost effects push an individual further.  A beautiful real life example is the 90%-completion syndrome:

This syndrome refers to the tendency for estimates of work completed to increase steadily until a plateau of 90% is
reached. Thereafter, programmer estimates of the fraction of work completed increase very slowly. In some cases, inaccurate estimation leads to situations in which software projects are reported to be 90% complete for half of the entire duration of the project, an obvious impossibility (Brooks 1975).

Keil et al. test 6 constructs taken from these 4 theories which were previously connected to escalation behaviour – psychological self-justification, social self-justification, sunk cost effect, goal incongruence, information asymmetry, and completion effect.
With a series of pairwise logistic regression models between the groups of escalated vs. non-escalated projects – all 6 constructs and therefore all 4 theories can empirically be proven.  However the best classifier for escalation vs. non-escalation is the completion effect.

Building knowledge in projects – A practical application of social constructivism to information systems development (Jackson & Klobas, 2008)

Donnerstag, Oktober 23rd, 2008

Building knowledge in projects - A practical application of social constructivism to information systems development (Jackson & Klobas, 2008)

Jackson, Paul; Klobas, Jane: Building knowledge in projects – A practical application of social constructivism to information systems development; in: International Journal of Project Management, Vol. 26 (2008), No. 4, pp. 329-337.
http://dx.doi.org/10.1016/j.ijproman.2007.05.011

Jackson & Klobas describe the constructivist model of knowledge sharing and thus organisational learning. This classical model describes knowledge sharing in organisations as a constant cylcle of

  • Creating personal knowledge
  • Sharing newly created personal knowledge = Externalisation
  • Communication knowledge = Internalisation
  • Acquiring other peoples‘ knowledge = Learning

This cylcle includes the facilitating steps of Objectivation (=creating organisational knowledge), Legitimation (=authorising knowledge), and reification (=hardening knowledge) between externalisation and internalisation.

Jackson & Klobas argue that IT project failure can be explained using this model. The authors outline and discuss three failure factors – (1) lack of personal knowledge, (2) inability to externalise knowledge, and (3) lack of communication.

Graphical Representation of the Project Management Body of Knowledge

Dienstag, Oktober 21st, 2008

Poster (black, horizontal)

Today I woke up very early and created these beautiful pictures summarising all keywords from the last 5 years in the International Journal of Project Management and the Journal of Project Management.

In my lunch break another thought struck me – you need something on that bare wall you have here. From there on it was a short step to run the PMI’s PMBOK Guide 3rd Ed. through wordle.net and after a lot of tweaking, it created some beautiful posters, reminding me what the PMP is all about. I use Lulu.com to print the poster on demand – I am quite satisfied with Lulu the largest poster measuring 23″ x 36″ (61cm x 91 cm) comes for just $39.95, excluding shipping.

The posters can be ordered at my Lulu Store.

And here are all of the designs I put online:

Poster (white, horizontal - 2nd Version)

Poster (black, horizontal)Poster (white, horizontal)

Poster (black, vertical)Poster (white, vertical)

Creative Commons License
These works are licensed under a Creative Commons Licence.

Relating, reflecting and routinizing: Developing project competence in cooperation with others (Söderlund et al., 2008)

Montag, Oktober 20th, 2008

Relating, reflecting and routinizing: Developing project competence in cooperation with others (Söderlund et al., 2008)

Söderlund, Jonas; Vaagaasar, Anne Live; Andersen, Erling S.: Relating, reflecting and routinizing – Developing project competence in cooperation with others; in: International Journal of Project Management, Vol. 26 (2008), No. 5, pp. 517-526.
http://dx.doi.org/10.1016/j.ijproman.2008.06.002

Söderlund et al. explore the question – How do organisations build project management capabilities? They analyse a focal project to show how the specific competence, project management, is build in an ever changing environment. As such comptence creation is situated and recursive.

The authors use a process view to explain the capabilities building. The process is three-fold – (1) Relating, (2) Reflecting, and (3) Routinising.

First step – Relating to expand the resource base, in this step the organisation

  • Acknowledges the situated character of project competence
  • Expands the resource base, which builds social capital
  • Engages in boundary spanning activites to cooperate with stakeholders and act against de-coupling, which decreases the overall resources needed for the authority system as coordination mechanism
  • Creates interdependencies

Second step – Reflecting to improve use of resource base, in this step the organisation highlights actions of importance for institutionalising a common frame of reference and stimulating shared reflection in the project. As such it:

  • Improves the resource base
  • Engages in problem solving
  • Shifts from exploitation based to experimentation learning, which re-uses previous processes, and recycles old solutions
  • Detects system-wide errors & generates new associations

Third step – Routinising to secure resource base and improve relational activity, in this step the organisation tries to ensure the best use of its resource base. Therefore it

  • Codifies new knowledge
  • Triggers reflecting
  • Exploits what is known
  • Emphasises and builds project-level comptence

Images as action instruments in complex projects (Taxén & Lilliesköld, 2008)

Montag, Oktober 20th, 2008

Images as action instruments in complex projects (Taxén & Lilliesköld, 2008)

Taxén, Lars; Lilliesköld, Joakim: Images as action instruments in complex projects; in: International Journal of Project Management, Vol. 26 (2008), No. 5, pp. 527-536.
http://dx.doi.org/10.1016/j.ijproman.2008.05.009

Images are quite powerful. I hate motivational posters which a distant corporate HQ decorates every meeting room with, but I once saw the department strategy visualised by these folks, they include all employees and the group dynamic is unbelievable. Later on they cleaned the images, blew them up, and posted them around the company – of course, meaningless for an outsider but a powerful reminder for everyone who took part.

Taxén & Lilliesköld analyse the images typically used in project management. They find that these common images, such as PERT/CPM, Gantt charts, or WBS are increasingly difficult to use in complex projects, in this case the authors look into a large-scale IT project.

Based on Activity Domain Theory they develop alternative images better suited for complex projects. Activity Domain Theory, however, underlines that all tasks on a project (= each activity domain) have a motive, fulfils needs, modifies objects, and has actors. Outcomes are produced by activity domains and are at the same time prerequisites for activity domains. Activity domains have activity modalities, which can be either manifested as resources or as communal meaning. These activity modalities are

  • Contextualisation = situation of human action
  • Spatialisation = need for spatial orientation in human action
  • Temporalisation = need for certain order in human action
  • Stabilisation = need for certain rules and norms in human action
  • Transition = need for interaction between activity domains

Useful images, the authors argue, need to fulfil these needs while being situated in the context of the activity. Traditional images focus on optimisation and control, rather than on coordination and action. Thus alternate images need to focus on dependencies and integration; on value comprehensibility and informality over formality and rigour.

Alternative images suited for complex project management are

  • Anatomies – showing modules, work packages and their dependencies of the finished product, e.g., functional node diagrams
  • Dependency diagrams – showing the incremental assembly of the product over a couple of releases, e.g. increment plan based on dependencies (a feature WBS lack)
  • Release matrices – showing the flow of releases, how they fit together, and when which functionality becomes available, e.g., integration plan
  • Information flow diagrams – showing the interfaces between modules, e.g. DFD

Stakeholder salience in global projects (Aaltonen et al., 2008)

Montag, Oktober 20th, 2008

 Stakeholder salience in global projects (Aaltonen et al., 2008)

Aaltonen, Kirsi; Jaako, Kujala; Tuomas, Oijala: Stakeholder salience in global projects; in: International Journal of Project Management, Vol. 26 (2008), No. 5, pp. 509-516.
http://dx.doi.org/10.1016/j.ijproman.2008.05.004

In their 1997 article, Mitchell et al. define stakeholder salience as „the degree to which managers give priority to competing stakeholder claims“. Furthermore, Mitchell at al. describe how the salience of a stakeholder is defined by three characteristics – (1) the stakeholder’s power to influence the firm, (2) the legitimacy of the stakeholder’s relationship with the firm, and (3) the urgency of the stakeholder’s claim on the firm.

Aaltonen et al. use the case study of a construction project of a paper-mill in South America to outline what strategies Stakeholders use to influence their salience. In line with typical case studies of construction projects Aaltonen’s stakeholders are environmentalist groups trying to influence the project. [I personally think based on my experience what Aaltonen et al. describe is also true for all sorts of projects, just if I think back to my organisational change and IT projects where we had workers‘ unions and councils as equally hard to manage stakeholders.] The authors observed a couple of strategies used:

  • Direct/indirect withholding strategy
  • Resource building strategy
  • Coalition building strategy
  • Conflict escalation strategy
  • Credibility building strategy
  • Direct action strategy

As per Mitchell’s definition these strategies aim to increase influencing power, legitimacy, and/or urgency. The tactics used to increase power were

  • Affect & influence parties, that provide resources, e.g., lobbying financiers and politicians
  • Affect the resource supply directy, e.g., laws and policies that prohibit imports
  • Build lobbying alliances, e.g., between environmentalist groups and unions
  • Recruit individuals with networks to important resource providers, e.g., ex-regulators, governmental workers, activists

The tactics used to increase legitimacy were

  • Initiate legal and political conflict, e.g., court action, political support
  • Inform the public about impacts of the project, thus damaging reputation of the project and increasing legitimacy
  • Signal illegitimacy of project, e.g., boycotts, counter impact studies
  • Attack supporters, e.g., showing them being partial, exposing lobbyists
  • Use other projects as showcases, e.g., using abandoned projects and withdrawls to show the illigitimacy of the project

The tactic used to increase urgency was signalling urgency, time-sensitivity, and criticality of decisions, e.g., by staging direct actions, protests, sit-ins, road blocks.

Managing user expectations on software projects – Lessons from the trenches (Petter, in press)

Dienstag, Oktober 7th, 2008

 Managing user expectations on software projects - Lessons from the trenches (Petter, in press)

Petter, Stacie: Managing user expectations on software projects – Lessons from the trenches; in: International Journal of Project Mangement, in press (2008).
doi:10.1016/j.ijproman.2008.05.014

Petter interviewed 12 project management professionals on managing the end-user expectations.  What worked and what did not work?

The conclusions cover three broad areas – end user involvement, leadership, and trust. As far as user involvement is concerned the practices that work included

  • Listening to users
  • Asking questions
  • Understanding concerns about change and actively ease these
  • Working with the user (not at or to them)
  • Let user make tough choices, e.g., on functionality, budget, cost, time
  • Create small user groups to hear them all
  • Giving credit to specific users for ideas
  • Keep users involved and updated throughout the project

What did not work were – not communicating the project status, and trying to outlast difficult users.

On the leadership dimension useful practices mentioned include

  • Ensure project champion
  • Articulate clear vision
  • Motivate team to get it done
  • Educate users on benefits
  • Obtain buy-in from primary stakeholders

Factors leading to end-user dissatisfaction were

  • Scope creep
  • No mission
  • No explanation of purpose/value of the system
  • Follow others

Trust building activities that worked well, were sharing good and bad news, and providing specific times for deliverables. What did not work were hiding the true status of the project, and ‚fake it until you make it‘ also known as hiding knowledge gaps.

The effectiveness in managing a group of multiple projects: Factors of influence and measurement criteria (Patanakul & Milosevic, in press)

Freitag, Oktober 3rd, 2008

The effectiveness in managing a group of multiple projects: Factors of influence and measurement criteria (Patanakul & Milosevic, in press)Patanakul, Peerasit; Milosevic, Dragan: The effectiveness in managing a group of multiple projects: Factors of influence and measurement criteria; in: International Journal of Project Management, in press, corrected proof.http://dx.doi.org/10.1016/j.ijproman.2008.03.001Update: This article has been published inInternational Journal of Project Management, Vol. 27 (2009), pp. 216–233. Multi-project management. I covered a similar topic yesterday looking at it from a Complexity Theory viewpoint. The authors argue that multi-project management is increasingly used in the industry mainly for reasons of better utilisation. [Having worked as a multi-project manager for marketing projects back in the old days, I don’t know if that is really true. My projects always culminated in a week with crazy workload, followed by dry spells, where I bored myself to death.]Patanakul & Milosevic analyse the critical success factors for managing multi-projects from a ‚bundle of projects‘-perspective, i.e., by interviewing a multi-project manager and his/her supervisor. Thus they build six case studies of organisations using multi-project-management. Accordingly the authors define multi-project as the middle state in the project continuum, where single projects are on one end, and programmes are on the other end of the scale.What do Patankul & Milosevic find? The antecedents of multi-project management effectiveness are

  • Organisational field
    • Project assignments
      • Projects‘ strategic importance
      • Required fit to managers‘ competencies
      • Organisational & personal limitations
    • Resource allocation
      • Sufficient resource allocation
      • Sustainable resource allocation
    • Organisational culture
      • Commitment
      • Communication
      • Teamwork
      • Rewards
  • Operational field
    • Project management processes
      • Individual processes
      • Inter-project processes
      • Interdependency management
    • Competencies of the multi-project manager
      • Competencies for leading individual projects
      • Competencies for coordinating between projects

Finally the authors identify the consequences of multi-project management effectiveness as

  • Organisation
    • Resource productivity
    • Organisational learning
  • Project
    • Time-to-Market
    • Customer satisfaction
  • Personal
    • Personal growth
    • Personal satisfaction

Are we any closer to the end? Escalation and the case of Taurus (Drummond, 1999)

Dienstag, Juli 8th, 2008

Taurus

Drummond, Helga: Are we any closer to the end? Escalation and the case of Taurus; in: International Journal of Project Management, Vol. 17 (1999), No. 1, pp. 11-16.
http://dx.doi.org/10.1016/S0263-7863(97)00074-4

The Taurus Project is a great case study. First of all it is a failed IT project. It took the project some 500 million GBP and 5 years to fail. And secondly it was a visionary project overhauling the IT of the London financial market. Drummond examines the route to failure. In this article she applies Escalation Theory aka Escalation of Commitment or the Vietnam War Syndrome as it was labelled in Freakonomics.

What did Drummond see? A destructive progression, i.e., one sub-optimal decision leading to another sub-optimal decision, that leading to another sub-optimal decision and so on. This effect was reinforced by an effect first found by Kahnemann & Tversky. They showed that gradual deterioration in a condition is usually underestimated and goes unnoticed. [Therefore addicts need an intervention]

What are the lessons learned?
Avoid the Garbage Can Effect. Don’t let the solution dictate the problem. Especialy if you have a keen vendor.
Make progress tangible. On Taurus experienced managers where struggling with controlling and managing the project because progress in IT systems‘ development can not be touched.
Engage in Second-Order Thinking. First-order thinking is solving the problem with the usual problem solving patterns, aka ‚more of the same‘. This does not help in deteriorating conditions. To break that vicious cycle second-order thinking is needed, which basically examines the assumptions of given decisions, plans, requirements, solutions.
And lastly balance power and responsibility. Politics and outside over steering destroyed the power and responsibility balance in this case. Project Managers had huge responsibilities but no decision power whatsoever to really solve the problem. Even if they saw recognised the problem and asked for project cancellation earlier than it was acknowledged by the project board.