the Bridger

Now that's innovation!

April 11, 2011

Technology for people- why a Bridger?

Filed under: Sales and Marketing, communication skills, product development, project management — admin @ 5:18 pm

Technology for people- why a Bridger?

The problem

Technologists, vendors and technical architects alike invent clever technology, but they build it to their view of the world and expect people to adapt to processes and methods that are often unruly and throw out the baby with the bathwater.
Project managers will deliver a pizza, or new gold mine to the same rules and Quality people will ask you what you want, get a signature and give you exactly that for better, or for worse.

The result

This failing causes products to stay on the shelf and systems to fail altogether, or deliver dismal benefits. Using the same approach and people to tackle the problem usually exacerbates it.

The solution

A Bridger approaches the people dimension along with the benefits and works back to the solution so that it is designed, or configured to deliver a specific outcome and bearing in mind the critical human elements for success.

The outcomes:

n Systems that meet the need exactly

n Products that are cherished

n Customers that become your unpaid sales force

Comments Off

February 8, 2011

Requirements, tests, training, help files – the connection?

Part one What would you like sir

Part two Requirements,tests, training, help files

Part three Why no project exists onin isolation-whwat should be done

Part four Business rules, Process rules, Process, Data, different viewpoints

Part five Testing requirements is not optional

Part six Requirements strategy can make or break your project

Really! – Have you seen this new stuff?

This could easily have been Mick Jagger and Keith Richards after their first successful gig. In the modern world, it is more likely to be a hard working CTO talking to a COO about his systems needs.

Systems are not like any other purchase. You can go to a tailor today and he will do almost the identical things that a tailor did for Julius Ceaser. You can call an architect and his approach will differ little from that of Hiram Abif apart from the time taken to produce drawings. When it comes to systems though, it is more like medicine. Patients differ, you only hear what they tell you and you don’t really understand anything you have not personally experienced, you have to tease it out using your instinct and experience and play the numbers game.

There are techniques for flushing out the problems and verifying them and for getting the medicine accepted, but ultimately every doctor likes to deal with life threatening situations. If he succeeds for whatever reason, he’s a hero and if not, well, he did his best.
Apart from a lucky few, most of us in the software industry have to earn a living by delivering value in the real world through cost savings, or competitive advantage and that’s a tall order.
It calls for a mixture of calculated risk taking and good fall back positions and it requires an insight that combines real understanding of the business domain with leading edge technological ability. It doesn’t matter whether this is done by a committee or a genius as long as it gets done

The requirements challenge

So how do you meet a business person, listen to his/her needs and six, nine or thirty six months later get a well done, thank you response?

There isn’t a really good answer to this. If it is six months, you are in with a chance. If it is nine you are still in there, at thirty six, the likelihood is that before you deliver this, a much better solution will have been invented, or the problem will have been replaced by a new one.

There is a considerable number of methodologies out there, most of them geared up to coax you into paying for expensive training courses and few aimed at really bridging the divide between what a business needs and what technology can deliver with reasonable reliability. A methodology that really works has to be able to understand business needs, translate it into process and match this with the best possible technical solution.

Defining the problem

This is not as simple as it sounds. If you read my business case blogs, you will probably remember the way I recommend tying corporate objectives in a direct and accountable way to the benefits delivered by the business case. That makes perfect sense of course, because a good business sets a plan and then works to deliver on it.
There are other scenarios however that need to be taken into account, this example will hopefully help to illustrate the point.
Suppose we approach an Amazon tribe still living in the traditional way, tell them that we would like to give them some gifts and ask them about the problems they would most like to solve and the things that might give them the most satisfaction. Problems and exciters. The likelihood is that having seen bright steel machetes amongst the crew, they might suggest a steel spear to make fishing more productive. We might then suggest that rather than give them a spear, we can give them a monofilament net. This way they can catch enough for the whole tribe in an hour instead of having to fish all day.Here we have seen a classic example of the two cardinal sins of analysis:

1. Asking a question that the object of the question can’t possibly be expected to answer well.

2. Answering with a solution rather than a problem.

