Tag: Learning

The Top 5 Mistakes in Requirements Practices and Documentation

Written by Angela Wick on May 28, 2012. Posted in Articles.

In my work with dozens of organizations improving business analysis practices, the following are the most common themes I see hindering the great value that good business analysis practices can provide.

1) Lack of collaboration and review of requirements

Collaboration and review of requirements should be an ongoing process of meeting, discovering, and collaborating to share information and context. Verifying that requirements met the needs of others to guide further work and validating that the requirements will add value to the business are critical pieces to this review and collaboration.

The mistakes I typically see in this area are teams that “gather” and “collect” requirements from stakeholders rather than using proven successful elicitation, discovery, and validation techniques. Following a “gather” and “collect” mindset sets a team up to jump to the solution too quickly before truly understanding the business needs and value required by the stakeholders.

The BA is often assigned to the project after business needs and values have already been discussed and the stakeholders pressure the BA to just move forward. This is the most important time for a BA to use powerful collaboration techniques that help the stakeholders feel that they are not restating the same information but are improving the business value proposition the project is set out to achieve.

Some teams see requirements reviews as sufficient collaboration. With requirements reviews I often see the following:
• Lack of review
• Reviewed, but missing critical stakeholders and consumers of requirements
• Reviewed but as a formality, and stakeholders struggle to truly understand requirements documentation

Ideally for requirements reviews to be successful, those using and signing off on requirements need to be fully engaged in reviewing requirements, verifying they are understandable, cohesive, and usable for the further work to be done, and validating the business value and intent of the requirements. To achieve this, BAs need to ensure that documents are presented and communicated in ways that are understandable to all audiences and the review process engages all audiences to fully participate in the review.

2) Not differentiating between capabilities, rules, project tasks, and design

Many requirements documents that I see in a large number and variety of organizations are missing the essence of what requirements are. The mistake I see is requirements documents lifting project tasks, detailed technical design, and business rules without listing the context and capabilities needed. This sets the project and solution up for a multitude of missed requirements and missed value to stakeholders. Business and solution requirements are capabilities needed by a solution to achieve a desired change in the business. They are not project tasks lists, technical design details, or bullet lists of business logic. Focusing on the true requirements instead of the project tasks and design will shorten the requirements timeline.

Project tasks need to be in a project plan of some sort, and design should be happening progressively as requirements are discovered and must account for feasibility and alternatives. Design needs to be differentiated from what the requirements are, and this can occur in a separate document or not, but it needs to be differentiated. It is no fun to manage requirements change when the requirements document is really tasks and design; this will cause more change management administration than needed. Requirements change becomes much more manageable when it is truly business and solution requirements that are changing. Changing design details and project tasks is likely to happen with more frequency and may not impact the end result, and a failure to differentiate can cause costly rework and unneeded administrative tasks.

Business rules are critical to successful requirements, but I often see requirements only in the context of business rules, and sometimes up to 90% of a requirements document is a listing of business rules. Business rules listings without the context of processes, people, data definitions, sets, projects up for missed requirements, inefficient and inconsistent implementation of business rules. Understanding the business rule outside of technology enablement is crucial to improving the consistency and efficiency of business rules. Differentiating business rules from requirements is critical to understanding and analyzing the capabilities needed to implement the rules.

3) Lack of context and visuals

Context and visuals provide our requirements readers with brain candy. Many studies show that visuals are consumed by the brain much faster than text and help depict relationships, whereas text is processed in a more linear fashion in our brains. Cognitively, visuals are proven to be more effective than text at increasing a reader’s comprehension and retention. On the other side, visuals without text can be too ambiguous. So, why do so many requirements documents lack visuals and context that would help readers comprehend and retain the very information BAs are asking them to approve? As Bas, visuals are sometimes present but often are too complex to engage our readers and need to be simplified. Sometimes our visuals as BAs are design oriented rather than intended to help readers understand context, interactions, and relationships.

Great requirements are documented in a way that allows the reader to choose the level of detail they would like to consume, provide visuals and context of varying levels of detail needed to guide further work, and provide text that clearly traces the visual and context representing the text.

4) Too much focus on the as-is current state

Projects and business analysis work is about changing the way organizations operate. It amazes me how much time is spent on documenting the as-is; I am not advocating ignoring the as-is or current state, because it is needed to understand the gaps that must be crossed to get to the future desired state. The challenge and mistake I see teams making is never getting to defining the gaps and future state. And, sometimes all of the context and visuals are about the current state with nothing showing the context or visuals for the future state.
Our requirements need to understand the current state, but the requirements themselves should represent the gaps and future state. We are not asking our stakeholders to approve the current state. Instead, they are asking us to help them change, hence we need to define the future state. Our requirements need to answer the questions: Why are we spending money on this solution? What value will the solution bring?

