When is a business case not a business case (part two)

Read part one   part two Read part three  Read part four

In this section I will be talking about benefits, why they are so important to the business case and how they can be tracked right through the project, thus making the business case  a key document in successful project delivery, rather than just a tool to get the budget released.

Benefits map diagram expains the bridger method of mapping requirements to benefits

The model above illustrates our basic theory of benefits delivery.
On the left side of the diagram, we represent high level requirements.
This is intended to illustrate the level of requirements that is generally outlined in the business case.

This requirement is then tied indirectly to the composite benefits illustrated on the far left of the diagram. These benefits are the ones providing the key arguments for action.
That part of the model is very simple and intuitive. We have high level requirements and we expect to deliver the identified benefits.  The denotes that this metric is to be measured.

A key element of this approach is to remember at all times is that the requirement exists in the business case only to deliver the identified benefits and any change to the requirement or surrounding circumstance that impacts it’s ability to deliver these benefits is a red flag issue and must trigger a business case review.

The devil may be in the detail

 Between the high level requirement and the composite benefit, naturally, lies a lot of very important detail.  While this detail is not represented in the business case, but in other documents such as requirements specifications and benefits realisation plans, the exploration and bottoming out of this detail, will be critically important to the final conclusions of the business case process.


We look at this benefits mapping activity in terms of feature level requirements I.E. identifiable succinct features of the product or deliverable and with this we associate two things:

  1. The measurable benefit that is expected as a result of this feature, along with a suggestion of how it might be measured.
  2. The risks management attached to realising this benefit.  We describe it as risk, because we want to confine the change management activities to those that are necessary in order to deliver the benefits.

By taking this approach, we are proactively testing the likelihood of our successfully delivering the benefit and we are planning the change activities required to ensure that they are delivered.

Benefits realisation example

E.G. In the CO2 example, we may have assumed a fuel saving of 1000 gallons per month resulting in a measurable reduction CO2 emissions.
In order to actually realise these benefits, we might have to take steps to ensure that all the lean cars are not last to be taken from the car pool, while the big luxury ones are first choice. The approaches can vary considerably, but they have to be planned and in many cases included in the costs of the project.

Without this risk assessment and change management activity, the likelihood is great that the potential impact of replacing luxury cars with lean ones will deliver little or no benefit to the environment or to the organisation, No ROI and a project failure.

Now if we look again at our diagram, it may become obvious that we will have quite a few of these feature level requirements and that each will have it’s own mini business case including the level of ROI and the level of risk attached to delivering benefits.

 As the project takes shape and more is learned about each of these requirements, this mini business case needs to be constantly reviewed and updated so that poorer candidates can drop off the radar and stronger ones get promoted to a higher priority.

Approaching the business case in his way and continuously managing it as the development continues from outline business case to full business cases will keep the business in control and minimise the likelihood of pursuing projects that perform below expectations.

 Read part one   part two Read part three  Read part four

 

Four foundations of change management.

The phase of an organisational change

1. The organisation and the individuals that comprise it are different issues
2. Changing attitudes is achieved one by one, changed behaviour is a group activity
3. The change agent is not leading or driving but acting as a catalyst and facilitator
4. The change agent and his peers must be united in rationale and in mutual support
Silos, individuals and a single team – Exploding the myth.
“All for one and one for all” is a load of old c.’’@’., s
There is no single team, not even in top flight football. There are individuals and silos that have sufficient common cause, mutually understood process, just sufficient mutual trust and just sufficient understanding of the team dynamic to get the job done. And that’s as good as it gets.
Silos are not all bad, they are just teams with the wrong focus
Let’s not be too hard on Silos. First of all the gurus that designed what has become the modern organisation started off by designing silos. Quality people who never make anything, HR people who never manage anyone, Project managers with no reports and on and on.
It’s not surprising for example, that accounts like each other’s company and that they do battle with sales who are keen to give bigger discounts and more added value.
In the pecking order of the organisation, it is inevitable that some people will find their corner of the pond in favour or out of favour at different times and will then form a silo of their own.
Silos are created to protect ill gotten gains or to defend against a perceived threat. When the Normans invaded England and when the British invaded America, the first thing they did was build a great defensive silos and climb inside it.

