Planning an IT project is a daunting task
for most people. The most common mistake nontechnical business people make is
to believe that in order to have a successful outcome, they must become “geeks”
in order to be able to communicate with the IT professionals who will be
working on the project. In reality, the person who thoroughly understands the
business is the most valuable resource a technical professional can have.
The Business Plan
The business plan is the most critical
document for any entrepreneur to write. The goal of the business plan is to
create and organize the business in the entrepreneur’s mind. It establishes the
founding principles and processes under which the business will operate, and it
will highlight any areas that need to be further developed or clarified before
the business opens.
All computer systems are simply models of
reality. A well-written business plan creates a model that can be used to
develop a computer model of the business, and thus automate many of the
functions described in the business plan.
The same concept holds true for an
established business. If a new process needs to be automated, the first thing
the businessperson should do is to write a formal business plan describing the
process in as much detail as possible. This document becomes the foundation the
IT workers will use to develop a project plan.
Who,
What, How, Why & When
No business operates in a vacuum. Everything
a business does involves some action begin performed on some entity or object.
Every business process follows rules regarding how the transaction should be
handled. All of these things fall into one of four categories: Entity, Object,
Process, and Business Rule.
An Entity is the “who” of the
business. Do not fall into the trap of thinking that an entity must be a living
breathing person. An Entity is anything that performs an action or responds to
a changing condition, so entities could be people, or computer programs.
Objects are
passive “what” items in a business. They are subject to the actions of
Entities, and have no capability to take action. An object could be a physical
piece of merchandise, a collection of data, or a report generated in response
to a database query.
Processes are the action words that
describe “How” work gets done. Processes should be constructed as
Entity-Action-Object statements. The actual style and verbiage can be what ever
provides the greatest clarity.
Business Rules control “Why” and “When” things happen. A business rule is the
underlying reason(s) that a process is performed in a particular order, at a
particular time, or to justify the statement, “That’s just the way things are
done around here”.
Business Rules are often the result of
legal or social constraints, and in some cases create inefficiencies in
computer systems. Process descriptions should include all business rules that
could affect the logical flow of the process.
A business rule could be used to specify
actions to be taken in response to a predefined condition.
Example: A company divides its sales force
by geographic divisions based on Zip Codes. The business rule states that all
online sales inquiries and orders must be approved by the sales manager assigned
to the division in charge of the customer’s Zip Code.
The process description would look like
this:
“When a new online Order is received, the
System must use the customer’s Zip Code to find the Sales Manager for the
customer’s Division, and send the Sales Manager an Email to notify him of the
new Order.”
This process description contains all of
the elements described above.
Entities (Who is involved)
- System
- Sales Manager
- Customer
Objects (What is involved)
Business Rule (When & why)
- The company divides sales responsibilities into geographic
division based on Zip Code.
- When a new online order is received…
Using this classification style in a
business plan greatly facilitates the task of describing the business model for
both the business manager and the IT workers who will develop the computer
systems necessary to run the business.
Building Relationships
Now that the business plan has been
completed, the businessperson can turn to the task of describing the data that
is required to run the business. This is not as difficult as it sounds since
all of the Entities have already been described in the business plan.
Many people confuse the terms “data” and
“information”. Simply put, data is a fact taken out of context, and information
is a collection of facts presented in a specific context.
Example:
February 24, 2003 is a piece of data.
Without a context, it remains relatively useless. If a second piece of data,
“Contract Expiration Date”, is added to it, the original data takes on context
and becomes information albeit, still of limited usefulness.
All entities and objects can be described
using a collection of data. Many processes also generate data that can be
stored and recalled. The business plan should contain a list of all of the
types of data that must be collected about each Entity, Object, or Process.
The next step in the planning process is to
turn all of these disparate pieces of information into a coherent whole through
the use of “relationships”.
Modern databases store data in “tables”, so
that each table describes a type of entity or object. A table consists of
columns and rows.
Columns define the type of data being
stored.
Example: ID,
First_Name, Last_Name, Email_Address
Data about each specific entity or object
is stored as a “row” in the table.
Example: 101,
John, Smith, Jsmith@Acme.com
To facilitate data access, each record
contains a unique identifier called a “Primary Key” value. The key value allows
the system to locate a specific record in the table, and it also allows the
designer to create relationships between tables.
Example:
Customer Table
101, John,
Smith, Jsmith@Acme.com
In the above example, “101” is the Primary
Key of the Customer table.
To create a relationship between two
tables, the Primary Key from one table must be included in each record in the
second table. When a Primary Key from one table is included in a second table,
it is called the “Foreign Key”.
Example:
Customer Table
101, John, Smith,
Jsmith@Acme.com
Order Table
10, 101, Blue
Jeans, 44x32, 2, 24.99, 04/01/2004
11, 101,
T-shirt, XXL, 1, 8.99, 05/01/2004
In the above example, “101” is the Primary
Key of the Customer table, and 10 is the Primary Key of the Order table. By
including the Customer Table Primary Key in the Order Table, “101” becomes the
Foreign Key in the Order table. This has created a relationship between the
Customer Entity and the Order Object.
By creating relationships in this way, the
system can locate information about all entities and objects in the
relationship.
Example:
If the user needs to know the Ship
To address for the customer who placed Order #10, the system can use the
foreign key “101” to look up John Smith in the Customer table.
If the user
needs information about all of the products John Smith has ordered from the
firm, the foreign key allows the system to quickly retrieve the data on Orders
#10 and #11.
Relationships are also subject to hierarchy
rules. If an object cannot exist without at least one other object, then the
objects are said to be dependent on each other. The nature of the dependency is
determined by deciding which object must exist before the other object can be
created.
In the above examples, the Customer entity
had to exist before the Order object could be created, so the Customer is
considered to be the “parent” of the Order, and the Order is called the “child”
of the Customer.
Another aspect of relationships is the
number of one thing that can be related to another. Three types of numeric
relationships exist, “One-to-Many”, “Many-to-One”, and “Many-to-Many”.
In a One-to-Many relationship, also written
as (1:N), one object is related to multiple objects in another table. Example:
A customer can place an infinite number of orders, so the Customer has a
One-to-Many relationship to Orders.
Many-to-One relationships, also written as
(N:1), exist when multiple objects are related to a single object in another
table. Example: When multiple attendees register for the same seminar, they
have a Many-to-One relationship to the seminar.
Many-to-Many, also written as (M:N), are
created when multiple items can all be related to some none or all of the
things in another table. Example: People purchasing season tickets to a
sporting event would have a Many-to-Many relationship to the games in a given
season.
Once again, business rules enter the
picture. All relationships can be defined using business rules. Defining the
rules for relationships often uncovers additional process rules that were
missed earlier.
Example:
Customers can place multiple
Orders. Customer (1:N) Order
Orders can contain multiple
Products. Order (1:N) Product
Orders can be shipped to multiple
Addresses. *
*This creates a new relationship:
Customer (1:N) Ship_To Address. It also creates two new processes:
1) “Customer must enter his
shipping address is different than his credit card billing address.”
2) “Shipping Clerk must verify the
Ship To address for each Order.”
At this
point the planner must insure that the new processes are added to the
corresponding process descriptions.
Never be
afraid to admit you don’t know how a process or relationship should be handled.
Concentrate on documenting the entities, objects, processes, and most
importantly, business rules to the best of your ability. Make notes and insert
questions where necessary. A good IT team will be able to offer suggestions on
how to handle any gray areas.
Summary
No special skills are required for the
businessperson to develop a successful IT project plan. The only thing that is
required is a thorough knowledge of the business model and the rules governing
that model. Once these concepts have been converted into a written business
plan, the plan can be presented to an internal IT department or published as an
RFP for bid by IT outsourcing companies.
