Name:Reg.No.

16MCA0100

Assignment-1

Introduction to Step Wise project planning:The framework described is called the Step Wise method to help to distinguish it
from other methods such as PRINCE2. PRINCE2 is a set of project management
standards that were originally sponsored by what is now the Office of Government
Commerce (OGC) for use on British government ICT and business change
projects. The standards are now also widely used on non-government projects in
the United Kingdom. Step Wise should be compatible with PRINCE2. It should be
noted, however, that Step Wise covers only the planning stages of a project and not
monitoring and control.
Step Wise:-

Fig: An overview of Step Wise planning.

Step 0: Select project:This is called Step 0 because in a way it is outside the main project planning
process. Proposed projects do not appear out of thin air some process must decide
to initiate this project rather than some other .While a feasibility study might
suggest that there is a business case for the project, it would still need to be
established that it should have priority over other projects. This evaluation of the
merits of projects could be part of project portfolio management.
Step 1: Identify project scope and objectives:The activities in this step ensure that all the parties to the project agree on the
objectives and are committed to the success of the project.
Step 1.1: Identify objectives and practical measures of the effectiveness in
meeting those objectives:CASE STUDY EXAMPLES: PROJECT OBJECTIVES:The project objectives for the Brightmouth College:-

Amanda at IOE has the objectives clearly laid down for her in there
commendations of a business case report which have been accepted by IOE
management. The main objectives are to allow:
_ details of annual maintenance contracts to be recorded;
_ details of maintenance work covered by these contracts to be recorded;
_ analysis of costs to be carried out so that the optimal level of maintenance
contract fees may be identified;
_ recording of job requests and notification of jobs to engineers via mobile phones.
Other objectives are laid down that refer to expected timescales and the resources
that might be used.

Step 1.2: Establish a project authority:A single overall project authority needs to be established so that there is unity of
purpose among all those concerned.
Step 1.3: Stakeholder analysis identify all stakeholders in the project and
their interests:The stack holders are those people who has been connected to the organization
either directly or indirectly . The stack holder may be a manager of an organization
or it may be a outsider who has invested the money in to the organization.
Step 1.4: Modify objectives in the light of stakeholder analysis:In order to gain the full cooperation of all concerned, it might be necessary to
modify the project objectives. This could mean adding new features to the system
which give a benefit to some stakeholders as a means of assuring their commitment
to the project. This is potentially dangerous as the system size may be increased
and the original objectives obscured. Because of these dangers, it is suggested that
this process be done consciously and in a controlled manner.
Step 1.5: Establish methods of communication with all parties:For internal staff this should be fairly straightforward, but a project leader
implementing a payroll system would need to find a contact point with BACS
(Bankers Automated Clearing Scheme), for instance. This step could lead to the
first draft of a communications plan to read more about these.
Step 2: Identify project infrastructure:Projects are never carried out in a vacuum. There is usually some kind of existing
infrastructure into which the project must fit. Where project managers are new to
the organization, they must find out the precise nature of this infrastructure. This
could be the case where the project manager works for an outside organization
carrying out the work for a client.

Step 2.1: Identify relationship between the project and

strategic planning:We saw above how project portfolio management supported the selection of the
projects to be carried out by an organization. Also , how programme management
can ensure that a group of projects contribute to a common organizational strategy.
There is also a technical framework within which the proposed new systems are to
fit. Hardware and software standards, for example, are needed so that various
systems can communicate with each other. These technical strategic decisions
should be documented as part of an enterprise architecture process. Compliance
with the enterprise architecture should ensure that successive ICT projects create
software and other components. compatible with those created by previous projects
and also with the existing hardware and software platforms.
Step 2.2: Identify installation standards and procedures:Any organization that develops software should define their development
procedures. As a minimum, the normal stages in the software life cycle to be
carried out should be documented along with the products created at each stage.
Change control and configuration management standards should being place to
ensure that changes to requirements are implemented in a safe and orderly way
.The procedural standards may lay down the quality checks that need to be done at
each point of the project life cycle or these may be documented in a separate
quality standards and procedures manual. The organization, as part of its
monitoring and control policy, may have a measurement programme in place
which dictates that certain statistics have tobe collected at various stages of a
project. Finally the project manager should be aware of any project planning and
control standards. These will relate to how the project is controlled: for example,
the way that the hours spent by team members on individual tasks are recorded on
timesheets.
Step 2.3: Identify project team organization:Project leaders, especially in the case of large projects, might have some control
over the way that their project team is to be organized. Often, though, the
organizational structure will be dictated to them. For example, a high-level
managerial decision might have been taken that software developers and business
analysts will be in different groups, or that the development of business-toconsumer web applications will be done within a separate group from that
responsible for traditional database applications.

