Outputs of Risk Management Planning

Do you know where to begin when it's time to identify your projects' risks? You should review the outputs of other project management processes before risk identification begins. The other project management processes are the risk management plan and other planning outputs.

The risk management plan
One of the planning outputs that you should review before identifying risks is the risk management plan. You should review the risk management plan because this is the document that describes how risk management activities for the project will be performed. It describes how risk identification, qualitative and quantitative analysis, response planning, monitoring, and control will be structured and performed during the project life cycle.

Lulu, a project manager at Beacon Corporation, develops a risk management plan for the Smart-Mart department store development project. The Smart-Mart risk management plan describes how Lulu and her team will approach an examination of the risks involved with this development and how they might address these risks. Lulu makes certain that the plan is comprehensive because she knows that it will serve as a guideline for risk management throughout the project's life cycle.

In the risk management plan, Lulu doesn't focus on the responses that will be taken for specific risks on the Smart-Mart project. Instead, it is a holistic overview of the risk management approaches that Lulu and her team will use for the Smart-Mart project.

Other planning outputs
There are eight categories of other planning outputs.

• project charter - The project charter is a document issued by senior management that formally authorizes the project. It provides you with the authority to apply organizational resources toward project activities.
• work breakdown structure (WBS) - The WBS is a grouping of the project elements that organizes and defines the total work scope of the project, based on deliverables.
• product description - The product description is a list of the features and functions of the product.
• schedule and cost estimates - Schedule and cost estimates are estimates of likely dates and costs involved with your project.
• resource plan - The resource plan is a description of the people, equipment, and materials needed to perform project activities.
• procurement plan - The procurement plan is the information about what needs to be purchased and when it needs to be purchased in order to carry out your project successfully.
• assumptions lists - An assumptions list contains the factors that are considered givens for your project.
• constraint lists - A constraint list contains the restrictions that will affect when your project activities can be scheduled.

After Lulu reviews the risk management plan, she examines the other planning outputs she should review as inputs to risk identification for the Smart-Mart project. First, she reads the Smart-Mart project charter. She thoroughly examines the human resources and the budget that have been allocated for this project because these two variables will have a significant impact on the way she manages the project. She also examines the WBS to see who should be doing what and the dates when each step should be completed.

Lulu notes the description of the Smart-Mart development. She wants to present the client with the exact building and layout requested. The schedule and cost estimates are clearly outlined on a graph that Lulu posts on a wall in her office and on a wall of the management trailer on the construction site.

Lulu examines the resource plan to see which Beacon employees should be placed in management positions for this project and to place accurate requests for building materials and supplies.

Lulu also reviews the procurement plan for Smart-Mart. This plan outlines what building and software materials will need to be purchased by specific dates. This will help Lulu place the orders on time and keep development moving at an acceptable rate.

The constraints list shows Lulu that lumber and concrete availability will affect when building activities can occur.

The fact that unionized construction workers receive a certain salary rate is a component of the assumptions list that Lulu examines.

The following list shows the name of each of the other planning outputs followed by the form they took in Lulu's project.

• Project charter - human resources and budget
• WBS - roles, responsibilities, and completion dates
• Product description - building and layout
• Schedule and cost estimates - available graph
• Resource plan - management positions and building materials
• Procurement plan - purchase materials
• Assumptions list - employee salaries
• Constraint lists - material availability

When Lulu reviews the project's other planning outputs, she familiarizes herself with all aspects of the project—such as scope, schedule, costs, and requirements—so that she can identify any areas that could be potential risks. Like Lulu, you will want to review the risk management plan and other planning outputs before you begin to identify risks. This process will make you more competent at risk identification.

What Are the Inputs to Risk Management Planning?

In his famous book, "Poor Richard's Almanac," Benjamin Franklin wrote, "An ounce of prevention is worth a pound of cure." What might this mean in the context of risk management planning?

Prevention seems like a common sense idea, but achieving it does require some thought. Remember that projects are often long and complex and that they involve large amounts of money and other resources. Therefore, it's important to plan your risk management approach so that an "ounce" of risk prevention is in place.

You will use several different types of information and documents as inputs when planning for the management of your project's risks. The inputs used in risk management planning are the:

• project charter and work breakdown structure (WBS)
• organization's risk management policies
• defined roles and responsibilities
• template for the organization's risk management plan
• stakeholder risk tolerances.