Changing individual behaviour is not the same as changing individuals
The first is your moral duty the second is morally wrong unless you are a therapist working with the persons consent.
Managing individuals in the workplace must be done with complete respect for the individuals private psychological space.  Only behaviour is monitored or commented on.
E.G. An individual may ignore the new procurement dept and call a supplier directly. This is not perverting the system, it is not obstructing change, it is not being awkward or being anything! It is just making a single error of behaviour. It should be treated that way.

Listen to them and hear them, understand their views on office  politics and territorial behaviour and empathise with their fears, but don’t blame them for feeling fear.
Every reaction is an action and every action results in a reaction.
Don’t react to behaviour that is not what you hoped for. Each action will bring an equal and opposite reaction and hence people become entrenched. Let it ride and approach it positively at an appropriate time when the message will be received and no threat will be felt.

Walk a bit in their shoes
You can never expect to be listened to, or to be heard, until you are seen making a genuine effort to understand the other point of view. That’s a big leap of faith on your behalf, but until you accept it and make, it you can never expect that same leap of faith from the other individual.
Stop and think about it, if you are not prepared to listen, you have already discounted that individual completely and are therefore imposing your will with force on them, be it for good or bad.  That is a sure fired recipe for resistance and reaction.
Make sure you have a rational you can really believe and evangelise before you start work in earnest.
If you are going to lay your sole bare and let them take a pot shot at you in order to earn the right to pitch them, then you had better be very confident and be well prepared. Developing a vision is like developing a value proposition for a new product, you need to start with experts and test on real customers until you hone it into something that is bomb proof, and boiled down enough to pitch someone going the opposite way on an escalator.
Remove and allay fear to accelerate change
When people are being asked to change the way they work and abandon skills they have come to rely on for their security, it is not surprising that they will resist.
Winning hearts and minds is important, but it is only one step on the ladder. Once you have convinced them conceptually, you then need to give them the wherewithal to change and a bit of encouragement to make the final move.

Process is a great place to start
Once you have won the conceptual fight, you then need to begin painting in some of the detail. The best way to get a workforce very familiar with a new way for working is by designing and verifying the processes via a systematic approach involving increasing numbers of the workforce as the result becomes more polished and closer to completion.
Involving people in designing their future helps to achieve buy-in and begins the process of transferring ownership from you to them.
Training is a key component
Here is you chance to sweeten the pill by providing new bankable skills through training. Suddenly people are in a classroom situation getting a dress rehearsal and things become much clearer and a lot less fearsome. A change is as god as a rest once the fear has  gone away and with confidence in their new capabilities, you will see a new attitude emerge and a healthy competition will begin to develop.
Tools and systems
When you coax a horse onto a new stable, you often have to face him to the door and stand there a long while until he builds up the courage. Too much pushing can spell disaster and in desperate cases you have to blindfold him, but once he is in there, you close and firmly lock the door.
In our age of automated process, it is almost inevitable that a change brings with it a new set of software tools to support the new processes. These can be seen as an extra hurdle to cross or as a friend and ally.  I tend to see it as an ally, because once the processes are accepted and automated, it has the same effect as closing the stable door. The old is switched off and the new is here to stay.
Now build in excellence
You’ve done the hard work and you now have the most receptive and malleable workforce you will have had for a long time with enthusiasm, self belief and optimism for the future.
All you have to do now is keep it going long enough until it becomes a habit and then develops silos and then the next change comes along and . .
Don’t stop now, build in continuous improvement, teach them to develop better faster processes and tools, encourage innovations and ideas and keep the optimism and dynamism going.

Ed Taaffe

Agile development is the opposite of Fagan type process inspection, is this a phenomenon or another short lived fad

 

