How to Fix: Scansnap ix500 scanner won’t power on

If you can’t turn on your scanner, here’s a way to fix it.

Disclaimer: Nothing here should be harmful to your scanner, but you do it at your own risk! 

The Scansnap ix500 is a great little sheet-fed scanner. Mine suddenly wouldn’t turn on any more, and it seemed to be dead, just turned off all the time. The manuals were of no help, so I contacted support. They were very good, and got back to me within a few hours with the following suggestion:

On the top surface, on the left hand side when your ScanSnap iX500’s ADF cover is opened you will find a small black square. This square is a power switch which automatically should “pop up” as the ADF cover opens. The switch can sometimes get stuck pressed down and cause the scanner not to power up. Please make sure that this black square is level with the rest of the plastic around it. If it would be pressed down it can be released by manipulating it with a thin object like a paper clip and the scanner should light up.

If the button is level and the scanner is still not showing any sign of life I would have to ask you to try another plug for powering your scanner and another USB port. I would also advise trying another power lead and adapter as well as another USB cable if possible.

The button works on the same principle as the switch that turns the light on and off in a refrigerator. I’ve fixed it by poking a pencil into the button just to give it a little nudge, and also by

I’ve fixed it by poking a pencil into the button just to give it a little nudge, and also by very gently tapping the left-hand side of the scanner with my hand.

These images show the little black button that you need to pop out, circled here in red. Click the image for a larger version if you need to.

ScanSnap IX500
ScanSnap IX500
ScanSnap IX500
ScanSnap IX500

A “fan” of simplicity

This blog post from Digital Amit is an oldie-but-goodie on a quick lesson in simplicity. This could be a useful story for you to tell when motivating your teams to keep it simple!

It compares two approaches to solving the problem of weeding out an empty box of soap on a manufacturing line.

Of course, you might argue that there should be a root cause analysis to find out why the box of soap was empty in the first place, but that spoils the point of the story!

The Agile BA: Agile Business Analyst Course

I found a very good course for Agile Business Analysts, called The Agile BA.

As the homepage says, there’s 150 minutes of learning material (comprising 62 videos in 7 modules) and 30 quiz questions (with solutions) for self-assessment.

The course has a very good introduction to lean thinking, and the thought processes behind agile, which is a nice change from some educational materials and certifications that I’ve seen.

Business Analysts, project managers, developers, and business people who commission software would all benefit from understanding the material covered on this course.

It’s a shame it doesn’t count towards a recognised certification, but at $100 until the end of 2014 (and then $125) it’s very good value for money, and I recommend it to you.

The Agile BA

Fun and useful tools from Google that you might not have seen

Here’s a few genuinely useful things that you might not have realised you can do with Google.

Here’s the ones I think will be most useful or fun for you:

Set a timer, optionally full-screen: Just search for an amount of time, followed by the word timer, eg 25 minute timer (good if you’re a fan of the Pomodoro Technique!)

Google NGrams lets you see how usage of certain words in books has changed over time, from years 1500 – 2008.

See how to pronounce huge numbers by searching for the number and then typing =english, eg 1234567890=english produces “one billion two hundred thirty-four million five hundred sixty-seven thousand eight hundred ninety

Google Trends lets you see what the top searches are right now:

You can also enter a search into Google Trends to see how a search term has trended over time: http://www.google.com/trends/explore#q=awesome

Google Trends Google Timer

Problems coordinating your project? Try a short daily stand-up meeting.

This article is very back-to-basics, but I think many people would still benefit from applying it. So here goes!

I was chatting to someone recently who’s involved in a project with lots of different departments within her company, including marketing, IT, finance, and third-party vendors. She said that it’s proving difficult to keep everyone coordinated with the status of the project, and with what needs to happen next. She’s also having problems making sure that all the different parts of the project will be ready by the time they are needed. This has been even more difficult during the summer holiday season, when many people are away from the office.

So what can be done to improve things?

First, of course, there are the standard project management techniques such as a Gantt Chart showing when each part of the project needs to be completed. This could even just be a list that gets pinned to the wall, or put on a website or wiki page so that everyone can see it. (If you’re interested in wikis, I’ve had great success with Atlassian Confluence wiki software.)

