the Bridger

August 23, 2008

What would you like sir?

Filed under: Requirements, product development, project management — Tags: , , , , , , , , , — admin @ 10:45 am

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

What would you like sir?

 Countless reports on the reasons for project failures in the software industry point heavily towards poor requirements as a source of the problem. It isn’t too hard to see why that might be. After all if you hope to get exactly what you want, you are going to have to spell it out in some detail.

How many times have all of us left a restaurant disappointed because we misinterpreted what a dish consisted of, or had a bad experience ?

Ordering what you want in a restaurant where they speak your language is relatively low risk. There is a risk of misinterpretation and there is a risk of a poorly executed dish, a meal that arrives after a very long wait, or a nuisance at the next table making you uncomfortable.

If you want to give yourself a strong chance of being satisfied with your meal, first you will need to be aware of all these contributors and make your choices with this in mind.
Taking this approach might help you avoid the family from hell at the next table, the dish that isn’t what you expected etc and if it doesn’t work out you are at least in a strong position to seek recompense.

Software is much more complex than food and like a restaurant meal there are more concerns than simply  the ingredients. In an ideal world you would be dealing with a professional who could interpret your tastes, avoid the poorer restaurants and order on your behalf.
This is the main purpose of the Business analysis and product  development body of knowledge.

It gives you the option of working with trusted professionals that can help you achieve what you had hoped for and keep your costs down.

Product versus System.

Few people stop to consider the difference between developing products and developing systems for a private audience and will often approach both in exactly the same way, but although there is a lot in common, there are also critical differences.
1. The first and most important difference is the fact that a system will be rolled out to desktops ot devices and the organisation will train users and tell them to get on with it, whereas a product will be launched into a marketplace who have to be attracted to explore the product and then persuaded to purchase it.

2. A system will largely be rolled out into a controlled technical environment whereas a product will b at the mercy every conceivable version of operating system and technical environment

3. A product must breakeven quickly, deliver a profit and exit gracefully before it becomes a liability.

The first of these is one of the more telling differences for our purposes because it requires an entirely different approach to understanding requirements  and defining outcomes and it introduces a whole new level of financial constraints.

When developing a product, the analyst/Product manager  is often working with a user advocate  or product forum to define the desired functionality and get requirements down on paper in the same way as with a system.

A better process will run Alpha and Beta releases with early adapters in order to learn about how users react to it and make critical changes that improve it’s chances.
All the time the success or failure of a product rests on the likelihood of the user base receiving it will, perceiving a persuasive benefit and viewing it as value for money.
The project manager delivering a system on the other hand has the luxury of rolling out a system and only worrying about complaints that threaten it’s ability to deliver.

The project manager can learn a lot from the product manager in terms of delivering a well received output and maintaining good communications with stakeholders. 

Innovation as opposed to state of the art

 Projects that involve a level of innovation either in terms of process or the technology to drive it will require a different approach and a strong element of prototyping both as proof of concept and as a way of communicating to users a blue skies concept, will generally be the better approach leading to a point where requirements and scope can be nailed down and the process of delivering it can get under way.

Complex domain knowledge 

Another situation requiring a different approach to requirements is the one that involves extreme complexity in a domain outside the scope of the analysts, project managers or technical staff.

Let’s say for example that we are building software to manage extremely complex trend analysis forex traders and only a small number of skilled individuals understand the underlying mathematics.

To get a product manger or analyst to a sufficient level of understanding could take years and it would still be a second best option. The best option is a totally agile approach whereby the statistician the analyst and the developer all sit together and build prototypes without the statistician ever needing to understand the underlying code and architecture, or the programmers and analyst ever understanding the fine detail of Monte Carlo analyses etc being used to construct models.
 In this situation the requirements are written after the code has been written and unit tested and it’s purpose is to support maintenance and future development processes.

COTS versus Development

The biggest are of effort by a long shot is the purchase and implementation of COTS (Commercial Off The Shelf) software systems.

