Showing posts with label information. Show all posts
Showing posts with label information. Show all posts

Friday, April 3, 2009

Understanding Clear Messages

For executives, communication is a critical part of leadership.

The essential elements of sending clear messages include:
  1. conceiving your messages
  2. sending your messages
  3. monitoring your messages.
Conceiving your messages
There are a number of steps that you can follow to create a clear message. These are shown below:
  1. The first step in creating a clear message is knowing why the message needs to be sent. You could be requesting information or asking for a specific action. Carefully consider the reason for your message before you craft it.
  2. Focus on who it is you're contacting. The greater your awareness of that person and his or her concerns, the greater the effectiveness of your message.
  3. Believe that the details of the message already exist within you. Learn how to let this information come to the fore, and distinguish between the details that are important and those that are extraneous.
Sending your messages
The second stage of communicating her message is choosing the means of delivering her message and actually sending it.

If the message dictates a personal delivery and you can't go yourself, consider a spoken form such as a messenger, a telephone call, or a videotape. However, if the message is nonpersonal, technical, or routine in nature, then consider delivering it via letter, e-mail, news release, or organizational publication.

Monitoring your messages
The last step that you have to consider before sending your message is how you are going to monitor the receipt of the information and whether or not it was understood.

The following are a few key ideas about following up after the message is sent:
  • Set up a way to check whether the message was received, understood, and retained.
  • If the recipient didn't receive the message, find out why and correct the problem.
  • Make sure you have the attention of the person to whom you're sending the message.
By carefully following the steps to sending a clear message and understanding the key elements of the process, you can effectively communicate information.

Friday, March 27, 2009

The Benefits of a Risk Database

William Pollard, a businessman and author, once said, "Information is a source of learning. But unless it's organized, processed, and available to the right people in a format for decision making, it is a burden, not a benefit."

A risk database is a repository that can organize, process, and format the information that is collected and used in the risk management processes. The use of a risk database throughout a project's life cycle will make documented information easily accessible for important decision-making purposes.

Project risk information that you may need to store in a database could include agreements, current priorities, specifications, project plan changes, instructions, results, and other information depending on the nature of the project.

You must enter information into the database on a regular basis so that this information is up to date.

You can use a risk database not only for storing and retrieving data, but also for analysis. A database can sort information into categories and generate reports based on what you need to know.

The database can perform complicated calculations in seconds, which provides information that may help decision makers avoid mistakes. You can analyze project information for risks and alert team members about any emerging risks.

Over time, your company will gain experience in keeping track of project risks in a risk database. This documentation can be compiled for a single project or across similar projects, and be used as lessons learned for future projects. Prior to planning new projects, team members can search through the lessons learned to avoid making similar mistakes.

You can use a risk database to help you avoid mistakes and plan effectively for future projects. A risk database can organize and format information so that it is a learning source to help you make important project decisions.

Tuesday, May 6, 2008

Historical Information Sources for Cost Estimating

Have you ever made an important project decision based on a similar situation in the past? Historical information and estimating publications are important inputs to cost estimating because they serve as benchmarks.

In project management, historical information is information about previous projects that can be used to help with a current project. Four sources of historical information a project management team can use for cost-estimating purposes are discussed below.

1. Project files
In all likelihood, your current projects are not that different from projects your company has done in the past. Each of these finalized projects should have a file, whether it is a "hard copy" file in a cabinet somewhere, or an electronic file.

You should consider both similarities and differences between past and current projects when consulting closed-out project files. One way to do this is to carefully compare the project scope statements.

An essential part of project management is keeping complete files of all planning inputs, work results, performance reports, and correspondence. If external organizations also worked on a project, you could obtain copies of their records for the project as well.

The documents most relevant to cost estimating are previous cost estimates, budgets, reports on cost performance that include actual costs, and documents that show the rationale behind revised cost estimates and budget changes.

Knowing how useful project files are to future projects should motivate you to keep every output your project management process generates. For example, you could implement a system for document retention within your project team, make sure that all stakeholders know that you want to keep all documentation in a central project file, set up a shared directory on your company's computer network where documents can be stored and backed up, and keep records of the reasons for cost variances, even when it causes embarrassment for the cost estimators.

2. Project team knowledge
The knowledge of your project team members is another form of historical information. Employees with experience and maturity are a great asset when it comes to cost estimating. They can draw on their experiences when cost estimating, since they likely will recall cost information about the various projects on which they have worked.