There are many statistics out there about the percentage of functionality in current systems that is not used; the numbers typically range between 60-80%. This raises the question of why we would document requirements for the future the way the system works today when 60-80% is not even used today? After all, today’s system was likely designed 10, 20, or even 30 years ago and we can’t possibly compete in todays business environment by developing solutions based on functionality designed for business years ago. After all, how will this take the organization into the future?

Great requirements practices and documents show how the current state is going to change, what the future state is, and the gaps to get there. There are many areas of solutions where the current rules, process, and technology will be leveraged in the future state, and this is where we need to ensure we are focused on the future by defining what pieces will move forward, and we shouldn’t spend too much effort on current state items that will not carry forward. This is done by identifying the current state at a higher level and questioning if this piece will continue to add value in the future state vision. At that point, a BA should only go into details if the value is justified.

5) Allocating requirements too early to the applications they will be implemented in

When evaluating business analysis practices and how they align with software development processes, I often see that the requirements are being allocated to software applications before the requirement itself has much context or elaboration. Understanding the requirement and business need is needed before we can specify what system or application will be changed or built to implement the requirement. The practice of assigning the technology to a requirement before the BA is assigned or before the requirement is vetted defeats the purpose of business analysis in many ways. This practice also makes requirements change a huge challenge. As we discover and elaborate requirements, we often find that the initial idea on implementation is not feasible or optimal. If the requirements process has already allocated the requirement, it takes a change request to change that in some organizations. This is where the process hinders good business analysis. Many times this practice is not in the control of a BA, but I do believe that a BA can collaborate with others, and elicit and document requirements in a technology-agnostic manner to facilitate the discovery of other ways to implement requirements.

Great requirements practices focus on the user, process, rules, events, data, and non-functional needs before deciding which exact implementation technology will be used. This allows the team to discover the true business need and explore options and alternatives that may not have been previously thought of. It also helps ensure feasibility prior to committing to a specific solution design.

Let me know your thoughts on the common mistakes in requirements practices and your challenges in these areas.

Don’t forget to leave your comments below.

The Best Virtual Meeting…EVER! Five Fun Games to Engage Your Virtual Project Group!

Written by Claire Sookman on March 26, 2012. Posted in Articles.

Do you ever have those days when go you off on philosophical tangents? You know, those cold, gloomy mornings when you stare out the window, coffee mug in hand, wondering, “Does a fish know what water is?”, “Is the colour red really universal?” or “Is Robert from marketing a real person?”

We’ve all been there. The truth is it’s hard for virtual project groups to bond on a personal level with other group members…partly (well, mostly) because we may not even know what the other person looks like! Without bonding, the results could be dangerous. The University of California, San Francisco, lists some of the common symptoms of a disengaged team:

Decreased productivity
Conflicts or hostility among staff members
Confusion about assignments, missed signals and unclear relationships
Decisions misunderstood or not carried through properly
Apathy and lack of involvement

And there’s more:

Lack of initiation, imagination, innovation; routine actions taken for solving complex problems
Complaints of discrimination or favouritism
Ineffective staff meetings, low participation, minimally effective decisions
Negative reactions to the manager
Complaints about quality of service

And there’s still more! A 2009 article from the Occupational and Environmental Medicine showed that a lack of team spirit can even cause employee depression…But don’t panic!

Before you scurry off to Google, furiously searching “how to engage virtual project groups” — take a breath. We’ve done the work for you. Here are some innovative games that are sure to have your team amused and engaged in no time.

1) Virtual Charades – Charades is a great game that builds group spirit, whether in a traditional workplace or a virtual one. If your company usually sets up video conferences for meetings, this is definitely a game that will have everyone working together, solving problems and having fun along the way. If you’re unfamiliar with the game, Charades requires the player to mime or imitate a certain action or subject that the rest of the team has to figure out. For more information on how to play, click here .

For those who use voice chat instead of video chat, there’s a fun alternative for you too — Voice Charades. For Voice Charades, create a secret list of objects, animals or famous people. To decide who will go first, enter all team member names onto a site such as Random.org and choose the first name that shows up. Email or send an individual/private instant message to this team member letting them know what they will be acting out. Remember to keep the clues work-appropriate and respectful of others. Have fun guessing what/who the person is imitating. Some entertaining suggestions are:

