the Bridger

Now that's innovation!

April 21, 2012

Scope a real ball breaker, do we really have to master it?

Filed under: Strategic thinking, management skills, product development, project management — admin @ 12:14 pm

I remember many shopping trips with partners when she has described in great detail exactly what she needs to set off the rest of the outfit for an upcoming event.

I have managed to get enthusiastic enough to scan the windows and shelves with her and then there it is. I can’t believe my eyes it is such a perfect match. The price tag is a bit saucy, but worth my putting in the extra so we can relax and enjoy the rest of the day.

No, it is not what she wants. Yes it does match all the needs, but no it is not right. On we go and hours later exhausted we end up with what she is willing to accept. I am now spending heavily to get out of the dog house and I have finally managed to empty my brain and reach a state of alcohol encouraged xen. I have given up.

That is how people really are as opposed to how people pretend they are.

Ask any recruiter about the clients who continuously reject perfect candidates. It costs on average £15,000 to recruit an executive as a direct result of this indecision and inability to truly define scope up front and stick to it.

Can a business really afford to operate like a shopping trip?

Well the average MBA is going to say no to this one, but I am not totally in agreement. Businesses are far from perfect, in fact they are dismally bad even at their best and to be the best you only have to be marginally better than the worst. I’m not suggesting that this is easily achieved, just painting the map for now.

I worked around the advertising industry quite a bit and it operates exactly like the shopping trip. Decisions happen, usually when there is a gun to someone’s head (metaphorically of course) and those who are “gifted” seem to get it right more often than wrong. The accountants take the paperwork out of the dustbin and announce the results, to their surprise; “We made a profit, we are clever aren’t we?” Are they? They’re having more fun than anyone I worked with in any other industry.

Business is a very simple concept

Business is simply a matter of investing capital to make a return greater than you might have done had you invested in a risk free environment like Gilts (when such a concept existed) otherwise why bother. The bit that is usually unwritten but implied is that the return should compensate for the extra risk as well as giving a better return. (That assumes you can beat markets? Another great blog opportunity)

So when I take capital from a Capex budget and invest it in the “red coat to match the shoes”, this is money that belongs to the retired lady in Dagenham who relies on her dividends to keep her little car running, or Larry form Luton who is saving for his retirement in five years time and worried abut being in poverty. By law we should have retuned it to him, but we offered to reinvest it and make him even more money and he trusted us with his savings.

Clearly we need to be responsible about the way we make the decisions and we need to be accountable if questioned, but at the same time, we can’t; let fear, or external constraints blind our intuition or cloud our judgement.

Choose your weapons in advance

The answer in my view is to approach the decision about methodology up front.
The next advertising campaign for a big brand needs to be right and rightness is a subjective decision that is best made intuitively by people who have a record of getting this right. Waiting days, weeks, or months longer for this magic to work is a rock solid investment and rushing it with any form of coercive or brainstorming techniques threatens to kill the golden goose. Deadlines have been proven to weaken creativity contrary to most misconceptions among journalists.

Is time the key factor?

Sometimes you only need the best possible output in a timeframe, or for a budget. E.G. the front page leading article by 9 p.m. sharp, but other times you need the bee’s knees and it is worth waiting for.

Is the decision subjective, or objective?

If it is objective, then the key requirements can be clearly articulated and a process followed that will take you to the best decision. The answer is then very mathematical and logical, it may be a TCO, or ROI figure or simply the highest score.

If it is subjective, then you need to identify the people who will make this decision, you have to tell them whether you need best possible answer by Friday, or the bee’s knees and give them all the support you can.

If this is a visual thing, or a kinaesthetic thing, then you may be able create prototypes and let your experts see, feel or even experience some element of the design recording as you go along the things that go down well and narrowing the scope, or if nobody looks happy you may think laterally and try to find something that stimulates them.
The fastest cheapest way from A to B

It has been well established and indeed I have blogged about this in more detail previously, that without question the fastest cheapest and most certain way form A to B is to establish where B is and how to recognise it when you arrive, break the journey into easily managed stages and then follow your plan.

If however; as is sometimes the case, B is can not be defined objectively and/or there are no maps available for the territory in between, then you need to take a more agile approach and allow for the extra time and cost, but balance it against the reward.

Changing your mind along the way