The interviewee in this example can’t be expected to know how to manage this process, so the entire responsibility lies with the interviewer. By the way, that includes the many occasions when the interviewee believes she knows exactly what she wants and is driving.
The responsibility of the analyst extends to making sure that the interviewee has explored and understood the problem and has a sufficient understanding of it and of the desired outcomes to start either designing or verifying the solution.
I include verifying here, because an increasing number of business people believe themselves to be tech wizards and arrive with fait accomplis and a budget wanting a technically trained fellow to make her vision happen. In these cases, instead of designing a solution, the analyst goes through a process of verifying the problem, the requirements and the solution. If these three don’t match and the sponsor doesn’t see it then it is up to the individual analyst’s conscience and professional intergityas to what he/she should do next.

In Summary

In this part we have talked about three key issues:

1. The unique challenge facing a systems professional in getting to the real problem before starting on the solution.

2. Educating the client about possibilities in order to truly understand what the problem is.

3. Tempering the part time inventor with a little pragmatism without dampening his/her enthusiasm.

The next part will get much deeper into the language and culture of requirements and and discuss different methods of achieving a reliable result.

Comments Off

February 6, 2011

The IT guy and the balloonist

Filed under: Uncategorized — admin @ 3:30 pm

“A man in a hot air balloon is lost. He sees a man on the ground and reduces height to speak to him.
“Excuse me, can you tell me where I am?”
“You’re in a hot air balloon hovering thirty feet above this field,” comes the reply.
“You must work in Information Technology,” says the balloonist.
“I do,” says the man, “How did you know?”
“Well,” says the balloonist, “Everything you told me is technically correct, but it’s no use to anyone.”
“You must be in business,” says the man.
“I am,” says the balloonist, “How did you know?”
“Well,” says the man, “You don’t know where you are, you don’t know where you’re going, but you expect me to be able to help. You’re in the same position you were before we met, but now it’s my fault.”
We have all been in that field or hovering above it, or even both at different times and I expect we can all sympathise immediately with at least one of these characters. The sobering thought in all of this however, is that the man in the field won’t survive very long unless the balloonist finds his way home and the balloonist stands little chance of surviving without the help of the man in the field.

The baloonist talks turkey

Did I mention that your salary and bonus are in this baloon, but I won’t be able to deliver it said the balloonist, looking rather smug.

He went on, do you remember when you came to me for more budget so you could hire balloon analysts, to understand my needs and provide a better service, well that was when it became your problem, so maybe we should start again.

Can you tell me where I am?

The IT guy replies

Actually no, it became my problem when you got lost with my salary on board, but unfortunately, I am only able to understand how your balloon works and help make it work better, that’s what my analyst helps with, but deciding where you are, where you want to be and how to get there, is still your responsibility and incidentally, one that I am not qualified to advise on.

I ask, you tell, I provide the supporting technology.

By the way, I take it your salary is in there too?

Baloonist replies

Yes, I believe we have had a misunderstanding and I see we have a shared problem.

You have the option to find a more reasonable employer and I wouldn’t blame you.
I on the other hand, have the option to outsource to someone who will shoulder full responsibility. I had an Indian team here last month who know our industry intimately and are working with some of our biggest competitors. They will advise strategically, partner with our SMT and provide us with thought leaders and presentaions, provide all the business analysis and deliver the end results and they will do it at offshore rates.

What do you think we should do?

The IT guy ponders and then replies.

If I look for a new employer, there are indeed many options, but I expect all of them will be much like you or have other equally difficult issues, so I see the solution as more important than the geography.

My gut feeling is that if you really believed in Santa Clause, we wouldn’t even be having this conversation because your Indian pals would already be sitting in my office.

Once you begin to outsource, getting out of that is the most painful and most expensive experiences you are ever likely to have. You will have mission critical systems that nobody understands, or can maintain and you will be forced to accept any amount of price rises or reduced service levels. The path to extricating and uncoupling your systems will look so impossible as to not even warrant consideration.
Controlled outsourcing may well bring benefits, but you will need me more than ever if you go down that route.

If you pay for the champagne I’ll happily take you and your other directors to the races, I will be more than pleased to keep you up to date on the changing face of IT and it’s implications for you, but I don’t believe it is appropriate for anybody but yourself to make strategic balloon decisions because they are ultimately your responsibility .

