What are the Different Kinds of Requirements?

ARGUABLY the most well-known categorisation of requirements is the Functional and Non-Functional dichotomy.  So ubiquitous is this classification that one can refer to them with the acronyms F and N/F and people know what you mean. 

F is about what the system must be able to do, and N/F is about characteristics that the system must exhibit to some specified level, such as being “available for use 99% of the time” or ‘of yellow colour’.

Another major classification of requirements is that between business and system requirements.  The vast majority of projects in the IT and Telecoms field will produce two requirements documents: the BRD (Business Requirements Definition / Document), and the SRD (System Requirements Definition / Document).  The key distinction between a business requirement and a system requirement is that the former is about what the ‘business’ (or organisation) needs from the system, whereas the system requirement is about what the solution system needs to be able to do (functionality), and exhibit (non-functional requirements), in order to meet the business requirement.

If a system project is aware of only these two classifications of requirements, then serious gaps exist and it is very likely that the resulting system will not meet the business objectives to the degree promised in the business case.

One way to look at the requirements is that they form a hierarchy which is more than merely the business and system requirements.

Mission Requirements

At the top of the requirements hierarchy lie the mission requirements.  An organisation has objectives that need to be met, such as ‘improve processing speed’, ‘reduce cost per part’, ‘meet regulatory requirements’.  A concept of a solution is developed and mission level requirements are developed.  These requirements specify what is needed from the solution in order that it will meet the business objectives.  The concept solution, if it is to deliver the objectives of the organisation, must meet the mission level requirements.

These requirements may include such things as interoperability with existing organisational systems, availability by a certain future date, or cost only a certain amount.  

Stakeholder Requirements

Next come the stakeholder requirements. What do each of the stakeholders need to be able to do, in order to meet the mission requirements?  If the mission is to 'improve processing speed by 100%’, what does stakeholder A, B, C, etc. need?  These requirements are written in the language of the stakeholders (for it originated from them, and since they need to confirm the cleaned-up version). 

Although these requirements originated from the stakeholders, they almost always need to be elicited from them through capable facilitation.  They also need to be reviewed for completeness.  Stakeholders tend to provide only the most salient requirements prominent in their mind.

Derived Requirements

The Stakeholder Requirements are analysed and reviewed to produce the Derived Requirements.  Derived Requirements are the input to the Design process and the Verification process and therefore are written both in more precise language (e.g., “the system shall…”) and in more technical language.   Since these requirements are derived, there must be some form of written justification as to how a derived requirement meets a stakeholder requirement.  From an administrative point of view, we also need to maintain traceability links back to the stakeholder or mission requirements.

System Requirements

System Requirements are Derived Requirements which specify system-level functionality or characteristics of the desired system.

Component Requirements

Component Requirements are Derived Requirements which specify what specific components must meet.  For example, for a web-based system, components might include requirements for web servers and database management systems. 

There are other ways to classify requirements, but they are orthogonal to the above.  For example, there are things such as Input Requirements, or Operational Requirements, and Schedule Requirements, but each of these also fall within one of the above hierarchy.

Comparing the BABOK and SEBOK, Part 6

The BABOK Knowledge Area called “Elicitation” shares some overlap with some of the contents of the SEBOK Knowledge Area called “Concept Definition”, which discusses the elicitation of requirements, among other topics related to concept definition. 

How do the BABOK and SEBOK compare in their coverage of requirements elicitation?

The BABOK “Elicitation” Knowledge Area

This Knowledge Area’s topic is the drawing forth of requirements from the various stakeholder, and documenting these requirements.

The first thing that strikes me about the BABOK’s coverage, is that it’s extremely generic and lacking any real depth.  Most of the discussion touches on what the elicitation tasks are, what the most common inputs are, what the most common elicitation techniques are, and what the most common outputs are.  Notice that I prefixed each item in the list with a ‘what’, because that is pretty much all that the BABOK covers. 

It does not address the why’s and the how’s.  It merely mentions nouns with very little fleshing out.   As an example, one of the outputs is a Requirements Management Plan.  There is no discussion about such a plan contains.  The BABOK identifies which tasks produce this plan, and which tasks use it as input, but that’s about it.

SEBOK Elicitation Coverage

The SEBOK does not have a specific Knowledge Area focused solely on Elicitation.  However, elicitation of stakeholder requirements is discussed under “Stakeholder Needs and Requirements”, which is a topic under the ‘Concept Definition’ Knowledge Area.

The SEBOK distinguishes between ‘needs’ and ‘requirements’.  In fact, it speaks of activities necessary to ‘identify and prioritize the needs of stakeholders, as well as transform those needs into requirements’

The SEBOK stresses that the stakeholder needs (which are obtained as a result of the process of elicitation), are to be transformed into stakeholder requirements.  I could not find something similar in the BABOK, which seems to treat the elicited stakeholder needs as requirements, evidenced by a statement like this:

“Requirements [Stated, Confirmed]: Identical to Requirements [Stated] for all practical purposes, including use as an input to other tasks.”

The SEBOK explains that requirements come from needs (i.e., they are more formal and precise expressions of needs).  It also goes into fair detail about the different types of needs:

• Real Needs
• Perceived Needs 
• Expressed Needs 
• Retained Needs
• Specified Needs
• Realized Needs

Comparison of Elicitation Techniques

Both the SEBOK and BABOK give us a list of common techniques used for elicitation.  This table blow shows their lists:

BABOK	SEBOK
Brainstorming	Structured Brainstorming Workshops
Document Analysis	Technical, Operational, and / or Strategy Documentation Review
Focus Group
Interface Analysis
Interviews	Interviews
Observation
Prototyping (including Storyboarding, Navigation Flow, Paper Prototyping, Screen Flows)	Prototyping
Requirements Workshops
Survey / Questionnaire	Questionnaires
	Simulations and Visualisations
	Modelling
	QFD (Quality Function Deployment)
	Use Case Diagrams
	Activity Diagrams
	Functional Flow Block Diagrams

