Dec 30, 2008

Project Planning

Project Planning

The amount of project planning you should do depends on your organizational requirements along with project size and complexity. The information on this page consists of general guidelines. The following general steps are taken during the project lifecycle, although for an iterative process some of these functions are intermixed throughout the process.

  1. Need justification (feasibility) - This phase is also called the inception phase. A mission need statement or project request is written. At this point management may approve a limited budget for limited research and testing. Preliminary risk assessment is done.
  2. Concepts development - Methods of accomplishing the project need are evaluated and researched. The details of how the project will be implemented shall be outlined. This phase will allow the team to determine technologies to be used to implement the project. A System Decision Paper (White Paper) is written for systems to be implemented. This paper is updated as necessary to reflect project changes. This paper will outline the methods and technologies to be used to implement the project along with a general project plan with regard to project phases. Minimal testing may be performed during this phase to determine whether specific technologies can support the project as required. Further risk assessment is done.
  3. Design Phase
    • Project Definition - The requirements are established or outlined during this phase. A functional specification (project requirements specification) is done.
    • Project Design - The project plan with schedule is done during this phase. During the project design or possibly earlier in the project lifecycle, depending on organizational requirements, the following is usually done:
      • Be sure the project is worthwhile from a financial perspective.
      • Be sure of proper financing (ability to complete the project).
      • Be sure infrastructure (facilities such as building, communication, and trqansportation) can support the project.
      • Prepare a project definition with cost, schedule requirements, project scope, and technical content (specifications).
      • Set up required communications with outside groups or organizations.
      • Preparation with sales and marketing for product marketing.
      • Set up organizational structure and project procedures.
      • Acquire or plan to phase in appropriate manpower.
      • Be sure no project disruptions may occur such as manpower, tool, or material shortages,
      • Be sure enough materials will be available to support the project.
      • Be aware of potential project bottlenecks and plan for them.
      • Plan how operations and maintenance will be executed and determine requirements during this phase.
    • Risk Assessment is completed and a Risk Management Plan (RMP) is developed.
    • Project Approval
  4. Production
    • Project Development
      • Development
      • Integration
      • Test
      • Evaluation
  5. Project Turn over
    • Project Deployment
    • Operation and Maintainence

Operation and Maintainence

Remember, when iterative development and management processes are used, many of the above processes are intermixed throughout the project and are done over iteratively. This allows greater responsiveness to change and unexpected events than a traditional waterfall process. During iterative development, it is acknowledged that all requirements cannot be fully accurately determined at the start of the project, so don't get bogged down with requirements if you are using an iterative process.

Project planning can be broken down into three functional areas that generally involve three different groupings of people.

  • Management - Management personnel.
  • Functional - The customer and a combination of management and technical planners.
  • Technical - Technical personnel and lower level management.

Requirements

Regardless of the management and development processes used, it is important to begin requirements definition early in the project for the following reasons:

  • Gets the team focused on the definition of the problem.
  • Gets the customer thinking seriously about the requirements (needs and wants) which may surface during a later meeting.

Involve as many customers and team members as is possible during this part of the project. People from all three functional areas listed above should be involved.

Project Design and Project Plan

During this part of the project the following is done:

  • Functional requirements are refined further. Quality requirements should also be defined.
  • Hardware, software, and manpower requirements are determined and a project schedule is created.
  • Risk Management Plan (RMP) is created.
  • Work Breakdown Structure (WBS) is created. This breaks tasks into subtasks at a management level to allow budgeting, planning, and performance measurement.
  • Responsibility Assignment
  • The project plan is created - This plan defines how the project will be developed, implemented, documented, tested, and maintained. The following documents or subsections to the project plan are created.
    • Project Development Plan Project Integration plan - How the project will integrate with existing systems. Any integration phases required are specified. Project Implementation plan or project deployment plan - How the project will be installed at required facilities. Installation manuals will be required. A project document plan shall be developed.
      • Document types determined.
      • Document production schedule is determined.
      • Document detail level is determined.

Draft documents are to be reviewed in a timely manner to ensure proper content and completion of documentation on schedule.

    • Project test plan - Test plan is required.
    • Project maintainence plan - Users manuals are required.

The plan must be effectively communicated to the team. The team must believe in the plan. They must believe the plan is feasible. They will not work hard to achieve a plan they believe will fail.

Risk Management and RMP

