It is the responsibility of the Project Manager to come up with a suitable plan for the development of the software being undertaken by his organization, says Dr R Srinivasan

In the previous article, we looked at the importance of Architecture in Software Development. This week we will discuss another noteworthy and vital aspect, viz., Project Planning. We should have seen it prior to Architecture because the decision of the appropriate architecture is part of Project Planning. It is the responsibility of the Project Manager to come up with a suitable plan for the development of the software being undertaken by his organization. As stated by Brown, et.al. Software Panning is the representation of the reality of software development. It is through the Project Management Plan that all the required strategies at a topical level leading to discrete process plans for the specific details. The Project plan has to be pragmatic in many respects, viz. covering the cost of the development within the budget (through proper schedule and effort estimation), test plans, review schemes and tracking progress and also the method of handling Software Configuration Management. To assist the Project ?Managers, we have well laid standards for Project Management Plan. NASA's, "Software Development/Management Plan and SEI / CMM's, "Plan Technical Effort" provide the real guidelines for an effective Project Management Plan.

To give a brief account, NASA's template covers important bullets like Statement of the Problem, the Technical approach, the Management Approach and the ways and means of assuring the performance of the developed software product. Under the technical approach it advocates the need to take care of any software component developed earlier for reuse, the assumptions and constraints in undertaking the project, the types of activities, tools to be used and also the strategy for the development of the project. It also brings out the importance of Management Approach encompassing resource requirements, milestones and schedules, the need to collect metrics on critical parameters, identify possible risk factors and methods to manage the situation. Quality Assurance and Configuration Management are illustrated under Product Assurance.

In any engineering design, well spelt planning and bringing out a document of the plan are very vital for the execution of the project. Software development, employing Software Engineering methodologies is not an exception - successful software development, therefore, depends very much on effective planning. Frederick Brooks in his book on, "The Mythical Man Months", says as a rule of thumb, the average time taken in a typical software development cycle are: 1/3 planning, 1/6 coding, 1/4 component test and early system test and 1/Ľor over all system test. He points out that all these estimated times go well as per plan until reaching the System Integration point and system testing. (It is therefore necessary that the Project Plan projects sufficient time for system test; otherwise it will lead to disastrous results like unexpected days, cost over run to the Management and psychological stress to the members in the team.)

While the project plan is a critical factor in software development, there should neither be over planning nor under planning, because improper and inadequate level of planning will lead to problems in the management of the project like unexpected risks, delays and also, as an extreme case of failure to deliver the product to the customer. William Brown, et. al (through their Planning 911 AntiPattern) illustrate three important categories of poor planning in a software development organization. They are: Detailitis Plan, Glass case Plan, and the Management Plan. A Project plan attempts to capture maximum details needed in the course of development in a Detailitis Plan. On the other hand, in Glass Case Plan, the Project Plan is decided and documented at the beginning of the project but is never revisited during development for reviewing and tracking. In either of the above cases, it is impossible to assess the status of the project at any time. As an example of an extreme case, the third category, viz., Management Plan is the one where the Senior Management takes the responsibility of producing the plan/schedules of the project. This is a very wrong move, because it not possible for the Senior Management to have direct contact with the Project Manager and the team on a daily basis; as it is not possible to have periodic tracking of the project against the plan and hence in all probability the planned schedule and efforts estimation will go awry!! To circumvent this, the Senior Management will resort to surprise fire drills defined by the milestones in their management plan. This situation will happen because while designing the Project Plan the Senior Management does not take cognizance of the inputs from the Project Manager and the team and hence there will be a striking disparity between the Management planning model and the actual development activities; a clear case of having two plans - a formal one by the Management and a hidden plan of the team!! Each one of these Project Management Plans described above will result in delays, disgruntled staff leading to attrition and failure of the project.

To quote Brown. Et. al from their book on, AntiPatterns in Project Management", "while each of these poor planning classes is common, the best management approach is to produce a published plan whose detail is appropriate for the phase of development and then capture progress, replanning as necessary on a weekly basis for each development team".

(to be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)