Category: Leadership

Posted on

Is your project SMART or STUPID?

Luna rover on the moon

Any project or plan needs a bit of preparation, a bit of structure to ensure that everyone and everything is aligned.

SMART goals are often discussed, usually positively, occasionally less so. It usually comes down to their interpretation. For starters, the nemonic isn’t fixed – many interpretations feature duplication and have their own built in limitations.

Specific: What are you looking to achieve? If this isn’t clearly defined then the hard work could be all wasted. Without a specific goal it is too easy to be distracted along the way. “Conquer space” is vague, “Put a man on the moon” is specific. Put a man on the moon and bring them back alive might be better still.

Measurable: How will you be able to gauge completion and success? Will it be enough to place a footprint on lunar surface or will it need a photograph of someone holding a flag against a black and starry background. In most businesses, this is more likely to be a numerical target: output to 25giga widgets

Achievable: The first of the contentious points. What defines achievable? Why is it important? If it is too hard will people be demoralised from the start? The risk here is that you use past performance as a guide to what is achievable – “We’ve done 22giga widgets so 25 is achievable.”

The problem is that is very limiting. Putting a man on the moon wasn’t something that had been done before – not even close. It wasn’t the previous goal with a 10% increment. https://www.theguardian.com/lifeandstyle/2016/mar/27/think-big-tasks-ambitions-creativity-smarter-faster-better-charles-duhigg provides an example of when a stretch goal is needed to bring in new thinking.

What both of those projects, rockets and trains, demonstrate is a willingness to take bold new steps and that the collective investment was sufficient in terms of people and resources.

Relevant: Where does this goal sit in the scope of your overall mission? Putting a man on the moon was a huge scientific and explorational achievement. It was also highly political at the time, potentially the only reason it got the funding necessary and why we haven’t put a foot on the moon since 1972.

While many lists put realistic here that seems to close to achievable to be worthwhile.

Timebound: When would this need to happen? “I’ll paint the shed” might be specific but if it is followed with “when I get around to it” it isn’t likely to happen in this lifetime. Putting times & dates in place doesn’t automatically mean that is when the project will be completed – breaking it up in to chucks with an option to review can increase the success rate as it enables changes mid project to be accounted for. Third party suppliers or even the weather can add delays.

In 1961 “end of the decade” was good enough for JFK. End of the quarter might be more appropriate for your next project.

So how do you avoid being STUPID?

Spontaneous: Ah, that knee jerk reaction to something that doesn’t get thought out properly. Don’t let people convince you that this is a good thing by calling it Agile. Even Agile methods have a clear structure.

Traumatic: If you don’t ensure your team are happy with the project you are likely to find you are doing this alone.

Unplanned: Even if the next step is to plan this properly it is a plan. Fail to plan, plan to fail.

Peacemeal: Don’t rush into something without considering what will happen next. There may be discovery along the way, especially so with new goals but it should still form part of a bigger plan or mission.

Insular: Otherwise known as working in silos. Where one team makes great changes without considering the effect on others. Or where huge amounts of work are duplicated, probably with a few tiny details that make merging the projects impossible.

Doomed: The result of STUPID goals.

Posted on

Be careful what you wish for

Hand drawn five bar gates and stopwatch

If you don’t measure it you can’t improve it.

That was what a previous senior manager of mine used to say. I was working in a customer service centre and part of my role was to collate the measurements that were used to evaluate the team’s performance.

The team was split in two: One half took incoming phone calls, the other half dealt with written  communication. This was in the mid 1990’s and written meant paper. Email was just starting to become adopted internally and the workflow used a fledgling digital system. Customer’s letters would be scanned automatically and those scans added to a queue to be dealt with in turn.

That queue also had requests from the phone team that were deemed complex and needed escalating as the paperwork team was generally more senior. 

The phone team were measured for total number of calls taken and the average duration of call.

So the aim was to take as many calls as possible and to keep them short.

Calls came in via an automated switchboard and would be non stop unless you clicked DND (Do Not Disturb). This was a feature of the phones and it prevented the next call coming through. It was measured but did not have the same weighing as call number or duration.

So to meet individual targets, many of the call team would make notes (pen and paper) during the call, press DND, type the request and add it to the queue for the paperwork team.

So rather than dealing with the majority of caller requests in the moment, a significant volume were added to the queue for the other half of the team. The phone team looked good because call volumes were high and duration was short. Yet two people were involved for a task that could have been completed within the duration of a call.

All because the measurements encouraged gaming the system.

So when you want to know the performance of your team be careful what you ask for.

Focusing on certain Key Performance Indicators rather than gaining a broader understanding can inadvertently lead to encouraging behaviours that reduce your overall effectiveness.

For further reading about how using rewards may actually lower output see https://www.danpink.com/books/drive/

Posted on

Problems are great

Lightbulb and ideas cloud

Don’t bring me problems, bring me solutions.

I’m not a fan of that much used phrase.

From a leadership perspective, the start is a blocker – Don’t come to me.

Then it goes on to explain that if you are in need of help I am not interested. I only want to know about things once you have worked out how to fix them.

Why? So that I can make the final decision only when you’ve done all the hard work?

The spirit of the phrase is meant to empower, to encourage reflection so that the request becomes one where the risk has identified and a plan been created. That’s great when it is within normal boundaries and presents no additional side effects. Not so much a problem as simply business as usual.

What makes problems so good?

They tell us that we are looking forward. Actively seeking a way of doing things better.

Problems also indicate that people are talking.

And here’s the really delicate bit. By discussing problems earlier you get the combined input of a wider range of people. Note, that doesn’t mean relinquishing responsibility nor does it mean showing weakness.

Instead, it prevents two significant risks:

Of making decisions without key pieces of information. We frequently have to make decisions without all the information otherwise there would be no case to deal with ambiguity. If you wait for perfect conditions, you will never get anything done. However we may not realise the significance of what we are proposing without gaining outside view. Anyone who has worked in software development will be familiar with how easily a seemingly small change in one area of a project can have huge repercussions in another.

It also gives an opportunity to break the pattern of “we’ve always done it this way.” If you ask the same people you will tend to get the same advice so consider going outside your usual circle of contacts. That might mean a coach or consultant who specialises in this topic.

Finally, sharing problems is good for you. We sometimes get things out of proportion, get blinded by our own desire to be unshakeable that when we do get stuck we don’t know how to deal with it. Our vision drops, our creativity suffers and that small glitch becomes all consuming.

So keep talking to me.

Posted on

Can you do everything?

Pint of beer on wooden bar

My first job was behind the bar in a country hotel.

My boss was very proud of being able to do any job in the place – he could join me serving food & drinks, he could and did make up the rooms, cover shifts in the kitchen, wether as chef or washer up and he’d drive the minibus to take regular customer home after a long and enjoyable evening. If anyone was off sick he would step in without fuss.

That ethos stuck with me for a long time – that the manager should be able to step in and do the job of anyone they are responsible for.

It was many years later that I found myself working in a team where all of us had amassed a great deal of technical knowledge in our respective areas of expertise. We had been hired as trainers based on our prior professional experience.

After one leadership restructure, we noticed our new manager couldn’t do any of our roles. Not one.

And they were great.

Supportive, challenging and focused on our development and our results but they couldn’t do what we did. Yet it wasn’t significant.

Understanding the people and the roles of those you are responsible for is vital. Being able to do their job is not.

 

Picture credit: Photo by mnm.all on Unsplash