Archive for the ‘General Business’ Category

Older Entries »
h1

Reduce Wasted Effort…

February 20, 2010

Far too many software development projects fail to meet deadlines and run over budget.  You’ve possibly seen this first-hand.  In fact, I’d be surprised if anyone working in this industry hadn’t personally experienced at least one development that ended up taking a lot longer and costing a lot more than originally intended.

Watch for ice

Part of the problem is that designs and specifications are commonly put together in a short phase right at the beginning of a project.  Some effort is put into trying to specify the requirements and translate them into a workable design in one swoop.

This is a noble but flawed thing to do.  It almost always fails – and here’s why:

Things change…

things change

Projects can run for weeks, months or even years.  However, such projects don’t exist in vacuums.  They are part of a wider world of business, in which change is an ever-present reality.

By expecting to be able to specify a design up-front, and stick to it right through a development project, we set ourselves up for failure.  Even supposing everything went well, and we missed nothing out from our requirements analysis, the fact is that the world will be a different place in the weeks, months or years it takes to translate those requirements and that design into an actual product or service.

What’s more, if we expect to get our requirements right and then build a single design to turn those requirements into something worthwhile, we’re placing all of our eggs in one very big and rather flimsy basket.  We’re assuming that those requirements are correct, and that they won’t change.  But, inevitably, the requirements will be written by someone who’d rather be out playing golf, and the very busy business stakeholder is really rather too busy to read that requirements specification.  Probably a business analyst is trying to come up with a workable design without having any technical know-how, and in any case they’ve missed a huge chunk out because they didn’t really know how the new widget was going to fit into the existing system.  So, they hide their misunderstanding in a veil of abstract and obtuse language, which is easy to misinterpret and difficult to follow.

To compound all of this, the rather unreliable requirements documentation is then revered as ‘correct’, and management will apply pressure for Real Work to begin.  Which means cracking on with the build phase before anyone has engaged with the end-users to see if the proposed design is going to be up to the job.  Which it probably won’t be.

Fast forward a few weeks or months, and the false assumptions, omissions, bad decisions and flaky designs have become so entangled in the actual fabric of what is being built, that disappointment and failure is a certainty.  As the developers start to question the designs and requirements, it suddenly dawns on everyone that something is not right but nobody knows how to turn this baby around.

Superbaby bib
Effective requirements definition is not a one-shot deal.  It must be treated as an ongoing process, which needs to be shaped by constant feedback from all the right people.  Requirements prototyping, using software prototypes, feedback sessions and constant adjustment, is the answer to ensuring that requirements are up to the job.

By spending a bit more time at all stages, adjusting the design and the requirements to cope with new knowledge and user feedback, we can ensure that there is a much higher likelihood of delivering a quality system which actually does what it needs to do, rather than what was originally proscribed so many months previously.  Expensive development effort is minimised because the design and requirements are clear and unambiguous.

At the end of the day, any additional cost of using requirements prototyping is more than offset by the significant savings by reducing wasted effort.

Try it – you might surprise yourself by how much better your project runs!

Posted in General Business, Prototyping | Tagged , , , , , , , | Leave a Comment »

h1

Save money: invest in a big display

February 18, 2010

Today’s article is a bit of a diversion, but it’s something that I see time and again which unquestionably hurts the productivity of anyone who uses a computer professionally.

Many companies wax lyrical about the need to operate more effectively and do a lot of pondering on matters of productivity and efficiency.  They sometimes pay top dollar to external consultants who come in and analyse this, measure that and recommend changes to processes, systems and so forth.

All of this can be really worthwhile but in my opinion the benefits gained on an organisational level are usually easily bettered by a small change for every computer user.

What am I talking about?  Display size (or, more specifically, resolution)

Big curved monitor

Far too many companies ‘go cheap’ by providing their users with small, inexpensive monitors – say, 19″ os a typical example these days.  These small monitors might well have been considered ‘luxurious’ by the standards of the Windows 3.1 days, but those days are gone now and our increased reliance on windowing systems has raised the bar and companies need to understand that they need to move with the times.