Ballonist

Maybe we need to have a rethink and start putting the relationship on a more realistic footing

It guy

Agreed.

Comments Off

February 4, 2011

Interview: Christine Ashton, BP Group

Filed under: Requirements, feasibility study, project management — admin @ 4:46 pm

One of BP’s top IT managers has firm views on melding business and IT to give business an edge and open new career options for IT specialists.

Christine Ashton has one of the most senior IT jobs in the huge BP group, yet she jokingly refers to herself as chief stirrer.

Christine Ashton BP group talks about the role of bridgers

Comments Off

February 2, 2011

Business analysts: a bridge between IT and business

Filed under: Requirements, project management — admin @ 4:30 pm

Role of business analysts
Business analysts intervene at the project management stage in information technology. Working with the project manager, their role is specifically to analyze business requirements before the start of a project. Their work involves identifying, defining, analyzing then documenting the underlying needs of a project. They guarantee the compliance of a project with business requirements and help determine which projects have priority.

The work of business analysts differs from that of traditional information systems analysts because they focus exclusively on the benefits of the project for the company’s business. It is also different than that of project managers and functional analysts because their role is to show what the product will be required to do, and not how it will do it. The analysis of needs is carried out with no commitment toward a specific product.

January 30, 2011

Business Analysts Bridge the Business Gap

Filed under: Requirements, project management — admin @ 4:24 pm

A dramatic change is taking place in the way businesses operate, and the business analyst is leading the charge.

The business analyst (or business process analyst) is the vital link between business executives and IT staff, translating business goals into IT requirements and communicating the requirements to IT. That’s no small matter. According to research firm Meta Group, “Poor requirements gathering, analysis and management are directly responsible for 70 to 80 percent of project failures.”

Until recently, IT requirements typically originated in the IT department. In some companies they still do. When IT is not given clearly defined business expectations, not surprisingly it develops solutions that fail to meet expectations. By improving communication between business stakeholders and developers in IT, the business analyst reduces costs and delays.

This article by By Charlie Orosz of Boston University discusses the change in focus as business analysts seek to bridge the gap from the business to IT as opposed to the other way around.

Comments Off

January 28, 2011

The three parts of the bridge

Filed under: Requirements, product development — admin @ 3:59 pm

The construction metaphor is familiar to people who have had experience with enterprise IT initiatives. Technical specialists (a.k.a. “IT”) are experts in their field – they can create or configure an IT system – as long as they get detailed technical requirements. People outside IT (a.k.a. “The Business”) are also specialists in their respective fields, e.g. accounting or sales – they are not trained to express what they need as detailed requirements.

Since communication problems are bound to occur we need someone in the middle translating for each side and facilitating communication. That is what the bridge metaphor is trying to convey. But it’s not as simple as it sounds. Bridge builders know you can’t build a bridge just anywhere. To have a bridge you need solid ground on both shores. It’s as true for IT projects as it is for crossing water.

Peter Lefterov gives us a valuable insight into the three sections of the bridge and how they combine to create the full solution
The three parts of the bridge.

Comments Off

January 21, 2011

Design phase Product development

Filed under: Sales and Marketing, product development — admin @ 5:37 pm

Dont let the creative urge design a Hummer when your customer is asking for a bike.
What you are designing is a space in the mind of your customer who perceives real value for their money and the marketing input is as important for value creation as the technical.
Design phase product development is the part where most organisations are reasonably competent. Whether they are developing engineering, health-care, software or other products, they tend to have many people who are expert in their field and there is generally an appetite for late nights in the lab or prototyping space, or wherever the creative process is happening. Sometimes, even when the ideation has presented a palette of ideas and filtered them down to a set of requirements, some of the best organisations then loose the plot entirely and begin to design products in isolation from commercialisation, stakeholder requirement, strategy, Voice of the customer (VOC), or any of the guiding influences that are there to make the job easier and more successful.

