Planning, 'A Must Do'

A journey is not
likely to be completed in the most comfortable and effective manner

unless it is planned. We have often heard people saying, "thanks

to meticulous planning, my business trip was very comfortable and successful."

However, do we apply the same planning rigor when it comes to executing

software projects? More often than not, business managers are in a hurry

of initiating projects to impress the customers. The same managers are

likely to cut a sorry figure in front of customers at the time of delivery-as

an unplanned or a poorly planned project has higher probability of schedule

slippage and quality issues in their deliverables.

Why plan?



Many will like to ask, why plan, let us just go ahead and do it. Well,
in the absence of a plan how will we know if we are moving in the right

direction. How far or close are we to the target. In the same context,

I am reminded of a Chinese proverb which says, if you do not know where

you are going, any road will do. Watts Humphrey, very aptly paraphrases

it by saying, "If you do not know where you are, a map will not

help."






A bit of planning helps us by providing a road to follow. It becomes
a roadmap for successful execution and provides milestones to know that

we are progressing in the right direction and will reach the destination.

It also boosts our morale as we see ourselves inching closer to the

destination.






Deming's four-step approach, also referred as PDCA cycle for achieving
Quality begins with Plan. No wonder the Capability Maturity Model (CMM)

from Software Engineering Institute has also identified project planning

as the foundation for process maturity by addressing it early in the

framework.






What does it take to plan?


Planning, like most other activities, requires commitment. It is something
that will help in the endeavor and therefore any time and effort spent

in planning is actually an investment instead of expenditure. The basis

of sound planning is the ability to comprehend the complexities of project

and foresee its problems. Planning, therefore, is iterative in nature

and generally improves with experience. It is always a good idea to

learn from history by referring to plans of similar projects executed

in the past.






What to plan?


The SEI-CMM provides the right set of recommendations for planners of
software projects. Software project planning, a key process area of

SEI-CMM, recommends certain parameters that on which a software project

can be planned. These parameters are likely to have direct bearing on

the project performance:






SIZE: Let us estimate the size (or volume) of software that is
required for the project. Irrespective of whether we use lines of code

or function points or feature points or any other unit for measuring,

the volume of software, size of the project remains a key parameter

as it forms the basis for further planning of the project.






EFFORT: Having estimated the size of software, let us now convert
it into the term more familiar to software industry worldwide. Yes,

let us now compute mythical person months. The technique for arriving

at person months is to multiply the size by productivity (the productivity

can be lines of code per person month, hours per function point etc)

usually specific to every organization. The computed figure can now

be used to manipulate the team size and duration for the project.






COST: The software industry generally follows a simplified costing
model of Dollars (or Rupees) per person every month, making it relatively

simpler to compute cost of the project by multiplying the effort with

rate. Add to it other project-specific costs and expected profitability

to know how much to charge the customer.






SCHEDULE: It is now time to develop a schedule for the project
by identifying various phases of the project, i.e milestones, delivery

dates etc. For each phase, the project manager will allocate person

months (out of total person months arrived in effort computation above)

based on previous experience and/or historical data. These person months

can be divided by the available team size to get the calendar duration

of the phase or divided by the time period to arrive at required team

size to achieve the milestone. Detailed planning for each phase can

happen before the beginning of each phase.






CRITICAL COMPUTING RESOURCES: This is one aspect that has probably
become obsolete in today's context for commercial software development,

computing resource being no longer scarce. However, this may still need

some considerations for embedded and system software development.






RISKS: Risk identification, analysis and planning is perhaps
the trickiest aspect of project planning. The recommendation here will

be to identify the possible risks, prioritize them, based on threat

perception and probability of occurrence, and prepare mitigation and

contingency plan for top few risks. It is generally said that if a project

manager can manage his top three to five risks, he would do an excellent

management for the project and likely to succeed in the project.






What to do with plan?


There is an adage that 'good beginning is half done,' similarly good
planning is half of project management. The remaining half is tracking

and ensuring adherence to the plan. Therefore, a good project manager

will periodically review his plan and fine-tune it to meet the project

objectives based on current performance levels.






SANJAY SINGHAL,


Senior Consultant,


QAI (India) Ltd.

Back To Home

| Back

To Content

Copyright Cyber Media India Ltd.



You must read the terms and conditions before
using this service