Market Share, Market Risk

Even as Company A owns and enjoys the biggest share of demographic market for teens, it begins to direct a zealous eye towards another section of the market, the one dominated by competitor Company B. 

Company A looks at the sales and profits of Company B and decides: “we’d like that share”.

Company A undertakes a campaign to grab market share from B.  A few expensive months of marketing begins to make substantial progress.  After a couple of years, Company A is swamped by regulatory demands which were never a problem with their other market.  Consequently, the profit margins end up far far less than originally expected, and the headaches far, far more.

Companies do this all the time.  They notice a market share and say: “we’d like that”. 

But they forget that markets are characterised not only by profits: they also come with market costs, market responsibilities, and market risks.

It seems company B was more adept at managing the risks of that market, hence its profits.  Company A did not have the experience managing the risks of that market, hence its headaches.

Negotiation Bibliography / Library

 General Negotiation

Adler, Bill. How to Negotiate like a Child: Unleash the Little Monster within to Get Everything You Want. 2006.

Asherman, Ira, and Sandy Asherman. The Negotiation Sourcebook. Amherst, MA: Human Resource Development, 1990.

Beasor, Tom. Great Negotiators: How the Most Successful Business Negotiators Think and Behave. 2006.

Billings-Yun, Melanie. Beyond Dealmaking: Five Steps to Negotiating Profitable Relationships. 2010.

Brams, Steven J. Negotiation Games: Applying Game Theory to Bargaining and Arbitration. New York: Routledge, 1990. Print.

Cohen, Herb. Negotiate This!: By Caring, but Not T-H-A-T Much. New York: Warner, 2003.

Cohen, Steven P. Negotiating Skills for Managers. New York: McGraw-Hill, 2002. Print.

Cohen, Steven P. Negotiate Your Way to Success: 24 Steps to Building Agreement. New York: McGraw-Hill, 2007. Print.

Dietmeyer, Brian J., and Rob Kaplan. Strategic Negotiation: A Breakthrough 4-step Process for Effective Business Negotiation. Chicago, IL: Dearborn Trade Pub., 2004.

Donaldson, Michael C. Fearless Negotiating: The Wish-want-walk Method to Reach Solutions That Work. New York: McGraw-Hill, 2007.

Evans, Eric. Mastering Negotiations: Key Skills in Ensuring Profitable and Successful Negotiations. London: Thorogood, 1998.

Fisher, Roger, William Ury, and Bruce Patton. Getting to Yes: Negotiating Agreement without Giving in. New York, NY: Penguin, 1991.

Kolb, Deborah M., Judith Williams, and Deborah M. Kolb. Everyday Negotiation: Navigating the Hidden Agendas in Bargaining. San Francisco, CA: Jossey-Bass, 2003.

Lax, David A., and James K. Sebenius. The Manager as Negotiator: Bargaining for Cooperation and Competitive Gain. New York: Free, 1986.

