Thursday, November 26, 2009

21 methods to innovate

I couldn't help but to copy it from the source (http://feedproxy.google.com/~r/business-strategy-innovation/~3/dXCsA8Esff8/21-great-innovation-methods.html?utm_source=feedburner&utm_medium=email):

1. Copy someone else's idea. One of the best ways to innovate is to pinch an idea that works elsewhere and apply it in your business. Henry Ford saw the production line working in a meat packing plant and then applied to the automobile industry thereby dramatically reducing assembly times and costs.

2. Ask customers. If you simply ask your customers how you could improve your product or service they will give you plenty of ideas for incremental innovations. Typically they will ask for new features or that you make your product cheaper, faster, easier to use, available in different styles and colours etc. Listen to these requests carefully and choose the ones that will really pay back.

3. Observe customers. Do not just ask them, watch them. Try to see how customers use your products. Do they use them in new ways? This was what Levi Strauss saw when they found that customers ripped the jeans - so they brought a line of pre-ripped jeans. Heinz noticed that people stored their sauce jars upside down so they designed an upside down bottle.

4. Use difficulties and complaints. If customers have difficulties with any aspect of using your product or if they register complaints then you have a strong starting point for innovations. Make your product easier to use, eliminate the current inconveniences and introduce improvements that overcome the complaints.

5. Combine. Combine your product with something else to make something new. It works at all levels. Think of a suitcase with wheels, or a mobile phone with a camera or a flight with a massage.

6. Eliminate. What could you take out of your product or service to make it better? Dell eliminated the computer store, Amazon eliminated the bookstore, the Sony Walkman eliminated speakers and record functions.

7. Ask your staff. Challenge the people who work in the business to find new and better ways to do things and new and better ways to please customers. They are close to the action and can see opportunities for innovation. Often they just need encouragement to bring forward great ideas.

8. Plan. Include targets for new products and services in your business plan. Put it onto the balanced scorecard. Write innovation into everyone's objectives. Measure it and it will happen.

9. Run brainstorms. Have regular brainstorm meetings where you generate a large quantity of new product ideas. Use diverse groups from different areas of the business and include a provocative outsider e.g. a customer or supplier.

10. Examine patents. Check through patents that apply in your field. Are there some that you could license? Are some expiring so that you can now use that method? Is there a different way of achieving the essential idea in a patent?

11. Collaborate. Work with another company who can take you to places you can't go. Choose a partner with a similar philosophy but different skills. That is what Mercedes did with Swatch when they came up with the Smart car.

12. Minimize or maximize. Take something that is standard in the industry and minimise or maximise it. Ryanair minimized price and customer service. Starbucks maximised price and customer experience. It is better to be different than to be better.

13. Run a contest. Ask members of the public to suggest great new product ideas. Offer a prize. Give people a clear focussed goal and they will surprise you with novel ideas. Good for innovation and PR.

14. Ask - what if? Do some lateral thinking by asking what if…..? Challenge every boundary and assumption that applies in your field. You and your group will come up with amazing ideas once the normal constraints are lifted.

15. Watch the competition. Do not slavishly follow the competition but watch them intelligently. The small guys are often the most innovative so see if you can adapt or license one of their ideas - or even buy the company!

16. Outsource. Subcontract your new product development challenge to a design company, a University, a start-up or a crowdsourcing site like ive or NineSigma.

17. Use open innovation. Big consumer products companies like Procter and Gamble or Reckitt Benckiser encourage developers to bring novel products to them. They are flexible on IP protection and give a clear focus on what they are looking for. A large proportion of their new products now start life outside the company.

18. Adapt a product to a new use. Find an entirely different application for an existing product. De Beers produced industrial diamonds but found a new use for diamonds when they introduced the concept of engagement rings. It opened up a large new market for them.

19. Try Triz. Triz is a systematic method for solving problems. It can be applied in many fields but is particularly useful in engineering and product design. Triz gives you a toolbox of methods to solve contradictions e.g. how can we make this product run faster but with less power?

20. Go back in time. Look back at methods and services that were used in your sector years ago but have now fallen out of use. Can you bring one back in a new updated form? It has been said that Speed Dating is really a relaunch of a Victorian dance format where ladies had cards marked with appointments.

21. Use social networks. Follow trends and ask questions on groups like Twitter or Facebook. Ask what people want to see in future products or what the big new idea will be. Many early adopters are active on social network groups and will happily respond with suggestions.

Tuesday, November 24, 2009

Wiki for requirement management... Why not?!

Today I had a conversation with one of project managers. They need a tool that will help capturing existing system behavior in form of product requirements. I suggested using one of of-the-shelf solutions but he argued that they have good reason to stay within Wiki used for documentation management at the project. I doubted that Wiki is the right place to do this because of its limited functionality. So, it made me go to the Google and seek for the answer.