The project charter and the WBS are key documents you use when planning risk management activities. Some of these activities are budgeting, scoring and interpretation, and tracking.
The project charter is a document that formally authorizes a project. It includes the business need that the project is undertaken to address.

The WBS is a deliverable-oriented grouping of project components that organizes and defines the total scope of the project.

When it comes to an organization's risk management policies, every organization is different. Some organizations have predefined approaches to risk analysis and response that need to be tailored to match individual projects that are carried out by the organization. It is your responsibility to know whether or not your organization has these predefined approaches. If it does, you need to make sure that you tailor and apply the predefined approaches to risk analysis and response to the project you are managing.

Another input to effective risk management planning is the defined roles and responsibilities. These include the predefined roles, responsibilities, and authority levels of the people that will influence project planning.

Templates for the organization's risk management plan are used as a format for creating the risk management plan. Many organizations have developed templates that are also known as pro-forma standards. Project team members adapt the template to their current project. Companies continuously improve the template based on its application and usefulness to the project.

The final input to risk management planning is stakeholder risk tolerances. Different organizations and different individuals have varying tolerances for risk. These tolerances may be expressed in policy statements or in actions.

The starting point of any risk management planning process must include inputs. Without them, the effect of your risk management planning would be like trying to take medicine from an empty bottle: no inputs, no positive benefits. Understanding the inputs used in planning risk management activities is basic to a sound project management approach at any level of expertise.

Project Quality Planning Tools: Benchmarking

Did you know that project management can be similar to detective work? The benchmarking process (BMP) is like an investigation. It involves searching through available clues, finding leads, and then following up on those leads to understand the processes of world-class companies.

The BMP compares the performance of one company against another that is best-in-its-class. This is an effective tool and technique for quality planning.

Why should you perform a BMP? There are two main reasons for benchmarking—setting goals and process development. The BMP also will help you to know yourself, understand your competition, and define and integrate the best processes into your organization.

The benefits of benchmarking far outweigh the costs or effort involved. Benchmarking will:

• improve customer satisfaction
• define the best processes
• improve already-existing processes
• promote a desire to improve and change
• identify your competitive position
• improve the relationship between benchmarking partners.

The BMP provides information about where a company stands when compared to standards. These standards are set by customers, companies, certification organizations, and industry associations. The BMP will indicate the areas of strength within a company and uncover opportunities for improvement.

There are four common types of benchmarking assessments: internal, competitive, world-class operations, and activity-type benchmarking. Details are provided below.

• Internal benchmarking. This type of benchmarking usually takes place first. It involves examining your own organization and determining the best practices observed. It's easy to carry out, and matters of security and confidentiality do not exist.
• Competitive benchmarking. This is also called reverse engineering. It involves studying a competitor's services, products, and processes. The easiest way to do this type of benchmarking is to buy the competitor's product or service and then analyze it.
• World-class operations benchmarking. This benchmarking type takes the BMP past a specific type of organization to one that is different. It's a useful technique for discovering innovative processes not currently used by an organization.
• Activity-type benchmarking. This type of benchmarking examines specific process steps or activities that go beyond specific industries. It includes activities such as recruiting, invoicing, and engineering change control.

The benchmarking process is a useful tool and technique for quality planning. It's natural that companies want to immediately visit a top-notch organization as their first BMP activity. Although doing this is a part of the BMP, it's not the only activity that should be performed. There are six separate stages for every BMP.

• Process design (planning). Select one quality process to study at a time. Form a team of people involved in the process you wish to study. Determine the measurements you will use.
• Internal data collection. Know your own practices and performance. This can be done using such techniques as system and process flowcharts, or cause-and-effect diagrams.
• External data collection. Select a competitor in the same or different industry as your company. Select one that is best-in-its-class for the process you are studying.
• Data analysis. Compare the information gathered with the information from your own company.
• Process upgrading. Based on information you have learned from your competitor, identify which ideas can be adopted for your own process and decide how they can be implemented.
• Periodic reassessment. Monitor the effectiveness of the new ideas and re-benchmark them at specific intervals of time.

Effective benchmarking requires choosing the specific benchmarking type and completing the appropriate steps. This process is not just about uncovering the secrets of your competition—it includes learning about yourself.

Project Quality Planning Tools: Flowcharting

Just as road maps are useful tools for reaching your destinations, flowcharts are the road maps used to reach project quality. A flowchart graphically represents a process and its activities in almost the same way a map represents an area.