3. Commercial cost-estimating databases
Commercial databases are another source of historical information from which you can obtain cost information about previous projects. Publicly-owned corporations are required to make such information available. Other companies charge fees for access to databases that compile this information.

If you find a number of projects similar to yours in a database, compare them to your project and make adjustments for differences. You should be able to arrive at fairly accurate cost estimates for your project. Remember that certain factors, such as inflation, need to be considered when basing current cost estimates on former projects.

4. Estimating publications
Estimating publications are similar to commercial databases, as they contain commercially available analyses of raw data that can be used to prepare estimates. These publications help team members who are preparing cost estimates customize general information to their specific project. This streamlines the cost estimating process and increases efficiency.

Estimating publications can include such resources as computer software programs, industry-specific case studies, and periodical articles. These resources can provide you with useful project data in a reasonably short amount of time.

Of the four sources discussed above, project files contain the most reliable cost information. Project team recollections are useful, but they are generally far less reliable than documented results. Historical information and estimating publications are a great starting point for cost estimating. Remember to use the cost estimates that were proven accurate so you can avoid making the same errors again.

Thursday, February 28, 2008

Detailing Supporting Data and Resource Requirements

Have you ever had so much to do that you needed a little extra help? Or have you ever overlooked something that was very important?

Supporting detail and resource requirement updates are two essential outputs from project schedule development that can help you effectively manage your time.

Supporting detail includes all identified assumptions and constraints. Included as part of a project schedule's supporting detail are:
  • times when resources are required
  • best- and worst-case scenarios
  • schedule reserves
  • schedule risk assessments
The amount of additional detail depends on the project. If you were to look at the supporting detail for a large construction project, you might see items such as a resource histogram (a graph that shows the amount of project resources), cash flow projections, and an order and delivery schedule.
Whereas, if you looked at the supporting detail for a small electronics project, you might only see a resource histogram.

Have you ever heard the saying "There are no guarantees in life"? Well, the same is true for the life of a project. For this reason, updating the project's resource requirements is a very important component of the project schedule development process.

Throughout the course of your project, events may arise that require the project's resources to be adjusted or activity lists to be updated. Adjustments of this nature will likely have a significant effect on preliminary estimates of resource requirements. Therefore, in order to maintain a degree of accuracy, the resource requirements will need to be monitored and updated to reflect the changing demands of the project.

Vinyl-Win is developing its project schedule for the production of a packaging machine. The project team has been notified by senior management that its client would like two machines instead of one, produced in the same time frame. This change requires the project team to update the resource requirements for the project.

The original schedule includes the resources to develop one machine. The amount of resources is not enough to produce two machines in the same time frame, so the resource allocation will have to be changed. Then the schedule needs to be updated to include the resources needed to produce two machines.

Since change is constant, it is virtually impossible to complete a project without having to make adjustments to the plan. However, understanding the importance of detailing all the project's supporting information will eliminate the need to make changes to your project. This will also reduce the need to update your requirements.

Tuesday, February 26, 2008

Presenting Schedule Information Graphically

Everyone follows a schedule of some sort—a meal schedule, an exercise schedule, or a meeting schedule. In the area of project management, a schedule includes a list of project activities along with the planned start and expected finish dates for each part of the activities. This schedule may be presented in summary form or in detail using either a tabular or graphical format.

The tabular format presents the information in a table. The tabular format is very rarely used, as the information it presents is hard to read and understand.

The graphical format presents the information in the form of a diagram or chart. It allows the project manager to visualize the schedule.

When it comes to presenting schedule information graphically, you have a number of choices. The most common graphical presentation formats are the project network diagram (PND), Gantt chart, milestone chart, and time-scaled network diagram.

A project network diagram (PND) is a schematic display of the project's activities and the logical relationship between them. Each planned activity is numbered on the PND. For example, the number 1 could be Activity 1—the architecture and design of the project. Number 2 could then be the foundation work.

A Gantt or bar chart is the most convenient, commonly used, and easiest-to-understand format of data presentation for project planning, resource scheduling, and status reporting. It shows start and finish dates as well as the expected durations for each project activity.

A milestone chart is a summary-level schedule that identifies the major activities or deliverables of the project. It can become the skeleton for the master schedule. A milestone typically marks the end of an event or the completion of an activity.

A time-scaled network diagram is a cross between a Gantt chart and a PND. It displays the project logic, activity durations, and schedule information. The positioning and length of the activity arrow represent its duration.

