Uncertainty in Project Plans

Projects involve uncertainty. At the beginning of a project, the exact amount of

time that will be needed is not known, nor is the precise amount that the project

will eventually cost. For some projects, it is even uncertain whether the intended

goal will be reached at all. In a world of fast-paced change, the foundations of a

project have sometimes already changed before the project is completed. This

sometimes occurs because of technological developments or developments in the

market or political arena.

When preparing project plans, project leaders can only estimate the control

factors (i.e. time, money, team, quality goals and necessary information) of the

project. As the project proceeds, more knowledge emerges about the project itself.

In the initiation phase, only an idea exists. In the definition phase, the idea is

refined according to requirements. In the design phase, possible designs are

examined and developed, providing even more clarity. In the development phase,

it becomes clear how the design should be realised. In the implementation phase,

the actual project result is built, and in the follow-up phase, all of the loose ends

are tied together.

(image taken from AIMS project management academy course)

Clarity increases as a project progresses. It is therefore pointless to make a

detailed budget for the follow-up phase (which will take place later) during the

initiation phase. At this stage, it is still possible for the project to proceed in any of

a number of possible directions. The idea has yet to be elaborated. The exact form

of the follow-up phase is probably also known only in the broadest terms. This is

too little information upon which to base a realistic, detailed estimate for the

follow-up phase. A broad outline of a budget is the most that can be expected at

this stage.

Project plans therefore work as follows: a global budget is made for the entire

project, along with a concrete budget for the next subsequent phase. For example,

if a project team is preparing to enter the implementation phase (after the

development phase), they are well aware of what must happen. At that point, it is

possible to make a detailed budget for the implementation phase.

(this article which originally written by me when I was giving lectures in my institute for the students of project management certification will continue in parts on my blog).

Implementation phase

The project takes shape during the implementation phase. This phase involves the

construction of the actual project result. Programmers are occupied with encoding,

designers are involved in developing graphic material, contractors are building, the

actual reorganisation takes place. It is during this phase that the project becomes

visible to outsiders, to whom it may appear that the project has just begun. The implementation phase is the ‘doing’ phase, and it is important to maintain the

momentum.

In one project, it had escaped the project team’s attention that one of the most

important team members was expecting to become a father at any moment and

would thereafter be completely unavailable for about a month. When the time

came, an external specialist was brought in to take over his work, in order to keep

the team from grinding to a halt. Although the team was able to proceed, the

external expertise put a considerable dent in the budget.

At the end of the implementation phase, the result is evaluated according to the list

of requirements that was created in the definition phase. It is also evaluated

according to the designs. For example, tests may be conducted to determine

whether the web application does indeed support Explorer 5 and Firefox 1.0 and

higher. It may be determined whether the trim on the building has been made

according to the agreement, or whether the materials that were used were indeed

those that had been specified in the definition phase. This phase is complete when

all of the requirements have been met and when the result corresponds to the

design.

(image taken from AIMS project management academy course)

Those who are involved in a project should keep in mind that it is hardly ever

possible to achieve a project result that precisely meets all of the requirements that

were originally specified in the definition phase. Unexpected events or advancing

insight sometimes require a project team to deviate from the original list of

requirements or other design documents during the implementation of the project.

This is a potential source of conflict, particularly if an external customer has

ordered the project result. In such cases, the customer can appeal to the

agreements that were made during the definition phase.

(this article which originally written by me when I was giving lectures in my institute for the students of project management certification will continue in parts on my blog)

Follow-up phase Project Management

Although it is extremely important, the follow-up phase is often neglected. During this phase, everything is arranged that is necessary to bring the project to a successful completion. Examples of activities in the follow-up phase include writing handbooks, providing instruction and training for users, setting up a help desk, maintaining the result, evaluating the project itself, writing the project report, holding a party to celebrate the result that has been achieved, transferring to the directors and dismantling the project team.

The central question in the follow-up phase concerns when and where the project ends. Project leaders often joke among themselves that the first ninety per cent of a project proceeds quickly and that the final ten per cent can take years. The boundaries of the project should be considered in the beginning of a project, so that the project can be closed in the follow-up phase, once it has reached these boundaries.

It is sometimes unclear for those concerned whether the project result is to be a prototype or a working product. This is particularly common in innovative projects in which the outcome is not certain. Customers may expect to receive a product, while the project team assumes that it is building a prototype. Such situations are particularly likely to manifest themselves in the follow-up phase.