Flowcharting is an effective quality planning tool you can use to describe an existing process or a proposed new process. You can use flowcharts when charting work on an object, when charting workers' tasks, when charting an operation or inspection process, and even when brainstorming.

For quality planning, flowcharting can help you identify problems in a process. Flowcharting will also:

• result in disciplined thinking
• facilitate communication about problems
• illustrate how different elements fit together.

Some flowcharts are recorded in a narrative form, like an essay. For example, first you do this, and then you do this, and then you do this, and so forth. However, this method can be vague and hard to follow. Using charts and diagrams to map a process can allow information to be more clearly and easily understood.

There are 12 standard flowcharting symbols that indicate what is done to a product from one step to another. Everyone using this method on a project must understand the meaning of each symbol. Process information is placed inside or beside the symbols. Various symbols indicate an operation or an activity, movement or transportation, decision points, inspection, paper documents, and delay.

Symbols also indicate storage, annotation, direction of flow, transmissions, connectors, and boundaries, which are the beginning or end of a process. It's important to understand these symbols and how they add to the flowcharting process.

Flowcharts do not have to be drawn by specialists. They are researched and drawn by quality improvement teams. However, some training is usually necessary to draw an accurate flowchart.

Drawing a flowchart is drawing a picture of a process. With some training and practice, process flowcharts can be somewhat straightforward to create. To create a flowchart, follow the steps outlined below. Keep in mind, however, that drawing your first process flowchart is not easy. If necessary, quality improvement teams can call on an expert in their field to contribute to the process.

• Step 1: Define the process steps. As a team, brainstorm to talk through the steps in the process. For an already existing process, examine the process in action. Suggestion: Write the steps on sticky notes.
• Step 2: Sort the steps in order. Identify what is done at each step. Suggestion: Use the sticky notes from Step 1 and sort them in the proper order.
• Step 3: Place the steps in the appropriate symbol. Use the standard symbols to sketch the flowchart. Suggestion: Make a rough copy at first. Then rework the graph to fix errors.
• Step 4: Evaluate the steps. Check for completeness, efficiency, and problems. Review the actual process and then make any necessary revisions to the flowchart.

For every quality effect or problem in a project, a cause must be identified. Cause-and-effect diagrams, also called Ishikawa diagrams or fish-bone diagrams, focus on the causes of problems instead of the problems themselves. Cause-and-effect diagrams are often used in brainstorming sessions because they act as visual displays for breaking large problems into manageable parts. Follow these steps to construct a cause-and-effect diagram.

• Step 1: Identify the problem or effect. Place a concise statement of the problem or effect in a box at the end of a horizontal line.
• Step 2: Identify the causes. Identify the causes of a problem or effect in a brainstorming session by focusing on one cause at a time. Discussions usually will focus on methods, materials, people, information, machines, and environment. Identify any subcauses.
• Step 3: Build the diagram. To build the diagram, organize the causes and subcauses into the diagram layout. Each branch represents cause-types such as materials, machines, and people. The subcauses connect to these branches.
• Step 4: Analyze the diagram. Identify potential solutions weighing the cost-effectiveness and achievability of each solution.

Drawing a flowchart or diagram involves creating a picture of a process or effect. Both act as visual displays that assist with problem-solving. Once you and your project team become accustomed to using these tools for quality planning, they'll become an automatic part of your processes.

Quality Planning Benefit/Cost Analysis

Since it costs money to implement project quality planning in your organization, it's important to understand the benefits of quality planning, so you can justify these costs if necessary. In addition, knowing the benefits of meeting quality requirements makes tasks more meaningful and successful. The four main benefits of meeting quality requirements on your projects are:

• less rework
• higher productivity
• lower costs
• better customer satisfaction.

Weighing benefits against costs can help with the major decision-making issues of a project. A benefit/cost analysis involves estimating the costs and benefits of meeting quality requirements, and then assessing the available project options. The benefits, of course, should outweigh the costs. The general procedure for analyzing benefits and costs is explained below.

• Analyze the plan, decision, or process by examining its activities and events.
• Calculate or estimate the benefits and costs related to each element.
• Compare the sum of the benefits and costs.

Subtracting the costs from the benefits should always produce a positive number. A negative number indicates the benefits are not worth the expense.

Benefit/cost analysis is a useful tool for project quality planning. It's a simple procedure you can use to determine if the benefits of quality planning outweigh the costs.

Categorizing Project Quality Planning Costs