Programming is the discipline of talking pure logic to a machine that will unfortunately take everything you say literally and act upon it.
Process, is continuum of actions or mini processes that have inputs and outputs is repeatable.
The programme is a process and the programming too is a process.  It is therefore not surprising that many old school programmers simply can’t accept the principals that make agile development successful.  Are they right?
The Fagan method of code review is a milestone in the thinking that developed around software engineering in the seventies. Invented by no less an authority than IBM, the same organisation that taught me agile fifteen years later, the Fagan method set out by code review and manufacturing strength measurement, to eliminate errors and produce perfect code.
This was not Six Sigma, but a measurement of sufficient opportunities to eliminate reworks at the earliest stage. IBM claimed substantial improvement in case studies published.  The impact on software success rates was not however significant  and I, at least, am not shocked by this revelation.

Here’s my take:
Software is built by trial and error, simple as that. Anyone who doesn’t know that has never written code and needless to say , few people who have written code ever get involved with lofty ideas like quality improvement.
1. Treating something like software development as a continuous process that can be accurately measured and improved is a theory that has some purpose but is limited in scope.
2. The problem with software is not and has never been the quality of code.
3. The definition of quality is invariably wildly inaccurate when it comes to software products.
Measurement and process improvement
I have had mixed successes in the past with Fagan like measurement of exit criteria form tasks or products and from analysing the scope and quantity of bugs by programmer, designer, functional area and other criteria. Luckily I was doing this in an organisation where I was surrounded by professional researchers and statisticians and despite my best efforts to gain and follow their advice, not a single test I could devise was able to satisfy their strict criteria for reliable measurement.

The things that did pay dividends was creating over time a culture of following strict guidelines and strategies that reduce the risk both at a design, documentation, communication and process level.
The real problem with software
Any time you analyse the causes of failure in software projects, the causes are found in a just a few places:
1. The commonest cause of failure is that the system delivered does not meet the needs or expectations of the users or stakeholders. Bad requirements, bad communication, bad UAT,  took so long that the needs had changed, etc , etc
2. The business case was built on flawed assumptions and it should never have been completed, but pulling the plug is seen as failure while a poorly performing, or even stifling system is not.
3. Too little time was spent on the core needs and too much on the flora and fauna around the edges
The definition of quality
I’m not going to quote anyone , but t bravely state that the proof of the pudding is in the eating.
This system must satisfy users by helping them to perform to the expected level or exceed it and that includes keeping them motivated or better still re-motivated. It must also satisfy stakeholders that it is delivering an acceptable return on investment
Not a definition I know, but definitions are not all they are cracked up to be

What’s the verdict then
Well my verdict is that we should use process intelligently whether at a detailed level or a framework level and bearing in mind the power of a motivated workforce, but should not try to drive a square peg into a round hole in terms of ordering something that is about intense and accurate human interaction between professions that share little understanding of each others worlds. What delivers the goods or gets the job done is thing that delivers quality.

At IBM, not so long after the Fagan era, I learned to my astonishment that, in direct contradiction of his earlier paper, the cheapest way t fix bugs was not to fix them until you had to. This was measured very simply on the basis of whether  the bug was preventing testing form continuing. If not, the developer could decide to ignore it and usually did. Once a week we all got round a table with a huge projector screen and we analysed the bugs together, drawing simple dependency  links as we predicted the relationships between them. Every programmer knows how one bug causes several and sometimes the one causing them is not manifesting itself in any other way.
A group of switched on brains after the first coffee of the day could generally choose one or two bugs each to work on which resulted in most of the remainder disappearing and not returning.
If these bugs had been tracked down doggedly by tired individual programmers we would have lost cumulative weeks chasing shadows and ignoring the power of collective minds over large areas of complexity.

My belief is that well managed agile approaches to software improve communication immeasurably and eliminate the chance of a system not being what was expected. I think this is already applied to other processes from having a suit made to furnishing your home.
I also believe that quality in delivery is as much about motivation and peer review and recognition as it is about process, testing, logging and measuring. Real quality is built in and can’t be applied afterwards.  In my view, well managed agile creates a vibrant team environment where programmers have direct contact with end users and stakeholders and receive regular feedback and recognition.