Printer sound
Al Pacino impersonation
Star Wars Light saber
Monday traffic
Radio anchorman

2) Spin a Tale – This fun game fosters creativity and helps team members think on their feet. During a meeting, make up the first line of a story. Then ask team members to take turns and add each subsequent line until a whole plot develops! Let the story go along on its own path and deviations. This is the fun part of the game; you never know what perils or fortunes can occur next! The best thing is, even though your team may develop favourite start tags, the story will never end up the same! In other words, you learn how to think innovatively. Here are some ways you can start your tale:

I woke up at 9am — that was when we were supposed to Skype in for the meeting…
Jared looked over the ledge of his balcony, wondering why the crowd had gathered…
The email had no subject line…I hate it when he does that…
Fifteen years, 15 days, 15 hours and finally the letter had come…
As Sophia hid behind the red SUV in the parking lot, she tried to remember how exactly she had gotten there…and why there was that giant scar on her arm…

3) Situation Puzzles – Situation puzzles are an exciting way to exercise creative problem-solving skills while also building team unity. In a situation puzzle, the team leader states one mysterious sentence such as, “a bell rings, a man dies, a bell rings”.* The rest of the team must now solve the situation by asking “Yes” or “No” questions. As each question unearths new information, the team can creatively build on each other’s thought patterns and ideas until all the loose ends are tied. A great reservoir of situation puzzles can be found here! *(Click here for the answer)

4) PowerPoint Game – You will never look at PowerPoint presentations in the same light after this game! This is a great way to get group members thinking on their feet while having loads of fun. To play the PowerPoint game, go online and find a series of complicated or extremely nonsensical PowerPoint presentations (try SlideShare). Then ask team members to improvise a presentation with the slides they’re using. Hilarity is bound to ensue! Go here for more information about the PowerPoint game.

5) 2-Minute LOL – This is another improvisation game that will get everyone thinking fast, learning about team members and literally laughing out loud. First, divide the team into smaller groups or partners. Then give each group a topic or let them choose one. Allow each team about five to ten minutes to create a set of jokes based on their topic. Make sure they have this discussion in a separate virtual conversation so that the rest of the team does not hear the punch lines beforehand. When everyone regroups, randomly choose a group to go first while timing their comedy improvisation for two minutes. Once again, remember to keep all jokes respectful and workplace-appropriate. Award the funniest team with a gift card or some other form of prize!

And there you have it — five amazing ways to engage your virtual project group! Try them out and let us know which game your team liked the best! And if five tips aren’t enough, here’s a whole book full of tips! Across the Hall, Around the World is the ultimate archive of virtual team-building tips that’s sure to get your team engaged!

Don’t forget to leave your comments below.

Claire Sookman is the driving force behind Virtual Team Builders, Claire brings to the table over a decade’s worth of corporate and public sector training experience, working with over 4,500 managers in the past three years. Specializing in virtual team building and communication strategies, Virtual Team Builders provides training that enables global teams to work more efficiently.

The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

Written by Karl Wiegers on February 21, 2012. Posted in Articles.

(adapted from More about Software Requirements by Karl Wiegers)

“Why?” is an excellent question to put in the business analyst’s bag of tricks. During a reengineering project, a BA named Dawn asked one of the developers why a utility company fee calculation was being performed a certain way in the existing system. “There’s a government statute that dictates how we have to calculate these fees,” was the reply. Upon investigation, Dawn discovered that in fact the current system had not implemented the computation correctly according to that statute. The system had calculated these utility fees incorrectly for an embarrassingly long time. This discrepancy never would have come to light had Dawn simply accepted the stated need for the current formula. Asking “why” revealed a major error that the replacement system corrected.

The shrewd BA asks why a lot. It’s important that “why” explorations be expressed in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin this way: “Can you please help me understand…” This phrase is longer than why and means essentially the same thing, but it has a more collaborative feel to it.

When a user representative presents a requirement that contains an embedded solution idea, asking why can let you know whether the solution idea is a true design constraint or just an idea or suggestion. Asking why several times in succession is a way to drill down from a superficially proposed customer “want” to the real underlying need. This helps the software team address the real issue, not just a superficially presented issue. Gently probing with why can reveal other sorts of useful information:

The answer to why might point out a business rule that affects the project. Then you can check to see whether the business rule is still pertinent and whether the information you have available for it is complete and accurate. You can discover whether and where the business rule is documented, who’s responsible for maintaining the information, and whether there are related rules you need to know about.
Asking why sometimes surfaces assumptions held by the person you’re questioning. An assumption is a statement that you regard as being true in the absence of definitive knowledge that it is true. It’s important to try to identify assumptions that various stakeholders might be making. Those assumptions could be incorrect or obsolete. They could be at odds with assumptions other people are making. Such conflicts make it harder for the stakeholders to have shared project expectations.
Asking why can reveal implicit requirements that no one thought to mention yet.
The answer to “Why is this requirement included?” supplies the rationale behind the requirement. It’s always a good idea to know where each requirement came from and why it needs to be included in the project. This can help the BA learn about requests that lie outside the project scope. This question sometimes also exposes that the “requirement” is really a design idea for an unstated higher-level requirement.
Suppose you encounter a requirement that a user representative presented as being high priority. It doesn’t look that important or urgent to you. If you ask why it’s high priority, perhaps you’ll learn that it’s logically connected to other requirements that also are high priority. Without this knowledge, someone might unwittingly defer the requirement that doesn’t seem so important, thereby crippling the related requirements that are scheduled for early implementation.
Sometimes the BA thinks she understands a requirement, only to discover upon further investigation that she really doesn’t. Asking why a requirement is necessary a few times could provide additional details that solidify the BA’s understanding of that requirement.
Asking why or similar questions can help the BA distinguish essential requirements knowledge from extraneous information.

Asking why might save you a lot of work. One project was replacing an existing customer relationship management (CRM) system with a package solution. Senior management directed the team to use out-of-the-box features from the package as much as possible and to limit the extent of configuration or changes to the package. One user representative asked that a specific function be added, a counter that indicated how many times a customer had used a certain product feature. It would have cost a significant amount to modify the core package to accommodate this requirement.

When the BA asked why that function was needed, the user said that the function was present in the current CRM application. The BA probed further: “What exactly does this counter show?” “Why do you check it?” “What action do you take depending on what it tells you?” This discussion eventually revealed that several stakeholders all thought that someone else was using the data. In reality, no one used it at all! By asking “why” a few times, the BA and user representative agreed that the function wasn’t needed, thereby saving a significant amount of money.

A BA needs to be a bit of a skeptic. Don’t believe everything you hear, and don’t accept it all at face value. Ask “why” enough times to give you confidence that you’ve got the real requirements in hand.

The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

Written by Karl Wiegers on February 21, 2012. Posted in Articles. 2 Comments on The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

The shrewd BA asks why a lot. It’s important that “why” explorations be expressed in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin this way: “Can you please help me understand…” This phrase is longer than whyand means essentially the same thing, but it has a more collaborative feel to it.

The answer to why might point out a business rule that affects the project. Then you can check to see whether the business rule is still pertinent and whether the information you have available for it is complete and accurate. You can discover whether and where the business rule is documented, who’s responsible for maintaining the information, and whether there are related rules you need to know about.
Asking why sometimes surfaces assumptions held by the person you’re questioning. An assumption is a statement that you regard as being true in the absence of definitive knowledge that it is true. It’s important to try to identify assumptions that various stakeholders might be making. Those assumptions could be incorrect or obsolete. They could be at odds with assumptions other people are making. Such conflicts make it harder for the stakeholders to have shared project expectations.
Asking why can reveal implicit requirements that no one thought to mention yet.
The answer to “Why is this requirement included?” supplies the rationale behind the requirement. It’s always a good idea to know where each requirement came from and why it needs to be included in the project. This can help the BA learn about requests that lie outside the project scope. This question sometimes also exposes that the “requirement” is really a design idea for an unstated higher-level requirement.
Suppose you encounter a requirement that a user representative presented as being high priority. It doesn’t look that important or urgent to you. If you ask why it’s high priority, perhaps you’ll learn that it’s logically connected to other requirements that also are high priority. Without this knowledge, someone might unwittingly defer the requirement that doesn’t seem so important, thereby crippling the related requirements that are scheduled for early implementation.
Sometimes the BA thinks she understands a requirement, only to discover upon further investigation that she really doesn’t. Asking why a requirement is necessary a few times could provide additional details that solidify the BA’s understanding of that requirement.
Asking why or similar questions can help the BA distinguish essential requirements knowledge from extraneous information.

(adapted from More about Software Requirements by Karl Wiegers)

Don’t forget to add your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons. Karl produced this article for Enfocussolutions.