Take, for example, a small software house I spent some time at a year back.  They were doing some fairly cool things with the latest tech, and there were some really good developers working there.  However, each was hamstrung with the sort of budget display that meant that even when an application was maximised, the actual ‘workspace’ was tiny after the various toolbars and panels took their cut.

Even assuming that these budget displays were completely free to the company, their cost was far higher than that of a pair of 24″ displays would have been, or even a 30″ display.  The low resolution meant that developers were frustrated and had to keep shuffling things around to make enough space to accomplish anything.

Let’s look at the ‘mid-range’ compromise of a 24″ display.  That will provide a desktop of typically 1920×1200 resolution, as compared to a typical 19″ offering 1280×800 or similar.  In numerical terms, the 24″ display has around 2.3Mp to the 1Mp of the 19″ display.  In other words, its ’screen real-estate’ is over twice as capacious as in the smaller display.

What this translates to is the ability to see more code, or more of that spreadsheet, or the opportunity to place two Word documents side-by-side for comparison purposes, or the option to have an email client open and visible at the same time as the web browser, and so on.

Every time a user is forced to reorganise windows on the screen to cope with limited screen real-estate, they waste valuable time and it can snap them out of ‘the zone’ of real productivity.  These context switches will, over the course of a day, a week or a month, have a cumulative negative effect on that user’s ability to perform.  Lower performance is opportunity lost; opportunity lost is money wasted.

I don’t feel the need to wheel out complicated equations or calculations to justify this stance; it should be obvious to anyone who has ever done anything on a modern computer.  However, lest I disappoint, if we assume that (over the long term) a restrictive display reduces productivity by even 5%, bear in mind that 5% of most any professional computer user’s salary buys several 24″ displays!

On top of that, a larger display gives that user a more enjoyable computing workflow experience, reduces mistakes due to excessive context switching and reduces the need to reduce font sizes so as to make it all fit.

Any company which skimps on decent displays for its employees is needlessly wasting money – and that’s a fact.

Posted in General Business | Tagged , , , , | Leave a Comment »

h1

Distracted by Shiny Things

January 11, 2010

This blog likes to talk about ways to improve your chances of delivering a successful software project.  One of our mantras is the use of software prototyping, but a recent conversation got me questioning whether building a software prototype might end up creating its own problems.

“Whoa!” I hear you cry.  Take a second to pick yourself up the floor; calling prototyping a liability on a site hosted at softwareprototyping.net might seem like a rather chilly day in hell.  And you’d probably be right, but I try to present the upsides and the downsides with a (relatively) impartial hat on.  Or at least that’s the plan.

So, software prototyping creating its own problems?  Surely some mistake?

Well, to answer the question: generally, no, software prototyping is usually a highly effective way of steering the early stages of a software project, therefore increasing your chances of success. 

However, if we widen our brief and consider requirements prototyping – i.e. the use of prototyping techniques as a core part of the analysis and specification of a new system – we hit across a small problem.

This is illustrated best with the story of Jeff*, at the time a divisional director in a large financial organisation. 

I was involved in the design of a considerably wide-scoped prototype.
Using the techniques of requirements prototyping, I was able to bring in feedback from users, stakeholders and technical analysts to help shape the design.  This was going rather well; hard work but with each revision showing real progress towards a killer design.  Along the way, however, Jeff started to sniff around in an example of classic hit-and-run micromanagement. 

Despite concentrating on building up the shape of user journeys, exploring the effectiveness of our interface and so forth, Jeff really wanted us to devote our time to ‘making it look just fantastic‘.  Which, unfortunately, involved endless fiddly adjustment to such things as the precise placement of fields, the exact colour of text, whether this image looked professional enough and so on.  All very interesting, but somewhat missing the point of the prototyping process.  All this served to do was divert significant time and effort into polishing the finest details of a prototype whose main purpose lay elsewhere.

On reflection, and in Jeff’s defence, it was pretty clear that he believed in making everything look as slick and professional as possible.  He knew that the project could gain support from his superiors only if the prototype gave the illusion of completeness, and so in a way he was right to push for consistency and professionalism in the appearance. 