It's a fact—projects cost money. However, even though planning for quality costs money, it's well worth the expense. People will remember poor quality much longer than a timely delivery or cheap price. In today's market, mistakes regarding the quality of a product or service can be expensive for everyone.

To meet quality requirements, projects must incur some primary planning costs. These costs can be divided into four main categories—prevention costs, appraisal costs, failure costs, and intangible costs.

Creating quality products and services requires an understanding of all of these costs. When project managers understand quality costs, it's easier for them to make decisions about such things as investing in a process, designing revisions, or changing procedures. The total quality cost of a project is considered to be the sum of the four main categories discussed below.

• Prevention costs. Prevention costs occur from activities that prevent poor quality in products and services. Such costs help ensure the customer's requirements are met.
• Appraisal costs. Appraisal costs are linked with measuring, evaluating, or auditing products and services. This can include material reviews, incoming inspections, work-in-process inspections, and final inspections or testing.
• Internal and external failure costs. Internal failure costs are associated with not meeting customer requirements prior to when the product or service is provided. External failure costs occur when the nonconforming product reaches the customer.
• Intangible costs. Intangible costs of poor quality are hidden costs that involve the company's image. They can be three or four times greater than tangible costs. Missing a deadline or other quality problems can be intangible costs of quality.

Identifying and utilizing the four primary costs in effective quality planning will help ensure that your product is a success. Recognizing that prevention costs, appraisal costs, internal and external failure costs, and intangible costs are valuable tools and techniques to the quality planning process will result in greater satisfaction for all stakeholders.

Standards, Regulations, and Project Quality Planning

Rules are everywhere. People are bombarded by rules in the form of standards and regulations. Do you know the difference between the two?

Quality planning requires you to be familiar with the standards and regulations that affect your project. For many projects, these are well known and your planning will reflect them. The difference between standards and regulations is explained below.

• Standards. Although standards are approved by a recognized body, compliance with them is not mandatory. They are documents of rules, guidelines, or characteristics for projects, and will shape a project's product.
• Regulations. These documents outline the products, processes, or service characteristics of a project. Compliance to regulations is mandatory.

Standards and regulations are inputs to quality planning that can have a great effect on projects. As a project manager or member of a project team, you need to be certain your quality system is "up to code."

As with most things in life, rules are not always clear cut. There's a definite "gray area" between standards and regulations. A standard will sometimes begin as a guideline and then become a regulation. This happens when a standard becomes well-known and is widely used.

Another example of the "gray area" between standards and regulations is when each one is authorized at different levels. For example, the government requires pilots to have a national-level license for flying. At a company level, however, a pilot may be required to have a national-level pilot's license, 1,000 hours of flying time, 600 hours multi-engine flight experience, and 150 hours of night flying time.

Standards can help companies meet their quality goals. The International Organization for Standardization is an establishment that helps companies accomplish this with the ISO 9000 series. Companies that use the ISO 9000 standards follow documented procedures for the work they perform. It does not guarantee organizations will always produce good products. Instead, the ISO 9000 standards act as a tool for helping organizations meet quality goals and confirm they have a set of quality standards in place.

In summary, standards and regulations are important inputs to quality planning. Following them helps ensure that a project product is of good quality and meets stakeholder requirements.

Developing a Project Quality Policy

A quality policy, which is an important input to project quality planning, is a collection of documents that are usually created by quality experts and supported by top management. These documents state the overall quality intentions and direction of an organization.

Not all projects require new quality policies. If a quality policy already exists, it can be adopted for a new project. If a quality policy does not exist or if the project is a joint venture, the management team will be required to develop a new quality policy for the project.

A quality policy must indicate the level of quality the organization considers acceptable and must be applied at all levels of a project. Communicating this information is a vital step for quality planning. Project management teams need to distribute quality policy information in a timely manner to everyone involved with the project. As a project manager, you can communicate quality policies in the following ways.

• Use written communication, in the form of formal reports, informal memos, and conversations, to send out clear and complete information to those working on the project and to outside parties.
• You can share information with your team members using information retrieval systems such as manual filing systems, project management software, and electronic text databases.
• You can forward information electronically using fax, electronic mail, voice mail, video conferencing, and a company intranet or the Internet.

Quality policies state a company's quality goals. These policies help a company create a sound reputation for good quality. Key goals should include continuous improvement of the product or service, customer satisfaction, and effective delivery of the service. In addition, quality policies should:

• promote consistency throughout the project
• include quality objectives
• describe how organizations view quality
• detail guidelines for all important quality matters
• state principles of what will take place during the project, rather than how it will take place
• state requirements for updating the policy
• be understood, implemented, and maintained at all levels of an organization.

Quality objectives are important elements of a quality policy. Some typical quality objectives are:

• clearly defined statement of customer needs
• specific statements about deadlines
• commitment to avoid harmful effects on the environment and society
• reviews to identify opportunities for quality improvements
• commitment to quality throughout the organization.

Quality policies are essential inputs to quality planning. Top-level managers implement quality policies throughout the duration of projects. It can be challenging for managers to stay focused on quality and avoid getting sidetracked by other matters. Ultimately, the best way for a project manager to show support for quality is to "walk the walk."

Sources of Expert Judgment in Resource Planning

Who did you look to for advice when you were younger? Was it a parent? A relative? A teacher? Chances are you sought out someone who you felt had been through your situation before. Having lived through the situation made that person an expert on the subject.

In project management, you may find you need help in the form of expert judgment. There are various sources of expert judgment for the resource planning needs of your project. Where you go depends on what kind of information you need.

The primary sources of expert judgment in resource planning are:

• other units within the performing organization
  The first place to look for help with your resource planning needs is within other units of your company. Different departments have specialized knowledge, and they can provide you with their resource pool descriptions, work breakdown structures, and scope statements. And remember, when you use company resources, your company saves money by using skills it already pays for.
  

• consultants
  Consultants are another avenue you can look to for help with your resource planning. Consultants focus their knowledge in one specific field. When that field plays a role in your resource planning, you should seek out the person who knows the information inside and out.
  

• professional and technical associations
  Expert judgment can also be found in professional and technical associations. These associations may offer their members up-to-date industry training or provide information on the latest developments in your field. This could be useful for updating organizational policies and as a source of historical information.
  

• industry groups
  Industry groups are another source of expert judgment for resource planning. Industry groups are involved in setting industry standards and lobbying governments, and can refer you to important sources of information relating to your project.
  
  Industry group lobbying may necessitate changes to your company's organizational policies. It may also require you to upgrade staff or equipment. These actions would affect your resource pool description.
  
  Industry groups can also put you in touch with companies you are interested in doing business with, or that have similar interests. If you need specific materials or equipment, your industry group may be able to tell you who to contact. This would impact your resource pool description. It may also influence your scope statement. As you contact more people in relation to your project, you have a better idea of the possibilities.
  

Knowing where to go for expert judgment and advice means that as soon as you need information for resource planning you know where to get it. This saves time for you and your project team.

The Importance of Resource Planning and Acquisition Policies

Organizational policies are the policies of the performing organization regarding staffing and the rental or purchase of supplies and equipment. These policies must be considered during resource planning to ensure that your project will run as smoothly as possible.

Organizational policies are the result of tried and true business practices. Company policies can encompass a wide range of issues from employee benefits to resource acquisition.

Staffing issues are covered by your company's human resource policies. A collective bargaining agreement is a factor that might affect your company's policies. These agreements place restrictions upon employers concerning hours of work, wages, and job security. They can determine overtime, vacation pay, and safety standards. Consider the example of Kurt, a project manager for an appliance manufacturer.

Another example of staffing policies are company hiring policies. These policies may include equal opportunity programs, internal hiring practices, and educational requirements.

Not abiding by these policies can lead to employee dissatisfaction, high employee turnover, and even lawsuits. To avoid these potentially debilitating problems, you will want to commit your organization's staffing policies to memory.

The other policy areas of interest to resource planners are organization's equipment and materials policies. These policies specify how you are to acquire resources from suppliers.

For example, your company may have policies:

• requiring that all suppliers be approved by the Quality Assurance department
• listing preferred suppliers from which you must choose
• regarding each step of the acquisition process.

Other policies may exist to help you decide whether to rent or purchase the necessary materials and equipment. If a project requires equipment or materials for a short period of time, a company may determine it is cheaper to rent rather than purchase the equipment or materials.
Each step of acquiring resources may have an accompanying policy. Make sure you know what your company has determined regarding these resource decisions before you begin. Failure to abide by resource acquisition policies can destroy hard-won relationships with favored long-term suppliers and may result in significant increases in supply costs which could result in project budget overages.