How quality should be measured
Quality is measured very simply by how the software performs for the user and delivers for the stakeholder and the two go hand in hand. The quality controller is mostly the user with input from the stakeholder and a technical reviewer.  Perfect software with nill defects is not only unnecessary, it is not wanted in a world changing so fast that it will most likely be discarded in a short period of time. Fit for purpose is the ultimate measure, once purpose has been agreed.

Are you delivery focused?

A lot of buzz words and pseudo terminology hangs around in the IT world, especially at the CV and recruitment end. One that I have stumbled on many times over the years when looking for the next contract or screening CVs is “delivery focused”, usually with reference to project management. (is there another type of project manager?).

Last week I was surprised when I got a glimpse of one of the meanings , which is both accurate from an IT viewpoint and just a little sad from a business and even human viewpoint.
A potential client, an IT director I have known for some time, asked if I was available for a strictly IT project. On asking the inevitable question quite tactfully, he explained that he saw me as a rounded person, who was generally keen on delivering the benefits of the project. What he urgently needed was someone who would concentrate on delivering the system.

Based on the banter that followed, I managed to guess that as far as he was concerned, he didn’t have much faith in the system to deliver, had not been properly consulted in his view and the boundary of his responsibility was delivering the system into production safely.
On a personal note, I was surprised at the assumption that I couldn’t take a brief and deliver on it, though I doubt this was really what he had intended to intimate.

What the incident really illustrated for me is the gulf that still exists between IT and the business across so many organisations. Delivering the technology is increasingly straightforward as we improve our skills, but delivering the intended benefits will always require a joined up effort from initial strategic planning right through to keeping users supported and induction of new ones.

A wise man once told me that you have to work within the capabilities of the organisation you are working with and he was right, so most of us deliver these projects on a regular basis and quite a few do go on to deliver benefits after a slow and expensive start, but wouldn’t it be so much more productive if we worked together. I’d like to see “results focused” replacing “delivery focused” on CVs and job specifications.

Is project management different from management?

Well actually it isn’t in my view. I believe that the “management “, is assumed.
If you look back to the origins of project management you will see why I say this.
Project management was introduced into organisations to handle a particular set of problems surrounding business change. The crux of the problem is that the shop must stay open and the customers must be served while the re-organisation goes on.
In this case the only way to get it done is to bring someone in from outside. There’s still a problem though, because every change demands the help support and decision making of different people involved in the day to day running of the business. The solution to this is a project manager who has CEO like authority to run the project and has a project board to help with the bigger decisions. Major decisions are made in advance and a strategy agreed, then the PM gets on with it. This works well in the main.
The main problems are gaining both buy-in and understanding of this process form the business initially so they get the most from it and know how and when to be supportive, or to stay out of it.
The most widely used framework for project management is Prince 2 and along with the framework it also provides guidance for a structured plan with a start, middle and end and some good practices like risk management, change control and managing basic documentation.
All of that is great and in some cases it can be seen to fill a void where little structure was agreed or understood in common previously, but what it utterly fails to do , and quite deliberately too, is to teach basic management.
Management still is and always will be about achieving goals through delegation, that means managing others and it requires skills just as important and just as structured as Prince 2, but starkly missing in the vast majority of practicing project managers in the profession today. The type of skills I am referring to, often referred to as soft skills are:
How to structure and mould a team so it will perform together, How to recruit people to attract and retain the best, How to motivate individuals to get the most out of them, How to present ideas, How to write reports and papers that will be read and deliver the intended message, how to build and maintain productive working relationships, how to negotiate.
In my view a project manager should also have hard skills and by this I mean real credibility in the area he is operating in. If he is delivering software, he should have credible knowledge of the software business, if he is managing a football team he should understand the off side rule.
In conclusion, Project management is about knowing how to structure and manage a project, but management is about people skills and taking responsibility for delivery in a specific domain that is well understood.

Four foundations of change management.