Our failing (as a project) was in letting him do this at far too early a stage.  After all, we hadn’t decided if we were going with User Details Capture Journey A, B, C or D at that point, so polishing them all to a high gloss was always going to be overkill.

What I learned from this was that the production of any tangible output – be it a paper design or a full interactive prototype – invites attention from those who don’t understand its role, its place.  Even though they may be senior, important people, they may not be important to the project itself. 

Sometimes, these people get distracted by shiny things, colours, minor details.  This isn’t a problem if they remain as observers or on the fringes of the project, but can be a serious risk if they attempt to push their way into the proceedings.  As prototyping practitioners, such people really slow down the responsiveness of the prototyping process and dilute the benefits of prototyping.  In other words, these people cause more harm than good. 

The skill is recognising these people and finding a way to either educate them to the purpose of the prototype or reducing their involvement/exposure to the team.  If they really must have their fully polished, ’slick’ design ideas visualised, then at least explain to them that it simply isn’t realistic to do this over the entire prototype.  Offer to ‘polish’ up a portion of the prototype once the fundamentals are stable.  In other words, don’t wallpaper the living room until you’ve finished building the walls…

As a final word, don’t take this article as a negative reflection on the use of software prototyping techniques – there are far more benefits than drawbacks…

* name changed to save on blushes and prospective lawsuits…

Here are some links to other articles which might be of some interest if you want to know when software prototyping is appropriate:

Posted in General Business, Prototyping | Tagged , , , , , , , | Leave a Comment »

h1

Involve important people (part 2)

December 11, 2009

A few weeks ago, I wrote the first in a series of short articles about who needs to be involved in the software design process if it’s to have an increased chance of succeeding.  We covered involving users then, but they are only part of the overall picture.

This article looks at the stakeholders – those people who have vested interests in the success of the project. 

Pictire of a business baby

To them, they may have been given the responsibility to see a project through to delivery and beyond; they may be in charge of teams of users and therefore their own productivity and effectiveness is impacted by that of those users.  Get it wrong, and their bottom line is threatened.  Understandably, they’ll want to get involved and keep an eye on the progress of the project.

In today’s troubled financial climate, you can guarantee that stakeholders’ bosses will be keeping a close eye on things too; the decision to proceed with a new software project is often made from fairly senior levels.  Support from senior execs doesn’t grow on trees, so when you do get it, you can’t take it for granted.  They’ll expect something in return, and that price is invariably success. 

Stakeholder management is, of course, a science and an art unto itself, so I won’t cover that here, but it’s worth taking the time to scope where their individual priorities lie.  Some will be looking for a direct impact – software that enables their team to do better, say – and others will look to gains by association with a successful project.  Some may have competing priorities, or hidden agendas, and it’s certainly no bad idea to tread cautiously when involving these people.  Even if all is well, there is always a real danger of ‘too many cooks spoiling the broth’.

One project I worked on suffered from just this problem.  It was a large-scale system-integration which aimed to provide a consistent interface to a number of systems both old and new.  That in itself was fine and a challenge to relish.  However, every system within scope (and a few out of scope) came with its own set of stakeholders, many of whom would try to force their ideas upon the overall design without necessarily considering its impact to the others.  A difficult thing to manage, but software requirements prototyping helped by giving the freedom to build quick mock-ups to test ideas out and influence the stakeholders to reject the occasionally inconsistent, flawed or even wacky suggestion.

This said, stakeholders hold responsibility and accountability within the project, and they will want to be involved.  Do so, and they will provide domain and contextual knowledge which would be difficult to obtain any other way.  They will also invariably be involved in the eventual sign-off of any design, so by involving them throughout the design process, they will already have a better understanding of, and buy-in to, the eventual design.

Posted in General Business, Prototyping | Tagged , , , , , , , | Leave a Comment »

h1

Adding magic

November 18, 2009