Comparison of Outputs

The BABOK ‘Elicitation’ activities and the SEBOK ‘Stakeholder Needs and Requirements’ activities produce outputs. The table below compares the outputs:

BABOK Outputs	SEBOK Artefacts	Remarks
Elicitation Results	Stakeholder Interview Reports	A record of what was elicited from the stakeholders.  This is subject to further processing and formalisation.
Scheduled Resources		A schedule of when the elicitation activities will take place, when, how, and who will be involved
Stakeholder Concerns [Unconfirmed / Confirmed]		Issues identified by the stakeholders.  These include assumptions, concerns, risks, and constraints.  The Confirmed version has been signed-off by the stakeholder.
Supporting Materials		“Any materials required to help explain the techniques used or perform them” (BABOK).
Requirements [Stated / Confirmed]	Stakeholder Requirements Document	BABOK - Stakeholder needs as stated by the stakeholder. The confirmed version is signed-off by the stakeholder. SEBOK – does not provide an description of ‘Stakeholder Requirements Document’
	Stakeholder Requirements Database
	Stakeholder Requirements Justification Documents	SEBOK – The SEBOK says this is for ‘traceability purposes’

Comparison of Tasks and Processes

The BABOK provides a clear list of key Tasks related to Elicitation and I have listed them in the table below.  Unfortunately, the SEBOK does not gather the activities in such a defined way.  I collect the main activities mentioned throughout the text and list them in the same table below, for ease of comparison.

BABOK Elicitation Tasks	SEBOK Activities	Remarks
Prepare for Elicitation
Conduct Elicitation Activity	Elicitation
Document Elicitation Results
Confirm Elicitation Results

In conclusion, the SEBOK coverage has more depth and meat.  The BABOK coverage could provide more information in upcoming versions.  As it stands, its current coverage is merely a mapping of inputs to outputs with virtually no description of what characteristics a good quality output should have, and no description of the processes that produce the outputs.  I also think it should deliver more distinction between stated needs and the requirements derived from those needs.

Churchill on Risk Management

Here’s an excellent quote form Winston Churchill, eminently applicable as the proper attitude to adopt in risk management.  The sentence comes after Churchill summarises the beliefs and convictions taken by the then British Prime Minister Neville Chamberlain on what Hitler will do the the limits of what he will do, taking the position that he (Chamberlain) has taken the measure of Hitler, and that he (Hitler) has satisfied his territorial conquest needs:

“The Prime Minister is persuaded that… He believes that… Mr. Chamberlain is convinced that… But all this lies in the region of hope and speculation.  A  whole set of contrary possibilities must be held in mind.  He may ask us to submit to things which we cannot endure; he may be forced to ask us to submit to things which we cannot endure.”  (Churchill, the Second World War Volume 1, The Gathering Storm)

I like this ‘a whole set of contrary possibilities must be held in mind’ assertion.  For this is what risk management is about – that things may not work out as we thought, or hoped, and we must be able to survive and recover when they do.

The Ten Qualities of Good Requirements

A solid database design provides a firm and extensible base an organisation’s data.  A well-architected solution brings with it a sense of integrity and elegance that allows systems to be extended easily, and yet retain its integrity.

If any of these are badly done, the resulting solution is flaky, troublesome, and a menace to update.

But bad requirements are even worse, for they are our map to what should be built.  If the requirement is wrong, the solution built is wrong.  If the requirement has gaps, then the solution will have gaps.  If the requirement is misunderstood, then the solution is wrong.

There is an art to producing requirements.

1. Requirements Must Have an Owner

2. Requirements Must be Singular

3. Requirements Must be On the System and Not the Operator

4. Requirements Must be Unambiguous

5. Requirements Must Not Specify the Solution

6. Requirements Must have a Rationale

7. Requirements Must be Tied to the Concept of Operations

8. Requirements Must be Justified

9. Requirements Must be Prioritised

10. Requirements Must be Contextualised

Comparing the BABOK and the SEBOK, Part 5

I want to take a second look at the Knowledge Areas identified by the BABOK and those by the SEBOK, specifically where there is an overlap between the two sets. 

I want to do this in preparation for a deeper comparison of their treatments of their Knowledge Areas and Tasks and Activities.

The table below lists the Knowledge Areas for the BABOK, and what to me might be the corresponding Knowledge Area addressed in the SEBOK.  As can be immediately seen, the SEBOK Knowledge Areas cover a lot more topics.

BABOK Knowledge Area	SEBOK Knowledge Area	Remarks
	Systems Fundamentals
	Systems Science
	Representing Systems with Models
	Systems Approach Applied to Engineered Systems
	Life Cycle Models
	System Deployment and Use
	Product and Service Life Management
	Systems Engineering Standard
Business Analysis Planning and Monitoring
Elicitation	Concept Definition	This SEBOK KA contains the following Activities: Mission Analysis Stakeholder Needs and Requirements
Requirements Management and Communication	System Definition Systems Engineering Management	“Requirements Management” is very briefly treated in the SEBOK under the “System Requirements” topic, which is under the System Definition KA. Configuration Management is considered part of the BABOK KA “Requirements Management and Communication”. In the SEBOK, Configuration Management is discussed under the Systems Engineering Management KA
Enterprise Analysis	Concept Definition	This SEBOK KA contains the following Activities: Mission Analysis Stakeholder Needs and Requirements
Requirements Analysis	System Definition	The topic of "System Requirements” addresses assessing the quality of the requirements and their prioritisation. System Requirements is a topic under the KA System System Definition
Solution Assessment and Validation	System Realization	This SEBOK KA contains the following Activities: System Implementation System Integration System Verification System Validation
	Product Systems Engineering
	Service Systems Engineering
	Enterprise Systems Engineering
	System of Systems
	Enabling Businesses and Enterprises
	Enabling Teams