1. The organisation and the individuals that comprise it are different issues
2. Changing attitudes is achieved one by one, changed behaviour is a group activity
3. The change agent is not leading or driving but acting as a catalyst and facilitator
4. The change agent and his peers must be united in rationale and in mutual support
Silos, individuals and a single team – Exploding the myth.
“All for one and one for all” is a load of old c.’’@’., s
There is no single team, not even in top flight football. There are individuals and silos that have sufficient common cause, mutually understood process, just sufficient mutual trust and just sufficient understanding of the team dynamic to get the job done. And that’s as good as it gets.

Silos are not all bad, they are just teams with the wrong focus
Let’s not be too hard on Silos. First of all the gurus that designed what has become the modern organisation started off by designing silos. Quality people who never make anything, HR people who never manage anyone, Project managers with no reports and on and on.
It’s not surprising for example, that accounts like each other’s company and that they do battle with sales who are keen to give bigger discounts and more added value.
In the pecking order of the organisation, it is inevitable that some people will find their corner of the pond in favour or out of favour at different times and will then form a silo of their own.
Silos are created to protect ill gotten gains or to defend against a perceived threat. When the Normans invaded England and when the British invaded America, the first thing they did was build a great defensive silos and climb inside it.

Changing individual behaviour is not the same as changing individuals
The first is your moral duty the second is morally wrong unless you are a therapist working with the persons consent.
Managing individuals in the workplace must be done with complete respect for the individuals private psychological space. Only behaviour is monitored or commented on.
E.G. An individual may ignore the new procurement dept and call a supplier directly. This is not perverting the system, it is not obstructing change, it is not being awkward or being anything! It is just making a single error of behaviour. It should be treated that way.

Listen to them and hear them, understand their views on office politics and territorial behaviour and empathise with their fears, but don’t blame them for feeling fear.
Every reaction is an action and every action results in a reaction.
Don’t react to behaviour that is not what you hoped for. Each action will bring an equal and opposite reaction and hence people become entrenched. Let it ride and approach it positively at an appropriate time when the message will be received and no threat will be felt.

Walk a bit in their shoes
You can never expect to be listened to, or to be heard, until you are seen making a genuine effort to understand the other point of view. That’s a big leap of faith on your behalf, but until you accept it and make, it you can never expect that same leap of faith from the other individual.
Stop and think about it, if you are not prepared to listen, you have already discounted that individual completely and are therefore imposing your will with force on them, be it for good or bad. That is a sure fired recipe for resistance and reaction.

Make sure you have a rational you can really believe and evangelise before you start work in earnest.
If you are going to lay your sole bare and let them take a pot shot at you in order to earn the right to pitch them, then you had better be very confident and be well prepared. Developing a vision is like developing a value proposition for a new product, you need to start with experts and test on real customers until you hone it into something that is bomb proof, and boiled down enough to pitch someone going the opposite way on an escalator.

Remove and allay fear to accelerate change
When people are being asked to change the way they work and abandon skills they have come to rely on for their security, it is not surprising that they will resist.
Winning hearts and minds is important, but it is only one step on the ladder. Once you have convinced them conceptually, you then need to give them the wherewithal to change and a bit of encouragement to make the final move.

Process is a great place to start
Once you have won the conceptual fight, you then need to begin painting in some of the detail. The best way to get a workforce very familiar with a new way for working is by designing and verifying the processes via a systematic approach involving increasing numbers of the workforce as the result becomes more polished and closer to completion.
Involving people in designing their future helps to achieve buy-in and begins the process of transferring ownership from you to them.

Training is a key component
Here is you chance to sweeten the pill by providing new bankable skills through training. Suddenly people are in a classroom situation getting a dress rehearsal and things become much clearer and a lot less fearsome. A change is as god as a rest once the fear has gone away and with confidence in their new capabilities, you will see a new attitude emerge and a healthy competition will begin to develop.