Remember, there are a number of formats that your company may choose from when creating a project schedule. Determine the individual needs of your project and the key stakeholders, then make your choice based on those needs.

Sunday, February 24, 2008

Coding Project Data for Extracting and Sorting

As a project progresses, project managers need to sort tasks based on their attributes. The easiest way to do this is to take advantage of the coding structure capabilities of whatever project management software you are using.

Project activities should be assigned a coding structure that will allow them to be sorted or extracted based on attributes such as, responsibility, geographic area or building, and project phase.

Sorting using the responsibility attribute will provide information about who is responsible for an activity. This may be an individual, a group, or a team.

The geographic area or building attribute tells you where an activity will take place. The geographic area may be a specific location such as the Dickson Building, or a general area such as a client's site.

The project phase attribute refers to a particular stage of development. Sorting by project phase will provide information about which activities will occur during specific phases of the project.

Jennifer is the project manager for BMR Railway's passenger car renovation project. She needs to find out several important details about project activities, and she needs them in a hurry. With a properly configured coding structure Jennifer will be able to quickly sort and retrieve this information.

Using the responsibility attribute, she is able to find out that four activities are being overseen by the project's lead designer.

Using the geographic area or building attribute, Jennifer discovers that 9 out of 10 project activities will occur at the rail yard on Wilber Avenue East.

Using the project phase attribute, Jennifer learns that the seat-recovering activities will be taking place during the second phase of the project.

As a project manager, you will be called on to sort and extract project-related data. By using a properly configured coding structure, you will find you can quickly and easily isolate the information you need.

Thursday, January 10, 2008

Historical Information and Project Activities

Historical information is an invaluable input to project activity duration estimating. As a project manager, you can use historical information, in the form of past project data, to make estimates on current similar projects.

For example, on a past project, John's company, Quick-as-a-Wink Computer Consultants, took five days to complete the audio for a two-hour software project. Based on this previous experience, John estimates it will also take five days for audio on the current two-hour software project.

There are many sources of historical information available to a project manager. You can start by checking the following three sources.

1. Project files
Past project files provide a fountain of information for project managers. A company may maintain records of previous project results that are detailed enough to aid in developing future duration estimates.

For example, John needs to know how long it will take to install a hub for a computer network system. John remembers installing a similar hub on a previous project. By retrieving the previous project files, John is able to find the information he needs. Since the first hub took 11 days to install, John will plan for 11 days on the current hub installation project.

2. Commercial duration estimating databases
Historical information is also available commercially through databases. These databases tend to be extremely useful when the activity duration is not driven by the actual work content.

For example, John needs to determine how long it takes a government agency to respond to a request for a license. John can contact a commercial duration estimating database company, which keeps information of this type on file. For a fee, the company will sell the information to John.

3. Project team knowledge
Another source for historical information is individual project team members who have worked on a similar project in the past. They can sometimes provide estimates of how long it took to complete the previous activity.

Remember, historical information can be a powerful tool for project managers. Don't be condemned to repeat the past. Instead, learn from it by using historical information.

Tuesday, October 2, 2007

Understanding Clear Messages

For executives, communication is a critical part of leadership.

The essential elements of sending clear messages include:
  1. conceiving your messages
  2. sending your messages
  3. monitoring your messages.
Conceiving your messages
There are a number of steps that you can follow to create a clear message. These are shown below:
  1. The first step in creating a clear message is knowing why the message needs to be sent. You could be requesting information or asking for a specific action. Carefully consider the reason for your message before you craft it.
  2. Focus on who it is you're contacting. The greater your awareness of that person and his or her concerns, the greater the effectiveness of your message.
  3. Believe that the details of the message already exist within you. Learn how to let this information come to the fore, and distinguish between the details that are important and those that are extraneous.
Sending your messages
The second stage of communicating her message is choosing the means of delivering her message and actually sending it.

If the message dictates a personal delivery and you can't go yourself, consider a spoken form such as a messenger, a telephone call, or a videotape. However, if the message is nonpersonal, technical, or routine in nature, then consider delivering it via letter, e-mail, news release, or organizational publication.

Monitoring your messages
The last step that you have to consider before sending your message is how you are going to monitor the receipt of the information and whether or not it was understood.

The following are a few key ideas about following up after the message is sent:
  • Set up a way to check whether the message was received, understood, and retained.
  • If the recipient didn't receive the message, find out why and correct the problem.
  • Make sure you have the attention of the person to whom you're sending the message.