Underlying Competencies	Systems Thinking Enabling Individuals
	Systems Engineering and Software Engineering
	Systems Engineering and Project Management
	Systems Engineering and Industrial Engineering
	Systems Engineering and Procurement / Acquisition
	Systems Engineering and Specialty Engineering

In the next post on this topic, I will start comparing the contents of the matching Knowledge Areas.

Comparing the BABOK and the SEBOK, Part 4

In this post I’ll compare how the two documents structure their presentation of a Knowledge Area (KA).

BABOK Knowledge Area Structure

The BABOK discusses each of its KA in turn.  The discussion starts with a short overview of the KA,  followed by an Input / Output Diagram showing the Tasks under that KA, the Inputs required by the Tasks, and the Outputs generated by the Tasks (and by extension the KA).

The core of the Knowledge Area is its Tasks, and the BABOK structures the presentation of the KA around the Tasks.  Each Tasks is described in turn using the following sections:

1. Purpose of the Task – brief explanation of the focus of the Task.
2. Description – usually more details about the Task.
3. Input – a list of information (typically documents) needed for performing the Task, also describing why each Input is used for.  This section is accompanied by a context diagram showing the Task, the Inputs it requires, the Task Outputs, and downstream Tasks using the Outputs as Inputs.
4. Elements – describes considerations relevant to the Task which need to be addressed for a successful execution of the Task.
5. Techniques – lists the most common techniques used in performing the task.  Techniques are methods or tools such as ‘Interviewing’, or ‘Brainstorming’.  All of the Techniques are described in more detail in Chapter 9, so this section is just a listing.
6. Stakeholders – is a list of organisation titles generally involved or interested in the Task execution.
7. Output – a list of the Outputs of the Task (generally documents).

SEBOK Knowledge Area Structure

As we have seen in the previous post, the SEBOK has many more KA’s than the BABOK.  Not only are there many more, the scope is more extensive.  Whereas the BABOK KA’s are narrow enough that one can expect every practicing BA to be knowledgeable at a professional level in ALL the KA’s (though perhaps not all the Techniques), the SEBOK KA’s are so expansive, it is unlikely that a majority of professional SEs would have high quality proficiency in all the SEBOK KAs.

Each KA is divided into Topics (contrast with ‘Tasks’ for the BABOK), which confusingly is also called ‘Activities’.  The KA itself is described in great detail (far greater than what is done in the BABOK).  After which a list of Reference work is provided.

After providing a detailed discussion of the KA, each of the Activities under that KA are discussed using the following structure:

1. Introduction – brief narrative about the Topic 
2. Purpose and Definition – detailed description of the Topic / Activity
3. Principles and Concepts - key concepts one needs to know about the Topic.  Depending on the topic being discussed, this can be fairly comprehensive.
4. Process Approach / Activities of the Process – description of the subtasks performed for the Activity
5. Artifacts – listing of most common outputs (generally documents) for the Activity
6. Methods and Modeling Techniques – listing and description of key Techniques one can expect to be used to perform this Activity.  (For the most part, the SEBOK uses the single-ell spelling ‘modeling’, but sometimes also uses ‘modelling’)‘
7. Practical Considerations – tips and lessons learned from the trenches.  
8. References – comprehensive list of Works Cited, Primary References, and Additional References relevant to the Activity.  Since the SEBOK is merely a 'Guide’ to the Body of Knowledge, this References section makes eminent sense – it points to where the reader can go to get more of the Knowledge.

Comparison of the Structures

The table below compares the KA presentation structure of the two BOKs

BABOK	SEBOK	Remarks
Overview	Introduction	Neither of these sections are titled as such.  Both sections are untitled narratives.
Purpose of the Task	Purpose and Definition
Description	Purpose and Definition
Input		It is very surprising that SEBOK seems to have no equivalent section
Elements	Principles and Concepts Practical Considerations
	Process Approach / Activities of the Process	The BABOK has no equivalent
Techniques	Methods and Modeling Techniques
Stakeholders		The SEBOK has no equivalent section
Output	Artifacts
	References	The BABOK references are all collected at the end of the Guide, where it is far less useful for someone wanting to know more about a specific Task.

Investing Bibliography

Value Investing

Calandro, Joseph. Applied Value Investing: The Practical Applications of Benjamin Graham's and Warren Buffett's Valuation Principles to Acquisitions, Catastrophe Pricing, and Business Execution. 2009.

Graham, Benjamin, and David L. Dodd. Security Analysis. 1996.

Graham, Benjamin, and Jason Zweig. The Intelligent Investor. 2003.

Klarman, Seth A. Margin of Safety: Risk-averse Value Investing Strategies for the Thoughtful Investor. 1991.

Comparing the BABOK and the SEBOK, Part 3

Knowledge Areas are subject matters of core interest to a profession or discipline.  They are the sort of knowledge often required to live the profession.  In the medical profession, a knowledge area might include physiology, how the body functions.  For project managers, an example might be scope management.

Knowledge Areas

For the BABOK, Knowledge Areas:

define what a practitioner of business analysis needs to understand and the tasks a practitioner must be able to perform.

In other words, it is an area that a Business Analyst should have knowledge on.

For the SEBOK, Knowledge Areas:

are groupings of information with a related theme

The SEBOK is reluctant to assert that an SE must know about the Knowledge Areas (henceforth KAs), whereas the BABOK claims the KAs are what the BA ‘needs to understand’ and ‘able to perform’.  The difference in these scope will become evident as we look at the KAs listed by each of the BOKs.  We can now say that the BABOK KAs are far more modest in scope than the SEBOKs.

The BABOK Knowledge Areas

The BABOK lists seven KAs:

1. Business Analysis Planning and Monitoring
2. Elicitation
3. Requirements Management and Communication
4. Enterprise Analysis
5. Requirements Analysis
6. Solution Assessment and Validation
7. Underlying Competencies