Step 3: Analyse project characteristics:The general purpose of this part of the planning operation is to ensure that the
appropriate methods are used for the project.
Step 3.1: Distinguish the project as either objective- or product-driven:This is concern with the project manager that the project can be managed in two
ways . it means the project can be managed by considering the objective or by
considering the product to which they have to make. As development of a system
advances it tends to become more product-driven, although the underlying
objectives always remain and must be respected.
Step 3.2: Analyse other project characteristics (including quality-based ones):For example, is an information system to be developed or a process control system,
or will there be elements of both? Will the system be safety critical, where human
life could be threatened by a malfunction?
Step 3.3: Identify high-level project risks:Consideration must be given to the risks that threaten the successful outcome ofthe
project. Generally speaking, most risks can be attributed to the operational or
development environment, the technical nature of the project or the type of product
being created.
Step 3.4: Take into account user requirements concerning implementation:The clients may have their own procedural requirements. For example, an
organization might mandate the use of a particular development method.
Step 3.5: Select development methodology and life-cycle approach:The development methodology and project life cycle to be used for the project will
be influenced by the issues raised above. The idea of a methodology, that is, the
group of methods to be used in a project, was discussed in previous. For many
software developers, the choice of methods will seem obvious: they will use the
ones that they have always used in the past. As well as the methods to be used,

there are generic ways of structuring projects, such as the use of the waterfall life
cycle outlined in Chapter 4, that need to be considered. While the setting of
objectives involves identifying the problems to be solved, this part of planning is
working out the ways in which these problems are to be solved. For a
project that is novel to the planner, some research into the methods typically used
in the problem domain is worthwhile. For example, sometimes, as part of a project,
a questionnaire survey has to be conducted. There are lots of books on the
techniques used in such surveys and a wise move would be to look at one or two of
them at the planning stage.
Step 3.6: Review overall resource estimates:Once the major risks have been identified and the broad project approach has been
decided upon, this would be a good point at which to re-estimate the effort and
other resources required to implement the project. Where enough information is
available an estimate based on function points might be appropriate.
Identify project products and activities:The more detailed planning of the individual activities now takes place. The
longer-term planning is broad and in outline, while the more immediate tasks are
planned in some detail.
Step 4.1: Identify and describe project products (or deliverables):In general, there can be no project products that do not have activities that create
them.
Wherever possible, we ought also to ensure the reverse: that there are no activities
that do not produce a tangible product. Identifying all the things the project is to
create helps us to ensure that all the activities we need to carry out are accounted
for. Some of these products will be handed over to the client at the end of the
project these are deliverables. Other products might not be in the final
configuration, but are needed as intermediate products used in the process of
creating the deliverables. These products will include a large number of technical
products, such as training material and operating instructions. There will also be
products to do with the management and the quality of the project. Planning
documents would, for example, be management products. The products will form a
hierarchy. The main products will have sets of component products which in turn
may have sub-component products and so on. These relationships can be
documented in a Product Breakdown Structure (PBS) example the products have

been grouped into those relating to the system as a whole, and those related to
individual modules. A third group, which happens to have only one product, is
called management products and consists of progress reports. The asterisk in the
progress reports indicates that there will be new instances of the entity progress
report created repeatedly throughout the project.
Step 4.2: Document generic product flows:Some products will need one or more other products to exist first before they can
be created. For example, a program design must be created before the program can
be written and the program specification must exist before the design can be
commenced.
Step 4.3: Recognize product instances:Finding out the product subroutines in order to the project can easily made.
Step 4.4: Produce ideal activity network:In order to generate one product from another there must be one or more activities
that carry out the transformation. By identifying these activities we can create an
activity network which shows the tasks that have to be carried out and the order in
which they have to be executed.
Step 4.5: Modify the ideal to take into account need for stages
and checkpoints:The approach to sequencing activities described above encourages the formulation
of a plan which will minimize the overall duration, or elapsed time, for the
project. It assumes that an activity will start as soon as the preceding ones upon
which it depends have been completed.
Step 5: Estimate effort for each activity:The effort for each activity is concern with the total work as well as the total amount of
cost taken by an activity in the project .