By carefully following the steps to sending a clear message and understanding the key elements of the process, you can effectively communicate information.

Wednesday, August 1, 2007

Historical Information and Scope Definition

Norman Cousins—writer, editor, and renowned Federalist—once said, "History is a vast early warning system."

Information from past projects can serve as an early warning system for your current project by giving you considerable insight when you're defining project scope. This type of scope definition input is referred to as historical information. Information from past projects that will be helpful in defining the current project scope includes the following.

1. Previous project documentation
You can find previous project documentation in the form of outputs from other planning processes. When collecting historical information, you should limit your search to documentation generated from similar projects.

The emphasis should be on identifying areas in which other similar projects were particularly successful. This information is easily found in the project development data that is included within a project's scope specifications.

You also should look for information that may have caused problems, such as scope omissions. This information is commonly found in the lessons learned output created during project wrap-up.

2. Personal experience
You also can gather historical information from personal experience. For example, the first working experience with a client provides insight into that client's preferences. Since you already know the client's likes and dislikes, you can apply this knowledge to your next project and make scope definition changes in advance.

You also can draw on the personal experiences of your co-workers. For example, a person who has worked on a project similar to the one for which you are defining the scope may provide you with useful information.

The lessons learned from previous projects provide early warning signs for potential project scope problems. Using historical information as an input to scope definition will result in more successful projects and happier clients.

Sunday, July 1, 2007

Elements of a Project Information Plan

In the IT project life cycle, outputs of one phase become the inputs to the next phase in the cycle. Since planning is the first phase conducted, where does the project team get its information to conduct the key planning activities?

The project team's information comes from the information plan. The information plan is an input to the planning phase and is obtained from the management team and the client.

The information plan provides a high-level description of the project's information systems and related business objectives. This plan is always the first document created for a project. Every information plan should contain a brief overview, as well as the following five sections.

1. Needs analysis
The needs analysis is a set of procedures undertaken to set priorities and make decisions about a product, based on the client's request. To conduct a needs analysis, the project manager (PM) interviews the client and reviews the project's schedule, resources, and budget to obtain information. During the information gathering process, the PM should follow the steps listed below.
  • Identify the business need. The PM restates the project request to make sure it is clear and asks why the client wants to invest in a product. Three of the most common needs are to generate revenue, reduce expenses, or comply with regulations. The PM then asks for a tangible goal that will result from satisfying the need.
  • Identify the gap. The gap is the difference between the client's current state and the desired state of technology that the project's product will help the client to achieve. The PM must ask the client what the current state of affairs is and what the client ultimately expects from the final product.
  • Identify the tasks involved. With the help of the client, the PM identifies what tasks the end users will perform when using the final product.
  • Identify the user groups. The PM asks the client who the intended users of the proposed product are. The PM also needs to obtain from the client a description of any user trait that might affect how the product is developed.
  • Identify any project constraints. Finally, the PM should identify any constraints. A constraint is anything that could potentially limit the success of the project.
If you have followed all of these steps to gather information, you should have the information you need to create the needs analysis section of the information plan for your client's project.

2. Project goals
The next section of the information plan, goals, contains two parts. First, it states the business objective and explains how the product will contribute to revenue, contain expenses, or comply with regulations. This information is obtained from the needs analysis section. The second part outlines product evaluation and explains how the customer can determine if the final product has achieved its goal.

3. Form of the product
The form of the product describes the medium you will use to deliver the product and the reason you chose that medium. You will have to choose the medium that best fits your product and that most efficiently distributes the information to the intended users. The available choices include mediums such as:
  • CD-ROM software packages
  • networks
  • network-installed applications
  • downloadable Web packages.
4. Product function
The next section, function of the product, briefly describes what the product will do for the company or the reason why the product was created.

5. Quality guidelines
The fifth section, quality guidelines, outlines the standards that the product must meet to be accepted by management and the client. A project usually has two types of guidelines.
  • Product guidelines affect production and the product's appearance. These guidelines cover such areas as programming languages and templates to be used, grammar standards, and a viewing platform for the final product.
  • Project guidelines affect time, money, and resources needed to complete the project, such as schedules or budgets.
Remember, the information plan is created during the project conception and is used as an input to the planning phase. It will provide the reasoning behind the design choices the project team will make. Without a complete information plan, the PM will not have the necessary information to achieve the project plan sign-off milestone that must be met to complete the planning phase and begin the analysis phase of the project.