Fells, R. E. Effective Negotiation: From Research to Results. Cambridge [England: Cambridge UP, 2010.

The Harvard Business School Publishing Guide to Smart Negotiation. Boston, MA: Harvard Business School Pub., 2003.

Holden, Reed K. Negotiating with Backbone: Eight Sales Strategies to Defend Your Price and Value. 2012.

Karpov, Anatoly, Jean François. Phélizon, and Bachar Kouatly. Chess and the Art of Negotiation: Ancient Rules for Modern Combat. 2006.

Karrass, Chester Louis. "In Business as in Life-- You Don't Get What You Deserve You Get What You Negotiate" 1996.

Korobkin, Russell. Negotiation Theory and Strategy. 2002.

Lax, David A., and James K. Sebenius. 3-D Negotiation: Powerful Tools to Change the Game in Your Most Important Deals. 2006.

Lewicki, Roy J., Alexander Hiam, and Karen Olander. Think before You Speak: The Complete Guide to Strategic Negotiation. 1996.

Lewicki, Roy J., and Alexander Hiam. Mastering Business Negotiation: A Working Guide to Making Deals and Resolving Conflict. 2006.

Low, Patrick Kim Cheng. Successfully Negotiating in Asia. 2010.

Lum, Grande. The Negotiation Fieldbook: Simple Strategies to Help Negotiate Everything. 2005.

Mulholland, Joan. The Language of Negotiation: A Handbook of Practical Strategies for Improving Communication. 1991.

Nikolopoulos, Andreas. Negotiating Strategically: One versus All. Houndmills, Basingstoke, Hampshire: Palgrave Macmillan, 2011.

Oliver, David. How to Negotiate Effectively. London: Kogan Page, 2006.

Raiffa, Howard, John Richardson, and David Metcalfe. Negotiation Analysis: The Science and Art of Collaborative Decision Making. Cambridge, MA: Belknap of Harvard UP, 2002.

Saner, Raymond. The Expert Negotiator. 2008.

Thomas, Jim. Negotiate to Win: The 21 Rules for Successful Negotiation. 2005.

Watkins, Michael. Breakthrough Business Negotiation: A Toolbox for Managers. 2002.

Young, H. Peyton. Negotiation Analysis. 1991.

 Interesting / Important Works Which I Don’t Have

Ross, George H. Trump-style Negotiation: Powerful Strategies and Tactics for Mastering Every Deal. Hoboken, NJ: John Wiley & Sons, 2006.

Ury, William. Getting past No: Negotiating with Difficult People. New York: Bantam, 1991.

Bazerman, Max H., and Margaret Ann. Neale. Negotiating Rationally. New York: Free, 1992.

 

Action is King

Nothing happens without action.  Change produces benefits.  Only action produces change.

You can spend years studying how the stock market works, but unless you take action, you will not reap the benefits.  You can spend a lifetime studying how to swim, but without diving into the water, you would not acquire the skill.  You can spend a lifetime thinking about a decision, but without taking the decision, and acting upon the decision, nothing will happen.

There are a few exceptions. You might receive a rich inheritance from a relative who passes away.  You might be born into a rich and wonderful family.  Another exception. but for most other things, if we want improvement in our life, we need to take action.

Why don’t we take more action?  There are two reasons.  First, deciding the right act is hard, for action can bring benefits, but it can also bring disaster.  This fear prevents many people from taking action.  I think buying stocks of ABC will increase my money, but it can also lead to losses, so I will not act for now and think more about it.   I think this more senior role will give me more satisfaction in my work, but I might fail and lose my job, so I will remain content in my current position.

That is why thinking behind an action is important.  What are my options?  Which one should I choose?  What are the rewards?  What are the possible consequences?  Can I survive these consequences?  What are my options if the consequences occur?  Is it worth it?  These are questions for which thinking and information gathering is required in order to set the right course of action. 

But without the action, knowing the right course of action produces nothing.  It is no different from not knowing the right course of action.  So, only study the right course of action if you will take the next step to act on it. Otherwise, it is all just a waste.

The other reason is that it is hard to take action. You want to write a book, but it takes a lot of effort and sacrifice, so you don’t do it. You want to get a better job, but it takes a lot of rejection, so you don’t do it.  There is no shortcut here. You just have to do it.  These most successful inventors worked very hard.  Many of the most successful people work very hard.  The top employees at Goldman Sachs are famous for being wealthy and for having to work very very hard and for very very long hours.  Why should you be an exception? 

But here you can get some help with tools.  Tools like computers and software and reduce the tediousness of work.  Writers from an earlier generation had to write their books using typewriters, and do their research from libraries.  You can write your book using your word processor, and do your research through Google.  The work require is not as hard as before.  It could be that you are just lazy.

Mission Requirements

Clarity in Mission Requirements is critical concept to successful solutions.

People in the solution delivery profession are generally informed about requirements.  Business Analysts, Software Developers, Solution Architects, Project Managers, know about the terms business requirements and system requirements, as well as functional requirements and non-functional requirements.

But seldom heard is the term ‘mission requirements’, which is interesting because it is the most essential of all the requirements of a system. Mission requirements are the raison d’etre of the system, its reason for being, the purpose for which the system is being produced.  All other requirements are subordinate to the mission requirements, and are derived from the mission requirements. 

The reason for the total absence of mission requirements in enterprises is undoubtedly because the word ‘mission’ itself is not part of the business vernacular.  One hears of the ‘vision’ for the enterprise, and its ‘mission’ but that is something quite different.

The phrase ‘mission requirements’ comes from the military and aerospace community.  A mission refers to the intention of the system, often a weapons system.  For example, a fighter plane’s mission is to shoot down enemy aircraft.  A Patriot missile battery’s mission is to shoot down incoming missiles. 

A system is assigned a mission because the super-system (the system which contains the system of interest), has objectives, and they perceive that to achieve the objectives, the system must be able to meet the mission requirements.

Mission requirements focus on the external system, not the system being built.  It is no surprise that mission requirements are measured using metrics called ‘Measure of Effectiveness’ .  This is about how well the solution is impacting the super-system and helping it achieve its objectives.

Think about a car.  A car with a top speed of 100mph.  It is impossible to say whether such a car is suitable or not without considering the mission for which it will be used, the part it will play.  If the car is to be used for transporting kids to and from school, then it’s perfectly suitable.  If it’s to be used to win a race, then it’s probably inadequate.

There is a hierarchy of requirements, and not the simple categorisation into just two: business,  and system requirements, is not rigorous enough. 

At the top of the hierarchy is the mission requirements.  All other requirements are derived from it, or in support of it.  These requirements must be set out very clearly.

Modern Tools for Business Continuity / Disaster Recovery

Today’s world provides so many enabling technologies for enabling an efficient and effective BC / DR plan in place.  Enterprises can no longer justify not having a working and effective BC / DR plans in place.

The coming of the Cloud is a tremendous help for BC/DR planning. You have a safe repository of all your important information physically separate from your physical operations. Even if your whole building becomes inaccessible through fire, flood, or terrorism, the data, applications, and knowledge stored in the cloud remain untouched, completely unaware that something has occurred. It is just there waiting for you to access it from wherever you are. No time or effort or cost need to be spend recreating hardware and infrastructure.

The BC / DR plans themselves that used to be kept in physical paper files can now be stored in electronic format, immediately accessible and available through different channels and devices. In electronic format, it becomes easy to update and keep current, easy to disseminate and and ensure that everyone has the latest version, and very importantly, easy to access when needed.

Copies of the plans can be kept in secure thumb drives at the homes of key employees.

When disaster strikes, the ubiquity of handheld smart devices allow employees to be easily advised, easily contacted, and potentially able to work from anywhere. 

For a web-based central platform for reporting and keeping track of what’s going on, you can also put up a wiki platform that key personnel can readily update as information and progress occur.  A wiki software you can use is Mediawiki.  This is the same software that Wikipedia runs on.

Tools for automating the DR testing make coming up with working plans far easier.  Solutions like VirtualSharp or Sanovi can help here.

BC / DR solutions need to go all the way to recovery.  Many cloud solutions merely back up your data and applications.  This is much better than nothing, but it is not enough.  You also need to restore the data and applications into a state suitable to continue doing business.  Plain backups do not help in adhering to RPOs (Recovery Point Objectives) and RTOs (Recovery Time Objectives) set for critical processes and data.

A lot of these tools were not around ten years ago.  Failure to take advantage of them is almost criminal.

The Work Breakdown Structure (WBS), part 2

Since the WBS is a hierarchical structure, it has bottom level parts.  The WBS can be constructed like a table of contents, like so:

WBS Item 1 WBS Item 1.1 WBS Item 1.2 WBS Item 1.3 WBS Item 1.3.1 WBS Item 1.3.2 WBS Item 1.4 WBS Item 2 WBS Item 2.1

The lowest level items (shown above in bold) are called ‘Work Packages’.  The Work Packages are discrete pieces of work to be assigned to someone in the project, perhaps an individual, a business unit, and internal, team, or a contractor.  The key is that there is someone responsible for delivering the Work Package.

WBS’s should be oriented towards the deliverables, not towards the functional groups.

The reason for breaking down the project into smaller work packages is for management and control. 

The smaller a piece of work is, the easier it is to estimate how much time is needed to do the work.  Work packages also facilitate the scheduling of the project. The work packages can be the components mentioned in the master schedule. Work packages can be scheduled individually, and the resulting duration be fed into the master schedule, which only shows the work packages.

It is also easier to estimate the cost of smaller work than bigger work.  To estimate the cost of the project, just estimate the cost of each individual work package and sum them up.

The WBS is often claimed to be the backbone of the project, and some writers have said that project failures can be traced back to faulty WBS’s:

“Component or full-project failures, when they do occur, can often be traced to a poorly developed or non-existent WBS”(Norman, Brotherton, and Fried, "Work Breakdown Structures: The Foundation for Project Management Excellence")

The Work Breakdown Structure (WBS)

After the Gantt chart and the network diagram, there is perhaps no other project management tool that is more ubiquitously discussed than the WBS. 

As the Gantt chart is the primary tool for documenting the project schedule, so is the WBS the primary tool for documenting the project scope.

What is a WBS?

The PMBOK Guide describes the WBS as “a deliverable-oriented hierarchical decomposition of the work required to be executed by the project team to accomplish the project objectives and create the required deliverables.” 

That is, the WBS, “defines the total scope of the project.”

According to this definition, the WBS is a “decomposition of the work required”. 

But work required to do what? There are two kinds of work:

1. Work required to accomplish the project objectives
2. Work required to create the required deliverables

Together, these two kinds of work define the sum total of all kinds of work required: all project work falls into at least one of these two.  We say at least, because it is possible that some piece of work can be properly thought of as belonging to one or the other – that is not a matter of great concern.

The first kind of work is about work that need to be done in order to successfully complete the project objectives, even though they are not the purpose of the project.  An example of this type of work is developing the project schedule (which is needed to help attain project completion date objectives).  Other examples include developing a WBS,  supervising the work-force, and conducting project communications.

The second kind of work is covers what’s needed to deliver what the project needs.  Examples include designing a piece of software, integrating components, reviewing the quality of sub-components, and testing the components.

Note that the WBS is “deliverable-oriented”, but it is not a compilation of the deliverables.  It is a compilation of the work required, hierarchically organised around the deliverables.  The star of the show is the work, not the deliverables.

A software development project with the goal of delivering a commercial software product (and nothing else, not even documentation), the list of deliverables will not change, whether you use an Agile approach or a waterfall approach.

However, the WBS for the Agile approach will be different from the WBS of a waterfall approach.  Examples of the differences include:

• The Agile WBS will include such work as ‘Write User Stories’
• The Waterfall WBS will include such work as ‘Develop Design Document’

The deliverable is the outcome, the work is the effort and activities required to produce the outcome. 

Given that there are many different ways to produce the outcome, the WBS is a reflection of the plan chosen to produce the outcome.  Change the strategy, the WBS can potentially change.