The result was better than I expected. I found out that many people did this and succeeded. All we need to do is following simple recommendations:

1. Do not let it become a mess

If several people are asked to write comments, change requirements suggesting variants it will soon become a mess. In order to avoid it, there should be strict rules and authorities to changes the requirements clearly defined within the team.

2. Keep it organized

Within time, Wiki description of requirements may deteriorate into amorphous, unstructured document. Especially when there are several contributors, each having own opinion on what it should look like. My recommendation is to keep the structure clear and understood by all contributors, so new articles appear in right place and connected to right pages.

3. Update it often

Do not wait until there are tons of changes to be done. Do it in small steps, immediately after a change comes up.

Wiki is a great tool for the collaboration. But as any tool it should be used wisely. As they say, a fool with a tool is still a fool. Don't be foolish. Find out about the issues before jumping into applying a tool to the process for which it is not intended to be used. Using Wiki for RM... Why not? But let's find out how for the beginning!

Happy requirement management!

Monday, November 23, 2009

Requirements: do it correct right from the start

Lately we had a quote from a client who was seeking for a help in writing software requirements. He was looking for someone to translate a unstructured input into a set of solid, high quality requirements. That was a wise step because requirements is where the quality of a product starts.

More and more people come up with ideas of a software product but the numbers of people who can transform an idea into a full spectrum of professional requirements remain too low. I will try to explain some of the ideas behind writing good requirements, so one could do this on a high level without a help.

Let's start with definition. Software requirements are a set of statements that define software behavior. Under behavior I mean the functionality available for the user or the characteristics of the software that directly affect its business success.

Aside from the qualities of requirements a big role is played by the process. The way you work with requirements defines their effectiveness in the development cycle. During the lifecycle requirements go through several stages:

- Creation or gathering
- Review
- Modification or update

As you see this is not enough to just create requirements. You have to have means to update it later, when changes come up. No matter how good at gathering requirements you are or how good you know what you want to have in the product, you will face change requests. They can come up out of review, development, testing, beta program and field usage. So, you must have a process how to deal about changes, so as to have the lowest possible cost of the update, making sure everyone interested is notified.

All above impose the following demands on the requirements:

- Correctness
- Completeness
- Consistency
- Non-ambiguity
- Testability
- Traceability
- Maintainability or changeability
- Sense of priority

Correctness means that your requirements shall speak the truth. This is not enough to simply state the truth once. You need to make sure that requirements are being updated timely.

Completeness implies the all the required information is provided. You need to remember who the customers of the document are. They span from developers through testers and deployment engineers toward technical writers and support engineers. In some cases, the customer also is a consumer. So, interests of all those people shall be taken into account.

Non-ambiguity means that there is only one understanding of what requirements say. Two different people reading requirements must have the same idea of what they speak of. There three possible failure scenario for this quality:

- Boundary shift ("up to 100" instead of "100 or less")
- Synonyms use (use the same term consistently throughout the document)
- Negative sentences (use positive sentences instead)


Testability
is as simple as its name. You should be able to check if a requirement is met. And you should be able do this in a reasonable time and with reasonable resources. Testers are best people to judge upon it.

Traceability is a key to connecting different entities in your process into logical chains. Change in requirements may need according changes in design or test documents. To track those changes and update all connected entities correspondingly, we need to give a requirement an identifier. This is usually an unique number, that defines one and only one atomic statement.

Maintainability is how easily you can update it. The structure of the document defines how much efforts you may need to make a change. Duplicate information doubles the efforts, so use references instead.

Sense of priority gives the possibility to easily say which requirement is a must and which is nice to have. This is especially important when it comes to selecting tests for regression testing or shaking up the functional scope with hope to find 1-2 man months you are lacking in the development plan.

If you manage to write requirements that meet the above qualities then you are most likely to succeed. I would also recommend keeping it short. As one wise man said "conciseness is talent's sister".

Additionally I would recommend finding articles related to wording to be used in requirements definition. Following simple rules may help making requirement easier to read. All the more, the language is ambiguous per se. You may find in there which construction of language to avoid making it less ambiguous.

Good luck!

Monday, November 16, 2009

Change your environment!

I am back from a short vacation that I have spent with my family. It was good but too short :) Anyway I felt much better getting back to work after a week I spent outside the usual routine. The most important about my comeback is how I feel about things that seemed common and normal before I have taken a fresh look at them. Once I am back I felt myself full of ideas and desire to change things for better.

If we only could change the way things are being done on a daily basis it would open a whole new thinking perspective to us. Instead of banging at the wall with our foreheads we would oversight the problems from above and find a solution we never though as to be existing before.

Every time I come back from vacation things looks a bit differently. It helps me to see in them what I have overlooked before. Hopefully you have the same feeling coming back from a lengthy vacation. Let's trust our fresh look and change things for better!

Happy innovating! :)