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

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.

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

  2. A product must breakeven quickly, deliver a profit in the long tail 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. In an Agile world the Product Owner will release an MVP (Minimum Viable Product) and perhaps then an MMP (Marketable)
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 for  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 area 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. Bill Gates freely admits that he ran the business on SAP using his own products to integrate where he needed the extra flexibility.

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 from 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 wooly,  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.

The agile organisation – a risky proposition

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:

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

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



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

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