Organizational policies act as a guide to ensure a quality project. They help your project run more smoothly because everyone knows what is expected in terms of resource planning and acquisition. In addition, these policies serve to protect against the negative effects of not abiding by policy, which can include employee lawsuits, damaged relationships with long-term suppliers, and increased project costs.

Planning Resources Using a Resource Pool Description

Before you begin working on a project, you need know if you have the resources to support it. This is where a resource pool description comes in. A resource pool description is a report that gives details about the people, materials, and equipment necessary to complete the project work.

People
To keep track of the human component of your project, you should compile a list of potential human resources. This list should include:

• the person's name
• whether she is an internal or external resource
• her resource type
• her skills
• the company or division she works for
• her supervisor
• her pay rate
• the anticipated project start and end dates
• her availability
• any vacation she may be eligible or already scheduled to take
• additional comments

Your human resource requirements may change as the project progresses and so may not have all the spreadsheet information at project inception, but you should strive to fill in as much information as possible before you begin assigning resources.

Equipment and materials
The information you need for your equipment and materials spreadsheet varies only slightly from your human resource spreadsheet. You would need to know:

• the resource name
• whether the resource is internal or external
• the supplier (source of the resource)
• the rate or cost per unit
• the resource location
• the resource availability
• a contact name
• the resource type
• specifications
• comments

Your resource pool description is not static. The different phases of a project may require different resources. That's why your list of possible resources may change as your project progresses.
You may need a large number of people working on your project to start with. As the project progresses, you may need fewer people, but with highly specialized skills. Or the opposite could happen. This means that you will constantly have to adjust your resource pool description.

Similarly, your project could require completely different equipment or materials, depending on which phase of the project you are working on. Your resource pool description should reflect this.

In addition to keeping track of what resources are "available," you should also keep track of the resources once you use them. This information is needed for accounting purposes and can also be used to estimate future resource requirements for future projects.

Your project plan outlines the type of work your project requires. Your resource pool description allows you to match the right resource to a specific task. As such, a resource pool description is an invaluable tool for the project you are planning now and for those you will plan in the future.

Key Activities of an IT Project

During the planning phase of the IT project life cycle, the project manager must complete three key activities, which will provide the foundation for the entire project. To complete these activities, the project manager will have to use a number of tools, such as word processing and spreadsheet software.

The three key activities project managers must complete during the planning phase are described below. As you review these activities, note that there are associated subactivities that will help the project manager successfully complete each key activity.

1. Project initiation and organization
The first key activity, project initiation and organization, involves identifying the work required to obtain management approval for the project and the subsequent planning of the work effort. The subactivities of initiating and organizing the project involve identifying the items listed below.

• The scope of the project identifies the key system objectives and describes the overall system function. It enables the development team to understand what the customer wants the system to do and what the team has to do to reach its goal.
• Applicable standards are any rules the development team must follow during the life of the project. These standards must be met in order for the customer to be satisfied with the project.
• The organization and training needs of the project team are identified and implemented in the planning phase so that the development of the product is not held up.
  

2. Project definition and planning
The second key activity, project definition and planning, is the largest of the three key activities, and will take the longest. It involves developing the project definition, and conducting the planning and estimation involved in the system's design.

The project definition is used as a major input to the detailed planning and resourcing that takes place as each phase of work is planned, initiated, and put into practice. Upon completion of this key activity, the project team will have a work plan that contains all the necessary information to move on to the next phase of the life cycle if management approves the project. The subattributes for conducting project definition and planning are shown below.

• Review present status. If any type of software is to be used in the development of the new system, the project manager should look at what is available on the market to see if it meets any of the project's needs.
• Identify business objectives and information strategy. The project manager should review the business and information plan to identify any requirements, guidelines, or strategies that the team should follow.
• Survey information needs. The information needs are acquired by assessing the needs of the end users. By assessing the functional and technical needs, the project team has a better idea of what the new system should be capable of doing.
• Identify hardware and software environment. To develop the conceptual design, the project team needs to know the software and hardware environments of the new system. If no environment has been selected by the client, the project team will select one.
• Develop conceptual design. The project team develops a conceptual design in order to communicate the basic functionality and behaviors of the new system. The conceptual design can be developed using drawings, flowcharts, or storyboards.
• Investigate packaged systems alternatives and evaluate development alternatives. Check to see if there is an existing system. If there is, it can be a valuable tool for the development team. The members of the team can rate the packaged system's strengths and weaknesses and determine what improvements need to be made.
• Prepare project impact analysis. The members of the project team prepare a report on the costs and benefits of the proposed system. They determine any risks and organizational impacts on the project.
• Finalize project work plan. The project team prepares a final report for management that covers the work that needs to be completed to create the project, and details the cost involved in creating the product.
  