This is a fatal mistake. Before you even consider any design efforts beyond basic technical feasibility of high level ideas, it is critical that you have a palette of requirements to begin with and that you know with a reasonable level of confidence how much value your customers place on each of these requirements. So now that you are ready to begin the design work, you should have a number of key goals in mind:
The ultimate goal of product design at this time, strategy, timing, constraints.
The need to create a product, which combines a number of the given requirements to deliver maximum value to the customer for price.

The need to create a product which poses the minimum level of risk either technological, political, regulatory or otherwise unless this is specifically agreed in advance.
The need to test prototypes at every stage from basic drawing to beta with real users (not your spouses or best friends)

Remember, a lot of research has already gone into this and a lot of decisions have already been made. I would never suggest that the process should be so rigid as to ignore a great idea at any stage, but in the interest of Time to Market, there can be little justification for rambling away from the requirements list at this point. Neither is there justification for taking unnecessary risk technologically unless enormous potential gain is sufficient to justify the risk and it is agreed at a high level. It is also useful to bear in mind that there is always more than one good solution to any problem and there is usually no sure way of picking the best one, so once you get to the point where you have a number of potential combinations that would deliver your product JFDI “Just *ing do it”. Pick one and get on with it.

It is important to bear in mind that design phase product development is neither the beginning nor the end of product design because it really began with involvement of engineers at early ideation stage and will continue until all of the marketing collateral is created and tested. So what did we learn today
The design begins at the research stage and goes on long after launch.
Design phase product development involves marketing and publicity people who can help create value.
Design phase product development begins with a set of carefully filtered and accurately recorded requirements and uses a combination of these to deliver value to the customer.

Comments Off

January 20, 2011

The birth and development of product requirements

Filed under: Requirements, Sales and Marketing, product development — admin @ 5:29 pm

Since the Dotcom boom we have all come to know and love them. Their USP is: “One eyed man in the land of the blind”, their value proposition is ” I won’t blind you with science because I don’t understand it myself”. Yes they are the product managers of the software world, the IT directors, the Gadget Barons. Luckily for us they know what we want before we do.
They will tell you that requirement engineering is for nimbies and that suggestions from users are too dumb to take seriously. Allowing a mere human to write software requirements specification is not something they would easily consider.
I suspect that GBs also exist in the white goods arena. I have no idea what all the buttons and programs on my microwave or washing machine are for.
The GBs also are firmly ensconced in my supermarket, where I pay for two loaves and take one because I can’t eat two and these gurus are convinced that selling me two at a discount will make me happier. Perhaps they are thinking of the sales of exercise bikes after all the overindulgence, or maybe they themselves eat a lot of bread.

We read with horror that 80% of government projects fail, but can you believe that in the hard bitten commercial world almost as many new product launches also fail. If you don’t, then you haven’t been paying attention.
Microsoft claimed recently that the majority of new feature suggestions from users were actually for features that already exist. Surely this tells you something about communication with users. What’s the betting that these features were included in response to user need?
Ok, now we’ve touched on one of the buzzwords and our world will never be the same again.
Why should we build products that are user focused? Dumb question I agree, but this message still has not made it’s way through to 80% of the marketing world and possibly 99% of the software world. I believe I know a little about why this problem persists. You see there is a unique relationship between a product, its users and it’s stakeholders. I describe this as the UPS Triangle™. User- Product-Stakeholder.

The ultimate driver here is the stakeholder which is often a board of directors, and shareholders, or in political terms it is senior civil servants, ministers and citizens. Products can’t begin with user demand as the nice diagrams would suggest. Henry Ford never had a deputation of frustrated horse-riders turn up and demand he invent a motor car. This is why the GBs have a real part to play, they are the visionaries willing to spot a potential opportunity and pull together the support and finance to explore it and to make it happen. The people who provide the finance and take the risk are the people who want and deserve the reward and this is what makes them stakeholders.

Here however, lies the twist. To deliver this reward users have to agree that your product gives them value and become customers. That’s why it is a mutually dependent triangle. The confusion domes when the Product manager loses sight of this triangle and agrees to satisfy the stakeholder directly, hence ignoring the user and ultimately failing to deliver a successful product. On the other the side of the equation, if you leave product development to salespeople they will give away everything to the customer forgetting about profit and lifecycle management.

