Project management hack #1: Focusing on technique (as opposed to outcome)

In life, there is no endgame.

Even the grandest crises are a chance to learn, adapt, try different techniques, and improvise. The latitude we have for developing and refining new techniques in a project – whether we are writing an 80 000-word thesis or rolling out a student management system – is truly enormous. Obviously, we do not always want to be experimenting wildly. For instance, if we want to develop our ambidextrous abilities by writing with our inferior hand, and so better channel our creativity, a literature studies exam is probably the worst time to start. Moreover, if we have a proven method available when saving a life, we should probably defer to tradition. Otherwise, however, we can apply deliberate practice to the performance – not just the dress rehearsal.


We can capitalize on this by producing work while we experiment – that is, prototyping.

Many professional writers would already be familiar with the routine of learning to write something as we are writing it. For instance, in instructional writing, we often debug the precise steps needed to write instructions, as we are writing them. To put it in rather Zen terms: we discover through the creation.

Whether we are writing a chapter of a thesis, or a module of user documentation, we should constantly perfect our process; only having done so can we move confidently onto the next chapter or module. We must also give ourselves the time to test out our prototype and determine its weaknesses and strengths, debugging through reiterated testing.

For example, often the mass of documentation I am producing can become so large that the only way I can keep track of what I have done (and what I haven’t) is by referring to a tracker document (which may not be up to date) or running an automated search. Never the less, I will occasionally find myself having written a page of instructions that I later find out I already wrote. However, when I compare the two documents together, I will tend to find that they match each other with unnerving accuracy. Some might read this as showing how technical writing can become sterile and devoid of personality. However, I see it as awesome proof that my process is near-perfect; the conventions and style guides are so comprehensive, and I have internalized them so thoroughly, that writing documentation had become like running an ideal science experiment: perfectly reproducible.

Always be learning
Thus, it is important to ensure that we have our technique down pat, before taking on the bulk of the actual work set before us. Obviously, exceptions to our rules will emerge - we will have to add to and adapt our style guides to accommodate things we encounter along the way; indeed, the body of work that our initial prototype belonged to can itself become a prototype in itself.

We can also transfer lessons learned between contexts – for instance, sharing principles of efficient and productive work within our lives, and between individuals, teams, and organizations. Case in point: applying what we learn from our favorite sport to our workplace.

Some projects, whether they are writing a PhD or rolling out a software system, can take years. It is a disservice to us to focus only ever on the product, and not the process.

Image credit: criggy1