But one of the best ways I’ve found to communicate project status is to have a short meeting each day, at the same time every day, with everyone involved in the project. In agile software development these meetings are called Stand Up meetings (or “standups”), because often the participants are all standing up. The idea with this is that nobody really likes standing up, so it keeps people brief and to the point!

The meeting should last no more than around 15 minutes.

Make sure that each person gives an update that includes:

  1. What they did yesterday
  2. What they will do today
  3. Any problems that they have faced that could affect their work (often these are called “blockers”, since they are blocking a task from being completed).

Lots has been written on how standup meetings should work, but it’s really not difficult, so if you’re having problems coordinating a project, give it a go!

Tip for Conference Calls: Ban Speakerphones

One of the big problems with conference calls is that it can be hard to hear what other people on the call are saying. I wouldn’t consider myself to be hard-of-hearing but sometimes I really struggle to hear what’s going on. This is especially true when one or more people on the call are using speakerphones: hands-free phones (that often look like UFOs) that people gather around in conference rooms.

Problems with speakerphones:

  • They pick up background noise
  • They pick up echo in the room
  • People are very tempted to shout into a speakerphone, because they are not physically close to the microphone, which can lead to an unwanted hostile quality in the voice!
  • Volume is inconsistent: speakerphone users are often very loud on the call, or very quiet, or a mixture of both (great to blast out the eardrums of everyone else on the call!)
  • Bottom line: voice quality is usually very poor, so communication is also poor.

One tip I’ve found is to ask participants not to use speakerphones on conference calls. Instead, ask everyone to use a standard phone, even if they are in the same room together. This way, everyone is speaking into their own microphone, which is held close to their face. Call quality is much clearer, and communication is much easier.

The same is of course also true when using Skype, GoToMeeting, GoToWebinar, or other Voice Over IP (VoIP) services.

How to create supportable software

As a business person it’s hard to see whether software is supportable and maintainable, right up until the point where it breaks and nobody can fix it! So let’s be proactive and see what it takes to make software that’s easy to keep running.

To keep your costs down, it’s important that your team creates software that is easy to support and maintain. This involves a little more work up-front, but will pay you back in spades over the long run.

Once your software team has built your software and it has gone live, they’re going to need to support and maintain it for you, probably for several years. Even if your software has already gone live it’s not too late to make it more supportable, although thinking about support and maintenance right from the start will make things easier and cheaper.

Principles of Supportable Software: MALT

Here are the key areas to consider – when gathering requirements and building software – when thinking about making software easy to support and maintain. They make the acronym MALT.

Monitoring: How can we tell if the software is running as expected?

Alerting: How will we know when something goes wrong?

Logging: How can we see inside the black-box at the detail of how the software ran?

Traceability: How can we trace the source of problems back to their root cause?

A detailed example

Let’s look at each of these areas in more detail, with a real-world example. For simplicity, I’m going to use the example of a little process that brings in sales data from a distributor who sells our products. It has a very simple task: it just reads a data file once a day and stores the contents in a database, then saves the file somewhere in case we need it again.

Monitoring

Without any monitoring, nobody would know whether the process had run or not. I’ve seen processes that people thought were actually running  in the background and storing essential business continuity data and backups, but actually they hadn’t run for two years! If this was business-critical data, and there was no ability to use these backups because they didn’t exist, the business would go bust overnight!

A nice way to monitor our example process would be to write into the database each time the process runs. We would store a few things of interest:

  • Date and time that the process started
  • Date and time that the process ended, so we can see how long it took
  • The name of the data file – it probably has a date in the name, eg SalesData_2015-12-01.csv
  • How many lines of data it processed
  • How many lines of data had an error

Separately we might also choose to store each error message in the database, for each faulty line of data, so that we could build up a complete picture of what was going wrong. It would then be easy to go back to the company supplying our data and tell them that they were giving us bad data, and give them the information they need to fix it quickly.

So by adding monitoring we’ve gone from a total state of not knowing what’s happening to being able to check exactly when the process has been running and what it’s been doing.

Sometimes it’s appropriate to build a dashboard to give a nice visual indication of how a process has been running. I like Geckoboard for this – it gives an attractive and quick way to build a dashboard that can be viewed on a desktop computer, phone or tablet.

If you are working on a web project and need good monitoring and alerting, consider services such as Pingdom or New Relic.

