January Archives - Duhallow Grey Geek

Focus: Are you paying attention?

“Are you paying attention?!”

Do you remember a teacher asking you that when you were at school? The same question can be applied to your project. Almost as important: “are you allowing yourself to pay attention?”

The work of Mihaly Csikszentmihalyi suggests that we are at our most productive when we experience a state he calls “Flow”.

What we need for “Flow” and what “Flow” gives us?

“Flow” is also known as “being in the zone”.

There are some requirements for achieving this state:

We have to be able to give the task we are working on our full attention – we have to be able to “lose ourselves in our work”.
The task has to be within our capabilities.
The task must stretch us, but just the right amount.

Csikszentmihalyi proposes that achieving “Flow” gives us some real benefits:

By doing something which is stretching us, in a sense we are being our most productive.
The Flow state itself is pleasurable and therefore our work becomes its own reward!

Focus helps us find “Flow” in our work and projects:

The idea of “Flow” has some implications for those of us who manage projects, those who are “workers” and those (like me) who do both.

People are most effective when they are allowed to concentrate on one thing. Multi-tasking makes people less efficient.
The “Flow state” is fleeting and takes time to achieve. Interruptions and distractions make it harder to achieve.

Both of these have implications for the working environment and project organisation.

Work should stretch people.
As they get better at performing a task, then they should be assigned progressively more challenging work.

These points mean that the choice of who is performing a task is significant, both for the project and for the person.

Where do you start?

A good place to start is with yourself. Begin by arranging your work so that you create opportunities to focus – to concentrate on one task at a time and experience Flow.

Do this by “time-boxing”. Set aside time specifically for the task and eliminate distractions and interruption. Find a way of doing this which works for you.

Eliminating interruptions need not mean being uncommunicative. Communication works best when you give it your full attention. People appreciate it when they see they are the focus of your attention.

Try it! Focus and go with the flow!

Prioritisation: Are you doing the right things?

Priorities over diary page — Prioritisation means knowing what you are going to do.

I know you’re terribly busy, but take a moment to ask “am I doing the right things?” If someone shouted

“Stop what you are doing!”

right now, would you look back at what you had created and be satisfied, or would you wish you had put the effort into something different?

Get your priorities right

Sooner or later every project comes to an end. Projects can end for many reasons:

All the work has been completed
We’ve run out of time, or
We’ve run out of money (budget)
Someone in charge says “I’ve changed my mind. Stop!”

Knowing what the priorities are as an individual and as a project at each stage is extremely powerful. It means that you know where to put your effort, you know what to do next, when you finish a task, or a task become “blocked” and it means that you know what you are _not_ going to do (at least for the time being).

Prioritisation: How should you decide your priorities?

You can do it on the basis of maximising benefit or minimising risk or cost or any other criteria you decide. Those in authority (which might or might not include you) should discuss the priorities (that includes having a good argument about them) for phase of the project you are working on, agree what the priorities are and then stick to that plan.

One of the strengths of the various “Agile” project management methods is the emphasis they put on agreeing the objectives or priorities of a time-box, iteration or sprint. Personally, I like to use MoSCoW for this, where:

M= Must have. There should only be one or two “Must haves” for each time-box.
S= Should have. There can be several “Should haves”
C=Could have. There can be several “Could haves”, and finally
W=Won’t have (this time around).

This approach concentrates on the “Must Haves” and only starts on the “Should Haves” when they have been completed. If you get it right, you run out of time or budget ideally somewhere in the Could haves (if you do well) or in the Should haves (if you make less progress than you hope).

Make sure that when someone calls “stop!” you (and everyone else) thinks they have received good value for your efforts.

Playing with elephants – Hadoop?

People who know me know that I’m interested in databases and SQL. I continue to describe myself as an Analyst rather than a Developer or DBA, but I also think it is useful to have a basic understanding of the characteristics of the tools one might be using. I’m busy at the moment but I thought that it was high time I “nailed my colours to the mast”.
I intend to start looking at Hadoop before the end of the year.
I know that may seem like a long way off, but it is getting closer all the time.