Right form early days in the industry, there was a realisation of the need for reuse of software and many of the various efforts that came and went have been sold to us on the basis of promoting re-use. In reality precious little is developed in Com or reusable classes and SOA is still not that widely used.
The theory that once you had created a “customer object” you didn’t ever need to do it again, just never caught on, but COTS systems did and today there is very little development of end to end systems outside of software houses that develop products.  Nobody builds their own CRM, or ERP, etc, because it makes no sense when you can buy it straight out of the box at a fraction of the cost.

The issues with COTS however are that businesses are all keen to differentiate their offerings and this adds to the variety of processes and business models in operation which in turn means that many of these all encompassing systems are a compromise rather than a solution and require a lot of integration and customisation in order to make them deliver benefits.

There has never been to my knowledge, any attention given to the needs of these systems. The most common problem I have encountered is people form the business assuming that you don’t need the normal skills to deal with this because it is in the box and it is like buying a lawnmower,  you bring it home and tell the IT boys to plug it in.

In reality this is a very dangerous mistake and pitfalls are as follows:

  • You are reading wooley warm and friendly descriptions of what the system will do, but no detail about how it gets there. All COTS is sold with a “Caveat Emptor” clause and unless somebody knows all the details of what it must do and whether it actually does, then you will end up with a very expensive system that just is not suitable.
  • The complexity and risk attached to integrating COTS systems with other systems can sometimes make them almost as expensive as starting form scratch.
  • The impact of the COTS systems on your infrastructure and on other critical systems can be devastating unless it is properly understood.

The job of procuring COTS software is  complex and tricky and it can often be a struggle to convince business stakeholders of the need for detailed requirements, detailed investigations, complex questionnaires, proofs of concept, and a range of testing before making the system live on a production environment.
The size and complexity of this area is such that it could not be addressed in this series, but suffice to say that all the rules about requirement apply equally and there are a number of new concerns to be addesses.

June 1, 2008

Interview with Gabriel Stenhardt of BlackBlot Product Management

Filed under: Organisational change, product development — Tags: — admin @ 10:34 am

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.”

 

 

April 21, 2008

Product or Internal System why it is important to make a distinction

Filed under: Systems, product development — Tags: , , , , , — admin @ 5:49 pm

When do you need a BA and when do you need a Product manager? why is it critical to get it right?
Whenever I write about anything connected to product development or systems implementation, I am acutely aware of the amount of critically important stuff that I have to gloss over or ignore in order to stay readable and this is no exception.

In broad terms, it is very easy to make a distinction between a product and an internal system. The internal system is being rolled out to the workforce and there is not normally much option about whether it can be adopted and used by the target audience, that is, unless it fails to deliver.
The product, on the other hand has to be launched to a public audience who must be sufficiently convinced that it meets a compelling need or solves a pressing problem, to part with their cash and use the product.

There’s a world of difference between investigating a business problem, creating a business case and designing a solution to this problem and identifying a market sized need, establishing a product problem and designing a compelling solution with confidence that you will have a success on your hands.
The stages we go through are remarkably similar and almost interchangeable, but the big difference is in how we engineer and verify requirements.

Although many products begin as an idea in the mind of a director and are driven forward by this vision, at some point a professional product manager has to establish a strategy for verifying these requirements with the intended purchasers and developing a compelling value proposition that will sell the product.
Faced with defining requirements that will motivate users to pay for your new product, you will need a lot of new consultation and communication techniques that are generally well beyond the scope of a Business Analyst, you will also need deep knowledge of the marketplace to assess not only how well your product may be received, but how the competition will compare and how they will react to your offering.

It is remarkable how often this fundamental truth is ignored by government and public agencies who believe or assume that they have a captive audience for their brainwave, when in fact the public often remain unimpressed and find alternatives or ignore it altogether. A simple product management methodology and the use of more appropriate skill sets could save many of the costly blunders in e-government and deliver dramatically more benefits for most of the remainder.

Ed Taaffe

Powered by WordPress