The BABOK KAs are closely related to skills.  One can develop ‘Business Analysis Planning and Monitoring’ skills, or ‘Elicitation’ skills.

The SEBOK Knowledge Areas

The SEBOK not only lists far more KAs than the BABOK, but the breadth and depth of the subject matter is in a different league.

The SEBOK KAs are divided into 5 Parts, each of which has KAs under it.  Here’s the full list of Parts and KAs under them:

1. Part 2 – Systems
   1. Systems Fundamentals
   2. Systems Science
   3. Systems Thinking
   4. Representing Systems with Models
   5. Systems Approach Applied to Engineered Systems
2. Part 3 – Systems Engineering and Management
   1. Life Cycle Models
   2. Concept Definition
   3. System Definition
   4. System Realization
   5. System Deployment and Use
   6. Systems Engineering Management
   7. Product and Service Life Management
   8. Systems Engineering Standard
3. Part 4 - Applications of Systems Engineering
   1. Product Systems Engineering
   2. Service Systems Engineering
   3. Enterprise Systems Engineering
   4. System of Systems
4. Part 5 – Enabling Systems Engineering
   1. Enabling Businesses and Enterprises
   2. Enabling Teams
   3. Enabling Individuals
5. Part 6 – Related Disciplines
   1. Systems Engineering and Software Engineering
   2. Systems Engineering and Project Management
   3. Systems Engineering and Industrial Engineering
   4. Systems Engineering and Procurement / Acquisition
   5. Systems Engineering and Specialty Engineering

The SEBOK list of KAs is comprehensive, ranging from the abstract subject of Systems, down to performance assessment of individual SEs.

At a first approximation, it seems to me that the scope of the BABOK KAs fall within this subset of the SEBOK KAs

1. …
2. Part 3 – Systems Engineering and Management
   1. Life Cycle Models
   2. Concept Definition
   3. System Definition
   4. System Realization
   5. System Deployment and Use

No surprise, SE is far more broad than BA if the KAs are to be the basis.  But that is not the main point of this series.  The key interest is where they overlap.   We will look more closely at these overlapping KAs in the next parts.

Comparing the BABOK and the SEBOK, Part 2

Business Analysis and Systems Engineering seem to share a substantial in their perceived areas of scope, so it might be informative to see what their respective BOK Guides say about the other discipline.

Do They Know Each Other?

It is interesting that neither the term “Systems Engineering” nor its variant “System Engineering” appear in the BABOK.  This is strange because the BABOK authors are evidently aware of the SE discipline, since the BABOK Bibliography includes these two SE-centric books:

Stevens, Richard, Peter Brook, Ken Jackson, and Stuart Arnold. 1998. System Engineering, Coping with Complexity

Forsberg, Kevin, Hal Mooz, and Howard Cotter-man. 2005. Visualizing Project Management: Models and Frameworks for Mastering Complex Systems

As for the SEBOK, it mentions “business analysis” three times, each time using it as a synonym for mission analysis, such as in this extract:

MA, in some domains called market analysis (glossary) or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise (p. 253).

Judging from this, the SEBOK considers business analysis as limited to mission analysis, which is only a part of the Concept Definition Phase

What is Business Analysis?

If Business Analysis is synonymous to Mission Analysis (according to SEBOK), it should be useful to compare and contrast BA as understood by the BABOK with MA as understood by the SEBOK. 

The table below lists the functions of BA as described by BABOK, and the functions of MA as described by SEBOK.  I tried to match them, with some degree of interpretive freedom on my part.

Business Analysis According to BABOK	Mission Analysis According to SEBOK
Liaison among stakeholders
Understand the structure, policies, and operations of an organisation
Recommend solutions that enable the organisation to achieve its goals	Analyse the solution space
Understanding how organisations functions to accomplish their purpose
Defining the capabilities an organisation requires to provide products and services
Definition of organisational goals
Define how goals connect to specific objectives
Determine courses of action that an organisation has to undertake to achieve those goals and objectives
Defining how the various organisational units and stakeholders within and outside the organisation interact.
	Establish a set of stakeholder requirements for a potential SoI (System-of-Interest)
	Focuses on the identification of the primary purpose(s) of the solution
	Part of the larger set of concept definition activities -
	Understand a mission / market problem or opportunity
	Initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity
	Define operational actions, not hardware / software functions; that is, it is focused on defining the problem space, not the solution space
	The primary products of MA are the revised ConOps of the enterprise, the operational concept, the operational scenarios for the mission, and the context in which the solution will exist.
	MA evaluates alternative approaches to determine which best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions).
	MA defines the problem space and analyses the solution space alternatives using quality attribute constraints driven by the enterprise objectives.

