Showing posts with label activities. Show all posts
Showing posts with label activities. Show all posts

Sunday, January 13, 2008

Expert Judgment and Project Activities

Project managers can use the special skills or knowledge of experts when activity duration estimating. This is known as the expert judgment process. It involves consulting with groups or individuals with specialized knowledge or training. These people can provide ideas and the probability of occurrence based on experience. There are four sources of expert judgment available to help you on your project.
  • Other units or departments within the performing organization. Ideally, this is the best place to obtain expert judgment. It can be obtained at no cost to you. For example, if you need to know how long it takes to assemble an automobile, you can ask someone who works on the assembly line.
  • Consultants. Consultants can be hired from outside the company to serve as experts for a project. However, this source is expensive and can cause costs to rise on a project. For example, a company that specializes in natural gas may be hired to consult on a pipeline project.
  • Professional and technical associations. Professional and technical groups can provide expert judgment when the information needed is very detailed or technical. For example, if you need to know what the building code is for a residential home, you could ask the local builders association.
  • Industry groups. Industry groups can offer general information. For example, if you need to know how long it takes for cement to cure, a construction group would be able to answer your question.
Once you've determine which expert or group of experts can help you during activity duration estimating, you can use three techniques to obtain the expert judgment you need.
  • Interviews. Interviews can be on a one-to-one or a many-to-one basis. Interviews are conducted by asking a series of questions that will increase your knowledge of the project or a particular project activity.
  • Brainstorming. Brainstorming works by getting a group to focus on a problem and then coming up with as many solutions as possible. Once the session has resulted in a number of solutions, the results can be analyzed.
  • Historical data. Historical data uses the knowledge gained on a similar past project activity to obtain duration estimates for each activity associated with a current project.
While a certain technique might be appropriate in some situations, in others the same technique wouldn't give you the information you need. Interviews are best used when knowledgeable, experienced people are available at an affordable cost and specific information is needed, while brainstorming is best used when input from multiple experts is needed or when experienced people aren't available. Historical data is best used when records are accurate and both projects are similar.
There are many advantages to using the expert judgment technique for estimating activity duration. The advantages are that it:
  • allows for different perspectives
  • makes valuable use of prior knowledge and experience
  • helps you find creative solutions
  • helps you avoid re-inventing the wheel.
Expert judgment, like so many things, also has disadvantages. You have to be careful when using expert judgment, because it can be time consuming. It also can tie up experienced staff for many hours, to the detriment of other projects.
In addition, expert judgment can be costly if you have to go outside your company to hire experts. Another disadvantage is that experts may tend to downplay the fact that an activity took longer than expected on past projects.

Used wisely, though, expert judgment is a powerful and invaluable tool for estimating activity duration. It allows for different perspectives and more creative solutions. Most importantly, when you use expert judgment, your team will be less likely to re-invent the wheel.

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.

Wednesday, January 9, 2008

Resource Requirements and Project Activities

How many people does it take to install a computer network, write a user's manual, or analyze a customer's needs? What equipment is needed to deliver a training session? These questions may not be pertinent to every project, but it's important for you to know what physical resources it will take to complete any activity related to your project.

Physical resources can include any or all of the resources listed below, depending on the nature of the project.
  • People. This is the most important resource of all. It is also the most diverse resource the manager has to deal with. People come with a wide variety of skills. The manager's job is to match the possible skill sets with the project tasks.
  • Facilities. Facilities are where the project activities will be performed. The project manager has to take into account what kind and how many of these facilities are required. Availability of facilities can have a big impact on the project schedule and has to be taken into account.
  • Equipment. Specialized equipment may be needed for some projects. This equipment may have to be bought, rented, borrowed, or built. The project manager has to make sure that the equipment will be available according to plan.
  • Materials. If a project produces anything tangible, the raw materials to produce the product need to be managed. Materials have to be managed to ensure they are available when needed.
Project managers should develop a list of all the resources needed to complete a project. This list is known as "resource requirements." Resource requirements are descriptions of the types of resources required and quantities needed for each element of the work breakdown structure and are important inputs to activity duration estimating.
Resource capabilities are another input you should consider when estimating activity duration. Resource capabilities can have a direct effect on an activity's duration. For example, a person with more experience and skills will complete a job faster than someone who is unskilled.

The capacity of the materials used for a project also will affect an activity's duration. For example, a machine that runs at only 50 percent capacity will take twice as long to complete the activity as a machine that runs at full capacity.

Resource capabilities not only affect the duration of an activity, but they can also affect the resource requirements. For example, if workers are unskilled, more of them will be needed to complete a project on time. If workers have more experience, fewer people will be needed.

As a project manager, you should look at all aspects of a project's resources when estimating activity duration. Remember, resource capabilities can have a far-reaching effect on the duration of a project activity.

Monday, January 7, 2008