3. Management review and approval
The last key activity, management review and approval, involves presenting the project definition and planning outputs for authorization to commence the project. Once management has granted approval, a sign-off is given, and the project can move on to the next phase.

During the planning phase, make sure that you conduct each of the three key activities described above. By doing so, you can help ensure the success of your project.

Planning for Future Project Development

What lessons did you learn from your last project? Whether the project was a success or not, it can teach you valuable lessons you can incorporate into your future projects.

However, applying lessons learned from past projects to future projects usually does not happen automatically. You must plan for future project development. By following the two strategies described below, you can ensure that you have an appropriate plan in place, so you can learn from past projects and manage future projects more effectively.

1. Gather project data.
You should begin by examining your data. If you have been documenting the progress of your project from the start, you can use the data you have collected to identify the most effective techniques to incorporate into your future projects. You also can implement the following three strategies to gather project data.

• Postmortem meeting. You can hold a project postmortem meeting, where all members can openly discuss the positive and negative aspects of the project. A postmortem meeting gives all team members an opportunity to discuss issues and brainstorm ways to eliminate similar problems in future projects. This strategy is useful only when participants have had a chance to review the project.
• E-mail summary. An e-mail summary from each participant is also a great strategy for gathering information on the good and bad aspects of the project. This strategy is useful when time is of the essence or when team members do not have time available to meet.
• Written reports. Written reports that describe the team members' experiences throughout the life of the project are useful when written documentation is required. For example, use this strategy when senior managers request a report.
  

2. Document the information.
Once the project information is gathered, it is imperative to document this data for future project development. There are three strategies you can use to document the information you've gathered.

• Develop a checklist. A checklist is effective as a reference tool for similar projects in the future. A checklist normally contains the positive points from the present project that your team can apply during specific stages of future projects.
• Create a top-10 risk list. A top-10 risk list contains negative points from your current project. It is an effective way to help your project team develop strategies for the elimination of similar risks in future projects.
• Prepare a formal report. You would prepare a formal report when documentation of both the positive and negative aspects of a project is required. For example, this strategy might be useful when the data requires a more thorough evaluation by senior managers.
  

Each project you manage will require the use of different strategies for gathering data and preparing this data for future project development. With a bit of foresight, you can easily determine the appropriate strategies for gathering and documenting data, and ensuring that lessons learned are applied to your future projects.

Outputs to the IT Project Phases

Think back to the last time you were in a bakery where the aroma of freshly baked bread teased your senses. Making bread may be less complicated than administering an IT project, but it follows a similar development process with inputs (ingredients), tools (oven), and outputs (a loaf of bread).

Using a recipe and the necessary tools, the baker expects outputs at each stage—a ball of dough made from various ingredients, a larger ball of raised dough, and finally a perfectly formed and delicious loaf of bread.

An IT project also produces outputs, which are known as deliverables. These outputs are the results derived from each of the IT project's six phases—planning, analysis, design, construction, testing, and rollout.

Outputs, or deliverables, can help your team keep a project on track. Well-planned outputs are also an effective way for managers, IT organizations, sponsors, and users to learn effective lessons from a project. Remember to focus on achieving benefits and objectives when determining the outputs that will be generated during each phase of your project.

There are a number of major outputs for each phase in an IT project. Not all phases have the same number of outputs, but all deliverables help you and your team achieve success with the end product. Examples of outputs for each of the six IT project phases are listed below.

Planning phase. An example of a planning phase output is the business case, which provides validation for any project decisions made. It acts as the framework for performing all evaluations and as the starting point for guiding the management of the project.

Analysis phase. An example of an analysis phase output is the requirements specification, which contains or refers to the definition and details about the data, event, and process models, as well as the project quality requirements.

Design phase. An example of a design phase output is the design document, which contains or refers to the application architecture and flows, database and user interface designs, and the workflow diagram.

Construction phase. An example of a construction phase output is a programming work unit. Programming work units lay the base for the development of project codes for testing aids and application and conversion programs. Other nonprocedural codes are also included when applicable.

Testing phase. An example of a testing phase output is the operating instructions, which can be in the form of manuals, installation procedures, or instructions for using the new system. These instructions would be accessible to all end users.