Alerting

What if the process doesn’t receive a data file? Perhaps something has gone wrong with the network, or perhaps our data supplier has stopped sending us files due to a problem at their end which they haven’t even noticed.

What if the data suddenly starts going bad, eg financial fields are all set to zero, or valuable marketing email addresses are coming out as jumbled nonsense?

We need to put some alerts in place so that somebody on our team can start to look into the problems as soon as we notice them. We don’t want to wait to be told by a third-party that our system isn’t working, or wait for a disaster to find that the system broke years ago and nobody even realised.

Alerts can take several forms. They could be an email, an SMS text message, or shown in a special app. Email alerts are simple and traditional, and are usually good enough. If the alert is time-critical, SMS might be more appropriate.

My preferred way of working is NOT to send an alert when everything is successful, and to ONLY send an alert when something has gone wrong. Otherwise people just suffer “alert blindness”, and don’t notice the one day that everything has suddenly gone wrong because they’re used to seeing success messages and mentally screen them out.

A good alert message will give enough detail to be able to understand the general problem, and so that the support technician will have some idea of where to start investigating in more detail.

I usually suggest that alerts go to a business person AND to a technical person. The business person can determine priority and severity, and can understand any impact on the business. The technical person can then just focus on finding what went wrong and understanding how to fix it. In the example of our data process, if the data goes bad then the business person will probably have the relationship with the distributor, and can work with them to get the problem looked into.

Logging

Although business people might see monitoring and alerting information, they are very unlikely to see logging, because this is more of a technical area. A lot of software produces log files as it runs – web software especially – and this can show things like which web pages were called, what information the user entered into the page, and which specific database actions took place. Log files tend to be actual files, rather than being written to a database, because they can get very large.

The idea here is that if the software goes rogue, you should be able to figure out what’s happened. Did a particular piece of the software run when it wasn’t supposed to? Did an expected action not take place? Did the user give us some bad data that we weren’t expecting?

If you’re writing the requirements for some software, you don’t need to specify anything specific for logging. You should make a general note along the lines that “Logging is required in order to trouble-shoot any anticipated problems.” If you make a list of possible things that might go wrong, the developers can make sure they have enough logging to be able to easily trouble-shoot this. In the example of our data process, we can reasonably expect that sometimes the data file won’t appear, sometimes the data file will contain errors, etc.

Good logging should at least let us understand that a problem has happened, and perhaps show some information about the internals of our software and how it has responded to the problem, even if that’s just a big error message that gets dumped into the log file at the point where things went pear-shaped!

Traceability

Traceability is all about identifying where things came from. It is best illustrated with an example.

In our data process, we write each line of data from our file into the database. But if somebody runs a file of test data through the process by mistake, or runs the same file twice, we need to figure out which data came from that particular file and take it out of the database, so we don’t end up with bad data or duplicates.

If we can trace each line of data in our database back to the exact file and process-run that it came from, we can very easily unpick our problem and get rid of the dodgy data. Without this traceability we’re pretty much sunk, and have no practical way of knowing which data is valid and which was faulty test data that needs to be removed.

On a website, traceability might include which user ran a certain report or saw a particular error message. If our website is calling out to a payment provider to take a credit card payment from the customer, if we get an error it’s good to make that error traceable by making it easy to link the error message back to a specific customer, his specific order, the call-centre operator that took the order, etc.

Conclusion

I’ve only really scratched the surface of making software that’s easy to support and maintain, but I hope you can see the general principles at work.

Think about these principles when you are putting together the requirements for your software – even if you’re a business person and not technical – and you’ll get much lower Total Cost of Ownership from your software as you are able to more quickly and proactively find and fix problems.

Cheaper software through better budgeting

I recently came across an organisation whose poor budgeting structure means their software costs are much higher than they should be. They could spend less, AND get better results, IF they changed the way they think about software.

Let me explain.

You can break down software projects into two parts: the initial development and launch, and then the on-going support and maintenance.

This particular company had totally separate budgets for the initial development and the on-going support.

What happens when budgets go bad?

Can you guess what happens if you budget like this? The initial development has to be done for a certain cost, or the first project manager gets a kicking. So the features that would make supporting the software a whole lot easier – or even possible vs impossible – just don’t get written. What are these features? Monitoring how the software is running, proactively alerting the right people when things go wrong, and giving visibility of what the software is actually doing behind-the-scenes.