(image taken from AIMS project management academy course)

Consider the case of a software project to test a very new concept. There was some anxiety concerning whether any results would be produced at all. The project eventually produced good results. The team delivered a piece of software that worked well, at least within the testing context. The customer, who did not know much about IT, thought that he had received a working product. After all, it had worked on his office computer. The software did indeed work, but when it was installed on the computers of fifty employees, the prototype began to have problems, and it was sometimes instable.

Although the programmers would have been able to repair the software, they had no time, as they were already involved in the next project. Furthermore, they had no interest in patching up something that they considered a trial piece. Several months later, when Microsoft released its Service Pack 2 for Windows, the software completely stopped functioning. The customer was angry that the ‘product’ once again did not work. Because the customer was important, the project leader tried to persuade the programmers to make a few repairs. The programmers were resistant, however, as repairing the bugs would cause too much disruption in their new project. Furthermore, they perceived the software as a prototype. Making it suitable for large-scale use would require changing the entire architectural structure. They wondered if the stream of complaints from the customer would

ever stop.

(this article which originally written by me when I was giving lectures in my institute for the students of project management certification will continue in parts on my blog)

Coordination of projects

As described in earlier chapters, the control factors are the parameters along which

projects are reported on and directed. These factors also play an important role in

the coordination of multiple projects:

Money: determining whether projects are financially feasible

Organisation: arriving at mutual agreements concerning the hierarchy among

projects and between the projects and other departments

Quality: determining whether the goals of a project are consistent with the strategy

of the organisation

Information: establishing who will report what about the project and when to the

management team?

(image taken from AIMS project management academy course)

Time: estimating how many personnel will be needed within a given period to

arrive at a good distribution of workers across the project teams.

Before the start of a project and after each project phase, a project leader should

provide an estimate of the control factors for the rest of the project. The project

leader also evaluates these factors as they have been implemented thus far after

each phase. This information is transferred to a programme manager or the

management team for decision-making purposes, usually in collaboration with the

project leader and external parties (e.g. customers, financers). Several of the most

important decision criteria are described below, particularly those that relate to the

coordination of projects.

Money

The evaluation of financial matters by a programme manager involves the following

issues:

·         Is the project as a whole, and the following phase in particular, adequately

·         financed?

·         What are the possible financial risks of the project? Should a go/no-go moment

·         be arranged?

·         What is the liquidity prognosis for the project? Would a problem arise if the

·         income from a project were to arrive later than the expenditures (e.g. if the

·         subsidy is paid only after the completion of a lengthy project)?

(this article which originally written by me when I was giving lectures in my institute for the students of project management certification will continue in parts on my blog)

The six phases of project management

This chapter provides a sketch of the traditional method of project management. The model that is discussed here forms the basis for all methods of project management. Later chapters go into more depth regarding a model that is particularly appropriate for IT-related projects. Dividing a project into phases makes it possible to lead it in the best possible direction. Through this organisation into phases, the total work load of a project is divided into smaller components, thus making it easier to monitor. The following paragraphs describe a phasing model that has been useful in practice. It includes six phases:

·         Initiation phase

·         Definition phase

·         Design phase

·         Development phase

·         Implementation phase

·         Follow-up phase

Image taken from AIMS project management academy from the course of project management degree

Initiation phase

The initiation phase is the beginning of the project. In this phase, the idea for the project is explored and elaborated. The goal of this phase is to examine the feasibility of the project. In addition, decisions are made concerning who is to carry out the project, which party (or parties) will be involved and whether the project has an adequate base of support among those who are involved. In this phase, the current or prospective project leader writes a proposal, which contains a description of the above-mentioned matters. Examples of this type of project proposal include business plans and grant applications. The prospective sponsors of the project evaluate the proposal and, upon approval, provide the necessary financing. The project officially begins at the time of approval. Questions to be answered in the initiation phase include the following:

•        Why this project?

•        Is it feasible?

•        Who are possible partners in this project?

•        What should the results be?

•        What are the boundaries of this project (what is outside the scope of the project)?

The ability to say ‘no’ is an important quality in a project leader. Projects tend to expand once people have become excited about them. The underlying thought is, ’While we’re at it, we might as well …’ Projects to which people keep adding objectives and projects that keep expanding are nearly certain to go off schedule, and they are unlikely to achieve their original goals.

I wrote this article in my early stages of project management certification and found it useful for my several students so now iam posting it online for all students of project management in world.
Blogging Fusion Blog Directory