Skip to main content

Author: Duncan Watts

Good Practice, Best Practice and 1984

George Orwell got it

Whenever I hear the term “Best Practice” I think of 1984. Not the year, the novel. George Orwell tells of doublespeak, the language of the oppressive state. In doublespeak meanings are reversed: “War is Peace”, “Freedom is Slavery”,” Ignorance is Strength” and so on.

Words are powerful, as Big Brother knew, and repetition can change meaning. So it is with “Best Practice” which now really means “Mediocre Practice”, since it isn’t what “The Best” are doing merely the average.

But that isn’t even what I dislike most about the term. Worse is the implication that the pinnacle has been reached, after all what’s better than the best? So by a combination of repetition and implication mediocrity is now installed as the most desirable state.

IT is still growing up

Information Technology as an industry is in its infancy. It started in earnest fewer than 60 years ago. The reality is we have very little idea how to create and operate efficient, robust and usable software that meets the need of our users.

In another 60 years people will look back at the primitive state of our tools and methods and laugh, just as we now laugh at early attempts at medicine – think leeches! We try to make ourselves look respectable. We copy ideas from mature industries like architecture and engineering. But the reality is that IT projects are still regarded as failures 60-70% of the time.

Calling what we do today “Best Practice” is so wrong it’s not even funny. I know it’s just marketing, but as Orwell knew, words are powerful and what starts as a harmless phrase soon comes to represent truth.

Good Practice

So how do we change this? First we stop using the term “Best Practice”. When you find yourself reaching for this phrase, substitute “Good Practice” instead.

“Good Practice” is always worth striving for, and does not imply that any sort of pinnacle exists. It’s not complacent. It’s open to change and improvement and constructive criticism is welcomed. There is recognition that improvement is always possible. There is always room for something better.

If I’m still working in IT in 60 years, there will still be “Good Practice” – although it won’t look anything like what we do today. Hopefully we’ll also have left the whole idea of “Best Practice” behind us – with the leeches.

Don’t forget to leave your comments below.

Why Your Idea is Probably Bad, and That’s OK

I’ve noticed that people often become very attached to their ideas, and don’t like having any flaws pointed out, or even questioned. That’s ok when it’s your own personal interest, but it’s a big problem when you’re part of a team working on a large and expensive project with a lot at stake. A key part of being a good Business Analyst is developing the habit of questioning everything so that you can sort the good from the bad.

Disclosure

In the interest of full disclosure, I’ll admit that before I started working as a consultant in IT I studied physics to a pretty advanced level. When you study one of the fundamental sciences you find that it’s really, really hard. And because it’s so hard, you learn to get used to being wrong most of the time, and not to become too attached to your ideas or be too fearful of criticism. You also learn how to go about testing ideas, and develop a healthy scepticism of silver bullets.

The reasons your idea is probably bad

The number one reason why your idea is probably bad is that there are simply many more ways to be wrong than right. In the space of all possible ideas the chances of hitting on a good one are improbably small. Of course you can have good ideas, but it’s likely that you’ll have many bad ideas before you hit on a good one.

The number two reason your idea is probably bad is that there are no really new ideas – only variations on existing ideas. The chances are good that somebody else already had your idea but then discovered it was bad, so it wasn’t pursued.

Why that’s ok

A good idea is only recognised as such after it’s been tested – and that means letting others criticise them. A vital part of the scientific process is peer review. This is essentially the process of putting your ideas in front of other people and allowing them to shoot. Einstein wasn’t lauded for his theories of relativity until after they had been pulled apart and survived experimental testing. At the time they weren’t obviously right.

Most entrepreneurs have many bad ideas, and fail many times, before they hit on the formula for a successful company – and become famous for it. You can’t expect to move into a new field and suddenly solve all the existing problems that others have failed to solve. You need to develop a deeper understanding before you’ll be able to spot why ideas are bad and then come up with good ones.

So don’t worry about it

Most of the time you’re wrong, and it’s really ok to be wrong because if you’re not prepared to risk being wrong you’ll never be right. The path to a genuinely good idea will take you through uncharted territory and take in many false turns. But don’t listen to me, take it from Einstein:

Anyone who has never made a mistake has never tried anything new.
― Albert Einstein

Don’t forget to leave your comments below.

Planning is Not a Solo Activity

Planning is something I have a love/hate relationship with. Done properly it is a thing of beauty: The team working together to plot a common path through a thicket of issues. An initially vigorous debate that eventually settles down as objections are countered and agreement is reached. Done badly it’s a dreadful sight. A Project Manager sitting alone at a computer cursing Microsoft Project.

Related concepts

It’s important to clearly distinguish a number of related concepts:

  • Planning is an activity in which the actions to be taken are developed in advance;
  • A Plan is some form of documentation that communicates the result of the planning activity;
  • Microsoft Project is a useful tool for producing some of the components expected in a plan, such as a Gantt[1] chart.

It should be clear from these descriptions that planning must come before a plan, and that entering scheduling information into Microsoft Project does not substitute for having an actual plan.

What’s in a plan?

A plan should include everything you need to communicate how your goals will be achieved. It should not contain unnecessary boilerplate as plans may change regularly and need to be easy to keep up-to-date.
Importantly, not every plan needs the same level of detail nor to cover the same timeframe. The project team requires a plan that goes into detail about the current stage, but can be vague about future stages, so they can coordinate their work. This kind of plan should be updated regularly as the team gains more experience and progress, or lack thereof, becomes apparent.

The project board needs a simple plan that shows a schedule of major milestones and deliverables for the whole project, and a high-level indication of how these will be achieved with the available resources. This kind of plan should be light on detail – because the detail isn’t generally known yet – and should only be updated at the end of a stage or in response to an exception.

A classic PM mistake is to try to have both these levels of plan combined together into a single document – or worse into a single schedule in Microsoft Project. The problem with this is that the project team is never allowed to change “the plan” because the PM fears the project board will think that “the plan” has changed.

It hasn’t of course, because in reality there are different plans with different purposes, and at different levels of granularity. But now the PM is stuck, and planning, if it occurs at all, is now off the record.

Who does the planning on your project?

On many projects it is assumed that the Project Manager does all the planning. This is a grave error[2]. The people who should be planning the work are the ones who will perform it. There are at least there reasons for this:

  1. Even a Project Manager with extensive experience of all the tasks to be performed is unlikely to be able to estimate accurately without knowledge of the capabilities of everyone else on the team[3];
  2. A team member who was not involved in planning her work cannot reasonably be held to a plan devised by someone else. Buy-in to the plan requires participation in creating it;
  3. Except in the simplest case, a plan is not a list of independent tasks, and therefore everyone involved must plan together to identify dependencies and gaps.

The Project Manager owns the plan, and should ensure that the results of planning are captured, documented, and can be used to monitor progress. But planning itself is a team activity. Get everyone in a room and work through what needs to be done together. Drill down until the key tasks are clear to everyone. Question assumptions. Repeat.

Plan well and prosper

Planning is not a solo activity. If you join a project and are given a detailed plan (or more likely a schedule) with your name next to various activities, ask when the next team planning session is.

Don’t forget to leave your comments below.

References
[1] http://en.wikipedia.org/wiki/Gantt_chart
[2] In mature industries this may not be the case, but IT is not a mature industry. If you don’t believe me ask yourself what other industry accepts a 60-70% failure rate for projects.
http://www.zdnet.com/blog/projectfailures/study-68-percent-of-it-projects-fail/1175
http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf
[3] In some organisations the same team works together repeatedly on similar projects. In which case the project manager may be justified in doing all the planning. This is the exception.