Constraints, Assumptions, and Project Activities

The PMBOK Guide describes a constraint as "anything that can limit the project management team's options." If a constraint is going to limit you, wouldn't it be better to completely avoid it?

Of course it would. Unfortunately, you cannot always avoid constraints, which can create risk. Therefore, project managers should learn to handle constraints—which are inputs to activity duration estimating—so their effects on a project are minimal.

There are two major types of constraints that a project manager must consider when determining the duration of an activity—imposed dates, which are required, and major milestones, which are requested.
  • An imposed date is a date that cannot be changed and must be met by the project team.
  • A major milestone is a project activity that upon completion will be delivered to the client.
Another input to project activity duration estimating is assumptions. Assumptions are factors that are considered to be true, real, or certain. Over the course of the project, these factors may turn out to be true or false.
Project managers should be extremely careful when making assumptions about a project. Assumptions carry a degree of risk and should be used only when the degree of certainty about the assumption is high.

Remember, constraints and assumptions can cause a risk to your project. With proper planning, you can minimize or avoid the impact of the risk.

Wednesday, December 5, 2007

Project Decomposition and Templates

To complete any task, you need to know what tools are at your disposal. Project managers who are engaged in defining project activities use two main tools to accomplish this task: decomposition and templates.

Decomposition
Decomposition means breaking a project deliverable down into a list of achievable activities.

Telecom Corp. is a telecommunications company. One service that it provides to its clients is the virtual private network (VPN). VPN project deliverables include a firewall, routers, encryptors, Internet service, IP backbone, and secure remote access.

The last deliverable could be decomposed into the following three activities:
  1. provide remote access
  2. provide encryption key
  3. authenticate users
After dividing a deliverable into potential activities, the team must evaluate each activity using the following six criteria.
  1. Status is measurable.
  2. Sign of completion is visible.
  3. Start and end conditions are clearly defined.
  4. Time and cost are easily estimated.
  5. Duration has acceptable limits.
  6. Work assignments are independent.
The first criterion to consider is whether the activity's status is measurable. For example, one deliverable in a Telecom Corp. VPN project is secure remote access. One activity defined for this deliverable is authenticating users, and it is measurable. When half the users have working login IDs and passwords, the activity is fifty percent complete.
Whether there is a visible sign that the activity is complete is the second criterion. This sign could be the delivery of a document or product, or it could be the manager's signature. In the Telecom Corp. example, the visible sign that users have been authenticated to the network is when all users can access the network with a functional user password.

The third criterion to use is whether an activity has clearly defined start and end conditions. Once the beginning event has occurred, work may begin on the activity and continue to a visible sign of completion. For Telecom Corp., the authentication activity should only begin when the network is in place. The authentication activity is clearly finished only when the users are able to use their login IDs and passwords to access the VPN.

Whether activity time and cost can be easily estimated is the fourth criterion to consider. This is accomplished by estimating the time and cost of a project's activities. In the Telecom Corp. example of authenticating users to the VPN, time can be estimated at a few days.

The fifth criterion to examine is whether an activity's duration is within acceptable limits. Although there is no set rule on this, projects should avoid activities with long durations. Delays in such activities can create serious scheduling problems. In evaluating Telecom Corp.'s authentication activity, duration can be estimated at a few days. Delays here would not create huge project delays or large-scale scheduling problems. The authentication activity then meets this fifth criterion.

The final criterion is an activity's level of independence from other project activities. Independence in an activity means that once work has begun on the activity, it may continue without interruption. For example, once Telecom Corp.'s authentication activity begins, it is not dependent upon any other project activities for completion.

Templates
The second tool a project manager and team uses to define project activities is a template. A partial or total activity list, or WBS from a previous project, can be used as a template for a current project. Using templates simplifies project activity definition and reduces project costs by improving team efficiency.

To define project activities, project managers use decomposition and templates. Decomposition means breaking project deliverables into achievable activities. A template is a partial or total WBS, or activity list defined in a previous project, which can be used in a current project.

Tuesday, September 18, 2007

Ensuring that Scope Changes Are Properly Implemented

Do you find it easier to manage a huge task by organizing it into smaller tasks? Project managers manage a huge task—the project—by organizing it into activities using a work breakdown structure (WBS).

The WBS is a framework that defines the scope of the entire project; work not in the WBS is outside the scope of the project. The approved WBS represents all of the work packages and activities that must be completed in order to finish a project.

