Environmental aspects are defined as any activity, product, process or service in your business that interacts with the environment. Typically, we think of these as having negative impacts on air, land or water but in some cases it could be positive. Every business today needs to have a systematic approach to identifying aspects and determining those that have significant impacts on the environment.
When implementing the ISO 14001 Environmental Management System an organization is required to have a process documented for identifying aspects (4.3.1, ISO 14001:1996). Remember, we are dealing with any aspect of our products, processes or services that can interact with the environment.
The steps to identifying them include:
1. Have a team of knowledgeable people review each process, product or service for potential interaction with the environment. (Don't forget utilities and maintenance.)
2. Draw a box diagram or flow chart of your processes and identify where interactions with air, land or water can or do take place.
3. Walk around the facility looking for potential interactions with the environment.
4. Record these in a logical and simple manner, for example a spreadsheet will work in most cases.
5. Review these with the team and then move on to the next phase of determining significance.
6. Document your process for identifying aspects in a controlled procedure.
When investigating all areas of your business, be sure to consider maintenance processes and equipment as well as your manufacturing systems. In some businesses, such as an on-site repair service clean-up and waste disposal may be significant.
In any case, be thorough and pay attention to all areas of the business. After you have identified the aspects, determining those that are significant becomes a priority. Establish a quantifiable methodology, if practical. This will enable you to focus efforts on minimizing the impacts associated with the significant interactions with the environment.
Davis M. Woodruff, PE, CMC is an internationally recognized consultant, professional speaker and author who is an expert in showing companies how to be the low cost, high quality, environmentally responsible leader in their industry. The benefits he brings to his clients include: developing leaders; optimizing resource utilization; improving processes, quality and customer satisfaction; and saving time and $$$. Since 1984 he has served clients in 35 states and on 3 continents. Davis is the author of a full length book Taking Care of the Basics: 101 Success Factors for Managers, and dozens of published articles. He is a 1972 Engineering graduate of Auburn University, a Certified Management Consultant (CMC) and Professional Engineer (PE). His consulting firm, Management Methods based in Decatur, AL, is now in its third decade. Davis can be reached at davisw@managementmethods.com or for more information visit http://www.daviswoodruff.com
Article Source: http://EzineArticles.com/?expert=Davis_Woodruff
Friday, October 29, 2010
Thursday, October 21, 2010
Understanding Attributes in E-R Diagrams
An attribute is a property or descriptor of an entity, for example, Customer Name is an attribute of the entity Customer. Each attribute will eventually be represented by one or more entity attributes in the physical database structure.
Attributes Define Entities
Collectively, attributes define an entity. An attribute is meaningless by itself. For example, date of birth comes from the context of the entity to which it is assigned, for example, date of birth of an employee.
Attributes are not shown on the Entity-Relationship Model but are recorded in the underlying data dictionary which contains the definitions of attributes for all entities and relationships identified in the model. An attribute should not have facts recorded about it. In practice, however, there are exceptions. For example, you might wish to show address as an attribute of Customer. Address is not significant enough to be modelled as an entity in its own right and would typically be shown as an attribute of Customer. However, at the detailed level, it may itself have attributes such as an indicator for mailing address or home address.
Attributes do not have to be recognized and defined during the early stages of entity definition. Entity definition is an iterative process, and it is unlikely that a completely satisfactory Entity-Relationship Model will be obtained on the first iteration.
Identifying Attributes
To identify entity attributes, examine:
· all external entities from the Context Diagram,
· the data flows passed by the external entities,
· existing automated data,
· each entity (i.e., generate a list of entity attributes that describe the entity).
Attributes Versus Data Elements
Attributes have a looser description than data elements. For instance, whereas an attribute may have only a descriptive name, a data element needs:
· a size and range,
· a format and length,
· an accurate and detailed description,
· valid values,
· defined edit rules.
Some attributes may be converted into many data elements. For instance, the attribute "address" may become four data elements representing:
· Street Address,
· City/Town,
· State/Province,
· Postal or Zip Code.
Additional data elements may also be defined as a result of customer requirements. For example, the customer may require a list of all companies by county.
For the purposes of Data Modelling, attributes and data elements are often considered identical because attributes in the data model typically become data elements in the database.
CANDIDATE KEYS
Description
A candidate key is a set of one or more attributes which uniquely distinguishes each instance of an entity. For example, a candidate key for Employee may be Employee ID, candidate keys for Budget may be Budget Year, Budget ID, or Effective Date.
Primary Key Identifier
The primary key of an entity unambiguously distinguishes between occurrences of the entity. It is a unique identifier comprised of one or more attributes of the entity. Each occurrence of an entity has one value for its primary key. Select the primary key from the list of candidate keys.
Each entity must be assigned a primary key. An entity can have only one primary key.
Foreign Key Identifier
Foreign keys (also known as referential attributes) are attributes that define relationships between entities. The attributes of a foreign key in one entity are the attributes of a primary key in another entity. For example, Department ID is the primary key of Department and Department ID is a foreign key of Employee defining the relationship "Employee works for Department."
CATEGORIES OF ATTRIBUTES
Attributes fall into three categories depending on the information that the attribute captures:
· Descriptive attributes provide facts intrinsic to each instance of the entity. For example, the Salary of Employee or the Address of Customer.
· Naming attributes provide facts about arbitrary labels and names carried by each instance of an entity. For example, the Employee Name of Employee or the Employee ID of Employee.
· Referential attributes (i.e., foreign keys) provide facts which tie an instance of one entity to an instance of another entity. For example, the Department Number of the Department to which an Employee is assigned ties the Employee to the Department.
ATTRIBUTE DOMAINS
A domain is a set of values for an attribute (i.e., the properties or characteristics of entities). The value set conforms to a common definition for the domain (e.g., type, format, syntax, meaning).
Specify domains in one of the following ways:
· List all possible values (e.g., for an attribute named color, possible values are red, green, blue).
· Identify a source (e.g., procedures manual) that contains the valid values.
· List an acceptable range of values for the domain (e.g., for an attribute named weight, possible values range from one to five pounds).
· Define a business rule that permits determination of the validity of a value assigned to an attribute (e.g., discounts greater than five percent only apply to commercial customers).
DERIVED ATTRIBUTES
Derived attributes are attributes whose values are generated from other attributes using calculations, algorithms or procedures. For example, Account Balance is derived by subtracting Total Debit from Total Credit.
Generally, the specifications for calculating derived attributes are a concern of the processing aspects of the information system (e.g., process model). Derived attributes may be included in the data model if the rules for calculating the attribute values would otherwise be lost.
Clearly indicate in the data model when an attribute is derived. Ensure that the rules needed to derive or calculate the attribute value are captured in the model. Verify that all attributes needed to calculate the derived attribute are present in the data model.
Once the physical data model is constructed, some derived attributes are added to the model to improve performance of the system.
Attributes Define Entities
Collectively, attributes define an entity. An attribute is meaningless by itself. For example, date of birth comes from the context of the entity to which it is assigned, for example, date of birth of an employee.
Attributes are not shown on the Entity-Relationship Model but are recorded in the underlying data dictionary which contains the definitions of attributes for all entities and relationships identified in the model. An attribute should not have facts recorded about it. In practice, however, there are exceptions. For example, you might wish to show address as an attribute of Customer. Address is not significant enough to be modelled as an entity in its own right and would typically be shown as an attribute of Customer. However, at the detailed level, it may itself have attributes such as an indicator for mailing address or home address.
Attributes do not have to be recognized and defined during the early stages of entity definition. Entity definition is an iterative process, and it is unlikely that a completely satisfactory Entity-Relationship Model will be obtained on the first iteration.
Identifying Attributes
To identify entity attributes, examine:
· all external entities from the Context Diagram,
· the data flows passed by the external entities,
· existing automated data,
· each entity (i.e., generate a list of entity attributes that describe the entity).
Attributes Versus Data Elements
Attributes have a looser description than data elements. For instance, whereas an attribute may have only a descriptive name, a data element needs:
· a size and range,
· a format and length,
· an accurate and detailed description,
· valid values,
· defined edit rules.
Some attributes may be converted into many data elements. For instance, the attribute "address" may become four data elements representing:
· Street Address,
· City/Town,
· State/Province,
· Postal or Zip Code.
Additional data elements may also be defined as a result of customer requirements. For example, the customer may require a list of all companies by county.
For the purposes of Data Modelling, attributes and data elements are often considered identical because attributes in the data model typically become data elements in the database.
CANDIDATE KEYS
Description
A candidate key is a set of one or more attributes which uniquely distinguishes each instance of an entity. For example, a candidate key for Employee may be Employee ID, candidate keys for Budget may be Budget Year, Budget ID, or Effective Date.
Primary Key Identifier
The primary key of an entity unambiguously distinguishes between occurrences of the entity. It is a unique identifier comprised of one or more attributes of the entity. Each occurrence of an entity has one value for its primary key. Select the primary key from the list of candidate keys.
Each entity must be assigned a primary key. An entity can have only one primary key.
Foreign Key Identifier
Foreign keys (also known as referential attributes) are attributes that define relationships between entities. The attributes of a foreign key in one entity are the attributes of a primary key in another entity. For example, Department ID is the primary key of Department and Department ID is a foreign key of Employee defining the relationship "Employee works for Department."
CATEGORIES OF ATTRIBUTES
Attributes fall into three categories depending on the information that the attribute captures:
· Descriptive attributes provide facts intrinsic to each instance of the entity. For example, the Salary of Employee or the Address of Customer.
· Naming attributes provide facts about arbitrary labels and names carried by each instance of an entity. For example, the Employee Name of Employee or the Employee ID of Employee.
· Referential attributes (i.e., foreign keys) provide facts which tie an instance of one entity to an instance of another entity. For example, the Department Number of the Department to which an Employee is assigned ties the Employee to the Department.
ATTRIBUTE DOMAINS
A domain is a set of values for an attribute (i.e., the properties or characteristics of entities). The value set conforms to a common definition for the domain (e.g., type, format, syntax, meaning).
Specify domains in one of the following ways:
· List all possible values (e.g., for an attribute named color, possible values are red, green, blue).
· Identify a source (e.g., procedures manual) that contains the valid values.
· List an acceptable range of values for the domain (e.g., for an attribute named weight, possible values range from one to five pounds).
· Define a business rule that permits determination of the validity of a value assigned to an attribute (e.g., discounts greater than five percent only apply to commercial customers).
DERIVED ATTRIBUTES
Derived attributes are attributes whose values are generated from other attributes using calculations, algorithms or procedures. For example, Account Balance is derived by subtracting Total Debit from Total Credit.
Generally, the specifications for calculating derived attributes are a concern of the processing aspects of the information system (e.g., process model). Derived attributes may be included in the data model if the rules for calculating the attribute values would otherwise be lost.
Clearly indicate in the data model when an attribute is derived. Ensure that the rules needed to derive or calculate the attribute value are captured in the model. Verify that all attributes needed to calculate the derived attribute are present in the data model.
Once the physical data model is constructed, some derived attributes are added to the model to improve performance of the system.
Tuesday, October 12, 2010
Tuesday, October 5, 2010
What are Entity Relationship Diagrams?
Entity Relationship Diagrams (ERDs) illustrate the logical structure of databases.
An ER Diagram
Entity Relationship Diagram Notations
Peter Chen developed ERDs in 1976. Since then Charles Bachman and James Martin have added some sligh refinements to the basic ERD principles.
Entity
An entity is an object or concept about which you want to store information.
Weak Entity
A weak entity is an entity that must defined by a foreign key relationship with another entity as it cannot be uniquely identified by its own attributes alone.
Key attribute
A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee's social security number might be the employee's key attribute.
Multivalued attribute
A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values.
Derived attribute
A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the employee's annual salary.
Relationships
Relationships illustrate how two entities share information in the database structure.
Cardinality
Cardinality specifies how many instances of an entity relate to one instance of another entity.Ordinality is also closely linked to cardinality. While cardinality specifies the occurences of a relationship, ordinality describes the relationship as either mandatory or optional. In other words, cardinality specifies the maximum number of relationships and ordinality specifies the absolute minimum number of relationships.
Recursive relationship
In some cases, entities can be self-linked. For example, employees can supervise other employees.
Monday, October 4, 2010
Parkinson's Law in I.T.
Tim Bryce
INTRODUCTIONEver wonder why our computers typically last no more than three years? Many contend it is because of the fast pace of technological advancements. Maybe. But I tend to believe there is a little more to it than just that, namely "Parkinson's Law." For those of you who may have forgotten, "Parkinson's Law" was devised by C. Northcote Parkinson, noted British historian and author. His original book, "Parkinson's Law: The Pursuit of Progress," was introduced in 1958 and was a top-selling management book for a number of years (it is still sold today). The book was based on his experience with the British Civil Service. Among his key observation's was that "work expands so as to fill the time available for its completion." Basically, he suggests that people make work in order to rationalize their employment. Consequently, managers create bureaucracies and superfluous work to justify their existence, not because it is really needed.
As an aside, CEO's clearly understood Parkinson's Law, which became the driving force behind the flattening of corporations in the 1990's, such as General Electric under Jack Welch's reign.
Whereas Parkinson was primarily concerned with people, his law is equally applicable to machines, particularly computers; for example, Parkinson's Law can be applied to computing in terms of "Data expands to fill the space available for storage." Years ago I had a Compaq Presario computer with 50mb of disk space, which I considered substantial at the time. I never dreamt I would be able to fill up the hard drive. But, of course, I did (as well as other PC's I have had over the years). My current PC has a hard drive with a capacity of 224gb and though I'm a long way from filling it up, inevitably I know I will for two reasons: I now feel more comfortable with downloading large multimedia files (MP3, AVI, WMV, etc.), PDF files, data base files, and other larger file formats, and; Second, because developers have become sloppy in programming.
Back when memory and disk space were at a premium, there was great concern over the efficient use of computer resources. Program code was written very tightly and consideration was given to file size. For example, establishing a simple file index was scrutinized carefully. But as the computer capacity grew and hardware prices declined, developers became less interested in efficient programming. To illustrate, not too long ago packaged software installation programs were delivered on 3.5" diskettes. Today, it is not uncommon to use multiple CD's to install the same products. This means that as computer hardware capacity increases, software becomes more bloated. This is but one example of Parkinson's Law as applied in computing.
An another example, let's consider data transmission lines as used in networking. It doesn't seem long ago we were using 14.4 baud modems over telephone lines. I remember when we doubled the speed to 28.8 and then 56.4. It seemed like the sky was the limit with every increase. But eventually performance seemed to slow to a crawl. Was it because the technology was aging or was it because our web pages were becoming bigger and more complicated requiring greater data volume over the lines? Frankly, it was the latter. Today, DSL and cable are commonplace in households as well as in business and "dial-up" is rapidly becoming a thing of the past. But as data volume increases with the number of subscribers, will we ever hit a wall in terms of capacity with DSL and cable? Undoubtedly. Again, more due to Parkinson's Law then anything else.
Make no mistake, computer hardware and software vendors are acutely aware of the role of Parkinson's Law. It is what allows them to build-in planned obsolescence into their products. As consumers reach capacity, they can either add additional capacity or, more likely, purchase new computers.
There is undoubtedly an incestuous relationship between hardware and software vendors. Hardware enhancements are primarily implemented to increase capacity in order to overcome software inefficiencies, and software vendors make their products more bloated as hardware enhancements are introduced. To illustrate the point, is it a coincidence that every major release of Windows requires additional hardware support? Hardly. This is done more by design than by accident.
CONCLUSION
Parkinson's Law is just as much a part of computer technology as it is in the corporate world. But what would happen if we decided to "flatten" computer technology in the same manner that Jack Welch flattened G.E.? Keep in mind, Welch did so to eliminate bureaucracy and force his workers to become more efficient and focus on the true problems at hand. By flattening the "bloatware" we would probably get a lot more mileage out of our computers. But I guess that wouldn't be good for selling computers (or the economy).
I guess Parkinson's Law and the vicious circle of computing will be with us for quite some time.
Four Ways to Transfer Risk
As a project manager, it is important for you to understand that the act of sharing can play a valuable role in your project's risk response planning process. Sometimes, the most efficient and effective way of dealing with project risks is to share the responsibility for their response with others.
Transference is a risk response strategy that does just that. It shifts the responsibility of a risk, or part of a risk, to a third party. Transference does not eliminate a risk or its potential consequences. This risk response strategy simply gives another party responsibility for the management of that risk.
Although a project will encounter many different types of risks, transferring risk liability is usually most effective when dealing with financial risk exposure.
Transference often involves the payment of a risk premium to the party taking on the risk. For example, a company will pay a monthly premium to its insurance provider as payment for the provider taking on one or more of the project's risks.
During your project's risk response planning process, you may decide that transference is the most appropriate strategy to use in order to effectively respond to one of your identified project risks. Once you make this decision, you must choose the transference method that will best address that risk. There are four methods available for you to use when transferring the responsibility for an identified risk.
1. Insurance
Insurance is a transference method that shifts the responsibility of specified risks to an insurance company. Typically, insurance companies provide monetary coverage for losses that result from such things as legal liability, fire damage, theft, or vandalism.
One of the most common methods of transferring risk and its potential consequences is to purchase insurance. As a project manager, you can share the responsibility of some of your project's identified risks by having an insurance company provide financial coverage for potential risk losses. During your project's risk response planning process, you should set aside risks that can be insured and transfer the responsibility for those risks to your company's insurance provider.
Some of the most common insurable project risks are:
* Direct Property Damage - to project equipment, project materials or a contractors' property.
* Indirect Losses - such as equipment replacement and business interruption.
* Legal Liability - such as public employee bodily injury, design errors, public property damage, and the failure of a product to perform as specified.
* Personnel Issues - such as employee replacement costs.
For project managers to transfer a project risk through the method of insurance, two conditions must be met. The first condition is that the potential risk loss must be due to chance. Insurance companies do not want to provide monetary coverage for risks that result from human error or poor project planning.
The second condition that must be met in order for a risk to be eligible for insurance is that the potential risk loss must be measurable. This means that the risk loss must have an assigned monetary value. A project risk cannot be insured if the potential loss is expected to be personal or emotional.
2. Performance bonds
Performance bonds shift the financial responsibility for poor performance back to the contractor. These bonds are usually issued by a financial institution, such as a bank, and force contractors to pay out a specified sum of money if their performance is unacceptable.
Project managers obtain performance bonds to guarantee the satisfactory completion of contracted work. These bonds provide monetary compensation to a company if its contractor fails to achieve the proposed project work.
3. Warranties
Warranties are written guarantees that purchased project equipment will be of good quality. This transference method shifts the cost and responsibility for repair or replacement of defective parts to the manufacturer.
4. Contracts
A contract is a binding and legally enforceable agreement between two or more persons or parties. During risk response planning, project managers can use contracts to help eliminate or minimize the impact of identified project risks.
In most cases, contracts are established between an organization and its contractors at the onset of a project. These contracts contain numerous details and clearly outline the contractor's responsibilities throughout the project. This transference method helps shift the potential cost and consequences of incomplete, tardy, or unsatisfactory work back to the contractor. A contract also protects the contractor, ensuring the company meets its obligations as well. This helps reduce the overall risk impact on the project.
Another benefit of a contract is that you may not have sufficient expert resources within your company to perform all of the various project activities in an efficient and effective manner. Contracting some of your project work out to someone with superior knowledge and expertise in a particular area can reduce the risk of poor performance or unsatisfactory project design.
It is important to keep the four transference methods in mind when formulating responses to your project's identified risks. If your project requires a contractor, it is good to obtain a performance bond to ensure that expected performance levels are maintained. In addition, if your project materials are purchased from an external source, it is wise to have a warranty in place to protect your company against material defect risks.
If you decide to respond to some of your identified risks by purchasing insurance, you will be able to protect your company from costly, unexpected, and unpredictable risks, such as legal liability and personnel injuries. If you choose to establish a contract at the onset of your project, you will reduce the risk of project plan deviations and miscommunication. You must carefully consider each transference method and determine which one will be most effective in minimizing the impact of an identified project risk.
Insurance, performance bonds, warranties, and contracts are the four primary methods for transference. During the risk response planning process, project managers can use transference to help them reduce the impact of potential risks to project objectives and overall project outcomes.
As a project manager, you should examine all of your project's identified risks and set aside those that will benefit from transference. This will minimize your project's overall risk impact and promote a successful project completion.
Defining the Scope in IT Projects
Neville Turbit
Scope vs Time & Cost
When people talk about scope, they immediately think time and cost. Time and cost are outputs of scope. Determining scope is a different exercise. In the context of this white paper, when we talk about defining the scope, we are talking about developing a common understanding as to what is included in, or excluded from, a project. We are not talking about deciding how long it will take, or how much it will cost. That comes after the scope is defined.
If we were looking for a car, we would first define the scope. For example we want a 4-cylinder front wheel drive with seating for 2 adults and 2 children, and less than 2 years old. Maybe you also want it to be a red convertible.
Having defined the scope, you can calculate cost and time. How much you will have to spend and how long you will take to buy it. If you get the scope wrong, the time and cost will be wrong.
Having defined the scope, you can calculate cost and time. How much you will have to spend and how long you will take to buy it. If you get the scope wrong, the time and cost will be wrong.
Why is Scope important?
Anyone who has ever done a project will have tales of how scope changes caused grief. Scope is bound to change, and this is to be expected. As the detail becomes clearer, more complications creep in. These are not foreseeable at the start and hopefully we build in a contingency for what we cannot see.
The scope changes that usually cause problems are those where the perception of what was in and out of scope was different between various parties. The Project Manager assumed there would only be four or five reports, and the business assumed ten to twenty. Nobody felt it was worth talking about because they assumed the other person thought the same way they did.
How Scope is usually defined
Scope definitions often account for a paragraph or two in a Business Case or Project Charter. Often, they are qualitative and/or focus on general statements.
"We will improve service by providing an information system to respond to customer inquiries." Is it a real time system? Is it all screen-based?
What reports can be produced? Where does the information come from? What manipulation is required for the data? Is all the data compatible? Do you want to generate standard letters? How many letters? How customisable are the letters? Do you want to store the questions? Do you want to store the answers? Etc. etc. etc.
Define the Outcome
We will cover several different ways to successfully define scope. All should start with an agreement on the outcome. The outcome is the change that will occur when the project is complete. Examples are:
- We will be able to answer customer queries regarding statements over the phone.
- All licensing details will be accessible on-line and we will be able to identify when they are due.
Assumptions
In order to define the scope, there will be assumptions that need to be made. There is no point in waiting until everything is clear to define scope. By that time, the project will probably be finished. Each of these assumptions should be documented and followed up at a later date to validate the scope. If the assumption is false, it may have an impact on the scope.
Which way to define Scope?
There are numerous ways to define. Ideally several ways should be used. Each looks at the situation from a different perspective and will elicit different information. We look at three main ways in this paper. They are:
- Define Deliverables
- Define Functionality and Data
- Define Technical Structure
Define Deliverables
One method to focus people on the scope, is to define the internal and external deliverables.
- External deliverables are things the project delivers to the users e.g. screens and reports. Users typically think of a system in these terms. It also includes any hardware or software required by the users or the project team.
- Internal deliverables are things the project generates internally e.g. Project Charter, Business Requirement Specification etc.
It is likely that the users will not be absolutely clear on all the deliverables. In this situation you can make generic assumptions. For example, you might not know exactly what reports are required but you allow for 12 unspecified reports.
Once the external deliverables are defined, the Project Manager can define the internal deliverables.
Example External Deliverables:
| Name | Description |
| License Detail Screen. | Screen to enter and view license details |
| Company Summary Screen | Screen to view all licenses issued by a particular company. Facility to drill down to License Detail Screen. |
| License Due Report | Report listing all licenses due in the next period. Facility to select a period e.g. 1 week, 4 weeks, quarter |
| 5 Reports | Allow for 5 unspecified reports |
| Server | Server to run the application |
| Etc. |
Example Internal Deliverables
| Name | Description |
| Project Charter | Document identifying how the project will be managed |
| Business Requirement Specification | Document identifying the requirements for the project |
| Weekly Reports | Status reports to be issued weekly |
| Prototypes x 3 | Three prototypes will be allowed for in the development. |
| Etc. |
Define the Functionality
Another technique is to define the functionality. This should not be either a long or detailed process. Typically, depending on project size, the exercise can be completed in a one hour to half-day workshop. A good technique is to use a functional decomposition. If using a spreadsheet and a projector, a scribe can create the scope as it is discussed. Remember to start all functionality with a verb.It is useful to do the functional decomposition in conjunction with a data definition. If this is not possible, once the scope is discussed, it will become reasonably clear what data is required.
The Project Manager can determine if there are any situations that need to be clarified with the users, and finalise the scope definition. If for example, in defining the functionality it becomes evident that considerable information will need to be transferred from a legacy system, which is known to be inaccurate, data cleansing can be factored into the scope.
Example Functional Decomposition
1.0 Capture License details1.1 Set up companies2.0 Generate payments
1.2 Set up products
1.3 Create licenses
1.4 Modify licenses
1.5 Delete licenses
2.1 Create payment reportEtc.
2.2 Authorise payments
2.3 Notify accounts
It can also be defined as a diagram:
Defining the Data
This approach is similar to functionality, and should be used in conjunction with functionality. The process is likely to capture what users expect to see in a system. The intention is not to make the business users, data modellers. The intention is to get the business users to verbalize their requirements for information in a structured manner. Ask the users what are the people, places and thing they want to keep track of. In this case, the focus is on nouns.This approach will not capture data that may be required to technically make the system work. For example, it will not capture things like transaction log files, archive files, SQL script files etc. Post workshop, the Project Manager will need to sit with a data modeller to sort out what else is required. The hardest part is to stop doing a data model. Keep the focus on where the data is to come from, and identify what is new, where the interfaces are likely to be, is existing data suitable, is the data currently captured etc.
Data Definition Example
| Name | Description |
| Companies | Details of the company including address, overseas offices, and up to ten contacts |
| Licenses | Licenses for all software and hardware used in the organisation. Include contracts, correspondence, quotes and any other related documents. Does not include manuals |
| Renewal dates | Dates the license is due for renewal and the cost of the renewal. . |
| Etc. |
Technical Structure Definition
This technique can be useful in defining scope where the project is focused on infrastructure. It can also be useful in a situation where an existing system is being modified. The output can be either a table, or a diagram. A table might just list the components to be modified and the modification. The structure diagram might identify the whole system and highlight which components are being modified and how they are being modified. It may also be appropriate to indicate the purpose of each component, however it will probably be vague at this stage of development.Example:
The 'outputs HTML' module takes information retrieved from the database and inserts it into an .asp document for output to the server. It also updates a transaction log with the database information and time of the output. If an error occurs in retrieving data from the database, an error log is updated and an error page sent to the server.Example Technical Structure Table
| Component | Description |
| Subsystem1 | Handles all customer processing and interfaces to CMS (Customer Management System). |
| Subsystem2 | Carries out inquiries on billing systems (2) and combines data into common format. Sorts data by date of payment. |
| Etc. |
Example Technical Structure Diagram
Other Considerations
In documenting the scope of the project, also consider describing the project boundaries, identifying the major business events, locations, divisions, functions and processes affected by the project, as well as the groups of people impacted both inside and outside the company. Consider also:- Business processes that will be affected
- Business areas/units that will be affected
- Business locations that will be affected
- Business data that will be changed
- Business applications that will be changed
- Technologies that will be changed
Other Work
The following is a list of work that may need to be specifically included or excluded. Make sure it is clear if this is to be included, and that it is documented. When we come to planning, it should be clear what needs to be catered for in the plan:- Preparation of training material
- Delivery of training
- Business Process documentation
- Business Process Re-engineering
- Rework
- Project management and administration
- Vendor management
- Security
- Disaster recovery plans
- Business continuity plans
- Provision and setup of equipment
- Software
- Communication
- Support after go-live
- Recruitment of permanent or contract staff
- Staff performance management and evaluation
- Hardware upgrade or purchase
- Hardware installation
- Data preparation for transfer
- System documentation
Summary
Defining the scope is a neglected area in most projects. It is however the foundation on which the schedule, budget and resource plans are built. Get it wrong, and everything else will be wrong. If the scope definition does not run to a few pages, it is probably too short.
Take the time to workshop the scope with users. Make sure there is a shared understanding. Force the business to think through the project. Use a number of techniques to cross check. Finally, unless you get the scope right, the project will never be under control and scope creep will likely cause the project to be considered a failure.
Sunday, October 3, 2010
Sunk-Cost Effect
Traditional economics predicts that people will consider the present and future costs and benefits when determining a course of action. Past costs should not be a factor. Contrary to these predictions,people routinely consider historic, nonrecoverable costs when making decisions about the future. This behavior is called the sunk-cost effect. The sunk-cost effect is an escalation of commitment and has been defined as the "greater tendency to continue an endeavor once an investment in money, time or effect has been made."
Sunk costs have two important dimensions—size and timing. Consider the following two scenarios:
A family has tickets to a basketball game and has been anticipating the game for some time. The tickets are worth $40. On the day of the game there is a big snowstorm. Although they can still go to the game, the snowstorm will cause a hassle that reduces the pleasure of watching the game. Is the family more likely to go to the game if they purchased the tickets for $40 or if the tickets were given to them for free?
Most people think the family is more likely to go to the game if they purchased the tickets. You see, the $40 cost of the tickets does not factor into the hassle of the snowstorm or the pleasure derived from the game. Yet people consider the sunk cost in the decision as to whether to go or not. A family that pays for the tickets opens a mental account. If they do not attend the game, they are forced to close the mental account without the benefit of enjoying the game, resulting in a perceived loss. The family wishes to avoid the emotional pain of the loss and, therefore, is more likely to go to the game. If the tickets are free, the account can be closed without a benefit or a cost.
This example illustrates that the size of the sunk cost is an important factor in decision making. In either scenario the family had tickets; however, it was the cost of the tickets ($40 versus $0) that mattered. The next example illustrates that the timing of the sunk cost is also an important component.
A family has long anticipated going to next week's basketball game. On the day of the game, there is a snowstorm. Is the family more likely to go to the game if they purchased the $40 tickets one year ago or yesterday?
In both cases, the $40 purchase price is a sunk cost. However, does the timing of the sunk cost matter? Yes; the family is more likely to go to the game if they purchased the tickets yesterday than if they purchased the tickets last year. The pain of closing a mental account without a benefit decreases over time. In other words, the negative impact of a sunk cost declines over time.
ECONOMIC IMPACT
The previous examples demonstrate that people are willing to incur monetary costs to facilitate their mental budgeting process. Remember that people tend to prepay for some purchases but that they prefer to get paid after doing work. By accelerating payments and delaying income, they are not taking advantage of the time value of money principles. Traditional economics would predict that people would prefer the opposite—delaying payment and accelerating income to maximize the present value of their wealth.
Mental accounting causes people to want to match their emotional cost with the benefits of a purchase. Their determination frequently leads to costly decisions. Consider the following example:7
Fifty-six MBA students were asked to select a loan to finance the $7,000 cost of a home-remodeling project. The project involved redecorating (new carpet, wallpaper, paint, etc.) and would last four years, when they would have to redecorate again. They had two loans to choose from: a 3-year loan with 12% interest and a 15-year loan with 11% interest. Both loans could be prepaid without penalty.
Note that the long-term loan has a lower interest rate. Additionally, you could convert the 15-year loan into a 3-year loan (that has a lower interest rate!) by merely accelerating the payments. That is, you could calculate the monthly payment needed to pay off the 15-year loan in only 3 years. Because the interest rate on the 15-year loan is lower than on the 3-year loan, the monthly payments would be lower. When asked, 74% of the MBA students preferred the 3-year loan. These students indicated a willingness to incur monetary costs (in the form of a higher interest rate) to make it easier to integrate related costs and benefits. It seems that the students were willing to pay a higher interest rate in order to guarantee that the loan will be paid in only 3 years.
MENTAL ACCOUNTING AND INVESTING
Decision makers tend to place each investment into a This mental process separate mental account Each investment is treated can adversely affect separately and interactions are overlooked your wealth in several ways. First, mental accounting exacerbates the disposition effect covered in Chapter 5. Remember, you avoid selling stocks with losses because you do not want to experience the emotional pain of regret. Selling the losing stock closes the mental account, triggering regret.
Consider a wealth-maximizing strategy of conducting a tax swap. When you make a tax swap, you sell a stock with losses and purchase a very similar stock. For example, say you own Northwest Airlines, which has experienced a price decline along with the entire airline industry. You could sell the Northwest stock and purchase United Airlines (UAL). This tax swap allows you to capture the capital loss of Northwest stock to reduce your taxes while staying invested, waiting for the airline industry rebound.
Why isn't the tax swap strategy common? You tend to consider the selling of the loser stock as a closing of that mental account and the buying of the similar stock as an opening of a new mental account. This causes two outcomes that affect you. First, the interaction between these two accounts increases your wealth. Second, the closing of the loser account causes regret. You tend to ignore the interaction between accounts. Therefore, you act to avoid regret instead of to maximize wealth.
Mental budgeting compounds the aversion to selling losers. Consider how you value the timing of payments and benefits. As time passes, the purchase of the stock becomes a sunk cost. The emotional pain of wasting some of the sunk cost on a loser diminishes over time.9 It may be less emotionally distressing for you to sell the losing stock later as opposed to earlier.
Finally, mental account Tne tendency to overlook the interacdon ing affects your perception of between investments causes vou to misper-portfoiio risks The next Gejve the risk of addng a securitv to an exist-chapter describes how mental jm portfolio.
accounting leads to the building of portfolios layer by layer. Each layer represents the investment choices to satisfy mental accounts. This process allows investors to meet the goals of each mental account separately.
Sunk costs have two important dimensions—size and timing. Consider the following two scenarios:
A family has tickets to a basketball game and has been anticipating the game for some time. The tickets are worth $40. On the day of the game there is a big snowstorm. Although they can still go to the game, the snowstorm will cause a hassle that reduces the pleasure of watching the game. Is the family more likely to go to the game if they purchased the tickets for $40 or if the tickets were given to them for free?
Most people think the family is more likely to go to the game if they purchased the tickets. You see, the $40 cost of the tickets does not factor into the hassle of the snowstorm or the pleasure derived from the game. Yet people consider the sunk cost in the decision as to whether to go or not. A family that pays for the tickets opens a mental account. If they do not attend the game, they are forced to close the mental account without the benefit of enjoying the game, resulting in a perceived loss. The family wishes to avoid the emotional pain of the loss and, therefore, is more likely to go to the game. If the tickets are free, the account can be closed without a benefit or a cost.
This example illustrates that the size of the sunk cost is an important factor in decision making. In either scenario the family had tickets; however, it was the cost of the tickets ($40 versus $0) that mattered. The next example illustrates that the timing of the sunk cost is also an important component.
A family has long anticipated going to next week's basketball game. On the day of the game, there is a snowstorm. Is the family more likely to go to the game if they purchased the $40 tickets one year ago or yesterday?
In both cases, the $40 purchase price is a sunk cost. However, does the timing of the sunk cost matter? Yes; the family is more likely to go to the game if they purchased the tickets yesterday than if they purchased the tickets last year. The pain of closing a mental account without a benefit decreases over time. In other words, the negative impact of a sunk cost declines over time.
ECONOMIC IMPACT
The previous examples demonstrate that people are willing to incur monetary costs to facilitate their mental budgeting process. Remember that people tend to prepay for some purchases but that they prefer to get paid after doing work. By accelerating payments and delaying income, they are not taking advantage of the time value of money principles. Traditional economics would predict that people would prefer the opposite—delaying payment and accelerating income to maximize the present value of their wealth.
Mental accounting causes people to want to match their emotional cost with the benefits of a purchase. Their determination frequently leads to costly decisions. Consider the following example:7
Fifty-six MBA students were asked to select a loan to finance the $7,000 cost of a home-remodeling project. The project involved redecorating (new carpet, wallpaper, paint, etc.) and would last four years, when they would have to redecorate again. They had two loans to choose from: a 3-year loan with 12% interest and a 15-year loan with 11% interest. Both loans could be prepaid without penalty.
Note that the long-term loan has a lower interest rate. Additionally, you could convert the 15-year loan into a 3-year loan (that has a lower interest rate!) by merely accelerating the payments. That is, you could calculate the monthly payment needed to pay off the 15-year loan in only 3 years. Because the interest rate on the 15-year loan is lower than on the 3-year loan, the monthly payments would be lower. When asked, 74% of the MBA students preferred the 3-year loan. These students indicated a willingness to incur monetary costs (in the form of a higher interest rate) to make it easier to integrate related costs and benefits. It seems that the students were willing to pay a higher interest rate in order to guarantee that the loan will be paid in only 3 years.
MENTAL ACCOUNTING AND INVESTING
Decision makers tend to place each investment into a This mental process separate mental account Each investment is treated can adversely affect separately and interactions are overlooked your wealth in several ways. First, mental accounting exacerbates the disposition effect covered in Chapter 5. Remember, you avoid selling stocks with losses because you do not want to experience the emotional pain of regret. Selling the losing stock closes the mental account, triggering regret.
Consider a wealth-maximizing strategy of conducting a tax swap. When you make a tax swap, you sell a stock with losses and purchase a very similar stock. For example, say you own Northwest Airlines, which has experienced a price decline along with the entire airline industry. You could sell the Northwest stock and purchase United Airlines (UAL). This tax swap allows you to capture the capital loss of Northwest stock to reduce your taxes while staying invested, waiting for the airline industry rebound.
Why isn't the tax swap strategy common? You tend to consider the selling of the loser stock as a closing of that mental account and the buying of the similar stock as an opening of a new mental account. This causes two outcomes that affect you. First, the interaction between these two accounts increases your wealth. Second, the closing of the loser account causes regret. You tend to ignore the interaction between accounts. Therefore, you act to avoid regret instead of to maximize wealth.
Mental budgeting compounds the aversion to selling losers. Consider how you value the timing of payments and benefits. As time passes, the purchase of the stock becomes a sunk cost. The emotional pain of wasting some of the sunk cost on a loser diminishes over time.9 It may be less emotionally distressing for you to sell the losing stock later as opposed to earlier.
Finally, mental account Tne tendency to overlook the interacdon ing affects your perception of between investments causes vou to misper-portfoiio risks The next Gejve the risk of addng a securitv to an exist-chapter describes how mental jm portfolio.
accounting leads to the building of portfolios layer by layer. Each layer represents the investment choices to satisfy mental accounts. This process allows investors to meet the goals of each mental account separately.
[collection]
Subscribe to:
Posts (Atom)