The initial project manager delivers on-budget and everyone is happy… until something goes wrong.

The manager in charge of the on-going support is now in a much bleaker position. He has got to fix whatever problem has arisen, but he has nothing to go on. He didn’t know the software had gone wrong until somebody told him, so he’s playing catch-up right from the start. He can’t see whether the software is running properly. He can’t see where the errors have happened. He’s just going to have to take random guesses and blunder on until his team finds something and fixes it. Then how does he know it’s even properly fixed, when he still can’t see what the application is really doing? He can’t have confidence that the job has been done properly.

Then the next time a problem happens, he’s back to square one again.

In reality, what would probably happen here is that in a busy department the manager would get somebody to have a quick five-minute look, declare that the problem can’t be found, and ask the business team to prioritise fixing the problem versus working on all the other things that the team has to do. The fix won’t get done for a few months, everyone will forget about it, and the software will just stop working. Sometimes the only person who really knew what was going on will leave the company. Effectively the whole development effort has then been wasted. This happens a lot!

The root cause of the problem

So what’s really gone wrong here?

The budgeting process has made the initial development slightly cheaper, but has simply shifted the cost of support into the future – and now the cost has doubled, trebled, or worse! The software remains out of action for longer, possibly even permanently, because it cannot be quickly fixed and supported.

The budget didn’t help the project, it actively hurt it.

The solution: consider support and Total Cost of Ownership from the start

The solution to this problem is to set the budgets for software based on Total Cost of Ownership (TCO), looking at the whole lifetime of the software. You might think this is obvious, but in a surprisingly large number of companies it isn’t!

Rather than considering initial build and then maintenance as two separate activities, consider them as two parts of the same whole. It’s usually folly to save a little money up-front if it means much bigger costs – or total unavailability of the software – further into the future.

Getting managers to think like this can be difficult. If you put your project manager’s hat on, the ability to support and maintain the software is really part of Quality.

Quite often nobody ever asks the question, “How long will this software actually be in use?” In most cases, the software actually ends up being used for much longer than anyone predicted at the start of the project (I’ve seen six-month proof-of-concept software still in use ten years later!) And the longer the software is used, the more the costs of unsupportable software mount up.

Action points

Consider whether the way you budget your software projects is harming your ability to produce supportable and maintainable software , thus pushing up your costs.

When budgeting, consider prioritising Total Cost of Ownership over the whole lifetime of your software, rather than a cheap initial build followed by years of pain.

If you still need to split your software budgets into initial build and then on-going maintenance, ring-fence some budget in the initial build to make sure the software is supportable – think about support and maintenance in your requirements.

Look out for another article where I discuss supportable software in more depth.

Ten reasons to use a wiki for documentation

I’ve been very impressed by how useful the wiki has been in real world use: here are the reasons that have made the wiki very successful for us.

Thought Wikipedia was the only wiki? Think again! A wiki can be a great help in keeping all your documentation up-to-date and easily accessible. In this article I’ll explain why you should give a wiki a try.

For a couple of years now, I’ve been working with a FTSE 100 company that uses wiki software for keeping its internal IT documentation. This includes notes relating to development, testing, and how the various IT systems and business concepts work.

I’ve been very impressed by how useful the wiki has been in real world use, so I thought I’d share the reasons that have made the wiki very successful for us (and for me in particular, as a documentation author as well as a reader).

As knowledge management becomes ever more important, most companies should give serious consideration to using wiki software, not just within IT departments but in the wider business.

The wiki software I’ve been using is Atlassian Confluence, but no doubt using other wiki software will realise some if not all of these benefits.

So in no particular order, the benefits that I’ve personally found with using a wiki for documentation are:

1. Easy to find information

A wiki puts information is all in one place and is fully searchable.

With hundreds of topics, potentially written by hundreds of users, it’s easy to end up with a labyrinthine folder structure of Word documents that sit gathering virtual dust because nobody can find them. For example, I had been working with the company for about 8 months before somebody pointed me to some useful documentation that I could have used right from my first day with them!

A searchable wiki makes it quick to home in on exactly the information you require.

2. Easy to tell how up-to-date a document is