This is a sure sign of immaturity, but occasionally it is necessary and justified.
She has just got home, tried the shoes again and then the party is cancelled.(bad example, she wants to keep them anyhow) You can still return them. It’s been changed to smart casual, you can exchange them. It’s troublesome but better than having no options.

What if we have one who just is a ditherer and wants to go to a different city to try there and returns them four times . . I sense we have been there.

In business you can most definitely put a stop t this and you have a duty to do so.
Once tht decision is made, it stays made unless a very powerful new piece of information justifies revisiting it.

The important thing coming out of this is that a decision must be made within some sort of constraints and the first order of business is to establish the constraints on this thinking.
If the decision can be made objectively, it should be and a clear scope written down and followed
If the decision is subjective, then all the inputs required to ease the journey must be in place, the owner of the intuition should be put in place and allowances made up front for delays and overruns
Once a decision is made, move on and only ever return if there is a powerful argument backed by strong evidence

Comments (0)

March 18, 2012

The agile organisation – a risky proposition

Filed under: Organisational change, Uncategorized, management skills — Tags: agile, product management — admin @ 8:47 pm

When somebody tells you that they want their organisation to be agile, what do you read from that? I’ll bet you feel a bit sheepish because you feel that yours is not, but it should be. I suspect that you remember this becoming a fashionable goal and thinking you would find out at some point what it all means.

If you answered yes, then you just joined a huge club closely affiliated to the new man”, “cosmopolitan woman” and all the others.

Maybe you have already announced to your boss that you are “going agile” and you still haven’t quite got round to working out what precisely it is, but you instinctively know that it is right for you. This is also a very large club growing daily. You won’t be lonely in there either.

The most likely thing is that you came across it via a systems project and all the new converts raved about their new found, almost religious belief in this cure-for-all-corporate-ills. You loved the stories about no decisions, no commitment, no planning, and no documents. ”This is damned interesting, I want to hear more”, you said

What did Bill Gates mean and what did it mean to Microsoft to be agile. Well Bill made the mother of all misjudgements when he said that the internet was of no interest to Microsoft and dismissed its potential. Within one and a half years, Microsoft had changed its mind, won the browser war with Netscape and delivered ASP, the first and still dominant commercial application server for the internet. That was agile, but it had not a thing to do with stand up meetings around whiteboards and walls covered in scribbles.

Horses for courses

Adapting a largely web development methodology and attempting to use it as a corporate philosophy is bonkers. Anybody who tells you otherwise is out of her tree and I’m not given to sweeping statements, so I’ll need to back that up with some arguments, here goes:

Large organisations need process, it is their blood supply

Have you ever experienced an agile development team in the software world? The entire fabric of specialisation, process, controls and method are abandoned completely. Everyone claims to be multi-skilled, they are a team of peers, and they operate outside of the business rules and the corporate structures.
They romanticise it as though they were a hit squad, “licensed to kill”.

All this was put in place for a reason. A highly skilled multi-talented team empowered to JFDI is a great solution to political stalemate and analysis paralysis in specific situations, but would we want the CIA or Mi6 running the country?

Even in a highly mature market, our only corporate goal is to maintain our competitive position or improve it and in many cases this is driven by economies of scale and brand strength. This is why we have oligopoly and cartels everywhere manipulating key domestic markets such as supermarkets, fuel, banking, etc. A typical sluggish, but safe operation is exactly right for the job, low risk, stable and relatively low cost. It can function with the average half to three quarter wit at the wheel and needs no dynamism. It’s all about horses for courses. You can’t take away their crutches and expect them to perform. History shows that it fails miserably.

2. The vital relationship between good strategy, intelligent planning and sane execution. Anybody who has working experience of trading the stock market knows the persona of the Bull and Bear. These fabled characters are, of course, not different individuals, but different phases in each trader’s performance. Adrenaline, or cortisol take over quickly when the action begins and knee jerk reactions produce cowardly hibernating bears, or arrogant testosterone fuelled bulls

