Wrike

Letter I sent to the people at Wrike:

I've had a quick look at Wrike, and like what I see.

Wrike seems to conceptualise a project as a set of tasks, rather than an information flow. Thus information about a task seems to have to be stored at second hand, in an attached document, and is not directly accessible from a task or a folder.

Incidentally, the use of folders for multiple representations of the project is very flexible.  I would use this to organise a project by phase, static element list (e.g. 'design'), by dynamic element (e.g. WBS element, where I'd like to be able to see hierarchical summaries), supplier, functional component, etc

But, back to the information content of a task. A task will have a number of basic information parameters: obviously name, description, WBS number, cost code, RAM nominations, antecedents and dependencies, which are metadata-like, then substantial data such as performance and acceptance criteria, issues, progress notes, risks (derived from a separate 'risk breakdown structure'), Requests for Information, Answers to Requests, decisions, pending antecedents, change requests, etc, each of which will have a status and need to be tracked and reported upon.

Being able to review a project on any of these items could then be facilitated. For example, the number of pending tasks with outstanding change requests, or overdue decisions, or unresolved issues could be looked at anywhere in the WBS hierarchy, or by project element, assigned manager, etc.

I didn't see how Wrike managed communications, including logging emails, which I would guess would be possible, maintaining project requirement sets, meeting  minutes and review lists that were linked to project components and not as binary blobs (ie attached text, spreadsheet or tabular documents that need their own viewing application). In complex projects tracking document issue, receipt and revisions is  vital. I couldn't see how I could do this in Wrike, nor how even simple configuration management could be done.

Project context may be a factor here. My project area is multi $100m property development projects that might take a few years. The illustrations on your website seem to be in other domains.

Flash Blog on PM

A late and uninvited participant in the international 'flash blog' on "what project management means to me".

Simple.

Getting things done through people.

Same as general management, of course, but the things either handle or creating a change in the business environment to attain or sustain a competitive or customer service advantage, defined as broadly as you like.

Here's Glen Alleman's take on it.

The risk in risk matrices

Not only did the consultant-led risk workshop start with a limp, it also ended with one.
For all practical purposes, it drew to its conclusion with the obfuscation of using a matrix to locate risks in a two dimensional space with dimensions 'likelihood' and 'severity'.

The problem with this was in neglecting to deal with the simple measurement error it gave us a result that was misleading; potentially so misleading it was no better than no result at all. The risk cells between different risk intensities have a natural error. That is, while they are bounded by lines, they should in fact be bounded by indeterminate zones where we cannot know the location of a risk.

This means that in a typical 4 x 4 matrix, it is not possible to distinguish between cells that touch at a corner.  But it gets worse: depending on the uncertainty between risk zones, it might be impossible to distinguish between cells one row or column apart in adjoining columns or rows. That makes the exercise pointless, and can lead to gross over- or under-allocation of resources to risk response.

Cox has examined this problem in detail, as discussed by Awati. Alleman also discusses uncertainty in projects.

As Gerd Gigerenza says (Helping Doctors and Patients Make Sense of Health Statistics), the first step in statistical literacy is understanding uncertainty. In risk analysis, above all, there should be some recursive application of uncertainty to that process that is established to deal with uncertainty. Physician, heal thyself!

Risk management charade

A while back I attended a workshop with a client. It was to develop a corporate risk management 'framework' (as they like to say these days). The workshop was facilitated, and probably at great expense (more original art works on partners' walls), by a major consulting firm. Let's call them King Prince.
In what was clearly a canned presentation, that had nothing to do with my client's business (the business is in health services), our bright young facilitator's first text book question was "what is [company name's] appetite for risk?"
OK, so let's think about his. What was [company name's] appetite for risk? That is, how many people should die each year from iatrogenic causes? Is that it?
In this question both the facilitator and the firm, let's abbreviate it to KP, shot their credibility. We continued the workshop politely, but left in awe at their misreading of a client's business.
I wondered how much my client paid for this tosh.
Of course risk appetite has a place, as a question. But its place is more in the world of finance, hedging and portfolio management, were risk can be objectively (sort of) assessed, priced, and managed. It has a completely different place in health provision where death is not tolerated (from non-natural causes, that is), but investigated and avoided.

What is a project?

There are lots of long and tedious definitions of a 'project' around, but I like this one by David Allen:

The project merely describes something in the world looking or being different than (sic) it currently is.

Project Software

As we all in the project world know, there is a plethora of project management software on the market: both web-based and for local hosting or installation.

Most of the software, to my mind, falls far short of helping one manage a project, and tends to be either for scheduling or task management; sometimes with the capability to upload documents.
I've mentioned this in a previous post, but very little of the software on offer truly supports the management of project information, documents and actions.

Recently I've been considering software for an investigation unit that I am responsible for, and the software that has lead me to looks far more like true project management software than products marketed for the purpose.

Not to say the packages that I've earlier mentioned (Project Administrator and Meridian's offerings) don't do that job, they do; but the cross linking and automation in COMtrac goes further than this.