I recently read a corporate document, that’s still being issued, that discussed upcoming changes for 2005 – it’s now 2014 as I write this!

A wiki breaks a large topic into a series of sections, one per page, and with automatic date tracking for when each section was last updated you can easily say how up-to-date or out-of-date each individual section is.

If you read a sentence in the documentation similar to “John recently did some work on the payment system”, which is bad because it isn’t specific, you can at least roughly narrow down when this time period might have been. In a Word document that was started 10 years ago and periodically updated, you would have no idea as to even which year it might have been!

Since out-of-date documentation cannot be trusted, and might be either wrong or actively misleading, being able to tell the precise age of the documentation you are reading greatly helps with understanding how much or how little you can trust the documentation.

3. Easy to update, so gets updated more often

Updating the documentation is as simple as clicking the bookmark in your web browser to get to the wiki and making a few changes. There’s no need to fiddle around with version control or re-issuing documentation.

It’s also easy to do a very small change here and there, when you have time, and then build up the documentation over a period of time. I have wiki pages that I update probably once a week as I learn a new snippet of information. This contrasts with the approach of writing documentation into Word documents, where it feels more like you have to write a whole manual or definitive piece of documentation all in one go and then more formally distribute it.

So because wiki documentation is so easy to update, it tends to be more up to date.

4. Easy version control and roll back

A wiki lets you easily go back to a previous version of a page. You can take a more active approach to updating documentation, because you know you can never really break it, and can always roll back if you put the wrong thing in the wrong place.

5. No need for a single document owner

There are no bottlenecks centred around individual people for writing documentation or putting together everyone’s contributions. If you’re reading or reviewing documentation, and you know that something is wrong or out of date, you can update it immediately, without asking permission, and without waiting for somebody else. This helps to keep documentation up to date.

6. See who wrote what

Depending on who wrote the documentation (and your assessment of their competence!), you know more about the likely quality of the documentation, and exactly who to speak to if you have questions about it.

7. Links within the documentation to help users navigate

Being able to easily add links to other relevant sections of the documentation means it’s easier to guide readers to the precise areas of the documentation they will find more useful, and easier to make sure that the reader doesn’t miss other important topics related to the section they are currently reading.

8. See a list of recent edits to know who has been working on what

Atlassian Confluence has a dashboard view showing who has been editing what. It’s like a running commentary showing all the changes that have been made. It makes it easier to see who is working on what areas of the documentation.

9. Notification of changes

It’s easy to set up notifications for sections of the documentation that you are interested in, and then be told when those sections are updated. This way you can be made instantly aware of when important information might have changed.

10. Easy team collaboration for fast-moving information

For sections of the document relating to project status, or what will be released in an upcoming software release, where several authors may all be making changes in the same day, the wiki environment makes it very easy to make and share these changes.

When NOT to use a wiki

There are some downsides to using a wiki, largely relating to making sure that information is kept secure, but any documentation written down can theoretically be disclosed outside the company anyway, so this isn’t an issue solely related to wikis. Wikis can restrict access to certain pages to certain users anyway.

Wikis can tend to be quite free-form, with different authors doing things in different ways, so sometimes you need to try and impose a bit of structure.

If you need full distribution and approval controls, perhaps when issuing documents to third parties, then you might want to consider a fully-fledged Document Management System, but they are quite heavyweight and expensive, and you’re unlikely to really need it.

Conclusion

I’ve found that using a wiki for documentation brings the documentation to life. It’s no longer an old, stale and outdated document that gets written once and then forgotten about, never updated and never read. It keeps the information up to date, prominent, and searchable. I’ve been very impressed with using a wiki, so I recommend that you give it a try.

Action Points

If you want free wiki software then consider MediaWiki, which is what Wikipedia runs on. If you’d prefer a hosted wiki that you can get started with immediately, there are a variety of free and paid services.

Benefits of staying simple: Lewis Hamilton Formula 1 Style

Here’s an interesting BBC article on the benefit of staying simple when performance really matters.

Here’s an interesting BBC article on the benefit of staying simple when performance really matters, as seen from the high performance perspective of Formula 1 racing driver – and former world champion – Lewis Hamilton.

Hamilton’s central argument is that  “When it’s not simple, it can be stressful, and when you’re stressed you’re not working at your best.”

It’s well worth a read.