I witnessed this just recently when my irrational fear of snakes was suddenly reawakened by almost stepping on one and watching him thankfully slither away. I was physically unable to walk any further and had to resist the urge to run back to the safety of the car. It took a few days before I could walk in the woods again without watching every blade of grass.
I went to Vegas once and discovered that one friend had a deeply rooted gambling issue such that he could only see the chance of winning the next hand and had no inclination of the odds. The higher the likely return the more attracted he was, never weighing it against the likelihood of winning. Both of these situations are unnatural and unrealistic reactions to risk and opportunity and both are potentially destructive.
Let neither fear, nor greed be your master
Human reaction to risk and opportunity both tend to bring out the very ugliest sides of human nature, greed and fear. Neither of these emotions is rational and neither can be trusted for any length of time. They stem from another era when we needed to run very fast into a cave without asking questions, or gorge ourselves before we were driven away from the feast by a more aggressive animal.

It is because of these irrational behaviours that every aspect of business behaviour must be driven by a well formed strategy that includes:

A well understood risk attitude
A carefully devised approach to managing day to say risk that keeps the bear and bull within us well out of the picture and supports rational management behaviour.
A risk strategy is not a simple thing to plan out. The fact of the matter is that the more attractive the reward is, the higher the risk will generally be. You have to make your choices

Some examples from the finance and gambling industries
E.G. A bank with its risks spread over the right industries and economies can expect that when one is doing poorly another is doing well and thus balance risk.A bookie can balance his books by taking a precise level of exposure on every horse in a race so that regardless of the outcome he wins a little over the day’s activity. Taking a big picture viewpoint as above, and developing from this a strategy that can be applied at a more granular level allows me to look at the snake philosophically and continue my journey, it allows my gambling friend to view his account on a quarterly basis and aim for a profit without making rash decisions on the spot. It doesn’t stop me from pausing till the snake has disappeared, or taking simple precautions in future.

A banker without a strategy would panic when three customers in a row defaulted on their payments. A bookmaker would run for the car park when two favourites in a row won forcing him to pay out. Only reliable insight, a solid strategy and a sound plan allows ordinary individuals to successfully run apparently high risk industries.
Knee jerk “agile” management is the stuff of the hard luck stories.

3. Responsibility to our shareholders demands responsible decisions, audit trails and experiential learning.
Never before have we been so aware of the responsibility to our way of life that is borne by officers of private businesses everywhere. Every quoted company is taking the savings of pensioners and promising to give them a return annually so they can finish their lives in dignity. Every business has a responsibility to employees and investors of all sorts whose lives depend o their performance. Our world is continually burdened with more audit requirements as more frauds are discovered. We need robust and recorded decision making and we need accountability.
Informal decisions around the water cooler open the door wide for the irresponsible amongst us. I’m not espousing process laden organisations with forms to fill in for everything, but if you leave the cookie jar without a lid, you just know what is going to happen

4. The team is everything
Teams are made of people, not numbers, roles or little boxes connected by lines.
People must have their needs met if they are to perform and if individuals don’t perform the team fails. The things that motivate people to perform are all based around security. Maslov’s hierarchy of needs and later Herzberg’s hygienes and motivators all demonstrate that people need to know where they stand in their group and that their standing must fit their contribution. An agile team in the software world can, if correctly balanced to begin with perform very well, but usually it is utterly dominated by one person and becomes a benign dictatorship. Any attempt to get things right first time are usually dropped in favour of constant revision mode and quickly they realise that constant activity disguises the lack of any meaningful outputs.
The peak of the productivity curve is reached very quickly and after that it is all down hill.
In a non software world, there is little difference other than the fact that sometimes the potential downside can be catastrophic and constant revision is usually less of an option. Single agile teams tackling key business change issues can, if correctly and responsibly set up and under constant enlightened management, both during the forming, norming . . phase and into maturity, produce exceptional results for exceptional managers, but as a broad approach and using a large team of teams, the roll call of spectacular failures speak for themselves.

5. The map is not the territory
Most management philosophies are corrupted shamelessly and misused without any insight into what makes them work. Agile works, but only in it’s own unique environment and only when the core competencies exist and the critical factors have all been properly taken care of.
The risk is seeing only the landmarks, e.g. that you see agile as: describing things in user stories, or having stand up meetings, or small empowered teams, or Just In Time decisions making, or incremental delivery of product. You can adapt any of these that catch your eye and maybe they well deliver what you expect, but that won’t make it agile.
See beyond the ceremony, stare straight through the dogma, but when the time is right, do it right and the rewards can be very encouraging, but don’t close your eyes and try to drive by the SatNav.

Comments Off

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

Older Posts »