To effectively control scope change throughout your project, you have to review the approved WBS. By reviewing the approved WBS, you ensure that the change will be properly implemented. At this review stage of the project, you should be looking at the activities and any resulting changes and impacts.
  • the activities - The first thing to review is the activity level of the WBS to ensure that all activities resulting from the change have been included so that the corresponding deliverable can be met. A forgotten activity can result in a missed deliverable or non-acceptance by the client, so this is a very important step.
  • any resulting changes and impacts - The project manager must also review the WBS to ensure that the resulting changes to the activities and their impacts on the schedule and budget have been considered. The project manager should ask himself if the change to the activities could cause the starting or ending date of the corresponding deliverables or final products to be delayed. He should also determine if the budget will be sufficient. If the answer to either of these questions is yes, the project manager can then use the tools and techniques of scope change control to assess the impact.
Project managers and the project team frequently refer to the WBS throughout the project. The WBS is the key to scope change control because it defines all the work in the project.

Tuesday, July 3, 2007

Key Activities of the Project Analysis Phase

The analysis phase of the IT project life cycle produces the detailed requirements and system architecture specifications for a project. Most importantly, it establishes what the end user wants the system to do.

During this phase, models of the application are developed. The development team uses these models to ensure that it understands the system requirements during the design phase and that the project meets the client's expectations.

In order to produce the detailed requirements of the analysis phase, the project manager (PM) must be familiar with the components listed below. Remember, the inputs and tools are used to create the key activities, which are the focus of this topic. Those key activities are then used to produce the outputs to meet the milestone for this phase.
  • The inputs required for this phase are the conceptual design, current system description, information plan, and project plan.
  • The tools needed for this phase are word processing software, presentation software, spreadsheets, and process and event modeling software.
  • The key activities for this phase are the end user requirements, quality requirements, and requirements analysis.
  • The outputs of this phase are the business process prototype and the requirements analysis.
  • The only milestone for this phase is the requirements' sign-off.
During the analysis phase, the PM must establish what the system will do so that the designer—during the design phase—can create a plan that meets the client's expectations. To do this, PMs conduct the following three key activities. Keep in mind that the first two key activities are documents you must prepare before you can conduct the third activity. The information you will need to create these documents is found in the documents from the inputs to the analysis phase.

1. Identify the end user requirements.
The first key activity, identify the end user requirements, describes user needs in terms of the new system and the differences between the new and the old system. Determining the end user requirements involves the two steps shown below.
  • Identify user requirements. The PM uses both the conceptual design inputs and the needs analysis section of the information plan to understand what the new system must do to satisfy the users' needs. The PM then prepares a statement that indicates what the users will be able to do with the product.
  • Perform a gap analysis. After the PM has identified the user requirements, the next step is to review the current system documentation and then perform a gap analysis, which determines the differences between the current and the new system and identifies the changes required.
2. Identify the quality requirements.
The next key activity in the analysis phase is to identify the quality requirements, which will help you understand how well the system will carry out its functions. To identify the quality requirements, review user requirements and product and project guidelines from the information plan. Explanations of what a quality requirement should contain are shown below.
  • Individual testable requirements. Quality requirements shouldn't be bunched together in a paragraph. Each requirement should have a separate entry that fully describes it. The description should be clear and understandable.
  • An explanation of how requirements will be tested. Explain exactly how the developers will test the function to determine whether each requirement is properly implemented. The developers can use inspection or demonstration, for example.
  • Prioritization. It's important that each requirement be prioritized in order of importance. Most PMs use the following scale: "High" indicates that the requirement must be included, "medium" indicates that it is necessary but can be added later, and "low" indicates that it is nice to have but not absolutely necessary.
3. Conduct the requirements analysis.
The next key activity is to conduct the requirements analysis. This is the process of increasing the team's understanding of the system requirements and translating them into a system design. The two models listed below are created during this key activity.
  • Process model. Process modeling is a technique for understanding, defining, and precisely representing the processes involved in developing an application. During process modeling, the PM uses modeling software to draw diagrams of each process. The diagrams are then used to develop the application.
  • Event model. Event modeling is a process that enables the project team to understand the events that trigger a process, which in turn causes a number of results. During event modeling, the PM uses modeling software to draw diagrams of each event and their possible results.
The analysis phase of the IT project life cycle ensures that the application you will develop meets the requirements determined by the customer. By following the steps described above to conduct the end user requirement's key activities for your project, you will be able to create a design that meets your client's needs.

Sunday, July 1, 2007

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.

Sunday, June 24, 2007

Project Management Activities

Project Management is composed of several different types of activities such as:
  1. Planning the work or objectives
  2. Analysis & Design of objectives
  3. Assessing and controlling risk (or Risk Management)
  4. Estimating resources
  5. Allocation of resources
  6. Organizing the work
  7. Acquiring human and material resources
  8. Assigning tasks
  9. Directing activities
  10. Controlling project execution
  11. Tracking and Reporting progress
  12. Analyzing the results based on the facts achieved
  13. Defining the products of the project
  14. Forecasting future trends in the project
  15. Quality Management
  16. Issues Management
  17. Issues solving
  18. Defect prevention
  19. Project Closure meet
  20. Communicating to stakeholders