Project Development Plan: the First Guide in Building an it System

When my team had an IT project to do during our college days, we used a very important document to help us get started during the initial stages of the project. We used a document called Project Development Plan (PDP) as guide.  It is adapted from the IEEE standards for Software Project Management Plans. This document is very useful because all succeeding documents (i.e. Test Plan) follow the initial guidelines stated in the PDP document and the general details and strategies for testing and quality assurance are also stated in this document.

          Apart from minor (but pertinent) details, the PDP is divided into four major parts, namely: Project Organization, Managerial Process Plans, Technical Process Plans, and Supporting Process Plans. The Project Organization part of the PDP document describes and illustrates the organizational hierarchy of the developing team. The Managerial Process Plan section of the PDP describes how the developing should start and how it will close. Apart from which, this section also tackles the general and specific details of managing resources, budget, staff and schedule. The Technical Process Plan part of the PDP is where the process, methods, tools and techniques in building the system, as well as maintenance and release, are stated. And, the Supporting Process Plan section of the PDP provides general details about configuration management, testing, standards and quality assurance, reviews, issue management, subcontract management and improvement plan. This part is essential because many documents particularly the Test Plan and the Quality Assurance documents base its initial plans, standards and processes.

          The first part of the Project Development Plan document details the purpose, scope and objectives of the project. Of course, the developers of the system must know what they are building, and the limitations and extent of the finished product. The initial section of the PDP also enumerates the list of deliverables of the project like documents and the finished system itself.

          The first major part of the PDP document is the Project Organization. This is where the internal and external organizations are identified, together with their roles and responsibilities. Improper or poorly defined position in the organization causes confusion amongst the members of the developing team regarding each one’s roles and responsibilities; causes some members of the team to slacken around and do nothing, while some have more than enough in their hands; and some members tend to assume the responsibility supposed to be assigned to another team member. Thus, poor staffing or poor Human Resources management might contribute heavily to the project’s total failure.

          The second major part of the PDP document is the Managerial Process Plans.  This is where the specific and general management process for the project appears. While doing this part of the PDP before, I find the contents of this section repetitive especially in the areas of schedule, budget, staffing and resources management. There are certain developers who don’t have to worry about estimating schedule, budget, staffing and resources because the company where they are employed provides them with all the things that they need.  However, there are developers who must do all the estimating and budgeting. Thus, the Start-up Plan (under the Managerial Process Plans) is where all the initial plans of the developers are found. Usually, this plan came about during the pre-Requirements stage. The opposite of the Start-up plan is the Close-out Plan that discusses how the project should end. Work Plan section (under the Managerial Process Plans) is where the specific details of budget, schedule, staffing and resources are found. Also, we can have an early glimpse of the Work Breakdown Structure and the specific work activities. Risk Management Plan (under the Managerial Process Plans) describes the mechanisms used to identify, analyze, build mitigation and contingency plans; and manages the risks possibly found in the project.

          The Technical Process Plans describe the processes used for developing the product or IT services.  The activities in the Work Breakdown Structure follow a guideline in the form of a Software Development Life Cycle Model (i.e. Waterfall Method). If a Life Cycle Model is not determined, sometimes it is difficult to prioritize the activities in the project.

          Lastly, the Supporting Process Plans of the PDP discusses the supporting processes of the project, namely: configuration management, testing, documentation, quality assurance, reviews, issue management (which I find somewhat similar with Risk Management), subcontract management and improvement plan. Configuration management has something to do with the configuration items identified in the project. These configuration items are already named as early as pre-Requirements stage but they are visible for every phase-end or if an item is already declared original and final version. Samples of configuration items are documents. Once changes are made in these items (which normally happens during project-end), a control board analyzes changes prior to acceptance or rejection. The analysis of the control board is one of several activities under Configuration Management. The general guidelines for the Test Plan and the Quality Assurance Plan documents are first planned and described in the Supporting Process Plans of the PDP. Without the initial guidelines, there is a huge possibility that testing and quality assurance activities are taken for granted.

          The Project Development Plan document is very important and essential especially if you’re into software development. Without this document as guide, an IT developer might experience “groping in the dark” in the middle of the project, NO FORMAL GUIDELINES AND STANDARDS established, and there is poor management in areas of budget, staffing, schedule and resources.

P. Lobrin

plobrin@gmail.com