Picture of a magic wandDesigning interactive software systems is a fantastic opportunity not only meet the objectives of your customer, but improve the day-to-day experience of the end users.  This responsibility doesn’t come lightly; get it wrong and you run can just as easily frustrate and irritate those users, and even a mediocre system will become a hated system over time. 

What we need to do is to try to think as a user does, see a system as a user sees it and consider the bigger picture of that user’s working day.  How does this system fit in with the other things they do.  Do they want to be able to use this system concurrently with another system?  Will we need to work with a non-maximised screen layout in mind?  How much assistance in using a system is enough?  How much is too much? 

The list of considerations is seemingly endless, but by thinking about these things we achieve something very important indeed: we start seeing a system from a user’s perspective.  In other words, we start to really appreciate just how a system will fit in with the workflow of our users, in the context of their everyday tasks.  In essence, we start considering that system’s place in the ecosystem of a user’s day.

We have, then, our opportunity to add value beyond the delivery of ‘a system’.  We can deliver ‘a solution’ that integrates into workflow more effectively, and delivers real benefit through the combination of increased productivity, ease of use, interoperability with other systems and so on.

What we have is the opportunity to really improve, to ‘add magic’ to that user’s day.  Let’s not waste that opportunity by rushing our software out the door…

[why not subscribe to this blog via RSS? It’s a great way to ensure you don’t miss a single post]

Posted in General Business, Good Design | Tagged , , , , , | Comments Off

h1

The power of small teams

November 16, 2009

One of the most recurring questions that crops up in software development is ‘what size of software team is optimal?’ It’s a tricky question and consensus seems as far away as ever.

Picture of figures lifting a piece of a puzzleThere is a school of thought which suggests that smaller teams are considerably more effective, per person, than larger ones. The theory goes that the overhead required to organise and manage a smaller team is proportionately lower than that of a larger team. As team numbers increase, in fact, this overhead appears to increase exponentially.

Why should this be? Well, there are a number of factors, including:

  • Communication
    The more people need to know, the greater the time spent propagating information and ideas, and the larger the risk of those ideas being misunderstood;
  • Diversity
    Generally a good thing, in an effective software team it can be difficult to ‘carry’ anyone whose skill-set and experience doesn’t closely match to the tasks in hand. Diversity is nice, but when there’s a job to do it’s better to have a few specialists than many generalists;
  • Division of tasks
    Splitting larger tasks into smaller ones makes sense but it requires careful planning and resourcing, and runs an increased risk of ‘compartmentalisation’ of knowledge;
  • Personality issues
    The greater the number of participants, the larger the likelihood of conflicts, fallings-out and so on. Also, more people mean that people have smaller individual stakes in the outcome of the project and may feel that their contributions are less valuable;
  • Environmental issues
    It is always trickier to locate a larger team together due to space constraints so larger teams may end up having to be split into two or more physical locations. This creates difficulties with communication, co-operation and dilutes the sense of ‘belonging’ that a smaller team located in one place would have.

In fact, a smaller team can be considerably more efficient than a larger team for a majority of software projects. And this is after taking into consideration the fact that a smaller team will have fewer ‘man days’ available within a fixed period. With the right people on board, a smaller team can be twice as productive per person as in a larger team, due to the considerably lower organisational overhead.

So, who are the ‘right people’?

There is a strong body of evidence to show that the very best individuals can be five or ten times as productive as even averagely competent individuals, when given the opportunity to release that productivity. This opportunity occurs only when the structure of the team permits rather than obstructs performance.

In other words, the team is small enough so that communication is direct and timely, meetings are short and only when required and management’s role is less one of fighting the bureaucracy and ‘red tape’ and more one of enablement and facilitation. The interaction between team members, playing to individuals’ strengths, promotes a synergy that is very rare in larger teams.

A smaller team, composed of talented individuals who have sizeable responsibility, enthusiasm and whose workflow is not impeded by the overhead of larger team issues, can achieve great things.

“Innovation always has been driven by a person or a small team that has the luxury of thinking of a new idea and pursuing it. There are no counter examples.”
– Eric Schmidt, Google.

