Author Archive

Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria (Atkinson, R. 1999)

Montag, Juli 7th, 2008

SCC-Thumb

Atkinson, Roger: Project management – cost, time and quality, two best guesses and a phenomenon, its time to accept other success criterin; in: International Journal of Project Management, Vol. 17 (1999), No. 6, pp. 337-342.

Once I spent some hours discussing with colleagues what the magic triangle might be. PMI says it is Time-Cost-Scope and Quality is a product of these three. My colleague argued it should be Time-Cost-Quality since Quality is defined as meeting or exceeding the expectations of the customer, which includes that the customer gets what he asked for, aka the scope.

Similarly Atkinson argues that this is only asking the question of the project is ‚Doing it right‘, which automatically focuses mainly on the delivery system. Thus leaving huge gaps in the ‚Getting it right‘ part unanswered. Which leads, as many IT project examples show, to a nice but unusable/unwanted/unaccepted piece of software. In order to get it right by doing it right Atkinson proposes the ‚Square Route‘ of success criteria – (1) The Time-Cost-Quality-Triangle, (2) The Information System itself, (3) Organisational benefits, and (4) Stakeholder/community benefits.

Fundamental Uncertainties in Projects and the Scope of Project Mangement (Atkinson et al. 2006)

Montag, Juli 7th, 2008

Uncertainty(1-Thumb) Uncertainty(2-Thumb)

Atkinson, Roger; Crawford, Lynn; Ward, Stephen: Fundamental Uncertainties in Projects and the Scope of Project Management, in: International Journal of Project Management, Vol. 24 (2008), pp. 687-698.

Very interesting article, clearly in the normative/positivist’s tradition of how to do Risk Management better. Firstly the authors dissect uncertainties typically found in projects into (1) Uncertainty in estimates, (2) Uncertainty with project parties, and (3) Uncertainty with project life cycle. What does it matter? The authors argue that not all uncertainties are typically the scope of classic risk management. Therefore the project objective should be the ultima ratio, especially if trade-off decisions are needed. Furthermore crystal clear decision making needs one decision-maker, therefore project uncertainties need an owner.

In the second part (on my page 2) Atkinson et al. outline the difference between hard and soft projects. They do outline some characteristics of hard vs. soft projects, e.g. degree of external influences, tangibility of artefacts. Secondly they outline two modes of problem-solving sense-making, and data collecting. They put forward, that a problem rooted in a difference in information required vs. information at hand, calls for a data collection effort to solve; whereas a problem caused by different interpretion of the same data requires sense-making as a problem-solving technique. Moreover they locate the typical soft projects in a high ambiguity and high uncertainty quadrant, thus needing sense-making, and value analysis for problem solving.

Lastly they call for trust (especially on soft projects) instead of controls. And outline a Trust Audit as a project management tool, instead of auditing controls.

What is Project Strategy? (Artto, K.; Kujala, J.; Dietrich, P.; Martinsuo, M.; 2008)

Sonntag, Juli 6th, 2008

WIPS? (Thumb)

Artto, Karlos; Kujala, Jaakko; Dietrich, Perttu; Martinsuo, Miia: What is Project Strategy?, in: International Journal of Project Management, 26 (2008), pp. 4-12

Artto et al. do have a very nice article in the first issue of this year’s IJPM. The authors look into behavioural strategies of projects. They see projects being ’sort of‘ autonomous of their organizational environment and that projects not always follow directions and decisions set-up by their mother corporations.

They do map 4 distinctive types of project strategy/behaviour on two axes. (1) Strength of link to parent organisation. (2) Degree of independence. Thus creating a 2×2-Matrix (what consultants usually love – „there is no problem which can not be shown in a 2×2-Matrix“) with 4 strategy types: (a) Obediant Servant, (b) Independent Innovator, (c) Flexible Mediator, (d) Strong Leader.

Their article closes with recommendations for future research on: (1) empirically validating these 4 strategies; (2) the question how strategies are formulated, what are the routes of development; (3) Empirical studies of strategy shaping factors, to address the dynamics and evolutions of projects‘ strategies; (4) Empirical investigations into different environments, aka application areas (innovation, organizational transformation, IT etc.); (5) Connection to mainstream strategy research and ops management; (6) bringing this to a stakeholder perspective: What kind of influences, levers, tactics are used by different stakeholders to formulate and implement a project’s strategy?

Towards a Conceptual Reference Model for PMIS (Ahlemann, Frederik)

Sonntag, Juli 6th, 2008

M-Model (thumb) Ahlemann, Frederik: Towards a conceptual reference model for project management information systems, in: International Journal of Project ManagementVolume 27 (2009), No. 1, pp 19-30.doi:10.1016/j.ijproman.2008.01.008 In his article Ahlemann shows the different functional nodes, from a business perspective of PMIS systems, structurally sorted by main user groups and life cycle stages. Furthermore the article maps all the needed data structures in huge but very nice UML diagrams. Ahlemann calls this reference model RefModPM.

Managing incomplete Knowledge (Pender, Steven 2001)

Mittwoch, Juli 2nd, 2008

ICK (thumb)

Pender, Steven: Managing incomplete knowledge – Why risk management is not sufficient, in: International Journal of Project Management, Vol. 19 (2001), pp. 79-87.

Pender basically looks into the question if project risks is better described by the term ‚incomplete knowledge‘ and therefore be linked to probability theory. (Kudos to everyone who did the PMP and still knows which contingency reserve accounts for ‚known unknowns‘ and which for ‚unknown unknowns‘.)

He looks into the question of randomness (probability vs. non-probability), repeatability, human limitations to understand such a complex thing as a project, uncertainty & ignorance, flow of knowledge, and fuzziness of parameters.

Why does Software cost so much? (DeMarco, Tom 1995)

Mittwoch, Juli 2nd, 2008

WDSCSM? (Thumb)

Let’s start with a real classic. Tom DeMarco’s „Why does software cost so much? And other puzzles of the information age“ (http://www.amazon.com/Why-Does-Software-Cost-Much/dp/093263334X)

Well, it is a bit aged but given the projects I have seen, it is far from being outdated. So what is his answer? It’s Peopleware not Software and people have to function in their roles and sometimes they don’t.

DeMarco lists as root causes: Scheduling errors („The schedule is crap, when even high performers have no slack“), missing accountability by management („I don’t ask for an estimate, I ask for a promise!“), missing prioritization („All these recommendations for improving ourselves are great. But what if only one thing succeeds? What would it be?“), and the general tendency to ‚fuck up‘ the end-game (i.e. value capturing after implementation).

And of course DeMarcos specialty – Software Development Metrics. He adds the nice insight that measuring something without a clear idea how to improve on that metric is a waste of time and money. It might be worthwhile to sample business case points etc. for a while, but in the long-run only defect counts should be institutionalized.