Most human endeavor ultimately comes down to a process of repetition and continuous refinement, based on some kind of feedback and improvement mechanism.

In previous and arguably simpler times, people would have just called this ‘practice’.

“Practice makes perfect”, “when at first you don’t succeed try try again” etc. is what we are taught from school. And it’s a pretty good mantra for drawing, playing tennis, cooking, driving a car, building houses, Installing kitchens and so on. But I say “most” because it starts to go awry when we apply it to large scale engineering projects. And arguably it often (or even always) goes awry for large scale bespoke activities generally – regardless of what they are.

This is because once we get into bigger and more complex things, the notion of repetition, practice and continuous refinement cannot apply. We can’t repeat the exact same thing again to get better at it, and anyway the pace of change means that what we’ve done previously isn’t necessarily relevant today.

Not too long ago I overhead someone repeating a phrase I have heard countless times over the years: “An IT project should be like MOT’ing (servicing) a car”. Well, what I have just said explains why this isn’t and can’t be the case.

From this we arrive at the theory that maybe the traditional “project” approach doesn’t really work for technology. We need a new approach of some sort.

If we take The Mythical Man Month (first published 1975 and stimulus for much work since) as the first solid documentation that “projects” don’t really work for technology, then we have had nearly 40 years of arguing and philosophising about it. The basis of this is why IT and technology projects aren’t like servicing cars.  It really is time to move on.

If you take away the notion of repetition, practice and continuous refinement, then the only other major technique we have available to us is knowledge management and education. Anyone that knows me, has worked with me or has read this Blog, will know that my view is that this is the route to successful outcomes. Not trying to re-invent the traditional “project” over and over. Not applying more and more command and more and more control.

A project will be successful if you have a knowledgeable team. Simple as that.

This is what the ‘agile’ books call “a good team”. What the project concept can’t do is make the team “good” to begin with. Personally, I think agile is a better way of running a project, but agile can only work if the team have a high level of knowledge. If that is the case they will deliver anyway. The techniques we use to organise things – be it waterfall, agile or whatever else, can only optimise a situation that is broadly already working.

I have to say though, that I am continually frustrated that the notion of the Business Analyst as champion of knowledge management and education, isn’t something I generally see many BAs being interested in. I’m not sure why this is; Admittedly it involves thinking somewhat differently, and perhaps the issue is that we are dealing with collective activities somewhat outside the fray and taken for granted. It involves volunteering information and sharing. Looking beyond the self and helping ensure people are as knowledgeable and ‘up to speed’ as possible.  Because I’ve spend a fair chunk of my career surrounded by people who aren’t, and struggle as a result - through no fault of their own.  I dread to think how much wasted time and money that equates to.

So given the rewards that can flow from all this I find this bizarre and more than a little annoying, but with the dawn of a new year comes new possibilities. I hope.

Happy new year!

« »