BI – This Is Why

Written by Salah Elleithy on November 21, 2011. Posted in Articles.

Business Intelligence has been a buzzword for years. Organizations saw it as optional or unnecessary. In the current environment, Business Intelligence has become a necessity. Organizations in any industry look for relevant information to make decisions.

Just as cash is the lifeblood of any organization. Data is the lifeblood of any information system in the organization. The importance of collecting data in a systematic and structured way is critical to the success of any business. Management needs to have visibility into all aspects of the business. Not only from a financial point of view but also other metrics that are critical to measuring the business success such as operations, compliance and HR. Accuracy and speed are among the most critical factors. We will discuss the importance of how business intelligence play a major role in providing the organization with the critical information it needs to make good decisions. We will focus on why business intelligence is important and how to implement a business intelligence solution.

Business Intelligence (BI)

Almost half a century ago, P. Hans Luhn, an IBM researcher defined business intelligence as the ability to apprehend the interrelationships of presented facts in such a way as to guide action towards a desired goal. This definition is still relevant today. No longer can management wait for historical information to make future decisions. Fact or evidence based systems have become critical to any organization.

In the past when data was not available, decisions were made based on intuition and “gut feelings”. Today in a dynamic and ever changing business world, data drives decision-making.

Healthcare is one of the major industries that could benefit from BI. Organizations in the healthcare industry have to quickly adapt to satisfy government regulations whether on the state or federal level. The need to build systems that are robust and adaptable to change is inevitable. The current challenges range from collecting data in a systematic and consistent way to securing the data to the ability of providing accurate and timely reporting and analysis. BI could be the spark that exposes different metrics to help healthcare organizations identify ways to improve quality.

Benefits of Business Intelligence

Data collected in the healthcare industry usually falls into one of three categories: Financial, Clinical and Operational. Within each of those categories, there are multiple variations of analysis that need to be sliced and diced in different ways. BI will provide information, develop knowledge about financial, clinical and operational metrics that will impact decision-making behavior to improve quality of care and achieve higher profitability.

Some of the benefits and improvements that can be reaped from implementing a business intelligence solution are:

1. Quality of care:

A healthcare provider such as a hospital or a home health facility main goal is to improve quality of care for patients. BI is not only used for operational and financial purposes. With the vast amount of stored clinical data including patient history, BI could help identify better ways of monitoring and treating our patients. Implementing a fact based system with analytics not only help clinicians and doctors better asses the trends and monitor improvement for their patients, it could provide insights on treatment outcomes that would enhance quality of care. This will provide a competitive advantage to any healthcare organization.

2. Strategy

What is measured improves, said Peter Drucker. Without measuring where we are today, we cannot plan where we want to be tomorrow. Using BI to develop metrics to monitor clinical, operational and financial information will help the organization with setting long-term goals and develop future strategy.

3. Speed

We need information and we need it fast. BI tools provide us with the ability to analyze data in multiple ways. It summarizes massive amount of data into variety of reporting formats such as dashboards and graphical representation to enable healthcare management to act quickly in a dynamic environment.

4. Accuracy

Providing accurate information is critical. Bad information leads to bad decisions. In healthcare, bad decisions could impact the livelihood of patients. BI uses visual capabilities that make finding inaccuracies more efficient. Identifying inaccuracies will serve as a red flag to correct the issues and minimize the risks associated with them.

5. Enhancing Decision Making

Using BI improves the decision making process. The steps of making a decision involve four different stages: intelligence (problem discovery), design (solution discovery), choice (choosing solutions), and implementation (solution testing). This process is iterative and can take a long time to run through different scenarios before finding a solution that could work. BI can significantly reduce this cycle of decision making by providing different scenarios and changing them on the fly to get instant reporting and analysis. It also allows us to visually see the impact whether it is on a summarized or a more granular level.

Selecting a BI Solution

There are many vendors providing BI platforms in the market today. Some of which have a great market share and an established track record. When selecting BI solutions, some of the factors we need to consider are:

1. Understanding our needs:

In order to choose a BI solution, we must first understand what we want to get out of the BI solution. What it is supposed to do and what are problems we are trying to solve by implementing the BI solution.

2. Ease of Use:

One of the main goals of implementing a BI solution is to give users the tools to analyze data. The BI solution learning curve has to be minimal in order to be adapted by the users. Training should be easily available and provide users with a quick understanding of how to use the BI tool. The BI solution need to be designed to empower developers to rapidly build BI applications that can be utilized by employees at all levels. This expands business intelligence far beyond analysts and power users – who have always been able to employ complex BI tools – and makes it readily available to line of business workers who require operational reporting to support their day-to-day activities and drive process efficiencies across functions.