The power of small teams is in achieving great things with minimal waste – and in this sense our original question ‘what size of software team is optimal’ might be answered as follows:

The optimal software team size is as small as one can get away with whilst still achieving the goals.

I know this doesn’t really commit to a particular number, and of course everything is dependent on the quality of the people in the team, the scope of the work to be carried out, the environment in which that work needs to be carried out and countless other factors, but if we had to be drawn on a number, we’d say that the very best software teams are composed of less than ten individuals in total. Generally speaking, of course…

Posted in General Business | Tagged , , , , , | Comments Off

h1

Involve important people (part 1)

November 14, 2009

It’s far too easy to forget to involve the most important people in your software design: the people who will use it.

Your important users
Your users are at the front-line; you should try to involve them in the design phase, so that their needs are acknowledged and their ideas considered and perhaps incorporated into your design.

Use software prototyping to give them interactive designs they can try out for themselves and see what works for them and what doesn’t. Listen to their suggestions and preferences. Value their opinions.

They will love to be involved, as they have a personal stake in the success of your design. Do it well, it will enrich their working lives; do it poorly and they may never forgive you.

Posted in General Business, Good Design | Tagged , , , | Comments Off

h1

Turning prototypes into training simulations

November 13, 2009

Last week, we discussed some reasons why we shouldn’t always throw away our prototypes. After all, we’ve invested a fair amount of time in them, so it makes sense to put them to as many good uses as we can.

Picture of Training Wheels on Motorbike

As mentioned, a powerful use of a software prototype is as a training simulation. Well, we received a couple of emails asking for some more detail about using prototypes for training, and how best to do this, so here is a little more information:

To create a training simulation from a prototype, we ask certain things of our prototype:

  • It must be stable (in terms of functionality)
    In other words, if we are going to use it to train users, it must reflect the system that will be implemented closely – otherwise the use of simulation will be counter-productive;
  • It must be interactive and sufficiently detailed
    Effective training has to feel like a real system, which means it must be interactive. Navigation should work, logins should be simulated, drop-down lists should contain real-world entries, selections on pages should work as a real system would, there should be mock training data and so on;
  • It must look and feel complete
    Each aspect of the prototype’s design should be consistent and complete, at least within the scope of the training requirement. There should be no ‘coming soon’ placeholder pages or anything that suggests a work in progress. Bear in mind that what we are trying to do is to make the simulation feel as much like a built system as possible.

Once we’ve confirmed that our prototype meets these requirements, then we need to think about what type of training simulation we want to create.

The two main types of training simulation that we’ll consider are:

Free (unguided) Training Simulations

…and…

Guided Training Simulations

Picture of 'keep right' sign showing left arrow‘Free’ training simulations allow the user to try systems out without imposing structure on what they should do, or how they should do it. Whilst there may be context sensitive help or general guidance on training objectives, the user is left to their own devices to explore the system and make their own discoveries. In these ‘unguided’ simulations, as we aren’t focusing on workflow or operational tasks. We simply want the user to gain confidence in, and awareness of, the system and how to navigate within it.

Guided training simulations are more complex from a design perspective as the overall aim is to guide users through one or more tasks – typically workflow or operational objectives – with supporting contextual material such as a step-by-step help system. Within a guided simulation, the objective is to train a user how to accomplish distinct tasks in a more directed fashion.

To create an unguided training simulation from an existing prototype isn’t a huge task, provided it meets the criteria mentioned earlier. In fact, it’s almost a ‘freebie’ if enough care has been taken within the prototyping process. Certainly, it’s an added-value output whose cost shouldn’t add significantly to the overall budget and whose benefits will certainly out-weigh those costs.

A guided training simulation is a more significant undertaking – care has to be taken to add ’state’ to the prototype – and this isn’t always easy. We need to do this, however, to hold the ‘current’ status of a user’s interaction with a guided task, and also to use this to control the context sensitive guidance materials. Building a guided training simulator requires a greater commitment from management as it will swallow time and resources to create. However, for critical systems, or where complexity is above average, the investment in creating a guided training simulation ahead of time pays off in diminished risk of ‘down-time’ (whilst users get ‘up to speed’) and increased acceptance from those users as they are already familiar with a new system before it is launched.