Tools and systems
When you coax a horse onto a new stable, you often have to face him to the door and stand there a long while until he builds up the courage. Too much pushing can spell disaster and in desperate cases you have to blindfold him, but once he is in there, you close and firmly lock the door.
In our age of automated process, it is almost inevitable that a change brings with it a new set of software tools to support the new processes. These can be seen as an extra hurdle to cross or as a friend and ally. I tend to see it as an ally, because once the processes are accepted and automated, it has the same effect as closing the stable door. The old is switched off and the new is here to stay.
Now build in excellence
You’ve done the hard work and you now have the most receptive and malleable workforce you will have had for a long time with enthusiasm, self belief and optimism for the future.
All you have to do now is keep it going long enough until it becomes a habit and then develops silos and then the next change comes along and . .
Don’t stop now, build in continuous improvement, teach them to develop better faster processes and tools, encourage innovations and ideas and keep the optimism and dynamism going.
Ed Taaffe

Learn about Agile from Keith Richards

Keith Richards of Keith RichardsConsulting gave me my first formal training in DSDM nearly a decade ago and I am thrilled to have him contribute to our blog. If you would like to know more about Keith’s methods, you can purchase his book;
‘Agile Project Management: running PRINCE2 projects with DSDM Atern’ by Keith RIchards published by TSO’

What is Agile?

The word ‘agile’ has now become the hottest term being used in the methodology arena, but what exactly does it mean?

Amongst project managers and process mentors there is a broad understanding of the ethos of ‘agile’ but equally there is little agreement on the exact specifics of the genre.

Here are the views of KRC about the ‘new wave’ of approaches which are challenging the traditional view on how to deliver business benefit in the most effective way.

KRC believe that to be ‘agile’ means satisfying a set of criteria. These ‘criteria’ can be described as follws:

Responsive to change

Scope tolerant

Collaborative

Iterative

On time

Built incrementally

KRC also believe that the highest level of performance in the agile space can only be achieved if there is also compliance to a further three criteria. These are:

Business Focus

Quality Focus

Communication Focus

Over the coming weeks KRC will add to these criteria – in the meantime please get in touch if you would like to contribute.

 

Keith Richards

Why you still need business analysts and change managers when you do agile.

The first reaction to the theory of agile is to think something like, ”great, now we don’t to pay business analysts and change manager”.

It is logical without a doubt. You are not going to interview stakeholders, try to merge all the information, improve the waste and perfect a new process or design like we did in the good old days are you?No, you are going to very carefully select knowledgeable, committed and influential stakeholders and make them part of the team. Then you are going to facilitate them while tey design the changes.

What a splendid idea that really is. In one fell swoop you have created champions, educated them and built their commitment. You have fed the grapevine, the only truly effective channel of communication, with positive accurate messages delivered with conviction and enthusiasm by respected influential people.
At the same time you have gathered the most important knowledge into one place and not only got their input but had it bounced around amongst them and built up in increments.

How could it possibly be wrong? and how could it fail to win loyal support fast?

Welltheory is a fine and wonderful thing, but experience shows us a couple of important things: >

1. When analysts go about requirement the formal way and they interview everyone who could possibly be important to the project and hold workshops and demonstrations, it often emerges that:

 

a.

yes;”> Stakeholders are often deluded about what really goes on, they think big, but don’t do detail.

Senior stakeholders have imaginations just the same as programmers and when they suddenly get the feeling that they have box of lego and nobody
is watching, they begin to get creative in their thinking.

If this is allowed to happen in an agile project, then it will quickly begin to flounder
. Here’s where an experienced BA can test the theories, verify the processes and police the scope.

2. When change managers tackle a major change there are two forces in particular to be reckoned with:

a. The early adapters and champions that are encouraged and developed and who spread the word and are a generally positive force for change. Amongst these will often be people who resist and challenge things because they are taking ownership and are very serious about the project.

< b.

The blockers who initially grumble and then sit in ambush. Some of them are very powerful generally and amongst them will be people who are always agreeable, appear to be the picture of cooperation and are a joy to evangelise to, because they have not the slightest intention of taking any of it seriously and don’t feel even a little threatened.

These people will wreak havoc left to their own devices and a strong experienced change manager is critical to identify and manage the threat in a safe and appropriate way.

 

So how agile is agile?

Agile is very clever stuff and it can deliver an awful lot very quickly and cheaply when used by an intelligent , experienced team, but is a methodology, not a wonder drug, so use it to the limits, but use it in the appropriate setting and don’t throw away all the safety nets.

