Q: What should be the nature of the relationship between the business plan and the IS plan?
When we talked about Business Plan according to Tim Berry of his business article, “A business plan is any plan that works for a business to look ahead, allocate resources, focus on key points, and prepare for problems and opportunities.” Business planning is about RESULT.
Is there a standard business plan?
A normal business plan (one that follows the advice of business experts) includes a standard set of elements. Plan formats and outlines vary, but generally a plan will include components such as descriptions of the company, product or service, market, forecasts, management team, and financial analysis.
The plan will depend on the specific situation. For example, description of the management team is very important for investors while financial history is most important for banks. However, if you’re developing a plan for internal use only, you may not need to include all the background details that you already know. Make your plan match its purpose.
The most important in Business plan are the following:
- Cash flow is both vital to a company and hard to follow. Cash is usually misunderstood as profits, and they are different. Profits don’t guarantee cash in the bank. Lots of profitable companies go under because of cash flow problems. It just isn’t intuitive.
- Implementation details are what make things happen. Your brilliant strategies and beautifully formatted planning documents are just theory unless you assign responsibilities, with dates and budgets, follow up with those responsible, and track results. Business plans are really about getting results and improving your company.
But of course, it depends on the case, but usually it’s the cash flow analysis and specific implementation details.
Here are some of the qualities of a good business plan, in order of importance:
1. It fits the business need
We simply can't look at business plans as generic. You have to start with whether or not the plan achieved its business purpose. Some plnas exist to get investment. Some are supposed to support loan applications. Those are specialty uses that apply to some business situations, while almost all businesses ought to develop management-oriented business plans that exist to help run the company, not to be presented to outsiders.
Obviously form follows function. The business plan used internally to manage the company doesn't have to polish and present the company to outsiders, so it probably lives on a network, not on paper. But the plan as part of high-end startup looking for VC or angel investment does in fact have to present the business to outsiders. These are very different plans. Some of them have sales objectives, selling an idea, and a team, and a market, to investors. Some have a support objective, reassuring a lender about risk, usually with assets. My favorite business plans are about managing: starting and growing a company. A plan that might be great at selling the company might be bad at supporting a loan application, or for managing a company. So point one, what makes a good business plan, is that it fits the business need. Does it achieve the business objective?
So it's entirely possible to have an excellent business plan that's never been printed, that isn't edited, that contains only cryptic bullet points that only the internal management team understands. And it's also possible to have a well written, thoroughly researched, and beautifully presented business plan that's useless.
2. It’s realistic. It can be implemented.
The second measure of good or bad in a business plan is realism. You don't get points for ideas that can't be implemented. For example, a brilliantly written, beautifully formatted, and excellently researched business plan for a product that can't be built is not a good business plan. The plan that requires millions of dollars of investment but doesn't have a management team that can get that investment is not a good plan. A plan that ignores a fatal flaw is not a good plan.
3. It's specific. You can track results against plan.
Every business plan ought to include tasks, deadlines, dates, forecasts, budgets, and metrics. It's measurable.
Ask yourself, as you evaluate a business plan: how will we know later if we followed the plan? How will we track actual results and compare them against the plan? How will we know if we are on plan or not?
While blue-sky strategy is great (or might be, maybe), good planning depends more on what, when, who, and how much.
4. It clearly defines responsibilities for implementation
You have to be able to identify a single person will be responsible for every significant task and function. A task that doesn't have an owner isn't likely to be implemented. You can go through a business plan and look to see whether or not you can recognize a specific person responsible for implementation at every point.
5. It clearly identifies assumptions
This is very important because business plans are always wrong. They're done by humans, who are guessing the future, and humans guess wrong. So business plans must clearly show assumptions up front because changed assumptions ought to lead to revised plans.
6. It's communicated to the people who have to run it
At this point we leave the discussion of the plan itself, as if it were a stand-alone entity, and get into how the plan is managed. The first five points here are about the plan. You can deal with them as the plan develops. This and the following two are about the management of the plan.
I know that's kind of tough, because it means that a plan that isn't managed isn't a good plan. But I can live with that.
So a good plan is communicated. Up above, where I suggest that the qualities of writing and editing are not essential for all plans, and I reference cryptic bullet points that only the team understands: I stick with that here. If only the team understands them it, it can still be a good plan; but it has to be communicated to that team.
We're judging the plan by the business improvements it causes; in some sense, by the implementation it causes. So people in charge have to know and understand the business plan. Plans in drawers, or locked on a single computer, only work when it's a one-person organization and nobody else has to know the plan.
7. It gets people committed
Here too it's about the process surrounding the plan, more than the plan itself. The plan has to have the specifics in point 3 and responsibilities as in point 4, but the management has to take them to the team and get the team committed.
For the one-person business that's easier, but still important.
Definition of commitment: in a bacon and egg breakfast, the chicken is involved, and the pig is committed.
8. It's kept alive by follow up and planning process
Sadly, you can have all seven of the above points, and if you drop the ball — the plan in the drawer syndrome — then the plan still isn't a good plan. It has to bring the planning process with it, meaning regular review and course correction.
No business plan is good if it's static and inflexible. Planning isn't about predicting the future once a year and then following that predicted future no matter what. Planning is steering and management. It takes a process of regular review and course correction.
In contrast, Information system, “It is an integrated set of components for collecting, storing, processing, and communicating information. Business firms, other organizations, and individuals in contemporary society rely on information systems to manage their operations, compete in the marketplace, supply services, and augment personal lives. For instance, modern corporations rely on computerized information systems to process financial accounts and manage human resources; municipal governments rely on information systems to provide basic services to its citizens; and individuals use information systems to study, shop, bank, and invest.” -Encyclopædia Britannica.
But what is Information System Planning? According to SDLC article (System Design Life Cycle), “the system planning seeks to identify and prioritize those technologies and applications that will return the most value to the business. Synonyms include strategic systems planning and Information resource management.
Information systems (IS) planning is recognized as one of the dominated managerial issues of MIS. Based on prior studies in strategic and IS planning, this study integrates three domains to investigate the effects of organizational contexts and planning system dimensions on the effectiveness of IS planning from a contingency perspective. The model is supported by the empirical data, showing the importance of many contextual factors and planning system dimensions to attaining greater effectiveness of IS planning. In particular, the results demonstrate the pivotal role of an organization’s improved planning capability in mediating the effects of organization contexts and planning system dimensions on IS planning effectiveness. Every phase of IS planning is important. The following are some of the phases that the IS will have.
Study the Business Mission
Although many businesses haven't formally documented their mission, they all have one. If information systems are to truly return value to the business, they need to directly address that mission. Thus, the first phase of systems planning is to study the business mission.
Ideally, the scope of the phase should be the entire business. For some companies, that is much too large. Consequently, the scope might be reduced to a more manageable level-a division, a plant, or some other significant operating unit. For other companies, the scope of the phase is limited by the level of top management support received. Top executives of the organization must be willing to participate in the development of any strategic plan. Otherwise, the phase is useless.
Members of the planning team include information systems managers and the key business executives (system owners). The key facilitator of this phase is a planning analyst.
Planning analysts are specially trained information systems planning professionals. Their job is similar to that of systems analysts; however, they must be even more business-oriented that?.
Planning analysts must be familiar with the planning methodology to be used and the deliverables to be produced. They require a unique blend of skills and experiences, including business management, systems analysis and design, data management, and networking.
Many IS shops have difficulty finding the correct mix of these skills. Particularly, IS professionals tend to be either too applications-oriented, too database-oriented, or too network-oriented. In this case, the business usually hires management consultants to serve as the planning analysts. These consultants are widely available through IS consulting firms (e.g., Ernst & Young, James Martin & Associates, or IBM)
The input to this phase is the business mission, as "discovered" through interviews and group sessions with system owners. The business mission Is usually defined in terms of customers, products and services, material resources, human resources, geographic operating locations, management structures and philosophy, corporate goals and objectives, unavoidable business constraints, critical business success factors, and other management-oriented criteria.
The key deliverable is business plans. Hopefully, those plans already exist; this phase merely translates them into terms or formats that are useful to the system owners and planning analysts in subsequent planning phases. (All too often, that plan does not exist!)
Based on the findings of this phase, the planning effort could be canceled due to a lack of management commitment or funding. It is more likely, however, that the project will continue to the next phase-possibly with a reduced business scope.
Define an Information Architecture
Given an understanding of the business mission, you can now develop a plan for information systems that truly mirrors and supports that business mission. The next phase of systems planning is to define information architecture for information systems.
Information architecture is a plan for selecting information technology and developing information systems needed to support the business mission. Synonyms include information systems plan and master computing plan.
This architecture phase can take six months or longer to complete.
Once again, this phase Is facilitated by planning analysts. The team also includes the same IS managers and business executives included in the previous planning phase. Additionally, the team should normally include at least one database, networks, and applications management representative -the reason will become apparent in a moment.
The key input to this phase is the business plans from the last phase. Other inputs include existing system details and limitations (from the documentation maintained during the Systems Support phase), facts and opinions (from appropriate system owners and system users), and technology forecasts and opinions (from Information systems management and/or consultants).
These inputs are used to build the information architecture. The key components in information architecture are:
· A DATA architecture that identifies and prioritizes the databases that need to be developed. These databases should be highly flexible so that they can support several areas of the business. (Note: A data or database manager usually helps define the data architecture.)
· A NETWORK architecture that identifies and prioritizes computer networks that need to be developed. These networks must optimize information systems support at all appropriate business operating locations. (Note: A networks manager usually helps define the network architecture.)
· An ACTIVITIES architecture (more appropriately called an applications architecture) that identifies and prioritizes business areas for which business processes and/or information systems applications must be redesigned. (Note: One or more applications development managers usually help define the applications architecture.)
· A PEOPLE architecture (actually, an IS organization structure) necessary to develop and support the databases, networks, and applications.
· A TECHNOLOGY architecture that identifies the information technologies that should be used for applications, and possibly for applications development. (Note: Information systems management, along with the applications, database, and network managers, usually provides the technology forecast and opinions needed to develop the technology architecture,)
The Information architecture is packaged in the deliverable, information systems plans. These plans will ultimately influence the development and support for all future Information systems. Thus, they must be made available to information systems management, any contracted consultants, and all current and future information systems owners.
Some planning methodologies call for other deliverable, distinct business areas (to be passed on to the next planning phase).
Business areas are groups of logically related business functions and activities, independent of organization structure. The term was Invented as part a planning methodology called information engineering.
This definition requires some clarification. Business areas define major functions of the business, for example, PROCESS AND FILL ORDERS. Several organization units may play a role in any given business area. For example, the processing and filling of orders normally requires activity in at least the following organization units: Sales, Order Processing, Accounts Receivable, Warehousing, and Shipping. Ideally, information systems should be built around the integration of these units' activities as they relate to the common business function-in this case, processing and filling orders.
Business areas are usually prioritized according to their perceived importance and value to the business- The next planning phase deals with one business area at a time (in order of priority).
The planning project could be terminated due to a lack of either funds or management commitment. Even if this happens, you still have the information architecture to guide future systems development. Alternatively, the project can continue to the next phase, business area analysis.
Business Area Analysis
The information architecture is a good high-level IS plan. But some IS shops seek to further refine that plan to define specific systems development projects. Thus, the next phase of systems planning is to evaluate business area(s) to identify and prioritize specific development projects. A project may trigger development of any of the following:
1. A network-subsequent projects would build databases and/or applications around that network.
2. A database-subsequent projects would build applications around that database.
3. An information systems application-which may include building an applications-oriented database or network if a network or database Is not completed first.
Business area analysis (BAA) can be a time-consuming phase that takes six months or longer (per business area) to complete. But many companies are willing to spend that time to ultimately develop highly integrated information systems around their business areas. Because BAA takes so long, most businesses analyze only one or two areas at a time, preferably those identified as most crucial in the strategic information architecture.
Note One challenge facing those organizations that analyze business areas is simply keeping up with application demand. For any given business area, the planing analysts may identify several applications development projects. While Systems analysts and applications programmers tackle those projects, the planning analysts generally move on to another business area, defining still more projects, and so forth. The growth in planned projects can easily exceed resources for those developing the applications. Fortunately, modern systems development technology offers some hope for keeping up with this demand.
Once again, this phase is facilitated by the same planning analysts who facilitated development of the information architecture. Systems analysts who will ultimately develop the applications are also frequently added to the team. Although most executive managers are excused from the phase, all managers in the specific business area must be involved in order to identify the applications
needed and prioritize the projects to develop those applications. Some system users may also become involved.
The key inputs are the Information systems plans and business area(s) from the previous phase. Additionally, the analyst collects facts and opinions from appropriate system owners and system users.
The key deliverable of the phase is planned applications development projects that will eventually be passed onto systems analysis. This deliverable will normally include documentation that can serve as a useful first draft for many systems analysis deliverables. The plan often calls for rather dramatic changes to how the business area will conduct business (fewer people, less bureaucracy, etc.).
There is no feasibility/scope checkpoint at the end of the phase. Why? The planning process has defined and prioritized projects. Only one question remains: When do we (can we) commit resources to the development of those planned applications?
This completes our survey of the systems planning phases. As a closing note, detailed coverage of systems planning is not generally included in the first systems analysis and design course. At some point it will probably become mandatory.
The following are the links that makes my resource answer.
http://timberry.bplans.com/2009/02/some-key-questions-on-business-plans.html
http://articles.bplans.com/writing-a-business-plan/what-is-a-business-plan/33
http://newton.uor.edu/Courses/SysAnaDes/planning.html