In a future topic, we’ll cover guided training in some more depth, but for now hopefully this overview will be useful.

[why not subscribe to this blog via RSS? It’s a great way to ensure you don’t miss a single post]

Posted in General Business, Prototyping | Tagged , , , , | Comments Off

h1

Choice and Accessible Design

November 10, 2009

Choice can be an empowering thing, but it can also overwhelm.

Picture of a pile of question marks Many great designs have succeeded because they kept things simple. Consider the Apple iPod: a music player like many others in functionality, but in essence a much more desirable gadget due to its great design. At least as far as the original iPod design was concerned, the engineers at Apple concentrated on how the device would be used rather than loading it up with niche features. The competition chose to stuff their competing devices with extra features which invariably got in the way.

The market recognised that having an accessible, simple design was more important than niche features and voted with its money: today, the iPod commands a market share of at least half of all portable music devices sold, if not closer to two-thirds, whilst the ‘also-rans’ scrabble to be noticed.

There is a strong correlation between good, approachable design and how well a product or service is adopted in its marketplace. Google Search is another great example: a very simple, easy to understand search page. It didn’t bombard you with banner adverts or confuse you with options and niche functions. It simply reduced the choice in the interface down to a bare minimum so that the it got out of the way, and people loved it.

So, as software designers we should look to our designs and see what is important, what is fundamental to the operation of our product. Speak to the people who will ultimately use your product. Find out what is really important to them, and how they would see it working. Build software prototypes of your design, and let them try them out. Listen to their feedback. Get the fundamentals right, before you even consider any secondary functionality.

It might seem radical, but as the majority of software users make use of only subset of functionality, it’s our job to put the majority of effort into ensuring that subset is as good as can be.

Posted in General Business, Good Design | Tagged , , , , , | Comments Off

h1

When not to prototype

November 7, 2009

As you will no doubt have realised by now, we’re incredibly keen on the whole concept of software prototyping. It’s something that, once you’ve seen the light, is difficult to get out of your system – and with good reason. It’s empowering, flexible, responsive and provides the sort of feedback into the design and development process that traditional methods lack.

However, it would be wrong to suggest that prototyping is the answer to all problems – it isn’t – or that indeed it can apply to all projects – it can’t.

For that reason, here are a few cases where the use of prototyping may not be the best choice, or even a valid choice at all:

  • Scale
    For the very smallest projects, creating a prototype might well be an investment in time and effort that is unnecessary and which may not be able to recover its own costs in subsequent savings;
  • Interactivity
    Prototyping excels at providing feedback about systems with which users interact. So, it goes without saying that non-interactive systems such as system batch jobs, services or data aggregation tasks may not benefit much from a visual prototype. This isn’t to say there is no benefit at all – the very task of visualising any system forces us to focus and to ask questions – but again it is unlikely that the cost of prototyping would be recovered by any savings;
  • Nebulosity
    If a system lacks even a basic scope and purpose, it will be incredibly difficult to create a prototype of any value. If a customer doesn’t have a clear vision of what they aim to achieve and some preference as to how that might be accomplished, it would be better to perform some early brainstorming sessions and conduct a little more research before starting any prototyping activity;
  • Specificity
    Conversely, if a system is already fully specified, had been rigorously designed to the last detail, and especially if the business stakeholders are happy with the specification and design, it may be unnecessary to create a prototype. There may be value in having a demonstrable model, of course, but in terms of using the prototype as a vehicle for soliciting feedback, its value is diminished.

There are, of course, other valid reasons why one might avoid creating a prototype, but they are overshadowed by the number one reason why people don’t prototype: awareness. Yes, lack of awareness of the process and benefits of software prototyping is the most common reason why people don’t do it.

Which is, in a roundabout way, the Raison d’être for this blog!

Posted in General Business, Prototyping | Tagged , , , , , , , , | Comments Off

Older Entries »