You can’t have much of a conversation with a marketing type without stumbling across the term “perceived value”.(PV) What they are referring to here is the “reason to buy your product”. Just think of it as another currency. The more of this PV you give to your customer the more of their currency they will be happy to give to you. That’s the ten second MBA, all you ever need to know about business.

The profit is in the P. That’s right you see perceived value is in the mind therefore it can be created relatively cheaply and maintained even more cheaply, whereas products have to be manufactured packaged and delivered and depend on supplies of other commodities. E.G. A Ferrari costs much the same to make as a Jaguar, but it sells for immensely more, because it’s PV is such that wealthy men will gladly part with buckets full of wedge just to be seen driving one.

In this case, which is likely to be more important? what users want you to deliver or what stakeholders want you to deliver. Whose perception is likely to drive product sales, the stake-holder’s or the user’s?

So what have we learned today?

The Gadget Barons are annoying but they are also necessary. Users perceptions is where the gold lies. Perceived Value (PV) is where the profit is made. The more PV we can offer in our product the more £ the customer will be willing to pay.
The first rule of product development is to manage the UPS triangle and reward stakeholders by maximising PV to the customer. If you want to write software requirements specification which will lead to winning products then you must forge and maintain the right balance between Stakeholders, users and technologists.

Comments Off

January 18, 2011

Learn ideation because it goes way beyond product development

Filed under: product development, soft skills — admin @ 5:14 pm

In product design, ideation refers to the process of generating ideas.

It is not a method of choosing ideas, this is a different step which hopefully comes later in the innovation process.

Ideation is about generating a vast number of potentially useful ideas. Ideators some time say that there is no such thing as a bad idea. In the ideation process this is partly true, because ideas can beget other ideas, especially in a vibrant group setting. I do believe however that ideas which are wildly irrelevant are bad ideas and should be quickly discarded because bad ideas can also beget bad ideas in a vibrant group.
The key to ideation lies in knowing where to start and finish.

Imagine you were locked in a room and told you have one hour to come up with an idea and if I don’t like it I will kill you. How would you feel as the metal doors slammed shut? Pretty frightened I imagine and I can’t see it getting much better with time. Where would you start? How would you judge whether he was going to like your idea. Where was your idea going to come from? What type of idea would it be? Are there types of ideas? What are they? How would you know it was an idea if you had one? Would there be a certain feeling? Maybe bells would ring. How would you measure this idea? How would you know when it was good? What could you do to make an idea better, or to get a new and better idea?

This whole product design ideation thing can be a little scary when you begin to analyse it.

Actually we all do ideation all of the time, but most of us do it extremely badly because of our conditioning and lack of stimulation and motivation to ideate well. The ability to ideate does not rely on intelligence, at least not in the classic definition, but it may well be that intelligence depends to some degree on the ability to ideate. Logic is only one type of intelligence, according to Howard Gardner (Frames of mind. The theory of multiple intelligences) there are seven intelligences. In any case many problems can simply not be solved by logic. One of these problems is how to generate an idea.

If we can not use logic then logically (just having some fun) we must use randomness or create a notion of randomness. Nobody has ever succeeded in creating randomness because they have always used logic to try to crack the problem. Random number generators are the most basic, but a decent programmer can reverse engineer the randomness in no time and predict the next ‘random’ number with ease. Randomness and spontaneity can however be practiced and learned over time to deliver something which at least appears spontaneous. For example my own usage of brainstorming techniques demonstrate clearly that a team directed to use divergent thinking could produce little extra by way of creativity, but a team who had been taught techniques for divergent thinking became very much more creative in all areas of their lives.

So it looks like real ideation is simply a matter of building our own random idea generator by teaching ourselves techniques for creative thinking and then practicing until random thinking has become unconscious and second nature. When this happens we have finally achieved the state of being able to think freely and generate ideas at will. A very good idea is to play a pleasant relaxing piece of music when you ideate, but never play it at any other time. With practice you will be able to switch on this tune and start generating random ideas. Just hope they don’t ‘play your tune’ when you’re on a first date.

Comments Off

Older Posts »