Step 5.1: Carry out bottom-up estimates:At this point, estimates of the staff effort required, the probable elapsed time and
the non-staff resources needed for each activity will need to be produced. The
method of arriving at each of these estimates will vary depending on the type of
activity. The difference between elapsed time and effort should be noted. Effort is
the amount of work that needs to be done. If a task requires three members of staff
to work for two full days each, the effort expended is six days. Elapsed time is the
time between the start and end of a task. In our example above, if the three
members of staff start and finish at the same time then the elapsed time for the
activity would be two days. The individual activity estimates of effort should be
summed to get an overall bottom-up estimate which can be reconciled with the
previous top-down estimate. The activities on the activity network can be
annotated with their elapsed times so that the overall duration of the project can be
calculated.
Step 5.2: Revise plan to create controllable activities:The estimates for individual activities could reveal that some are going to take
quite a long time. Long activities make a project difficult to control. If an activity
involving system testing is to take 12 weeks, it would be difficult after six weeks to
judge accurately whether 50 per cent of the work is completed. It would be better
to break this down into a series of smaller subtasks.
There might be a number of activities that are important, but individually take up
very little time. For a training course, there might be a need to book rooms and
equipment, notify those attending, register students on the training system, order
refreshments, copy training materials and so on. In a situation like this it would be
easier to bundle the activities into a single merged activity make training course
arrangements which could be supplemented with a checklist. In general, try to
make activities about the length of the reporting period used for monitoring and
controlling the project. If you have a progress meeting every two weeks, then it
would convenient to have activities of two weeks duration on average, so that
progress meetings would normally be made aware of completed tasks each time
they are held.

Step 6: Identify activity risks:Step 6.1: Identify and quantify activity-based risks:Risks inherent in the overall nature of the project have already been considered in
Step 3. We now want to look at each activity in turn and assess the risks to its
successful outcome. Any plan is always based on certain assumptions. Say the
design of a component is planned to take five days. This is based on the
assumption that the clients requirement is clear and unambiguous. If it is not then
additional effort to clarify the requirement would be needed. The possibility that an
assumption upon which a plan is based is incorrect constitutes a risk. In this
example, one way of expressing the uncertainty would be to express the estimate
of effort as a range of values.
Step 6.2: Plan risk reduction and contingency measures where appropriate:It may be possible to avoid or at least reduce some of the identified risks. On the
other hand, contingency plans specify action that is to be taken if a risk
materializes. For example, a contingency plan could be to use contract staff if a
member of the project team is unavailable at a key time because of serious illness.
Step 6.3: Adjust overall plans and estimates to take account of risks:We may change our plans, perhaps by adding new activities which reduce risks.
For example, a new programming language might mean we schedule training
courses and time for the programmers to practise their new programming skills on
some non-essential work.
Step 7: Allocate resources:Step 7.1: Identify and allocate resources:The type of staff needed for each activity is recorded. The staff available for the
project are identified and are provisionally allocated to tasks.

Step 7.2: Revise plans and estimates to take into account resource
Constraints:Some staff may be needed for more than one task at the same time and, in this
case, an order of priority is established. The decisions made here may have an
effect on the overall duration of the project when some tasks are delayed while
waiting for staff to become free. Ensuring someone is available to start work on an
activity as soon as the preceding activities have been completed might mean that
they are idle while waiting for the job to start and are therefore used inefficiently.
Example:-

Step 8: Review/publicize plan:Step 8.1: Review quality aspects of the project plan:A danger when controlling any project is that an activity can reveal that an earlier
activity was not properly completed and needs to be reworked. This, at a stroke,
can transform a project that appears to be progressing satisfactorily into one that is
badly out of control. It is important to know that when a task is reported as
completed, it really is hence the importance of quality reviews. Each task should

have quality criteria. These are quality checks that have to be passed before the
activity can be signed off as completed.
Step 8.2: Document plans and obtain agreement:It is important that the plans be carefully documented and that all the parties to the
project understand and agree to the commitments required of them in the plan. This
may sound obvious, but it is amazing how often this is not done.
Steps 9 and 10: Execute plan/lower levels of planning:Once the project is under way, plans will need to be drawn up in greater detail for
each activity as it becomes due. Detailed planning of the later stages will need to
be delayed because more information will be available nearer the start of the stage.
Of course, it is necessary to make provisional plans for the more distant tasks,
because thinking about what needs to be done can help unearth potential problems,
but sight should not be lost of the fact that these plans are provisional.