Ed Taaffe

Interview with Gabriel Stenhardt of BlackBlot Product Management

I’ve known Gabriel for a few years now and worked with his PMTK toolkit and I was keen to interview him for the benefit of the many people who still misunderstand the Product management Profession.

 I wont bore you with the “Good morning, how is your day” stuff and I won’t wait till the end to express my gratitude to Gabriel for giving us his precious time, so here goes:

ED; The Million dolar question, what is product management?
Gabriel, Product management is an occupational domain which holds two professional disciplines: product planning and product marketing.  This is because we build product functionality for the user via product planning, and market the product’s value to the buyer via product marketing.A somewhat more expanded interpretation would be to view product management as an occupational domain that is based on general management techniques, focused on product planning and product marketing topics.

 

Ed; Which common problems exist in the high-tech industry relative to product management?
Gabriel, Every company is different and handles product management differently – meaning that the product management discipline is not standardized as much as it could be across the industry.  We often see how different product delivery strategies, such as being technology-driven, impact people in product management to the point where product managers are mostly engaged in pre-sales and logistical support, and do not perform their true strategic planning and marketing roles.

For companies to be successful, other than just pure luck, all areas of product management must be fully addressed and handled professionally.  Failure as success is extremely complex.  One can attempt to investigate why certain companies and products have failed, only to very quickly realize that the cause is multi-faceted and that many factors need to be considered.

Relative to product management we know that providing wrong market requirements, wrong pricing, wrong timing, wrong market, wrong assumptions; are detrimental.  Getting just one of these factors wrong strongly diminishes the product’s chances of success.  Therefore, a company must cover all key aspects and details in product management in order to increase its chances of success.  Even though there might be failure, chances of success are increased if a company follows and consistently implements a complete product management methodology.

 

Ed; What characterises high-tech companies that have good product management practices?
Gabriel,  Relative to product management, companies with good product management practices are companies which realize that product management is a core strategic function to the organization and that there is great importance in making sure that product management processes are sound and fully covered.  As alluded to earlier, if this happens then products have a much better chance at success from the very beginning of the development process.

There are always external factors and some luck involved when products are successful.  Not all successful products have had great product management behind them, but it is clear that most product failures have had poor or no product management behind them.  Companies will most likely be more successful per each dollar they invest in product development if they do a better job in the area of product management.  Combining a definitive product management process with technology development is the key to commercial success in the high-tech world.

 

Ed; What are the challenges which product managers encounter at high-tech companies?
Gabriel, The main challenge product managers are faced with is the lack of professional focus.  Many companies erroneously view the product manager title as a collective term used to describe a combined role.  The product manager is often forced to act as a program manager, project manager, product planner, product marketer, product architect, and more.  Many struggle to define their own role.  Ask several product managers what their responsibilities are and you will get a variety of answers and descriptions.  This situation can reach a point where several product managers working at the same company and department provide very different perspectives on their position.

The remedy to this situation is primarily based on the realization that being professional means being very focused and strategic; and by ensuring that product management roles and responsibilities are profoundly clear, understood by everyone in the company, and their interpretations are consistent.

Additional issues product managers are faced with include which product management methodology to use, where to find uniform work tools, which tasks and processes to execute, and how to manage relationships with other corporate departments.  This matter is addressed by the adaptation of product management best practices.

 

Ed; What is the best way to improve product management practices at high-tech companies?
Gabriel, Improvement in product management practices is done via the application of a complete approach, which means “Processes > Tools > Implementation”.
From a practical perspective, this approach is manifested and accomplished by implementing a correlated set of “Training > Templates > Consulting”.

Often the implementation of product management best practices is done with the aid of a consultant after the company’s product management team had undergone training.  Product management training is helpful to foster corporate change as it makes methodology implementation much easier because of the shared knowledge and common terminology.

The key to any corporate change, particularly in the high-tech industry, is the understanding that success is often more dependent on following a process than on developing technology.  This notion is clearly exemplified in Toyota’s lean strategy which claims that Toyota gets “brilliant results from average people managing brilliant processes.”