Definition, selection and implementation of software systems to support business operations is a complex topic.  However, there are a number of core principles that we  have found can usefully be highlighted in short discussion.

 

In this first edition of the Kilcreggan newsletter we focus  on Requirements as the critical step to ensure the best possible return on what is typically a significant investment. 

 

We describe software that enables an organization to meet its goals as effective.  At first glance "effective" may seem like a modest descriptor for such software.  However, the dictionary definition is: producing the desired result.

 

Kilcreggan's experience with projects large and small is that the methods chosen for defining and selecting (or developing) software have a bearing on the effectiveness of the software.  We will be citing examples, both good and not so good. 

 

The discussions that follow are intentionally generalized so that they can be  applied equally to the selection of new software systems and to modifications to existing systems.

Everyone knows to start at the beginning.  The question is: what constitutes a good beginning?

 

The most important first step - the indispensable step - is to identify the business rationale for the project in business terms.  This is what we mean by a Business Requirement. 

 

Following are  some hypothetical examples of Business Requirement statements for you to consider:

(1) pilot experiments have demonstrated that the company will save between $X and $Y million by switching all customer order entry to self service

(2) the new system must allow for customer self-service

(3) the shipping department needs to be able to handle twice the current number of shipments within 6 months

 

You may want to think about the similarities and differences in these examples.  We will discuss further in next month's newsletter. 

 

 

 

This is one of the questions that we get asked frequently: how do we know that we have a firm foundation for proceeding?

 

The Business Requirements  (see examples above) constitute the frame of reference for the project: the final measurement of what is to be delivered.

 

But how do we know that they are the correct what's?

 

The best way to answer this is to test each element of a Requirement that is put forward by asking the simple question: Why?

 

If the answer to Why? is "so-and-so said so" the question must be put to so-and-so (possibly to multiple so-and-so's) until a definitive, non-personal statement (such as the prototypical examples in the previous section) can be formulated.  In one form or another such statements will be found to trace back to basic business objectives and strategy. 

 

See the following section for an example of how the underlying rationale for a project was taken for granted.

 

[A few details of the situation described below have been modified for purposes of illustration. - Ed.]

 

A distribution company handling specialty products needed to recreate the functionality of a stand-alone software application within the framework of the company's  overall business control system (ERP***). 

 

The starting  point for the project was a document that contained a general description of the business activities that relied on the existing application (this person/department does this, the other person/department does that, these kinds of information are collected, etc.).  A statement of Requirements was not created in any form.

 

A business analyst/project manager unfamiliar with this part of the business was assigned after the budget was agreed on and immediately found herself faced with several tasks concurrently:

(1) understand the current operational rules, terminology and data

(2) try to deduce the real business requirements in order to provide a coherent frame of reference that could help decide whether certain functions highly desired by the operations groups affected truly fell within the scope of the project

(4) stay within budget

 

In such circumstances there are several possible outcomes.  We will review these, together with what actually happened, in the next edition of the newsletter.

 

***ERP: enterprise resource planning systems provide integrated functionality for all aspects of business operations (engineering, purchasing, customer service, finance, etc.)

 

A major purpose of a clear statement of Requirements is to provide focus, and particularly to help control both the scope of the overall project and - as pointed out in the previous section - rationalize difficult design questions.

 

So, one suggestion is to visualize Requirements as a fortress, with thick walls, surrounded by a bottomless moat.  The Design process is analogous to the barbarians at the gate, trying to tear the fortress down and impose its will on the inhabitants.

 

If your Requirements are strong and well protected then the forces of Design will be  less likely to wear them down.

 

The most likely source of project creep is additional features incorporated at the technical requirements or design stages.  The more specific the Requirements, the better the chances of retaining the intended scope of the project.

 

Our purpose is to provide information that is both useful and thought provoking.  At the same time we strive to follow the advice of the clergyman's wife who, when she learned that her husband was starting to write his weekly sermon, commented, "Keep it short, dear".

 

We will be following up on the ideas from this newsletter in future editions.

 

In the meantime we invite you to visit our web site.  We welcome your feedback.