Tag: Moscow

bookmark_borderStyle by list

Posted on

I’ve never been to Moscow, but we talk about it all the time at work and, cos I like to plan things and use lists to help me cope with stressful times, like moving from a house to a flat and the splitting up of 14 years accumulated crap, well the topic of Moscow has reared in my brain.

For the most part, the furniture is the main thing that we’ll need to split up or, as is most likely, give away to charity. That’s the thing about co-owning things, they end up being to the taste of neither of you so when it comes down to it we are both of a mind to replace items so we get things that we like.

Over the past few months I’ve visited a few antique and thrift style stores, missing out on a fantastic lamp base made from wooden letterpress blocks, and I’ll do the same once I’ve got somewhere to live sorted out. Understandably this is the top item on my list and it is titled “Get roof over head”. Alongside this item is the letter M.

Which brings us back to Moscow. Or, as some of you will already have figured out, to categorising list items into the Must haves, Should haves, Could haves and Would like to haves.

This way I can make a big list of things that I want to buy and ordered them such that I don’t end up, for example, buying a Mac Mini instead of a bed, or a new set of kitchen knives instead of food.

It’s exciting, making lists. I’ve always enjoyed it but this list has much more gravitas to it, this list is all about me and it’s been a long time since I’ve both taken that view, let alone been able to. So there are such items on the list as a pair of Grado headphones, an M-Audio keyboard, an Eames armchair, as well as a bed, a mattress, a new sofa and a smattering of smaller items (lamps and whatnot).

Not everything is needed, nor will be bought. And everything that is needed won’t be bought immediately either. I’m happy to take my time, and buy items I like and which offer good value (I really don’t want to be buy these things again any time in the next 20 years or more). It’ll also be a challenge, a fun one, to find my own style.

A closing example then. Here is an item that is a Could have on the list. It is a rug that I quite like, and somehow it will have to play alongside something I’ve already purchased. A giant Lego head.

Hmmm, this style thing might take a while to crack.

Maybe I need to start a new list…

bookmark_borderHow to prioritise your work

Posted on

We all have a need to make sure we are working on the most important thing, the thing that needs our attention and focus the most. Given that all of us will have more than one thing that needs to get done, you need to prioritise.

But how?

Ivan Walsh recently posted his thoughts on this topic but he doesn’t cover the process that comes before the daily decision making of “what shall I do today?”.

Presuming that you don’t lurch from day to day and that you have a plan, or at least a list of things that you need to deliver, how do you go about setting the priority?

Some people will be lucky to have a direct customer who knows exactly what they want, you can work with them around any constraints of time and budget (resource) to prioritise the work that needs done.

But what if you have two customers, or three, or seven?

Well that’s close to the situation I’m in and my solution is quite simple.

Let them decide.

A few months back I started to jot down, in a spreadsheet, everything that my team COULD do. It includes some items like scouring our Wiki for any useful information that we can use, as well as “hey you know what would be really great..” requests we get which aren’t urgent but which I didn’t want to lose.

I soon realised I might as well track every information request there and very soon after that I realised that I needed a way to sort the list and make sure we were working on the right thing, at the right time.

Given that many items on that list were ‘put’ there by other people, I realised that if we estimated (very roughly) how much effort each would take, we would be able to bargain with people and, ultimately if two requests are in conflict then, hey, I can get the people who requested them to discuss the reasons and let them decide.

So we now have a big list of work items, each estimated, each prioritised (we are using MoSCoW) and which I can use to drive discussions when the next “must have, immediately” request lands in my inbox.

Ultimately, our customers decide what we work on and as I can give them a full picture of what, and why, it’s much easier for them to understand those times when they don’t get what they want. Having that information to hand makes the act of getting real priorities much easier.

My response, via Twitter, to Ivan’s post was this: “I tend to let other people set the priorities for my work. That way they all have (to have) a view of it.”

How do you set your priorities?

bookmark_borderNew Manager: How do you get better management buy-in?

Posted on

I recently received an email which asked:

Since my career seems to be following a path broadly similar to yours … I’d love to know what your experience was and any lessons learned.

Specifically Mark, who sent the email, asked a few questions:

  1. How do you take over as manager for a group of technical writers?
  2. How do you get better management buy-in (promise cheaper or faster docs?)?
  3. What are the first activities you should do (content audit, benchmarking?)?
  4. How soon is *not* too soon to start changing things?

I’ll break each question out into a new post, so without further ado, onto question #2.

How do you get better management buy-in (promise cheaper or faster docs?)?
Management buy-in is key to any team within an organisation. If the management don’t properly understand what the team brings to the organisation, be they hard or soft benefits, then your job will remain a battle.

So, how do you get it?

Firstly I’d suggest not making any promises to do things cheaper or faster. Whilst it is largely the type of thing your boss will want to hear and they are promises you can make later on, the first thing you need to quantify is whether you are producing what is needed or not. That may mean looking at improving the quality of the documentation, or it may mean re-evaluating the type of information that is produced.

How do you do this? Talk to your audience.

A simple statement, and something it everyone will tell you is core to your ability as a technical communicator but which remains one of those things that is very hard. Even if you have direct access to your audience, the customers of your part of the product, it can still be tricky to get useful feedback from them. With that in mind I’d set up a series of one-to-one interviews. They don’t have to be long, nor do they have to be formal (in fact I staged mine over a few casual chats, grabbing 15 minutes of time from some of our SMEs over the space of a couple of weeks) but you must talk to them.

The benefits are two-fold. Firstly it raises the profile of your team and alerts your customers that you are actively engaged and trying to improve things, secondly it should mean you can formulate a plan to take to your boss.

The former should also start to generate some goodwill, you’d be surprised how many people understand the need for good documentation and you may well be able to garner some support from some other parts of your company. Don’t be afraid to ask people to email you and your boss with their thoughts of your new plan, the more evidence she/he sees that you are driving improvements yourself, the more likely he will be to back you.

But ultimately you need, at some point, to present a plan to your boss. One that outlines what you are planning to do, what the benefits are, and how long you think it will take to achieve.

Benefits should be stated in business terms – for most software documentation the main cost benefit is to reduce the time it takes your audience to complete a task using the software – and the more specific you can be the better. Essentially you have to justify why the company is spending money on you and your team, and ultimately you may be asked for a fine grain of detail that you just don’t have. So, if your plan is to reduce Support calls, make sure you have a way of monitoring the stats AND that you can attribute them to the documentation, before suggesting that as a plan!

Buy-in, in my experience, is largely gained by showing a business awareness. Ever boss will want things faster and cheaper but instead of make presumptions, involve your boss in those discussions. During the start of a project, take the initial scope of the documentation that you and your team have planned, prioritise it (using MoSCoW perhaps?) and take that to your boss. Then it’s a simple case of saying “OK, this is what we MUST have in the documentation, this is what we SHOULD have, these are the things we COULD have and there are also some things we WOULD want to have, can you help me narrow this list down as we can’t produce it all”.

That allows your boss, in conversation with you, to make sensible decisions around the production of the documentation, allows a decision on faster or cheaper to be made, and shows that you understand the business reasoning behind what you do.

Be prepared to have discussions where you lose, where that Quick Start guide that you think is a really good idea gets put to one side. Part of gaining the trust of your boss, and his/her buy-in to your plans is showing that you have the bigger picture in mind, and if you can prove that then your boss should happily back you all the way.