3. Scalability:

BI solutions are selected to provide a greater impact on operational efficiency. This means that BI solutions need to scale to all levels of the organizations without the need for costly upgrades or great deal of maintenance. The availability to users is very important, as they will utilize the BI solution to analyze their operations and make decisions based on the analysis.

4. Information Sharing:

Information is mostly a “Pull and Push” process. Users pull information to share it with their team, customers, suppliers and others who need to know and act upon the information shared. The BI solution needs to allow the user to share the information efficiently. Most users share information by email, which is static. The information sharing process has to be more dynamic where once the data is updated; it is automatically update for the user. This can be accomplished by utilizing the web interface as a delivery method of the BI solution.

5. Integration:

Most organizations have multiple systems for different functions. The BI solutions must have the ability to easily integrate with current in house systems. BI solution is required to integrate with back-end systems in order to solve a problem. Organizations may need more integration tools however BI solutions should have the ability to integrate with major databases and file formats.

Implementing a BI Solution

The key elements of an organization are its People, Structure, Business processes, Politics and Culture. Implementing a new technology will impact those elements and should be addressed accordingly.

BI is a front-end technology that analyzes data. The Challenge is to put the structure in place to get the highest return on investment (ROI) of the BI solution. The data and systems have to be ready to implement a BI solution. Another challenge we face is once the technology is in place is how to get people to learn it and use it.

Data represent a key challenge since it is stored in different systems across the board. In order to solve this problem, a data warehouse needs to be developed. A data warehouse is created to centralize data into one place and is optimized for analytics needs. This is a huge undertaking but is necessary if we are looking to get a high ROI on our BI solution.

Summary

Business Intelligence (BI) is a culture change and not just a technology. Systems and structure have to be in place to fully leverage the BI solution. That being said, we can’t afford to wait until the systems and structure are in place. Our approach should be one that allows us to grow into the BI solution. BI can highlight data and system inefficiencies, therefore we need to implement a cost effective BI solution as a pilot. This is how a learning organization approaches new technology to reduce the risk of failure and understand the groundwork that needs to be done for it to be successful.

Don’t forget to leave your comments below.

Salah Elleithy, PMP, is an experienced Business analyst with a decade of experience in a diverse array of industries. He is passionate about performance management and data analytics. He has a wide experience in business development, business intelligence, and decision support to senior management. Salah worked on a portfolio of projects to develop a variety of metrics in the energy, pharmaceutical and health industries. Salah is also passionate about teaching and he volunteers with many organizations. You can follow him on twitter (@selleithy).

References

“A Business Intelligence System”, IBM Journal, October 1958, P. Luhn. http://www.research.ibm.com/journal/rd/024/ibmrd0204H.pdf (Link has been moved to IEEE)

Foundation of Business Intelligence: Databases and Information Management. K. and J. Laudon. Chapter 6, PP 222-223

Healthcare Tech: Can BI Save the System? InformationWeek. August 2009, Boris Eveleson

http://www.informationweek.com/news/healthcare/interoperability/showArticle.jhtml;jsessionid=W1Z0ZH23HDHPFQE1GHRSKH4ATMY32JVN?articleID=219300177&pgno=2&queryText=&isPrev=

Business Intelligence in the Healthcare Industry, http://www.hypatiaresearch.com/images/HypatiaResearch_2BIinHEALTHCARE_ExecSum_TOC.pdf

Applying Business Intelligence to the Needs of Healthcare Organizations

http://www.healthleadersmedia.com/content/TEC-90944/Applying-Business-Intelligence-to-the-Needs-of-Healthcare-Organizations.html

http://jonhunt.org/resources/HealthcareAnalytics_eHR_EMR.pdf

What is an Information System? , Dr. Harding http://polaris.umuc.edu/~gharding/isas610/wk1Ch01LectureteGlobalBusinesses.html

Databases, Dr. Harding http://polaris.umuc.edu/~gharding/isas610/wk4ch06Lecturette1Databases.html

Information System Definition, Information System in Global business today, ch.1, pg.16

Management Information System, ISAS 610, Ch. 12, Enhancing Decision Making, pp. 450

Key elements of Organizations, Dr. Harding http://polaris.umuc.edu/~gharding/isas610/wk1Ch01LectureteGlobalBusinesses.html