Rollout phase. An example of a rollout phase output is the post-conversion review document, which can contain specifics on the scope of the conversion process and details about any problems that have occurred during conversion.
It is important to be aware of the outputs for each phase of your project. As you move through each phase, you will begin to understand the relevance of the role of each output for the particular phase to which it belongs.
Outputs can help your team tremendously by providing direction and valuable methods of recording the processes followed throughout your project.

Inputs to the IT Project Phases

Have you ever heard the term "garbage in, garbage out (GIGO)"? This is a term used to describe the results you would receive if you entered insufficient or incorrect data into a computer, for example. It also applies to your IT project.

You should ensure that all of the information you use in your project is of good quality. Any project can be detrimentally affected by the use of poorly researched information.

With thorough planning, you will be better able to determine and gather the information you will need for your IT project. By documenting this information, you will have a road map for developing an effective IT project plan.

In project management, the documents or documentable items that are produced and will be acted upon are called "inputs." These documents contain all the information your team has researched to make the project run smoothly and efficiently.

There are a number of inputs to consider for each phase of an IT project. Not all phases have the same number of inputs, but all inputs are beneficial to the success of the end product. Examples of inputs for each of the six IT project phases are listed below.

Planning phase. An example of a planning phase input is the information plan, which contains an extensive description of the company's present systems and the objective of the project.

Analysis phase. An example of an analysis phase input is the conceptual design, which describes the scope, architecture, and other aspects of the new system in detail.

Design phase. An example of a design phase input is the business process prototype, which depicts the working functions of the new system or product. It also highlights crucial or problematic areas.

Construction phase. An example of a construction phase input is the design document. The design document of the construction phase can include references or details on application flow, database design, and a workflow design.

Testing phase. An example of a testing phase input is user documentation. This documentation includes user instructions and procedures that the end users will require. It also is appropriate to test the user documentation during this phase. This will help uncover and eliminate documentation errors that could result in the delivery of inappropriate instructions to the end user.

Rollout phase. An example of a rollout phase input is the current systems description. When designing a new system, it is necessary to document any changes that must be made to the old system to accommodate the new structure. These details are included in the current systems description.
By being familiar with the inputs of each phase of an IT project, you and your team can be more confident that you have given adequate consideration to all required tasks in the development of your new system or product.

The Six Phases of an IT Project

Have you ever heard the saying "putting the cart ahead of the horse?" If you wanted to move your cart forward, having the cart in front would not really help. In order to make progress, you would want to put the horse ahead of the cart.

Performing tasks in sequence is also an important aspect of IT projects. The phases of an IT project, also known as a software development lifecycle, make up the framework of an IT project. These phases, which are listed below in sequence, will help you to address the business needs of your project, and better define the activities that will occur throughout the project's entire life span.

1. Planning
First, you must look at the information technology needs of your company. These needs are determined during the planning phase of an IT project by using an information-gathering technique such as a questionnaire.

Keep in mind that the objective must address and remedy an issue or a problem within the company. Once you define the objective, you can put an action plan into place. A description of the development approach that the IT team will take and the estimation of the overall cost are factors that are determined during this phase.

2. Analysis
The analysis phase is the second phase in the software development lifecycle. This phase focuses on the functions the end system will need to perform.

Once you establish the performance needs, you will be able to develop and formalize a more detailed description of the system. The use of business, data, event, and process models during the analysis phase will ensure that both the development team and the end user are on the same track.

3. Design
The third phase of an IT project is the design phase. In it, the plan for the end system is developed. This plan should accurately define the implementation of the project without actually executing the project.

4. Construction
During the fourth phase of the project, the IT team actually constructs the project or system. In this construction phase, the team uses a process map that identifies the procedures that need to be completed to duplicate the agreed-upon plan.

5. Testing
The testing phase is possibly the most critical of all the IT project phases. It is in this phase that the team determines which tests to implement to ensure that the system being produced will be of the highest quality.

6. Rollout
The final phase in an IT project is rollout. It is during this phase that the team begins the activities for releasing the finished product to the end user. Planning for the rollout activities can help the process progress more smoothly.

For example, if another system is already in place, your team will need to thoroughly review the conversion process to ensure the smooth transition from the previous system to the new one.

Every organization should have a structure in place to deal with processes, principles, and guidelines for every IT project. The phases described above can provide a useful framework for the effective development and completion of your next IT project.