The risk management plan (RMP) addresses the following risk associated issues:

  • Risk identification - What risks to the project exist.
  • Degree of Risk - How serious the risk as with regard to probability and the impact on the project.
  • The response to the risk. - This identifies how the risk will be managed to minimize or mitigate it.

Documentation Planning

When planning project documentation, several items should be considered:

  • The document types to be produced.
  • Each document purpose.
  • The level of detail to be included in each document.
  • When the document must be complete to support the project.
  • The audience.

Managing Change

Change can be managed if a good development and management process is used by the organization. This process should be based on the particular needs of the organization and the types of projects generally done.

Your Structure and Methodology

It is important to note that the above mentioned project stages may not be done completely in order or done at various times repetatively depending on the development process your organization chooses. Also the amount of depth of up front planning for projects will vary widely depending on how formal your organization likes to be, the types of projects that are produced at your organization, and your quality requirements.

Defined management and development processes can be repeated and therefore over time are more efficiently used. This results in a great deal of time and savings to organizations. Therefore it is extremely important to organizations to pick a management and development process early. The management and development process should be determined together since one will affect the other. Mentioned in a previous section, some development processes work better for some projects than others. If your organization has a variety of projects, you may want to use a couple of development processes. This should work so long as there are guidelines on when to use one processes over another. Also it is important for everyone to understand why one process may be chosen over another one. In other words, it is very important that all members of your organization understand your defined management and development processes.

Organizational Maturity

Management must be sure a worthwhile development process is implemented in the organization. This process may vary from organization to organization and is dependent on the type of work being done, with how formal the organization is, and other factors. Generally organizational maturity may be measured by how well defined their development process is along with its effectiveness. According to Grady Booch in his book "Object Solutions: Managing the Object Oriented Process", organizational maturity has the following categories:

  • Initial - Organization has an informal process or is just beginning to implement one.(Many organizations)
  • Repeatable - There is reasonable control of the development process. (Many prganizations)
  • Defined - The development process is well defined, practiced, and understood. (Several organizations)
  • Managed - Process quantity can be measured. (few organizations)
  • Optimizing - An excellent running process is in place and quality products are produced on schedule.

Having a well tuned process does not mean the organization must be very formal with rigid and strict rules, but communications must be effective.

Group Integration

During the course of a project, many different groups must interact. Some of the various groups that interact include:

  • Marketing
  • Supply
  • Travel
  • Accounting
  • Engineering
  • Upper Management

Each of these groups, although supporting the same organization, have some differences which may lead to conflict or efficiency loss. These differences include:

  • Goals
  • Structure of the group
  • Time frames the group deals with

The groups that must interface with each other must be more closely integrated for efficiency when change occurs fast or often or the technology is complicated. Several ways to inhance intergroup interfaces are:

  • Matrix management
  • Special teams (permanent) or task forces (temporary)
  • Coordinators (permanent) or Liason officers (temporary)

Project Changes

As a project progresses through its various stages the organization and management must change to adopt to the needs of the project. At the start and end of a project, many people may be involved, but the responsibilities for the project fall on a few people. During the main construction part of the project, more responsibility must be delegated. When more responsibility is delegated, regular progress reports must be provided. At the beginning and ending parts of the project, progress reports are not as necessary since a specific deliverable is expected on or near a set time frame. Project reports are always important, however, when there are any major changes to the project or its schedule.

It is best if the changes in delegation are worked out at the project inception or early during project design. This avoids confusion and conflict later during the project lifecycle and helps ensure success. Additional methods used to support matrix management include:

  • Teams built from members of several departments.
  • Dual evaluation systems with one based on the project matrix and one based by department.
  • Extensive interdepartmental meetings for information distribution. Proper use of email can cut time required for meetings.
  • Planning organizational strategy and operating methods with members of various departments.

There are obviously positives and negatives to each of these methods so whether they are worth implementing depends on the organization and the work that must be accomplished.

Project planning

All project planning cannot be done at the start of the project. For traditional projects it is normally done in two stages. The initial project plan is done during project inception. For very large projects the initial plan will concentrate on delegating the planning of the project subsystems. This part of the plan will roughly estimate schedule, manpower, and budget. It will enable management to decide if the project is feasible (feasibility study). The rest of the plan is determined during and late in the project elaboration/design phase just before construction begins. The second part of the plan will firm up the schedule, manpower, and budget requirements

No comments:

Post a Comment

Popular Posts