Here is one of the articles which grabbed my attention: http://www.sqlservercentral.com/articles/Hadoop/99135/

There is nothing like committing that you are going to do something as a bit of encouragement.

Why do I want to look at Hadoop?

First of all, I want to do it as an excuse to “brush up my Unix” (sorry Linux)
That makes it an excuse to buy and use some new (to me) hardware.
It will also be a reason to collaborate with an old acquaintance of mine.
And I find the idea of “map reduce” intriguing and trying it out is the best way to learn.

As I said, I’m busy, so that’s it for this week!

Day to day plans – Having a dynamic To-Do list

I’ve come to regard myself as being like Winnie-the-Pooh “a bear of little brain”. I like to give myself a task, settle down to it and get on with it without distractions. Sometimes the task itself can be quite complicated though.

In recent posts I’ve shared a view of “Strategic” and “Tactical” plans with you. I know you haven’t seen what is inside them but I find having them enormously useful. That brings me to the next level down: the day to day, dynamic To-Do list.

Having a dynamic list of the tasks I have to do is enormously useful. If I’m managing other people doing things, then I need to know what they are doing too. This is what the classic project plan is all about. Even a small team needs a shared plan. I used to create them using spreadsheets but now I use a special purpose tool.

The picture above shows screenshots from today’s dashboard. The tool I use is PBWorks Project Hub (http://www.pbworks.com/). I use the “Freemium” version, and I find it adequate for my needs. It does most of the things I would have been doing with a spreadsheet and it does some other things too.

It is very good at doing the boring Project Office things like bugging people (including me) when they are due to be doing something today. It is also good for collecting reports of progress made or problems encountered. All that has to happen is that people have to get into the habit of making one-line notes on the task they are working on each day.

I have a geographically dispersed team. The two of us exchange notes and have the occasional phone call, but the project dashboard gives us something that we can go back to for status information without a lot of cumbersome bureaucracy (which would usually devolve to me!). The only downside of this approach is that we are using a cloud service which requires internet connectivity and could be vulnerable. That means that I take what I think are appropriate steps to have the critical information stored in some other form elsewhere.

What do you do when things go well? Make a new plan!

A little while ago I shared my “Tactical Plan” with you. Things have gone well! So well that some of the projects have been completed much sooner than I expected. Some of this is down to good luck and having estimates which were not much better than guesses. The question is: what to do now?

I expect we are all (painfully) familiar with the situation where a project is slipping behind the intended schedule. Sometimes the reasons are the same as the reasons for my success: luck, inaccurate estimates and sometimes “force majeure”. After the inevitable struggle to get back on track by cracking the whip, the response is usually to re-plan. That is exactly what I have done in response to my recent success.

Here is the redacted version of my latest tactical plan. In structure it is identical to its predecessor. The changes are in the bits you cannot see.

Let me tell you about what is in the updated plan (without giving any secrets away):

The objective was not achieved last time (but that would have been a miracle). So that has remained unchanged.
The “New Product” development is still (more-or-less) on track, so that remains unchanged from last time. Basically it is – “Keep working away on the new product!”
The “Marketing” project from last time has completed. It’s objective was to create something new. That has been done. Now I have a new project to use what was created by that project as part of a regular activity. I still call it a “project” because it certainly hasn’t become “business-as-usual” yet. I hope it will do eventually.
The “Administration” project from last time has been completed. It was necessary, and it is making things work more smoothly, but it is complete and there is no need for follow-up.
The completion of the “Administration” project has created an opportunity to start something new in the “Marketing”. That has already thrown up some interesting ideas, but the Tactical Plan is reminding me to focus on my current objectives. The new stuff can be considered for the next plan.

The tactical plan is part of the project wiki (I may show you a little more of that in the future). It is visible to all the contributors and I have a printed copy above my desk, a little to my left, as I type. It is great as a means of reminding us all (especially me) what we have agreed we are concentrating on.