Abhijit Kishore Khare DPGD/JL13/0854 E-Business
1 | Pag e
I am using this opportunity to express my gratitude to everyone who supported me throughout the course of this project. I am thankful for their aspiring guidance, invaluably constructive criticism and friendly advice during the project work. I am sincerely grateful to them for sharing their truthful and illuminating views on a number of issues related to the project.
I would like to thank my project external guide Mr. Milton Simons and all the people who provided me with the facilities being required and conductive conditions for my project.
hank you,
!bhijit "ishore "hare
2 | Pag e
I am using this opportunity to express my gratitude to everyone who supported me throughout the course of this project. I am thankful for their aspiring guidance, invaluably constructive criticism and friendly advice during the project work. I am sincerely grateful to them for sharing their truthful and illuminating views on a number of issues related to the project.
I would like to thank my project external guide Mr. Milton Simons and all the people who provided me with the facilities being required and conductive conditions for my project.
hank you,
!bhijit "ishore "hare
2 | Pag e
CE!"#"CA!E #$% G&"DE his is to certify that the project entitled, “Basic overview of various aspects of an IT project" submitted submitted by !bhijit "ishore "hare in partial fulfillment of the requirements for the award of #$%&'!# in ()'usiness at the *elingkar Institute of Management is an authentic work carried out by him under my supervision and guidance. o the best of my knowledge, the matter embodied in the project has not been submitted to any other +niversity Institute for the award of any &egree or &iploma.
Date' ()/05/(015 %i*ton +i,ons et.or suort *eaer !e2h %ahinra Business +eri2es
3 | Pag e
Chapter Number
Title (xecutive Summary
1
Introduction
(
-iterature review
3
bjective of study
4
Methodology
5
bservations !nalysis / &iscussion
)
Summary 0onclusion 1ecommendations
'ibliography
4 | Pag e
Page Number
"nformation echnology and the development of business computer systems, is relatively new, by which I mean less than 23 years old. !s the technologies grew more sophisticated 4e.g. disks, bigger memories and compilers5 so the systems we developed became much more complex. !s the I industry grew, so did the numbers of programmers, analysts and operators working within it. hese were mostly very bright people, skilled and inventive but with often little appreciation of the needs of business. he wheel would be reinvented countless times in many different ways and there were as many different ways of structuring computer programs as there were programmers doing it. hese were mostly very bright people, skilled and inventive but with often little appreciation of the needs of business. he wheel would be reinvented countless times in many different ways and there were as many different ways of structuring computer programs as there were programmers doing it6 his was partly the trigger for the emergence of project management methodologies because I project management was frequently assigned to systems analysts and programmers with massive technological skills but little in the way of organi7ational skills. he management consultancies quickly saw commercial opportunities
and
we saw
a
plethora of proprietary
project
management
methodologies but it was the +" government8s 00! which broke the mold and launched $1M$ ) an almost workable methodology for I project management. his was developed, firstly, into $1I90( and then into $1I90(:, which is good and has become widely adopted. $roject management is more than j ust the mechanics of
5 | Pag e
the process. It is about interpersonal skills, stakeholder awareness, presentation to management and understanding your rules for winning.
6 | Pag e
“A Project is a unique undertaking with a defined starting point and duration directed at achieving defined objectives, utiliing finite or infinite resources! $roject management is the management of an organi7ed set of activities directed toward a common goal, using speciali7ed management structures and techniques it includes;
s e 3 i t 2 e j b o t 2 e j o r 0 6 n i n i , r e t e D 5 s e 2 r u o s e r 1 n a s t e 6 1 u b 6 n i 6 a n a % 5 s s e r 6 o r P 6 n i t r o 0 e 5 s s e n e 3 i t 2 e 7 7 e 1 n a 8 2 n e i 2 i 7 7 e 6 n i t a u * a 3 E 5
Deter,inin6 roje2t obje2ties *hat is the goal 4or goals5 of the project< (xamples of project goals include building a bridge, relocating the MIS department to a new site or installing a new phone
7 | Pag e
system. More importantly, some examples of things that are 9 projects include scheduling the usage for a training facility or Scheduling engineers in a technical service department. hese are not projects because they do not meet all the criteria of a project. hey do not have a definitive start, finish, and duration. %ana6in6 bu6ets an resour2es $rojects do not get done without resources to do them. o ensure successful completion of a project, it is important to estimate correctly the number of personnel and the amount of equipment needed. *ith this, it is important to reali7e the cost of the project. Some projects can be completed in a shorter time by increasing the manpower on the project. =owever, doing this also increases the cost. ne of the project manager>s jobs is to maintain a balance between reducing costs and reducing the time to complete the project. eortin6 Pro6ress 1eporting progress is a key to project management. It is essential that key players in a project know what is happening, and whether they are on track, behind, or ahead of schedule. 'yre viewing progress on a regular basis, you can try to avoid possible problems in advance. ?or example, if you notice that a certain task was scheduled to take @3 days to accomplish, but on day 2 only :2A of the work was finished, you could possibly re)allocate resources to that task in order to complete it on time. Ea*uatin6 e77i2ien2 an e77e2tieness &uring and after a project, it is important to review and analy7e the performance on the project. his information can provide valuable insight into possible changes to
8 | Pag e
make for future projects. ?or example, your project was to build a house, and one of the steps involved was landscaping. !fter the project is finished, you notice that it took less time to do the landscaping than you originally planned. his information could be valuable if you build another house, because you could reduce the time allocated for landscaping. 'y constantly reviewing the efficiency and effectiveness of your project, you can more accurately plan future projects.
Characteristics of a project • • • •
Has a start and end date Unique endeavor Objective oriented Usually involves progressive elaboration and rolling wave planning.
?ive (ssential (lements of $roject Management.
| Pag e
@
:
&!itiate Pla! "#ecute Close co!trol $o!itor a!% C 2
B
1' | P a g e
Initiation process is about defining a new project or a phase of a project. hese initiation are often performed outside project manager>s domain. he initiation phase is the beginning of the project. In this phase, the idea for the project is explored and elaborated. he 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 4or parties5 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. (xamples of this type of project proposal include business plans and grant applications. he prospective sponsors of the project evaluate the proposal and, upon approval, provide the necessary financing. he project officially begins at the time of approval. Duestions to be answered in the initiation phase include the following;
• • • • •
*hy this project< Is it feasible< *ho are possible partners in this project< *hat should the results be< *hat are the boundaries of this project 4what is outside the scope of the project5<
11 | P a g e
he ability to say no is an important quality in a project leader. $rojects tend to expand once people have become excited about them. he underlying thought is, *hile we>re at it, we might as well .$rojects 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. In the initiation phase, the project partners enter a 4temporary5 relationship with each other. o prevent the development of false expectations concerning the results of the project, it makes sense to explicitly agree on the type of project that is being started;
• • •
! research and development projectE ! project that will deliver a prototype or 8proof of concept8E ! project that will deliver a working product.
he choice for a particular type of project largely determines its results. ?or example, a research and development project delivers a report that examines the technological feasibility of an application. ! project in which a prototype is developed delivers all of the functionalities of an application, but they need not be suitable for use in a particular context 4e.g. by hundreds of users5. ! project that delivers a working product must also consider matters of maintenance, instructions and the operational management of the application.
Many misunderstandings and conflicts arise because the parties that are involved in a project are not clear on these matters. 0ustomers may expect a working product, while the members of the project team think they are developing a prototype. ! sponsor may think that the project will produce a working piece of software, while the 12 | P a g e
members of the project team must first examine whether the idea itself is technically feasible.
13 | P a g e
$lanning phase is made up of : parts
De7inition Phase
$laning phase
De7inition 0hase
14 | P a g e
Desi6n 0hase
!fter the project plan 4which was developed in the initiation phase5 has been approved, the project enters
the
second
phase;
the
$lanning phase. In this phase, the requirements that are associated with a project result are specified as clearly as possible. his involves identifying the expectations that all of the involved parties have with regard to the project result. =ow many files are to be archived< Should the metadata conform to the &ata &ocumentation Initiative format, or will the &ublin 0ore 4&05 format suffice< May files be deposited in their original format, or will only those that conform to the $referred Standards be accepted< Must the depositor of a dataset ensure that it has been processed adequately in the archive, or is this the responsibility of the archivist< *hich guarantees will be made on the results of the project< he list of questions goes on and on. It is important to identify the requirements as early in the process as possible. *ijnen 4:33B5 distinguishes several categories of project requirements that can serve as a memory aid;
• • • •
$reconditions ?unctional requirements perational requirements &esign limitations
15 | P a g e
$reconditions form the context within which the project must be conducted. (xamples
include
legislation,
working)condition
regulations
and
approval
requirements. hese requirements cannot be influenced from within the project. ?unctional requirements are requirements that have to do with the quality of the project result 4e.g. how energy)efficient must an automobile be or how many rooms must a new building have<5. perational requirements involve the use of the project result. ?or example, after a software project has been reali7ed, the number of malfunctions that occur must be reduced by ninety per cent. ?inally, design limitations are requirements that involve the actual reali7ation of the project. ?or example, the project cannot involve the use of toxic materials or international partners for whom it is unclear whether they use child labor. &uring the definition phase of a project that involved developing a web application for a consortium of large organi7ations, no agreements were made concerning the browser that would be supported by the application. he consortium assumed that it would be Microsoft (xplorer, because it was the browser that everyone used. he programmers created the application in ?irefox, because they worked with the browser themselves and because it had a number of functions that were particularly useful during the development. 'ecause most of the websites that are made for ?irefox also look good in (xplorer, the difference was initially not noticeable. 9ear the end of the project, however, the customer began to complain that the website didn>t look good. he programmers, who had been opening the site in ?irefox, did not understand the complaint. *hen the problem of the two browsers became clear, the programmers reacted defensively, 0an>t they just install ?irefox< !fter all, it is free. he organi7ations, 16 | P a g e
however, were bound to the bureaucratic)minded system administrators who, for some possibly justified reason, refused to install ?irefox in addition to (xplorer. (ven if they had wanted to install it, it would have involved a lengthy process, and there would have been extra costs for the time that the system administrators would have to spend on the task. It was ultimately decided that the application would have to be made suitable for (xplorer. hat involved considerable extra work, whereby the project ran even more behind schedule than it already had, and it was necessary to negotiate the extra costs. It was later discovered that the various organi7ations were working with different versions of Microsoft (xplorer. It is very important that all parties that are involved in the project are able to collaborate during the definition phase, particularly the end users who will be using the project result. he fact that end users are often not the ones that order the project perhaps explains why they are often ignored. he client, who pays for the project, is indeed invited to collaborate on the requirements during the definition phase. 9onetheless, the project result benefits when its future users are also invited. !s a point of departure, it is helpful to make a habit of organi7ing meetings with all concerned parties during the definition phase of a project. &uring the development of an educational video game, the users 4young people5 were involved in the project only at a later stage. *hen the game was nearly completed, a group of young people was asked to test the game. heir initial assessments appeared mild and friendly. *hen pressed, however, they admitted that they had actually found the game extremely boring and that they would certainly not play it themselves. =ad these young people been involved in the project earlier, the game would probably have been a success. !s it stands, the game remains nearly unused on an Internet website. 17 | P a g e
he result of the definition phase is a list of requirements from the various parties who are involved in the project. (very requirement obviously has a reverse side. he more elaborate the project becomes, the more time and money it will cost. In addition, some requirements may conflict with others. 9ew copy machines are supposed to have less environmental impactE they must also meet requirements for fire safety. he fire)safety regulations require the use of flame)retardant materials, which are less environmentally friendly. !s this illustration shows, some requirements must be negotiated. +ltimately, a list of definitive requirements is developed and presented for the approval of the projects decision)makers. nce the list has been approved, the $lanning phase can begin. !t the close of the definition phase, most of the agreements between the customer and the project team have been established. he list of requirements specifies the guidelines that the project must adhere to. he project team is evaluated according to this list. !fter the definition phase, therefore, the customer can add no new requirements. ! part of a new exhibit in a museum was comprised of a computer installation, the creation of which had been project)based. 'ecause there had been no definition phase in the project, no clear agreements between the museum and those responsible for building the installation had been made. *hen the computer for the installation broke down halfway through the exhibit, the museum assumed that it would be covered by the projects guarantee. he project team had a different opinion. 9egotiations between the directors were necessary in order to arrive at an appropriate solution.
18 | P a g e
Desi6nin6 Phase he
list
of
requirements
that
is
developed in the definition phase can be used to make design choices. In the design phase, one or more designs are developed, with which the project result can apparently be achieved. &epending on the subject of the project, the products of the design phase can include dioramas, sketches, flow charts, site trees, =M- screen designs, prototypes, photo impressions and +M- schemas. he project supervisors use these designs to choose the definitive design that will be produced in the project. his is followed by the development phase. !s in the definition phase, once the design has been chosen, it cannot be changed in a later stage of the project.
E9a,*e' G*oba* esi6n 7or the DA+ Ar2hite2ture Ar2hie
?ront (nd
+ser
'ack end
'ack end
'ack end
1 | P a g e
In a young, very informal company, the design department was run by an artist. he term design department was not accurate in this caseE it was more a group of designers who were working together. In addition, everyone was much too busy, including the head of the department. ne project involved producing a number of designs, which were quite important to the success of the project. ! young designer on the project team created the designs. !lthough the head of the design department had ultimate responsibility for the designs, he never attended the meetings of the project team when the designs were to be discussed. he project leader always invited him, and sent him e)mails containing his young colleague>s sketches, but the e)mails remained unanswered. he project leader and the young designer erroneously assumed that the department head had approved the designs. he implementation phase began. *hen the project was nearly finished, the result was presented to the department head, who became furious and demanded that it be completely redone. he budget, however, was almost exhausted.
2' | P a g e
(xecution phase is divided into C parts
(xecution phase
De3e*o0,ent 0hase
",0*e,entation 0hase
#o**o.-u0 0hase
Dee*o,ent hase &uring the &evelopment phase, everything that will be needed to implement the project is arranged. $otential suppliers or subcontractors are brought in, a schedule is made, materials and tools are ordered, and instructions are given to the personnel and so forth. he (xecution phase is complete when implementation is r eady to start. !ll matters must be clear for the parties that will carry out the implementation. In some projects, particularly smaller ones, a formal development phase is probably not necessary. he important point is that it must be clear what must be done in the (xecution phase, by whom and when.
21 | P a g e
",*e,entation hase he project takes shape during the implementation phase. his phase involves the construction of the actual project result. $rogrammers are occupied with encoding, designers are involved in developing graphic material, contractors are building, and the actual reorgani7ation 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. he 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. *hen 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. !lthough the team was able to proceed, the external expertise put a considerable dent in the budget.
!t 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. ?or example, tests may be conducted to determine whether the web application does indeed support (xplorer 2 and ?irefox @.3 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. his phase is complete when all of the requirements have been met and when the result corresponds to the design. 22 | P a g e
hose 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. +nexpected 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. his 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.
!s a rule, the requirements cannot be changed after the end of the definition phase. his also applies to designs; the design may not be changed after the design phase has been completed. Should this nonetheless be necessary 4which does sometimes occur5, the project leader should ensure that the changes are discussed with those involved 4particularly the decision)makers or customers5 as soon as possible. It is also important that the changes that have been chosen are well documented, in order to prevent later misunderstandings. More information about the documentation of the project follows later in this handbook. #o**o.-u hase
!lthough it is extremely important, the follow)up phase is often neglected. &uring this phase, everything is arranged that is necessary to bring the project to a successful completion. (xamples of activities in the follow)up phase include writing handbooks, providing instruction and training for users, setting up a help desk, maintaining the 23 | P a g e
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. he central question in the follow)up phase concerns when and where the project ends. $roject 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. he 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. his is particularly common in innovative projects in which the outcome is not certain. 0ustomers 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. 0onsider the case of a software project to test a very new concept. here was some anxiety concerning whether any results would be produced at all. he project eventually produced good results. he team delivered a piece of software that worked well, at least within the testing context. he customer, who did not know much about I, thought that he had received a working product. !fter all, it had worked on his office computer. he 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. !lthough the programmers would have been able to repair the software, they had no time, as they were already involved in the next project. ?urthermore, they had no
24 | P a g e
interest in patching up something that they considered a trial piece. Several months later, when Microsoft released its Service $ack : for *indows, the software completely stopped functioning. he customer was angry that the product once again did not work. 'ecause the customer was important, the project leader tried to persuade the programmers to make a few repairs. he programmers were resistant, however, as repairing the bugs would cause too much disruption in their new project. ?urthermore, they perceived the software as a prototype. Making it suitable for large) scale use would require changing the entire architectural structure. hey wondered if the stream of complaints from the customer would ever stop. he motto, hink before you act is at the heart of the six)phase model. (ach phase has its own work package. (ach work package has its own aspects that should be the focus of concentration. It is therefore unnecessary to continue discussing what is to be made during the implementation phase. If all has gone well, this was already determined in the definition phase and the design phase. ?or a more detailed description of the six)phase model and the task packets for each phase. Monitoring and controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project. he key benefit is that project performance is observed and measured regularly to identify variances from the project management plan.
25 | P a g e
Monitoring and controlling includes; Measuring the ongoing project activities 48where we are85E Monitoring the project variables 4cost, effort, scope, etc.5 against the project management plan and the project performance baseline 4where we should be5E Identify corrective actions to address issues and risks properly 4=ow can we get on track again5E Influencing the factors that could circumvent integrated change control so only approved changes are implemented. In multi)phase projects, the monitoring and control process also provides feedback between project phases, in order to implement corrective or preventive actions to bring the project into compliance with the project management plan. $roject maintenance is an ongoing process, and it includes; 0ontinuing support of end)users 0orrection of errors +pdates of the software over time
26 | P a g e
Monitoring and controlling cycle In this stage, auditors should pay attention to how effectively and quickly user problems are resolved. ver the course of any construction project, the work scope may change. 0hange is a normal and expected part of the construction process. 0hanges can be the result of necessary design modifications, differing site conditions, material availability, contractor)requested changes, value engineering and impacts from third parties, to name a few. 'eyond executing the change in the field, the change normally needs to be documented to show what was actually constructed. his is referred to as change management. =ence, the owner usually requires a final record to show all changes or, more specifically, any change that modifies the tangible portions of the finished work. he record is made on the contract documents F usually, but not necessarily limited to, the design drawings. he end product of this effort is what the industry terms as)built drawings, or more simply, Gas built.H he requirement for providing them is a norm in construction contracts. 0onstruction document management is a 27 | P a g e
highly important task undertaken with the aid an online or desktop software system, or maintained through physical documentation. he increasing legality pertaining to the construction industries maintenance of correct documentation has caused the increase in the need for document management systems. *hen changes are introduced to the project, the viability of the project has to be re) assessed. It is important not to lose sight of the initial goals and targets of the projects. *hen the changes accumulate, the forecasted result may not justify the original proposed investment in the project. Successful project management identifies these components, and tracks and monitors progress so as to stay within time and budget frames already outlined at the commencement of the project.
$roject controlling should be established as an independent function in project management. It implements verification and controlling function during the processing of a project in order to reinforce the defined performance and formal goals. he tasks of project controlling are also;
he creation of infrastructure for the supply of the right information and its update he establishment of a way to communicate disparities of project parameters he development of project information technology based on an intranet or the determination of a project key performance indicator system 4"$I5 &ivergence analyses and generation of proposals for potential project regulations he establishment of methods to accomplish an appropriate project structure, project workflow organi7ation, project control and governance 28 | P a g e
0reation of transparency among the project parameters ?ulfillment and implementation of these tasks can be achieved by applying specific methods and instruments of project controlling. he following methods of project controlling can be applied;
• • • • • • • • • •
Investment analysis 0ostFbenefit analysis alue benefit analysis (xpert surveys Simulation calculations 1isk)profile analysis Surcharge calculations Milestone trend analysis 0ost trend analysis argetactual)comparison
$roject control is that element of a project that keeps it on)track, on)time and within budget $roject control begins early in the project with planning and ends late in the project with post)implementation review, having a thorough involvement of each step in the process. $rojects may be audited or reviewed while the project is in progress. ?ormal audits are generally risk or compliance)based and management will direct the objectives of the audit. !n examination may include a comparison of approved project management processes with how the project is actually being managed. (ach project should be assessed for the appropriate level of control needed; too much control is too time consuming, too little control is very risky. If project control is not 2 | P a g e
implemented correctly, the cost to the business should be clarified in terms of errors and fixes.
0ontrol systems are needed for cost, risk, quality, communication, time, change, procurement, and human resources. In addition, auditors should consider how important the projects are to the financial statements, how reliant the stakeholders are on controls, and how many controls exist. !uditors should review the development process and procedures for how they are implemented. he process of development and the quality of the final product may also be assessed if needed or requested. ! business may want the auditing firm to be involved throughout the process to catch problems earlier on so that they can be fixed more easily. !n auditor can serve as a controls consultant as part of the development team or as an independent auditor as part of an audit.
'usinesses sometimes use formal systems development processes. hese help assure that systems are developed successfully. ! formal process is more effective in creating strong controls, and auditors should review this process to confirm that it is well designed and is followed in practice. ! good formal systems development plan outlines;
! strategy to align development with the organi7ation>s broader objectives Standards for new systems $roject management policies for timing and budgeting 3' | P a g e
$rocedures describing the process (valuation of quality of change
#ie 2ontro* 7a2tors o7 a roje2t
Time
Money
Quality
Organiation
!n"ormation
!i,e
31 | P a g e
he time factor manifests itself in a project in the form of deadlines for tasks and the amount of time that these tasks may take. Managing time involves ensuring that tasks are completed on time.
ime in project plans; &etermine which activities should take place in which phase. (stimate how long each activity will take &etermine the order in which activities should be completed. !llocate people and materials. !llocate activities over time. &etermine the 4most important5 deadlines. ime in progress monitoring; Monitor progress. Monitor deadlines. !djust schedules. ime in project reporting;
1eport on the actual timeline. !naly7e and explain why some tasks proceeded much more quickly or much more slowly than expected.
32 | P a g e
ime schedules are based on a work)breakdown structure 4*'S5. ! *'S is a decomposition of the tasks that must be completed in order to achieve the project result. &eveloping a time schedule requires knowing the amount of time that is needed for each task, who will complete each task and when.
! rapidly growing organi7ation was continually taking on more projects. !s the company continued to become busier its products were in great demand the personnel began to feel pressured to work in a fren7y to complete all of the work that needed to be done. he personnel wanted more people to be hired. 'ecause of the cost, management was hesitant to do so, and they pressured the existing personnel to work harder. =ow much work could the team actually handle< his question apparently had no good answer, as the organi7ation had no time)registration system.
*hen a new project was started, an estimate was made of the number of hours that was thought necessary, but no one ever checked during or after the project to determine whether this number of hours was actually needed. $roject leaders were nonetheless urged to keep their projects under control. he project leaders protested that, without time records, they had no oversight over the projects. !fter all, because they had no insight into the number of hours that were used to carry out the tasks of a project, and there was absolutely no chance of adjustment.
ne project leader decided to register hours with his team. he registration showed that the project ultimately needed four times as many hours as had been originally
33 | P a g e
estimated. !fter reprimanding the project leader for allowing the project to get so far out of hand, the management decided to introduce a time)registration system.
!fter several months, a number of bottlenecks became apparent. It was revealed that nearly all of the projects had been budgeted too narrowly. In practice, personnel who had been assigned to work on a project for one hundred hours often proved to need three times as many hours. his transparency was accompanied by new dilemmas. ne the one hand, there were indeed too few personnel to carry out the projects well. !dditional personnel were needed. he costs of sufficient personnel were considerable. n the other hand, the projects had apparently been sold far too cheaply 4for too few hours5 to customers. he management was afraid that they would not receive any more orders if they began to charge more hours in their estimates.
%one
he money factor manifests itself in the project budget. he management of money within a project involves ensuring that the costs remain within the budget. %iven that the majority of the costs in most projects are comprised of labor costs, the factors of money and time 4the number of labor hours5 are closely intertwined.
Money in project plans;
34 | P a g e
&etermine the fees of the team members. (stimate the hours for the team members. !ssign budgets to team members for specific tasks. &etermine costs for material and tools. Money in progress monitoring;
Monitor cash flow. 9egotiate with suppliers. &etermine whether the original cost estimates are stil l accurate. !djust budgets. 9egotiate with customer andor client concerning budget adjustments. Money in project reporting;
0ompile financial reports and statements. !naly7e definitive financial report.
35 | P a g e
:ua*it
he project result must fulfil a number of quality requirements. his also applies to the various intermediate products of the project. *hen managing a project, it is particularly important for quality requirements to be determined, agreed upon and recorded in writing during the definition phase. hese requirements should never remain implicit. ! clear list of requirements can be checked at the end of the implementation phase. his can allow the project team to prove that they have carried out the project according to specifications. !dditional quality requirements may be specified for various tasks within the project. ?or example, a particular task can be carried out only by certified personnel.
Duality in project plans;
(stablish the desired quality of the project result and the intermediate products 4this takes place primarily in the definition phase5. (stablish the desired quality of the carrying out of the various activities in the project. Duality in progress monitoring;
est the 4intermediate5 results. !ddress any quality problems. Duality in the project reporting; 36 | P a g e
0onfirm that the desired quality has been attained. !ddress any complaints 4particularly in the follow)up phase5. $erfectionism impedes project management. ! pragmatic attitude toward the quality levels of a project can be expressed as 8%ood enough is good8. $rojects that strive to achieve the highest possible level of quality are often at great risk of never being completed.
37 | P a g e
$r6ani;ation
*ithin a project, the team must be managed. In the narrowest sense, team management involves determining who will do what from the list of activities. In broader terms, it also involves all of the soft skills 4e.g. motivational techniques, communication skills, leadership styles5 that are needed to achieve a goal with a group of people. 1egardless of their importance, these soft skills exceed the scope of this handbook.
rgani7ation in project plans;
!ssemble the team. !ssign authority. !ssign tasks to team members. Make agreements concerning the availability of people with other 4project5 managers and higher management. rgani7ation in progress monitoring;
&irect the team. Monitor human aspects 4soft skills5. Mediate between the parties who are involved in the project.
38 | P a g e
"n7or,ation he information factor concerns how, by whom and on which basis decisions can be taken. *ho may decide about which matters in the project< Is it the project leader, the client or a substantive expert within the team< *hat will be archived and by whom< *ill tools 4e.g. project website, issue tracker, e)mail notification, and joint agenda5 be used< hese and other informational questions must be answered before a project can be started. rgani7ations that regularly work with projects have a number of tools 4e.g. *ord templates5 on hand for handling information within a project.
Information in project plans; *hich information must be provided to whom and in which form< *hich information will be recorded, distributed and archived< *hich information tools will be used< Information in progress monitoring;
!rrange for periodic consultation. (nsure that the right information is provided to the right person. &etermine whether agreements have been met. Information in project reporting;
3 | P a g e
*rite the project report. !ppendices J through K of this handbook provide a number of samples of information forms that can be used for exchanging information exchange within a project;
Issue list !ction)and)decision list 1isk log Meeting report
he issue list contains all of the points that must be discussed. his list must be discussed regularly. ?or keeping track of progress and registering decisions that have been taken, a model for an action and decision list has been included. ! risk log has been included to help document risks that are identified during a project. hese risks must then be discussed in the next meeting of the project team and, where necessary, eliminated. ?inally, a standard meeting report has been included as an example of how to compiled and archive this type of report. !ppendix C contains an overview of helpful tools by third parties.
ne important aspect of securing the information concerning a project is that all decisions should be reproducible. &ecisions are often taken orally and not archived. 1egardless of how clear such decisions may seem at the time for both parties, they 4' | P a g e
must eventually appear in writing. If this is not possible, the undocumented decision can become a source of misunderstanding or even conflict.
Many projects are delayed by various interventions from outside 4e.g. this is even more important, this is better politically, the customer wants us to work on something else first5. "eeping a personal log for recording this type of intervention can help project workers identify the cause of project delays.
41 | P a g e
he $roject 0losure $hase is the last phase in the project life cycle. In this phase, you will formally close your project and then report its overall level of success to your sponsor. $roject
0losure
deliverables
to
involves your
handing
customer,
over
the
passing
the
documentation to the business, cancelling supplier contracts,
releasing
staff
and
equipment,
and
informing stakeholders of the closure of the project. !fter the project has been closed, a $ost Implementation 1eview is completed to determine the project>s success and identify the lessons learned. he activities taken to close a project and the templates which help you to complete each activity, are shown in the following diagram. 0lick the links below to learn how these templates can help you to close projects efficiently. he first step taken when closing a project is to create a $roject 0losure 1eport. It is extremely important that you list every activity required to close the project within this $roject 0losure report, to ensure that project closure is completed smoothly and efficiently. nce the report has been approved by your sponsor, the closure activities stated in the report are actioned.
42 | P a g e
he 9ovember @KL@ issue of Management
1eview
#
contained a paper by %eorge
#peci$c
. &oran called there>s an S.M.!.1..
way
management8s
to
goals
write and
Measureable
M
objectives. It discussed the importance of objectives and the difficulty of setting them. Ideally
speaking,
%
%c&ievable
'
'ealistic
each
corporate, department, and section objective should be;
+e2i7i2 F target a specific area for improvement.
T
Timely
%easurab*e F quantify or at least suggest an indicator of progress. Assi6nab*e F specify who will do it. ea*isti2 F state what results can realistically be achieved, given available resources.
43 | P a g e
!i,e-re*ate F specify when the result4s5 can be achieved. 9otice that these criteria don>t say that all objectives must be quantified on all levels of management. In certain situations it is not realistic to attempt quantification, particularly in staff middle)management positions. $racticing managers and corporations can lose the benefit of a more abstract objective in order to gain quantification. It is the combination of the objective and its action plan that is really important. herefore serious management should focus on these twins and not just the objective. +e2i7i2 he criterion stresses the need for a specific goal rather than a more general one. his means the goal is clear and unambiguousE without vagaries and platitudes. o make goals specific, they must tell a team exactly what8s expected, why it8s important, who>s involved, where it8s going to happen and which attributes are important. ! specific goal will usually answer the five 8*8 questions; *hat; *hat do I want to accomplish< *hy; Specific reasons, purpose or benefits of accomplishing the goal. *ho; *ho is involved< *here; Identify a location. *hich; Identify requirements and constraints.
%easurab*e 44 | P a g e
he second criterion stresses the need for concrete criteria for measuring progress toward the attainment of the goal. he thought behind this is that if a goal is not measurable it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal. ! measurable goal will usually answer questions such as; =ow much< =ow many< =ow will I know when it is accomplished< Indicators should be quantifiable
Attainab*e he third criterion stresses the importance of goals that are realistic and also attainable. *hilst an attainable goal may stretch a team in order to achieve it, the goal is not extreme. hat is, the goals are neither out of reach nor below standard performance, since these may be considered meaningless. *hen you identify goals that are most important to you, you begin to figure out ways you can make them come true. ou develop the attitudes, abilities, skills and financial capacity to reach them. he theory states that an attainable goal may cause goal)setters to identify previously overlooked opportunities to bring themselves closer to the achievement of their goals.
45 | P a g e
• • •
!n achievable goal will usually answer the question how< =ow can the goal be accomplished< =ow realistic is the goal based on other constraints<
e*eant he fourth criterion stresses the importance of choosing goals that matter. ! bank manager8s goal to #Make 23 peanut butter and jelly sandwiches by :pm# may be specific, measurable, attainable and time)bound but lacks relevance. Many times you will need support to accomplish a goal; resources, a champion voice, someone to knock down obstacles. %oals that are relevant to your boss, your team, your organi7ation will receive that needed support. 1elevant goals 4when met5 drive the team, department and organi7ation forward. ! goal that supports or is in alignment with other goals would be considered a relevant goal. ! relevant goal can answer yes to these questions; • • • • •
&oes this seem worthwhile< Is this the right time< &oes this match our other effortsneeds< !re you the right person< Is it applicable in the current socio)economic environment<
!i,e-boun he fifth criterion stresses the importance of grounding goals within a time)frame, giving them a target date. ! commitment to a deadline helps a team focus their efforts on completion of the goal on or before the due date. his part of the SM!1 goal criteria is intended to prevent goals from being overtaken by the day)to)day crises 46 | P a g e
that invariably arise in an organi7ation. ! time)bound goal is intended to establish a sense of urgency. ! time)bound goal will usually answer the question • • • •
*hen< *hat can I do six months from now< *hat can I do six weeks from now< *hat can I do today<
Proje2t reortin6 0rucial decisions must be taken at five points during a projectE these decision points correspond to the end of each project phase, and they call for recording the projects current status and writing an intermediate report. hey also provide the opportunity to reconsider the project phases that are yet to come. !t these decision points, project leaders should consult with their clients regarding decisions about the project and adjust the control factors, if necessary. ?or example, if many new and unexpected requirements have emerged during the definition phase that could increase the costs considerably, it is useless to proceed with the original budget. he decision points at the end of the phases are often (gono)go moments(E they call for decisions regarding whether to proceed with the project or whether it should be discontinued.
47 | P a g e
he following situation often occurs in organi7ations that do not work according to project phases; a project plan is initially written, in which the control factors are described. ! timeline 4ime5 is specified, and a budget 4Money5 is prepared, a team is formed 4rgani7ation5, a goal is described 4Duality5 and the tools for information services surrounding the project are determined 4Information5. &uring a project, the project leader continues to make sure that the project remains somewhat within the total budget and the timeline, but makes no real adjustments. 9ear the end of a project, the project proves to cost more or to take longer than originally expected. he project is then scaled back to avoid further cost over)runs or delays. +nfortunately, the project result suffers. =ad the project leader in such a case worked with the six)phase model, the team would probably have already concluded in the design phase or perhaps even in the definition phase that the original timeline and budget were insufficient. If the project
48 | P a g e
leader had made adjustments at that time, a simpler design could have been chosen that would have been less expensive and time)consuming to implement. !lternatively, more time, money or both could have been requested from the client. !t any rate, the status of the project would have been clear months earlier, and it would have been possible to steer the project in a meaningful way.
&n2ertaint in roje2t *ans $rojects involve uncertainty. !t 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. ?or 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. his sometimes occurs because of technological developments or developments in the market or political arena. *hen preparing project plans, project leaders can only estimate the control factors 4i.e. time, money, team, quality goals and necessary information5 of the project. !s 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 reali7ed. In the implementation phase, the actual project result is built, and in the follow)up phase, all of the loose ends are tied together. 0larity increases as a project progresses. It is therefore pointless to make a detailed budget for the follow)up phase 4which will take place later5 during the initiation phase. 4 | P a g e
!t this stage, it is still possible for the project to proceed in any of a number of possible directions. he idea has yet to be elaborated. he exact form of the follow) up ph phas ase e is pr prob obab ably ly al also so kn know own n on only ly in th the e br broa oade dest st te term rms. s. h his is is to too o li litt ttle le information upon which to base a realistic, detailed estimate for the follow)up phase. ! broad broad outline of a budget is the most most that can be expected at at this stage. $roject plans therefore work as follows; a global budget is made for the entire project, along with a concrete budget for the next subsequent phase. ?or example, if a project team is preparing to enter the implementation phase 4after the development phase5, they are well aware of what must happen. !t that point, it is possible to make a detailed budget for the implementation im plementation phase. he global budget estimates for the total project must be adjusted after each phase. !fter each phase, there is more knowledge and decisions have been been taken that allow the global budget to be completed in more detail. In this way, estimates of the total costs of the project become increasingly accurate after each phase. Making a global budget for the entire project and a concrete budget for the next phase is important, and not only for the control factor of money money.. It is important to work from global to concrete for the other factors as well. he process of making budget estimates can be summari7ed as follows; 'udgeting should occur before each phase. Make or adjust the global budget for the entire project. Make a concrete budget for the next phase. !ll control factors should be reconsidered reconsidered and re)estimated re)estimated for each new phase.
5' | P a g e
'udgeting in this way 4particularly with regard to time and money5 is a realistic manner of coping with uncertainty, which is greater at the beginning of the project than th an it is at th the e en end. d. It cr crea eate tes s a pr prob oble lem, m, ho howe weve ver, r, for or orga gani ni7a 7ati tion ons s th that at ar are e financed by government subsidies, social foundations or both. his is particularly true for organi7ations that conduct innovative, and thus uncertain, projects. Mostt fou Mos founda ndatio tions ns and gra grant nt mak makers ers req requir uire e a pro projec jectt pro propos posal al tha thatt inc includ ludes es a complete and firmly established budget before they will release funds for a project. !n organi7ation that seeks financing for a project must therefore develop a complete, concrete budget at a very early stage. In the beginning, however, the project is still in the conceptual phase, and it is thus impossible to make a realistic cost estimate or timeline. nly after the design phase, when the idea has been elaborated and a design has been chosen, is there sufficient information to say how much the project will cost and how much time its implementation will take. his stage does not occur until several months after the grant application must be submitted. ne result of the way in which grant makers and foundations tend to work is that many man y org organi ani7at 7ation ions s req reque uest st amo amount unts s tha thatt are bas based ed on rou rough gh es estim timate ates s of the project costs. $roject activities are subsequently fitted to the budget that has been made available. his puts the project team in a tight position from the start, even though the most flexibility is needed in the early stages. he pro proces cess s of ela elabor borati ating ng con concep cepts ts du durin ring g the def defini initio tion n an and d des design ign pha phases ses,, therefore, often reveals that the timeline that was proposed in the grant application is not feasible. he budget may also prove inadequate, including too much for some items and not enough for others others.. !ny addit additional ional requirements requirements from the grant make maker r 4e.g. no item may deviate more than five per cent5 place the project team under
51 | P a g e
immense pressure. Matters must be implemented in too little time and within a budget that is too tight. his situation often leads to considerable shuffling among the various items in the budget. 0onsiderable text and analysis is then necessary in the project statement to explain why the desired r esult was not achieved. he situation would improve if grant makers were to couple their financing onto the vari va riou ous s ph phas ases es in inst stea ead d of pr prov ovid idin ing g fu fund nds s at on one e ti time me in ad adva vanc nce. e. h he e in initi itial al financing would then be intended for the definition and the design phases. he requirements would be investigated and a number of alternative designs would be prepared within this limited budget. ! subsequent subsequent application based on these designs would then be submitted for implementation and follow)up. his would allow projects to av avoi oid d un unne nece cess ssary ary pr pres essu sure re.. !n ad addi diti tion onal al ad adva vant ntag age e wo woul uld d be th that at th the e expectations of the involved parties would be more realistic, saving time, money and disappointment.
N +ser involvement 1elates to involving the right users, who will depend on the technical solution professionally and personally to meet their goals. N (xecutive support specifically related to how timely decisions are made regarding critical issues that impact the project.
52 | P a g e
N 0lear business objectives the focus of the project must be on the business value that the project is to provide the organi7ation, which is driven by a clearly articulated vision of the project>s deliverable solution. N Scope management delivering what the users of the new system need to do their jobsE avoiding extraneous functionality that might never be touched by the users of the system. N 'usiness requirements management the ability to be flexible, yet decisive, in shaping, changing, and managing project requirements. N (xperienced project manager having a project manager on the team who has experience with projects of similar si7e and complexity within the industry on *hich the project is focused. N ?inancial management planning the presence of objective tools for monitoring and interpreting a project>s financial status and relating that to project performance. N $roject team management having access to project team members and subject matter experts with the requisite skills and knowledge to do the work necessary to provide an acceptable solution. N +se of a formal methodology the availability of a project delivery approach that is formally identified yet executed as informally as possible. N $roject management tools and infrastructure the availability and application of tools to facilitate project success, such as schedules, collaboration tools, and scope management tools, and the ability to use and interpret the project artifacts produced by those tools.
53 | P a g e
N $rocurement management planning $rogressive and responsive procurement planning and execution processes that identify procurement needs and the best approach for filling those needs.
54 | P a g e
$roject Management has developed in order to plan, co)ordinate and control the complex and diverse activities of modern industrial and commercial projects. !ll projects share one common characteristic ) the projection of ideas and activities into new endeavors. he purpose of project management is to foresee or predict as many dangers and problems as possibleE and to plan, organi7e and control activities so that the
project
is
completed
as
successfully as possible in spite of all the risks. he ever)present element of risk and uncertainty means that events and tasks leading to completion can never be foretold with absolute accuracy. ?or some complex or advanced projects, even the possibility of successful completion might be of serious doubt. $roject management can involve the following activities; planning ) deciding what is to be doneE organi7ing ) making arrangementsE staffing ) selecting the right people for the jobE directing ) giving instructionsE monitoring ) checking on progressE controlling ) taking action to remedy hold upsE innovation ) coming up with new solutionsE representing ) liaising with users. 55 | P a g e
Per7or,an2e an :ua*it he end result of a project must fit the purpose for which it was intended. !t one time, quality was seen as the responsibility of the quality control department. In more recent years the concept of total quality management has come to the fore, with the responsibility for quality shared by all staff from top management downwards.
Bu6et he project must be completed without exceeding the authori7ed expenditure. ?inancial sources are not always inexhaustible and a project might be abandoned altogether if funds run out before completion. If that was to happen, the money and effort invested in the project would be forfeited and written off. In extreme cases the project contractor could face ruin. here are many projects where there is no direct profit motive, however it is still important to pay proper attention to the cost budgets, and financial management remains essential.
!i,e to Co,*etion !ctual progress has to match or beat planned progress. !ll significant stages of the project must take place no later than their specified dates, to result in total completion on or before the planned finish date. he timescale objective is extremely important because late completion of a project is not very likely to please the project purchaser or the sponsor.
56 | P a g e
57 | P a g e
58 | P a g e
5 | P a g e
6' | P a g e
61 | P a g e
62 | P a g e
63 | P a g e
64 | P a g e