Capabilities of COMtrac I particularly like are the linking of entries against different categories of investigation action, and the use of those entries to produce investigation logs, tasks, offence analysis, briefs of evidence, statements, etc, without much further work. I don't know of any PM package that can do that. They all entail more work to make useful reports and summaries.

The front page of COMtrac shows recent logged activity and investigation progress at a glance, with information about investigation status, target dates (e.g. for court appearance), persons of interest, etc.

Incidently, its also a much better tool than other investigation databases that I've examined, based on Access, for instance; these have been OK, but were really just electronic filing cabinets, with little cross-linking and built in investigation management or brief/statement creation.

In the project world, Comtrac, like i-nexus, is designed around the project (let's stick with that word) end result. I-nexus works to benefits that must be realised, then tracks back to the actions that will produce the benefits. This is done in an hierarchical manner, with the software providing automatic summaries after the fashion of hammocks in a project network chart.

Comtrac bases the project on the project elements (could be a work breakdown structure showing deliverables, or some other form of project breakdown structure), then links documents and actions to that structure (evidence, actually, in Comtrac's terms). It also provides for a project log, project chronology and analysis of how the evidence links to the elements: easily translated into a project. One can also view the project in terms of the documents uploaded against the elements.

The great thing about it, though, is that it automatically produces draft reports from the data entered, with relevant references to files uploaded, with the reports available by date range, and a few other criteria, and with no further work, unless you want to edit the draft it prepares. I've not come across anything else that does this type of smart work.

For the complexity of a decent sized project, it would require some tweaking, but the basic architecture is exactly that which a useful project management application should have.

So when you think PM software, think of outcome/results/deliverables based management architectures such as Comtrac and i-nexus.

Pair that with Cheops and a decent document management package, and you're unstoppable.

Show me the money

Every time I've had a cost plan prepared, by a quantity surveyor, or sometimes an estimator, but I expect more from QSs, after all, I went to Uni with some of them, I don't fail to be disappointed.

The cost plan process starts early in the design cycle, typically, and to accommodate uncertainty, there are usually contingency allowances made: a 'design contingency', sometimes a 'project contingency' if the project scope is in flux, and a 'general contingency' to allow for architectural fantasies and client wishful thinking.

The contingencies are applied in a seemingly rote fashion: 10% here, 5% there, and so on.

I once asked a QS if he reviewed completed projects to see how the contingency allowances bore up to the real world. The answer was a staggering "no"! Here we are, with a great source of data to allow good calibration of many building and project types, and it's let blow in the wind.

The other thing I notice with project cost plans is that the estimate tends to increase as the project advances and more detail becomes available.

But, I think that it should go the other way. In the early days of the project, the margin for uncertainty should be quite high (worked out by the statistical history of similar projects), and as more detail is produced, it should drop, with the margins for uncertainty assigned quite clearly to particular elements of established risk. Then we'd be getting what we paid for!

The basic project questions

It may be a little bold to use the definite article, but for my part, here goes:

What do you need to achieve?
When do you need the results?
How much can you spend?

And the supplementary questions:

Why do you need it (to get the business context, or the overall 'mission' you want to conduct)?
Why do you need it then (just what is causing the timing)?
What value do you need to produce (in NPV terms, I'm thinking)?

Once the project is cooking;

What do we need to deliver?
How will we deliver it?
Has this been done before (by the owner, the project manager, the delivery crew...anybody)?
What resources and skills do we need?
Who will do what?
What could stop us?
How will we know when we've finished (that is, what will achieve the required performance?)

Another take on this is the Five Immutable Principles of project management.

A coffee would help...

A little while ago I attended a business presentation at one of my consultant's offices. The presentation was on using i-nexus software to develop and deliver projects that aligned with business goals (now, there's a novel thought).
I left my desk at about 10 to 9am after a busy couple of hours on EOFY work, sped down to the venue and dropped into a seat at the board table.
After a flat out morning, I looked around for a coffee; a couple of other attendees were nursing mugs, so I thought, well, I'm a few minutes late, perhaps coffee was for the early starters; but the start time was 9am, not 8:30, so that was unlikely.
Well, the story was, there was no coffee offered, either before or after. The two with mugs must have just been special.
The presentation, of course, had us doing the tennis swivel as we swung our gaze between the mostly pointless images projected onto the screen at one end of the room, and the speaker, sitting at his laptop computer at the other. Good neither for neck nor comprehension!
Then, we got to the actual software on screen. It was great, except that it loaded slowly, endured continuous band-width apologies, and the colours were such and the images so small that it was barely visible and made little sense!
If you are going to use Powerpoint, at least use it with a semblance of professional capability.

I might blog about the software another time, but here are some lessons:

1. If people are giving you their time, at least provide a coffee and some light snacks; it's dirt-cheap and for the money is a great investment in a convivial atmosphere. The hospitality shows that you care about your guests' experience.
2. If the 'presentation' (I mean, the talk) has no graphic content, don't bore or distract us with Powerpoint slides. Keep them for what's important and learn how to blank the screen between times: press the W for a white blanking, B for a black one! Not hard.
3. At least check the equipment beforehand and make sure it works. Don't rely on a live connection, especially if you are overseas: have some videos on a DVD, or a sequence of screen shots to show what you need to; but don't ever think you will impress people with excuses for non-performing software.

These are the main ones for doing a presentation; particularly one where you are basically touting for business.

But, there were minor problems as well.

One that sticks to mind is the presentation of graphs showing proportions of samples doing and not doing things. The almost inevitable, and almost unreadable pie-charts; '3D' pie charts at that were flung onto the screen. Not good. Not only are the area relativities almost impossible to grasp by inspection, it is impossible to build the chart to further comparsions. A simple and elegantly done column chart would have been far better. I recommend Charlie Kyd's or Juice Analytics' work on this.

Is there a design theory?

In a previous post, I claimed that there was no architectural design theory and suggested that this got in the way of efficient design management -- if you don't know where you're going, you don't know if you're getting there!

But, there are elements of architectural design theory around; proper scientific theory, not the art school hoodwinking that passes for design theory and that abounds to the building industries' detriment.

As one example, the work of Space Syntax comes to mind: its work grows out of a theory as to how movement makes meaning of spaces.

Some of the work of the Lean Construction Institute could also go in this direction as would the Design Structure Matrix approach to setting out design interactions.

The elements are there...just needs to be pulled together used as a springboard to further theoretical development.

The iron triangle

One of the most popular if time-worn characterisations of projects is the so-called 'iron triangle'. This is usually presented in a diagram with the sides of the triangle labelled 'time', 'cost', 'quality'.

I'm of two minds as to whether this is a useful motif for projects.

On the one hand it is simple, memorable and roughly correct. On the other, it is an oversimplification that omits the principle driver of the three project parameters: the out turn value of the project to its promoter.

The general contention is that to vary any one of the parameters, the others must 'give'. So, to decrease cost, the quality may have to be reduced, or the time extended, because usually to decrease time for a project's completion increases cost. Increase the quality, and you have to perhaps lengthen the project's life or increase the cost, or both.

Within bounds, this makes some sense.

But the terms themselves don't represent the reality of projects: I'd prefer delivery (because we don't manage time, we manage our activity with respect to time to achieve delivery), budget (which should include a buffer for the probability of risk) and performance, which brings together the specified quality and project scope to deliver the required business value (or we could alliterate it into 'price, production and performance'). Changing any of the three will change the value delivered, but sometimes value opportunities can be gained by increases. For example, increase the budget on a retail centre to achieve delivery before Christmas to delivery greater business value.

Max Wideman has some rather complex motifs, but I think that this over-cooks the mix; simplicity is best, but only as a point of departure; and the substitution of the terms I suggest helps, I believe, to clarify their implications; but what should be expressed, rather than implied, is that the result has to always be seen in terms of the business value produced.

Project graphics

In my previous post on this question, I suggested that the quest for an all encompassing project graphic representation was probably misplaced. Projects, at least large ones, but even smaller ones, are too complex and have too many information flows to lend themselves to comprehensive graphic summaries.

But, that said, a useful summary of progress vs plan at the 'whole project level' (that is, not at the more detailed level of WBS responsibility, resourcing and completion progress) could be as follows.

An actual vs. planned, per month, usually, of:

• expenditure
• earned value
• commitments (that is $ committed via contract, or work package commencement)

looking ahead, commitments vs planned is the best indicator of expected production. EV, of course, is the best rear vision indicator.

and tracking of numbers of

• unresolved issues
• activities commenced vs.plan
• activities delayed
• activities completed vs. plan

Getting closer to the action, the project manager needs a 'look ahead' schedule at the work package level, or whatever is meaningful in the project, showing work planned, preparation (lead times for materials and resources), and execution, including resources. This descends to daily calendars for actions to be taken: particularly for lead times on work package preparation.

Project charting

On Edward Tufte's site there's a fasinating discussion on project management graphics. The discussion hinges on the way one might effectively show project progress, or status, or future plans in a graphic.

Nice idea, but projects can be so complex that I don't think that any one graphic format is going to do the job.

A well designed 'dashboard' type presentation might help. Such as some on Charlie Kyd's site, but I think there is an air of futility in attempting to capture the complexity of a project in a single presentation format.

For summarising progress, the One Page Project Manager has some useful approaches, I think, as is a simple S-curve of cumulative progress. Another short piece on the S-curve.

But we have been beguiled by the notion that a project scheduling package is a project management package, and that the complex multiplicity of project information can be captured in a single graphic display. A project needs to be understood as a business. I don't think that a business would run on a single graphic! Although, the Balanced Scorecard approach comes close to consolidating the status information of company performance. Perhaps something like this for a project would be applicable.

However, the challenge is an inviting one. I hope to post some ideas for graphics later.

Meanwhile, one thing that must be bourne in mind is that projects need to be managed on a moving lens approach: that is plenty of detail for coming actions, less detail for those further out, with performance analysis for past work; and thus the lens moves on like a magnifying glass; all the time with the forecast out-turn cost and completion date updated. In construction projects I've worked on we have a master schedule, but develop 'look ahead' schedules at the micro activity level (per zone, or trade) for the next 6-8 weeks, updated weekly.

Project information 2

In a post a little while ago, I touched on the management of project information as being one of the unspoken 'secrets' of project management: not a secret now, of course.

Just a mass of information in a spreadsheet will not do once the project gets to any size: and I mean once it creeps over even a couple of million dollars worth of construction, or thereabouts, depending on project complexity.

The information that floods through the project needs to be tracked to the relevant parts of the project in some way. Drawing numbers might be a way to do it, but inadequate. A BIM system may allow information to be linked to the particular parts of the model, but this remains too atomistic for my liking.

I think there are probably three basic dimensions that can be used to 'locate' any piece of information in 'project space' and have it reliably available and easy to track in a way relevant to the project.

The obvious one is location: a BIM will do this, drawings won't due to locations being repeated at different scales on different drawings. The BIM will also give hierarchical contextualisation of information: e.g. an item in a room, will also be on a floor, in a wing of a building, in a block of a campus, etc.

Tagging the information by WBS package is also probably a benefit. But this limits the locus of the information to just that WBS package. Good, but it needs more.

Less obviously, but possibly of greater utility is location by building element (see the Summary of Elements as an example), this is because a building element will reach across the entire project, and can be then referenced to a WBS package and a locational nesting. The element 'key' can also sit in a hierarchy to generalise the information item in running a query. The element might be 'external envelope', or within that 'external openings', or within that 'external windows' as an element class.

Other dimensions that could be useful could be material, trade or supplier, functional or operational element, etc.

Thus a piece of information could be tagged primarily by element, then at a second level by its WBS and locational parameters. Then a query of the database could be run to find, say, all outstanding issues pertaining to the superstructure in block Z, or the floors in wing J, etc.

PM in the library

I slipped up to Dubbo in central NSW this week, care of REX airline, and during some down time from work, I dropped into the local library and relaxed browsing through its project management collection.
The books I grabbed off the shelves were:

• Project Management in Easy Steps by John Carroll;
• Project Management: a Competency-Based Approach, by Stephen Hartley;
• The Project Management Workbook by Nancy Cobb;
• The Fast Forward MBA in Project Management by Eric Verzuh and
• Manage Projects by Ken Langdon

The catalog also had Fundamentals of Project Management by James Lewis, but it was not on the shelves.

All not to bad, as far as books go, but, again as far as books go, rather reductionistic, making project management a rigid, lock-step series of phase-bound actions hanging on a formulaic approach captured in templates, and, of course, relying on a scheduling package.

But, while this might be a good underpinning framework; in practice, it has to be both looser, and more disciplined. Some of the disciplines were there, of course: preparation of a work breakdown structure, a light touch on configuration management, etc. and even the ritualistic mention of the iron triangle.

I don't think any of them talked about how the iron triangle has to flex through the project, and how trade-off parameters have to be found as circumstances evolve and risks come and go.

The risk management approach was almost uniformly naive and unhelpful, ending up with a matrix populated from the mathematically nonsensical product of risk likelihood and effect, but almost no discussion of cost-effectiveness in management of risks delineated in terms of project out-turn value.

What was fundamentally missing, and this is probably inevitable in book-land, is the daily cut and thrust of moving a project along: constant meetings, e-mails and phone calls to marshall stakeholders, get suppliers in line, achieve delivery by the team and keep on top of the torrent of information that flows in and needs to be captured in documents that flow out; all the while applying your understanding of the mission to project actions.

Then, there is the 'continuo' of project work: acting when you need to act, to efficiently effect the project: acting neither too late nor too early, tracking lead times for your actions and for production to be achieved, and dealing with issues and planned action to keep the tempo right; all the while preparing monthly reports to the executive in charge and defending those reports in a meeting.

When to do VM!

Quote from Project Workout, by Robert Buttrick:

Decisions taken at the early stages of a project have a far reaching effect and set the tone for the remainder of the project. In the early stage, creative solutions can slash delivery times in half and cut costs dramatically. However, once development is under way, it is rarely possible to effect savings of anything but a few percent. Good upfront work also reduces the likelihood of change later, as most changes on projects are actually reactive to misunderstandings over scope and approach...

As I read this, a post at Construction Survivor was my immediate reference: Value Management -- the great con trick.

Gerry is right if VM is done when the project is largely committed and all the valuable change opportunities have gone. VM is only of any use done early; and best coupled with project planning and definition workshops with the main project users participating. The NSW Value Management guide, as an example which I've made use of in many project development workshops, makes the point on this quite succinctly.

Walk-in sculptures

Comment I added to http://projectmanager.com.au/education/methodologies/strategy-project-design-management/

One of the issues with implementing a design management system is that the architectural profession, obsessed as it often seems to be with building 'walk-in sculpture' photo opportunities, doesn't really seem to have a usable theory of design: not an art-derived theory, but a theory as to how requirements are orchestrated parsimoniously into a built form. There is no theory, afaik, on which to hang Corbusier's dictum that an architect is an organiser, not a drawing board artist.

Risk management's funny side

Some time ago I chaired a Gateway Review of a major building redevelopment.

The review panel made a few comments about the project manager's approach to risk management, including its unrigourousness. For example, there was no evidence of a systematic identification of risks on the basis of even a high level work breakdown/project breakdown structure, or against a mapping of dependencies to identify risk sources.

The fatuousness of the exercise concerned all panel members with our concerns confirmed when we saw the risk schedule: the lead risk in the project was the location of the public car park!

Not sizing of the project for its market, or customer access (it was distant from a large proportion of its customers), or future demand (would there be too much or too little service capacity in the facility), industry capacity to deliver, or even something as simple as sub-soil conditions. No, it was the car park!

Moreover, there was no probability attached to the risk...to any risk in the list, and no range of effect on the project value: that is, the range of the dollar effect of the risk event on the net present value of the project, given the cost the risk event would cause to be incurred, or revenue deferred or avoided. There were no numbers at all in fact, so it was hardly a risk schedule of any kind, more a type of ceremonial gesture than anything of decision-making benefit.

Donnez moi une break!!

Project information

Everytime I come across a computer application that purports to be a 'project management' application, I wonder.

Rarely are they, in my view. There are scheduling applications aplenty, task managers by the ton (as if a project is just a collection of tasks!), and so on. Some scheduling applications do a good enough job with resource planning and work package cost management, even earned value management, but project management? No!

Managing a project does entail work that is aided by such applications, but the heart of it, in my view is being able to manage the continual wash of information that flows through and is demanded by a project. This information is variously in documents (a document management system is essential for all but the tiniest projects), meetings, e-mails, other correspondence, notes, conversations, and so on.

When an application claims to be a project management application, I think of products such as Prolog by Meridian, Expedition by Primavera (not sure if this vanished in the Oracle take over) and Project Administrator. I do not think of Microsoft Project, as useful as that application may be for scheduling.

PMBoK

I'm reading a book by Max Wideman at the moment: A Framework for Project and Program Management Integration.

I  respect Max's work and experience and his contribution to project management, and I particularly admire his view that project management is not a profession. If you want to characterise it, I suppose it is more like a craft than anything else; just like general management, in fact, a craft with a collection of practices.

Why I admire this view is that Max was one of the instigators of the PMBoK. The 'BoK' was developed in a forlorn attempt to demonstrate that project management is a 'profession'. Of course, a 'profession' has a 'body of knowledge'. The Guide to the PMBoK demonstrates that. Does it not?

If your 'body of knowledge' can be encompassed in a single book then there's not much to it, in my view. Compare this single book to the contents of a law library, and its depth of precedent, or medicine, similarly. A 'body of knowledge' cannot be captured in a single volume, or even in a whole bunch of volumes, but is dispersed across the history and activity of an entire profession's intellectual output; coming to grips with this is the point of professional practice.

So, in documenting a 'guide to a body of knowledge'; project management demonstrates that it is the very opposite of what it seeks: to be regarded as a profession.

That's not to decry the value of project management: of that it has plenty, but I'm sceptical that it has much discrete knowledge to offer society beyond its collection of practices.

Doing risk management

As Glen Alleman often quotes, 'risk management is how adults do projects'. But how to do risk management?

I'm reasonably familiar with the typical approaches taken in business and the project world here in Australia, and I'm also reasonably familiar with what has been written both on the Internet, and between hard covers ('books', for GenY and younger): it ranges from nonsense to good practice, of course.

It seems to be universal that risk events are identified, then categorised as to effect (or 'impact', as if they are meteors), and probability of occurence.

I had a look at an explanation on wiki answers and got the all too familiar twaddle about multiplying the effect rating by the probability of occurrence, in the misbelief that this produces something meaningful; in matrix fashion.

But even getting past this, whence the list of risk events?

I've been in countless 'workshops' where the collective wise heads dream up a list of risks, and assign the two ratings to each, in long tedious hours. And that's about it.

There is a more structured way.

Start with the project work breakdown structure, at whatever level it has been developed to; one hopes at least three of four levels; and examine each identified work element or package for risks to schedule (what could prevent this being completed on time), budget (will the budget fund the performance or capability needed) and technical performance (what would stop the deliverable form performing as required by the project).

The risks will come from a number of sources; in building projects, it will include adequacy of programming/briefing, owner engagement with the project, materials supply and labour/contractor delivery, design adequacy, sub-surface conditions (foundation conditions, in-ground services, presence of rock), and so on.

Risks occur as interuptions to dependencies: so what does a particular work package depend upon for completion (including for commencement). For instance, footing construction completion depends on adequate footing design. A major risk is foundation conditions: is sub-soil marsh or rock? What is the market like to supply expertise for either type of foundation condition and consequent footing design? How do we manage (mitigate) the risk? In this case, we get a drill rig on site and drill core samples to see just what is under ground. We also retain geotechnical engineers to conduct a fulsom examination of the site conditions, including relevant usage history.

For a well known type of project in a well known location, there should be some record of risk events and their frequency and effect: this produces real probabilty numbers to work with.

Thus, a more structured basis to develop an appreciation of risks than sitting in a circle dreaming in a workshop.

But...I've never experienced such a structured approach, or one that sought historic data, or even attempted reasoned cost ranges for effects! And they want to call project management a profession!!

By the way, for some helpful discussion on project risk, check out the relevant tags at Herding Cats and Eight to Late as a starter (see the blog list to the right); for a useful critique of the faulty practices that seem to be dominant at the moment, at least in Australia, I suggest a click on The Limitations of Scoring Methods.

One man band

Another article that thinks the world of business (and by extension, projects) is for prima donnas. At Quality Digest, an article entitled Systems Thinking is hardly about systems at all!

One of the comments posted says it all:

...the article is more about the vicious fiction of personal performance; and not the system that the person/s work in to achieve the organisation's mission. So, completely wrong-headed!
But the author is right in pointing to systems thinking as the source of organisation performance. Top management has to see the organisation as a total mission orientated system that facilitiates people achieving mission oriented outcomes: typically this means serving the customer.
One rule of thumb for a system oriented business is: no voice recognition call centre merry-go-rounds; but customers dealing with people who solve their problem or meet their need.

 [Link in quote added by me]

All about me!

My first post; and not a thought directly about projects, but it does touch: the principle is the same.

An article on Strategy and Business The Discipline of Managing Disruption by Clayton Christensen (a Harvard Business School 'professor'; in Australia this probably means 'lecturer') says it all: all about 'me', that is.

This article, like much of the rhetoric about 'leadership' emphasises the one at the expense of the 'community of action' which is the company. So how does a company; a community of action, stay fresh and resilient in the face of market changes (read 'project changes')? The challenge is to cultivate difference whereas most groups gravitate to similarity. So a sentinel of danger in any company is entrenched similarity: the company then ends up working for itself, and demonstrates this by creating a culture of conformity: language, ideas, personal style, and even personalities that are brought into the company gravitate to a modal identity: difference, and therefore innovation, are bred out. The company ends up being unable to tolerate difference, and undifferentiates itself out of its market, which, as an engine of difference, forges into the future.