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

< A/ by Jeffrey C/If you don't have a background in systems and software development, this response will give you a quick overview. It is far from complete, however. If you do have a background in this subject, you should be looking at your processes and procedures rather than trying to point the finger at one or more rogue developers.

Programs contain mistakes for lots of reasons. More often than not, problems occur at because the stated requirement is not really how the system needs to work.

The next most common set of errors occur at the interfaces between subsystems, the software and hardware, and between units within the software. One of the most famous of these interface problems was the Mars spacecraft that got lost because one team used SI units but the team they interfaced to used English units.

In real time and embedded work, we often see errors that occur because of the way the software interacts with the hardware. The most difficult to fix are the transient problems that do not reoccur easily. These errors often stay hidden in the code, showing their ugly heads occasionally to bring down a system.

The easiest problems to fix are those in the implementation. We perform unit test to confirm that the code meets the design (no, not code meets the requirements). Note that this testing does verify that the design meets the requirements, only that the code works as designed.

There are several levels of testing that prove the software meets the requirements -- integration testing, hardware/software integration, verification testing. I'm really not going to go into these. Suffice it to say that most mature organizations confirm that each requirement is associated with a test case and that each test case has executed.

The most important testing comes at the very end and often does not get the attention it deserves due to budget and schedule concerns. Validation testing confirms that the requirements are correct, complete, and consistent. This testing runs systems through real-life scenarios to be sure the system performs as desired.

At this point, you probably know a great deal about Collins since you've spent at least 2 years talking about it on this forum. You may be able to find out what the formal validation plan was from the MOD or the contractors. I don't know if this type of information is available to the public, but the adequacy of the plan may help you determine if there was a conspiracy of just a few people who destroyed this VERY large program, or if there were more basic problems due to an immature organization not really knowing how to take on such an involved task.>>

Read more on Marketwire

~~ Larry Elder — “The Larry Elder Show”

When Outsourcing Is Not a Great Plan

Outsourcing can definitely be profitable for a great deal of reasons. Numerous companies enjoy advantages such as lower labor expenses, bigger workforces, access to industry experts and extraordinary flexibility because of outsourcing. At any rate, in spite of the glaring advantages to outsourcing there are a few situations when outsourcing is not a great plan. Though there a number of scenarios where outsourcing is a sensible business opportunity there are other scenarios where outsourcing is not the best idea. In these situations it is best to control the job in-house rather than attempting to force an outsourcing situation to work out.

When Outsourcing Is Too Expensive

One of the main advantages of outsourcing is lower expenses. In a great number of cases outsourcing results in lower labor expenses because expenses such as social security, health care and workers’ comp are eliminated. In addition, the increased proficiency resulting when tasks are outsourced to industry experts can also result in cost trimming.

In spite of these numerous opportunities for expense reductions, there are many situations where outsourcing might actually be the more costly alternative and it may also lead to a monetary loss instead of a gain. This may also include a situation where the expense of outsourcing to a tremendously specialized freelancer exceeds the budget for the project. Fees for freelancers with immensely specialized degrees or areas of knowledge are frequently quite costly. An additional possible instacne is one where discovering an freelance worker experienced enough to finish certain tasks would be too costly of a procedure.

“The other part of outsourcing is this: it simply says where the work can be done outside better than it can be done inside, we should do it.”

~~ Alphonso Jackson — Secretary of the United States Department of Housing and Urban Development

When Outsourcing Causes You to Lose Command

Even when tasks or projects are outsourced the business accountable for the work likes to continue to handle the job and keep close tabs on the progression of tasks. It is extremely important for the business to proceed to control the job even after it has been outsourced because they are the ones who are ultimately accountable for the successful fulfilment of the work. Whenever an freelance worker or business wants to deny the company access to project files or documents, outsourcing is a bad plan. The business who has the vested concern in the result of the project should at no time be excluded from participating in making decisions concerning the project.

Prior to outsourcing a job or task care ought to be taken to lay out criteria for the managing of the project. Depending on the length and complexity of the job it may also be smart to schedule regular meetings to supply updates on the progression of the job. During this period the contractor ought to supply the employer with all information needed to assess the progression of the job and affirm it is still on track for completion by the specific deadline.

When Outsourcing is Not Permitted

Occasionally outsourcing is not a great plan merely because it is not permitted by contract requirements. A few project contracts may possess stipulations stating the labor cannot be outsourced to an freelance worker or to another business. Inserting such a clause into a contract agreement is well within the rights of the customers. When they employ a specific business to finish a task or project, they expect all work related to the task or project to be completed by members of that business unless they stated otherwise when negotiating the agreement. Breaching the agreement documents in this circumstance is not a great idea. The business could be penalized by the customer. Penalties may include withholding payment or refusing to grant future projects or tasks to the business.

[You may use this article (or portion thereof) for your website, ezine or blog as long as you include the bio/resource box with hyperlinks.]

Read more on WBTV Charlotte

A schedule management plan is a document which decides the norm for developing and maintaining the project schedule and signifies the whole project plan as well. The schedule management plan creates how schedule management will be carried out in the project. It provides a regulation for the scheduling method and set-up and describes the position and tasks for individuals in that processes. It is not complete schedule information, but instead it gives details on how that information will be detained, articulated, and adapted if or when it is required.
The schedule management plan includes the description of essential documents and some insight on how the documents could be formed. Leveled schedules will result in various efficiencies and this is something that should not be ignored. These are the benefits of a leveled schedule: quality-time work will be reduced. Efficiency would be maintained. And for a project schedule to be healthy, the following criteria should be followed, a schedule must be frequently updated, and the EAC value should be equivalent to baseline value, the work must be equally distributed among the team members.
The schedule management plan is always used by project managers and the project office to describe how management practices will be carried out. In some group, it may be a uniform document, functional across numerous projects and customized only to some extent to reflect the individual source and delivery necessities of the project. It is used to prevent project managers from creating a new process every time they get a new one. Before a project schedule can be created, the project manager should usually have a work breakdown structure (WBS), an attempt to estimate for each task, and a resource list with accessibility for each resource.

If the resources are not available then it may be possible to create something that looks like a schedule, it would definitely be a form of creative writing. The scheduling process will include both advanced and complete explanation of how the schedule and its workings will be generated. The process also comprises of information on when the schedule should be base lined and when documents should be updated. Schedule management is the real key to a successful project.