I could not match the two sets of functions and find very little, almost no direct intersection between what Business Analysis is according to BABOK, and what Mission Analysis is according to the SEBOK (which treats business analysis as a synonym for Mission Analysis.

And yet, my instinct tells me there is a strong intersection, it’s just that the two BOKs use very different terminology and very different ways of explaining.  (I find the BABOK a bit more refined in its explanations, while the SEBOK tend to ramble a bit).

Number of Pages

This is an easy comparison.  Version 2.0 of the BABOK has 253 pages.  The SEBOK is primarily laid to for reading online using a Wiki platform, but a PDF version is available for download.  This PDF runs to 850 pages.  Better have a full ream of office paper ready if you decide to print this.

Authors

The SEBOK lists 70 authors, some of whom I recognise as respected leaders in the SE discipline.  The ones I know by reputation include: Barry Boehm (but I know him from the software engineering field, not the SE field), Erik Aslaksen, Edmund Conrow, Dov Dori, Kevin Forsberg, and James Martin.

The BABOK also credits as Content Contributors about 19 names, of whom the only one I recognise (but recognise only the name, not what she’s about): Ellen Gottesdiener.  They do have an Expert Advisory and Review Group, from which I recognise the following names: Scott Ambler, Dean Leffingwell, Meilir Page-Jones, James Robertson, Suzanne Robertson, Steve Tockey.

Operational Risks

Operational risks are those risks related to failures in day to day operations. They are different from other kinds of risks such as credit risk, or market risk.

Operational risks are about things going wrong resulting in losses.  For example, a small grocery might encounter the following problems:

• Shoplifters
• Giving too much change to a customer
• A car crashing through the shop
• A customer slipping and hurting themself.
• Goods not the right one
• Counterfeit money
• Robbers
• Fire
• Employee theft

Other kinds of risks are not considered operational risks:

• Another shop opening nearby, drawing some of the customers
• A bank calling on the loan
• Interest rates going up
• Prices of goods going up

Operational risks are about failures of people, systems, and processes, and about external events.

The risk brought about by operational risk, like any risk,  depends on the likelihood of occurrence, and the consequences it brings.  These costs need to be balanced by costs related to mitigating the risk.  For example, the risk of being robbed may be mitigated by hiring guards to secure the store, but will the cost of hiring them be higher than the cost of being robbed, once or twice a year?

The cost of being passed counterfeit bills may be mitigated by installing a counterfeit checking device, but will that cost more?

Comparing the BABOK and the SEBOK, Part 1

I find it interesting that the disciplines of Business Analysis and Systems Engineering share an apparently substantial overlap in their areas of declared responsibilities and specialties.

In the domain of system related projects, both specialise in requirements development, in cost / benefit analysis, in solution assessment and selection, and in verification and validation of the solution.  Could it be they are one and the same thing?

The SE community recently completed its SEBOK Version 1.0 (Systems Engineering Body of Knowledge), available at http://www.sebokwiki.org.  The BA community, through the auspices of the IIBA, has its BABOK (Business Analysis Body of Knowledge), currently at version 2.0 (available at the IIBA website). 

I think it will be interesting to compare the two documents and see what each has to say in areas they have in common, but also in areas which the other is silent.  Where exactly are they similar?  How do they differ?

Since both documents are lengthy, I’ll do the comparisons in several parts. 

To start, let’s look at what each BOK has to say about their particular discipline. 

What is Systems Engineering?

What is Systems Engineering? SEBOK offers this brief definition:

Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems

This is a very thin definition, almost to the point of meaningless.  One can probably can use it to describe project management, or even portfolio management, both of which can be argued as enabling the realisation of successful systems. The SEBOK also provides a longer description:

“an interdisciplinary approach and means to enable the realization of successful systems” (INCOSE 2012). It focuses on holistically and concurrently understanding stakeholder needs; exploring opportunities; documenting requirements; and synthesizing, verifying, validating, and evolving solutions while considering the complete problem, from system concept exploration through system disposal.

In the glossary, it provides two other definitions, taken from unrelated official documents. The first is from ISO/IEC/IEEE 2010 which says that Systems Engineering is an:

Interdisciplinary approach governing the total technical and managerial effort required to transform a set of customer needs, expectations, and constraints into a solution and to support that solution throughout its life.

The SEBOK also quotes the INCOSE Systems Engineering Handbook (v 3.2.2). The first sentence is exactly the same as SEBOK’s definition:

An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:

• Operations
• Performance
• Test
• Manufacturing
• Cost & Schedule
• Training & Support
• Disposal

Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

The focus therefore, of SE is defining what the customer needs, and delivering the solution that fills the need.

What is Business Analysis?

The BABOK provides the following:

Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.

So, where SE is an ‘approach’ that ‘governs’ and ‘integrates’, BA is a ‘set of tasks and techniques’ and is meant as ‘liaison’. 

The BABOK continues:

Business analysis involves understanding how organizations function to accomplish their purposes, and defining the capabilities an organization requires to provide products and services to external stakeholders. It includes the definition of organizational goals, how those goals connect to specific objectives, determining the courses of action that an organization has to undertake to achieve those goals and objectives, and defining how the various organizational units and stakeholders within and outside of that organization interact.

Here we get some clarity about the focus of BA work: the organisation.

Business analysis may be performed to understand the current state of an organization or to serve as a basis for the later identification of business needs. In most cases, however, business analysis is performed to define and validate solutions that meet business needs, goals, or objectives.

Business analysts must analyse and synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives. The business analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires. In many cases, the business analyst will also work to facilitate communication between organizational units. In particular, business analysts often play a central role in aligning the needs of business units with the capabilities delivered by information technology, and may serve as a “translator” between those groups.

While BA work is clearly meant to identify the customer requirements, it is clear that BA work sits in the non-technical area of the organisation, specialising in what the organisation does and needs.  In contrast, the SE definition does not make it clear whether the SE is more focused on the technical aspects of the solution (we can assume so from the word ‘Engineering, but that is not the same as having it asserted directly).

A business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be. Business analysis practitioners include not only people with the job title of business analyst, but may also include business systems analysts, systems analysts, requirements engineers, process analysts, product managers, product owners, enterprise analysts, business architects, management consultants, or any other person who performs the tasks described in the BABOK® Guide, including those who also perform related disciplines such as project management, software development, quality assurance, and interaction design.

When you do work that is in the BA domain, you are doing Business Analysis, regardless of title.  So if you are an SE, you might also be a BA.

I’ll continue the comparison in another post.

ISO 31000:2009’s Definition of Risk

As anyone involved in risk management knows, a couple of years ago the ISO published their new Risk Management Standard known as ISO/IEC 31000:2009 (ISO 31000 for short).  This standard is new for ISO, and is not replacing an older ISO standard.  For countries like Australia though, which had its own standard (AS/NZS 4360:2004), this new ISO standard supplants that older standard.

One of the innovations coming from ISO 31000 is a new definition of risk.  It is a  concise definition, albeit but strangely phrased. It defines risk as:

"the effect of uncertainty on objectives."

At first glance, it looks straightforward.  But a closer interpretation of the words makes on pause: the what of what on what?  

But before we delve into what it means, let’s compare this definition with the one used in AS/NZS 4360:2004, which was not only the Australian (and New Zealand) standard, but also adopted in several other countries.  As testament to its wide acceptance, the core of ISO 31000, its Risk Management Processes, is taken almost verbatim from AS/NZS 4360:2004.

This is how AS/NZS 4360:2004 defined risk:

"the chance of something happening that will have an impact on objectives." 

Here it’s clear that risk is clearly tied to "something happening".  Risk is an event or a circumstance (together with its chance of happening).

By contrast, in the new ISO definition, risk is the "effect of uncertainty".  What is this ‘effect’? 

ISO 31000 provides an explanation:

Effect - "a deviation from the expected -- positive or negative".

Now, since we are talking about risk, and risk is about future events, we can safely assume that when they say ‘deviation’, they are talking about potential deviation, or a possible deviation, not a deviation that has already happened.

If we take that meaning, then it seems to me that the definition of risk can be translated to:

"the possible deviation … on objectives."

This makes some sense.  Risk is indeed about its possible deviation on our objectives.  We hope to finish a project within 6 months, but it might end up finishing after 17 months. 

But notice that I put in ellipses.  The reason I did that is because if I restore the missing words, the definition of risk becomes:

"the possible deviation of uncertainty on objectives."

Which is clearly gibberish, so let’s parse it further.

In risk management, the word ‘uncertainty’ refers to ‘ignorance’ or ‘lack of knowledge’.   ISO 31000’s definition is aligned with this view:

Uncertainty - "the state, even partial, of deficiency of information related to understanding or knowledge of an event, its consequence or likelihood."

Note the definition: ‘Deficiency of information’, lack of information, or lack of knowledge.  This lack of knowledge, does not, I believe, refer to lack of skill, or lack of expertise, but specifically to lack of knowledge about what will happen. 

Given the above, a possible rephrasing of the definition can go like this: 

Risk - the possible deviation, arising from lack of information, on objectives.

The key difference is that in AS/NZS 4360:2004, risk is an event, whereas in ISO 31000, risk is the deviation.  This is not the consequence, but the deviation. 

So for example, we launch a product which we estimate will bring in $20 million dollars.  For AS / NZS 4360:2004, a possible risk is that a competitor might launch a similar product which changes the market dynamics, resulting in lower revenues for us.  For ISO 31000 a risk might be that sales are not as big as we expected.  What are the consequences of that?

This change in the definition of risk has been met with praise, criticism, and confusion.  One of the primary impetus in redefining risk is the desire to better incorporate the handling of ‘positive risks’ in the risk management process.

It certainly makes one rethink.

Risk Management Bibliography / Library

Some key works on various risk management topics either in my library or I have read.  I plan to update this list every now and then.

Risk, Risk Management, and Uncertainty in General

Aven, T. Misconceptions of Risk. Chichester, West Sussex, U.K.: Wiley, 2010.

Bernstein, Peter L. Against the Gods: The Remarkable Story of Risk. New York: John Wiley & Sons, 1996.

Kammen, Daniel M., and David M. Hassenzahl. Should We Risk It?: Exploring Environmental, Health, and Technological Problem Solving. Princeton, NJ: Princeton UP, 1999

Moore, P. G. The Business of Risk. Cambridge [Cambridgeshire: Cambridge UP, 1983.

Morgan, M. Granger. Risk Communication: A Mental Models Approach. 2002

Rowe, William D. An Anatomy of Risk. New York: Wiley, 1977.

Wilson, Richard, and Edmund A. C. Crouch. Risk-benefit Analysis. Cambridge, MA: Harvard Center for Risk Analysis, 2001.

Yoe, Charles E. Primer on Risk Analysis: Decision Making under Uncertainty. Boca Raton, FL: CRC/Taylor & Francis, 2012. Print.

Business / Enterprise Risk Management

Culp, Christopher L. The Risk Management Process: Business Strategy and Tactics. New York: J. Wiley, 2001.

Fraser, John, and Betty J. Simkins. Enterprise Risk Management: Today's Leading Research and Best Practices for Tomorrow's Executives. Hoboken, NJ: J. Wiley & Sons, 2010.

Hampton, John J. Fundamentals of Enterprise Risk Management: How Top Companies Assess Risk, Manage Exposures, and Seize Opportunities. New York: American Management Association, 2009.

Monahan, Gregory. Enterprise Risk Management: A Methodology for Achieving Strategic Objectives. Hoboken, NJ: John Wiley & Sons, 2008.

Young, Peter C., and Steven C. Tippins. Managing Business Risk: An Organization-wide Approach to Risk Management.  2001.

Project / Program Risk Management

Chicken, John C. Managing Risks and Decisions in Major Projects. 1994.

Conrow, E. H. Effective Risk Management: Some Keys to Success. Reston, 2nd Ed. 2003.

Dorofee, Audrey J. Continuous Risk Management Guidebook.  1996

Operations / Operational Risk Management

van Grinsven, Improving Operational Risk Management. Amsterdam: IOS, 2009.

Banking and Financial Risk Management

Bessis, Joël. Risk Management in Banking. New York: Wiley, 2002.

Greuning, Hennie Van., and Sonja Brajovic. Bratanovic. Analyzing and Managing Banking Risk. Washington D.C.: World Bank, 2009.

van Grinsven, Risk Management in Financial Institutions: Formulating Value Propositions. Amsterdam: Delft UP/IOS, 2010.

Safety and Risk Management

Duffey, R. B., and John Walton Saull. Know the Risk: Learning from Errors and Accidents : Safety and Risk in Today's Technology. Amsterdam: Butterworth-Heinemann, 2003.

Status Your Project with the WBS

The WBS serves as a perfect framework for project status reporting

Your WBS is the list of everything that needs to get done to complete the project.  It’s a ready-made framework for monitoring and statusing the project.

Let’s begin with the basic structure of the WBS:

WBS Code	WBS Description
100	Project Management
200	Product
200.1	Product Requirements
200.1.1	Stakeholder Requirements
200.1.2	System Requirements
200.2	Product Design
200.3	Product Build
200.4	Product Testing
200.5	Product Deployment

If we are going to use this for reporting, we need to include who’s in charge of delivering each WBS Item.  Generally, this can be the Project Manager for that piece of work.

WBS Code	WBS Description	Responsible
100	Project Management	PM
200	Product	n/a
200.1	Product Requirements	n/a
200.1.1	Stakeholder Requirements	Bill F
200.1.2	System Requirements	Jane T
200.2	Product Design	John X
200.3	Product Build	Mary G
200.4	Product Testing	Keith D
200.5	Product Deployment	Sara S

The updated table above shows which manager or lead has responsibility for delivering the work described in each WBS entry.  The items 200 – Product, and 200.1 Product Requirements have no designated responsible person because all the work under them are parcelled out to the work subitems under them.

Now we need to update the table to show the status.

WBS Code	WBS Description	Responsible	Status
100	Project Management	PM	n/a
200	Product	n/a	Started
200.1	Product Requirements	n/a	Started
200.1.1	Stakeholder Requirements	Bill F	Completed
200.1.2	System Requirements	Jane T	70%
200.2	Product Design	John X	NYS
200.3	Product Build	Mary G	NYS
200.4	Product Testing	Keith D	10%
200.5	Product Deployment	Sara S	NYS

In the above update, we see that item 200.1.1 has been completed, 200.1.2 is 70% completed, some of the work are Not Yet Started.  Work 100 – Project Management will have no status because it is ongoing work, while 200 and 200.1 will have only Started at their level. They will become Completed when all the sub-items under them have been completed.

The problem with the above is that it says nothing about whether the project is going according to schedule, going ahead, or being delayed.

For that we can use Earned Values to show the status of the work.

And because the status date of each individual work item may differ, it might be useful to add another column to indicate the as-of status date for that piece of work.

The Project Manager as Disciplinarian

If your project does not have a strong a central organising individual, it will flounder, atrophy, and then collapse.

A project is a collection of talented individuals from many disciplines, individuals with their own agendas and their own visions and their own priorities. This collection falls down into disorganisation without someone providing the structure for the group to act.

Hence it is critical that the project manager be a disciplinarian.  I mean that in the sense that he or she imposes discipline to the group. 

The PM acts as the catalyst that energises the group.  The PM articulates the single vision of the project, makes everyone turn their heads toward that vision, and makes them march together toward that vision.

The PM must be forceful, not necessarily in the sense of overbearing or overpowering but in the sense of being the force that pushes the project forward day by day, prevailing over forces that will tend to rend the group apart into many directions, and keeps it – herds it - aimed in the right direction.

Writing Potent Copy

I borrowed this post’s title from David Ogilvy, arguably the most famous advertising professional. Many professional people who are not in the advertising profession have heard of him, and as a testament to his ability to promote, a lot of these people would find it difficult to come up with another name associated with advertising (I can’t, off the top of my head).

Ogilvy was a great believer in research and in using the knowledge gained from   research to develop successful advertisements. To him, advertising had only one purpose – to get people to buy the product. He claims to have little patience for ‘artistry’, ‘creativity’, ‘novelty’, all of which he considers an exercise in self-amusement by the advertiser at the expense (financially and otherwise) of their client. Sales was of paramount importance.

In the chapter ‘How to Write Potent Copy’ from his book, ‘Confessions of an Advertising Man’, he gives some advice about how to make your copy more memorable. I’ve picked out below some of the most reusable ideas.

The Headline

Advertisements without a headline is an absolute no-no. He calls it ‘the wickedest of all sins’. The reason? Most people read only the headline. If you don’t have one, you automatically give up your chance of hooking your readers. The headline is your tool for grabbing hold of your reader they scan the pages.

Know who it is you are writing for (which is never EVERYONE; it is always a subset of the readership), and use the words that address what they are looking for. His example: if you are selling a product for people with bladder weakness problems, use ‘BLADDER WEAKNESS’ in your headline.

But be careful not to exclude a good number of the people who are not your target. If your product is targeted for senior people with bladder weakness, don’t write headlines addressed to females only. Why risk alienating male readers with bladder weakness?

Always include the brand name in the headline, because most people read only the headline. If that’s all they will read, make sure the product name makes it way into their head. How many times have I seen witty slogans like the one from a moving company: ‘You will be moved by our service’. I remember the slogan, but do not know what their company name is.

The headline should invite the reader to read the body of the advertisement. Make them curious. Make them want to read on. But since you do not have any assurance you’ll succeed in pulling the reader in, make sure the headline stands on its own. It must make sense even without reading the body of the advertisement.

The Body

His advice with regard to the body of the advertisement is simpler less wide ranging. First, be specific and be factual. Avoid superlatives, generalisations, platitudes. Especially in these times when people are swamped in information. Just tell the truth, but make it fascinating (his words).

Testimonials are your best friend. Use them when you can. Ogilvy wrote these words in the early 1960s and notice how prescient they are. How many times do you look for testimonials before buying a product (testimonials and reviews from strangers on the internet!)

Give helpful advice the reader can use. Readers appreciate this.

Write plainly and avoid the temptation to produce ‘literature’. Use simple words so that you don’t fail to communicate what you want to say to the reader. Ogilvy says he once used the word ‘obsolete’ only to discover later that many of his target readers did not know what that word meant.

Transferable Advice?

Is his advice transferable? Many of us are not in the advertising business, but we are all in the sales business. Can you use his insights in the forms of communication you use? I believe so, and I certainly will try.

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.

People all the way

Working with people is already hard enough, with all their individual quirks, moods, emotions, hidden motives, competencies (or lack thereof), fears, ambitions, etc. 

What makes it doubly, triply, frustratingly hard sometimes is that we are working with people who themselves have to work with people, and who in turn have to work with people.  It’s people all the way down.

Scrum Fundamentals – Iteration, Sprints, and Feedback

I said in the previous post that one of the biggest problems brought about by a waterfall approach is the lack of feedback.  The future users of the software get to see the software only when it is finished, when the opportunity to provide valuable corrections and suggestions are practically over.

Not only is it too  late (or too expensive) to modify the program, the software is often actually unusable.  Scrum directly addresses these problems by mandating that software must be developed iteratively, in iterations, and the at the end of each iteration, the software must be demonstrated to the stakeholders to get their feedback. 

Scrum calls its iterations Sprints.  Scrum recommends that Sprints be between 2 to 4 weeks.  Whatever duration you choose, all the Sprint must be always the same duration.  If you go for 2 weeks, then all the Sprints must each be 2 weeks. 

This is in the ideal case of course, in practice a Scrum team that is just beginning to learn the ropes can choose a tentative duration to try out (say 2 weeks).  If the team finds that 2 weeks is too short, they are free to adjust it (and all future Sprints).  If they find that it suits them, they stick to it.

The key thing is to establish Sprints as a regular occurrence, like a heartbeat.  Sprints of different lengths are like arrhythmia, with all the unpleasantness it brings.

The completion of each Sprint produces a finished subset of the product.  The ideal is to deliver a working subset, preferably something that can be shipped.  In practice this is not so easy to achieve, for some functions rely on other functions which may not fit in the current Sprint. 

For example, an online store may include such functions as allowing the customer to search for products, order products, apply discounts, and have them shipped to an address of their choosing.   Very often all of these functions cannot be built within a single Sprint. So which ones to build in order to product a shippable subset?

The Scrum team (together with the Product Owner) decides which functions to build in order to deliver working software.  One such option could be to simply include only the search for products function.  So at the end of the Sprint you end up with software that searches for products, and does nothing else.  That is an acceptable choice.

It is far better than deciding to build all the user interfaces for all the above functions, but not have them work.  If you do this, what you get at the end of the Sprint is not working software, rather, you end up with a glorified series of screenshots.

Back to feedback.  At the end of each Sprint is a Demo of what was built.  The Scrum teams demonstrates the current product so that the Product Owner (and other stakeholders) can review it and give their feedback.   Is this what was envisioned?   If it was, was it what you wanted?  Very often, once we see the the incarnation of what we said we wanted, we come to the realisation that that is not really what we wanted.

The purpose of the Demo is NOT to show the Product Owner that the Scrum Team is working hard.  No.  The purpose is only feedback regarding the product.  (There is a time when evaluation of the Scrum Team occurs, but this is not that time, and I will talk about it later).

If there is one thing that feedback causes, it is change.  You can be sure that the feedback will result in changes, changes to what the software will do, and changes to what it is currently doing.

So what do we do with the changes?  I’ll talk about that in the next post.

Scrum Fundamentals – Iterations, Sprints, and Feedback

I said in the previous post that one of the biggest problems brought about by a waterfall approach is the lack of feedback.  The future users of the software get to see the software only when it is finished, when the opportunity to provide valuable corrections and suggestions are practically over.

Not only is it too  late (or too expensive) to modify the program by then, the resulting software is sometimes not only bad, but even unusable. 

Scrum directly addresses these problems by mandating that software must be developed iteratively, in iterations, and the at the end of each iteration, the software must be demonstrated to the stakeholders to get their feedback. 

Scrum calls its iterations Sprints.  Scrum recommends that Sprints be between 2 to 4 weeks.  Whatever duration you choose, all the Sprint must be always the same duration.  If you go for 2 weeks, then all the Sprints must each be 2 weeks. 

This is in the ideal case of course. In practice a Scrum team that is just beginning to learn the ropes can choose a tentative duration to try out (say 2 weeks).  If the team finds that 2 weeks is too short, they are free to adjust it (and all future Sprints).  If they find that it suits them, they stick to it.

The key thing is to establish Sprints as a regular occurrence, like a heartbeat.  Sprints of different lengths are like arrhythmia, with all the unpleasantness it brings.

The completion of each Sprint produces a finished subset of the product.  The ideal is to deliver a working subset, preferably something that can be shipped.  In practice this is not so easy to achieve, for some functions rely on other functions which may not fit in the current Sprint. 

For example, an online store may include such functions as allowing the customer to search for products, order products, apply discounts, and have them shipped to an address of their choosing.   Very often all of these functions cannot be built within a single Sprint. So which ones to build in order to product a shippable subset?

The Scrum team (together with the Product Owner) decides which functions to build in order to deliver working software.  One such option could be to simply include only the search for products function.  So at the end of the Sprint you end up with software that searches for products, and does nothing else.  That is an acceptable choice.

It is far better than deciding to build all the user interfaces for all the above functions, but not have them work.  If you do this, what you get at the end of the Sprint is not working software, rather, you end up with a glorified series of screenshots.

Back to feedback.  At the end of each Sprint is a Demo of what was built.  The Scrum teams demonstrates the current product so that the Product Owner (and other stakeholders) can review it and give their feedback.   Is this what was envisioned?   If it was, was it what you wanted?  Very often, once we see the the incarnation of what we said we wanted, we come to the realisation that that is not really what we wanted.

The purpose of the Demo is absolutely NOT to show the Product Owner that the Scrum Team is working hard.  No.  The purpose is only feedback regarding the product.  (There is a time when evaluation of the Scrum Team occurs, but this is not that time, and I will talk about it later).

If there is one thing that feedback causes, it is change.  You can be sure that the feedback will result in changes, changes to what the software will do, and changes to what it is currently doing.

So what do we do with the changes?  I’ll talk about that in the next post.