Information Technology Engineering
In this report, it shall analysis on the aspect of project management. The report shall explore the difference in Information Technology Project Management and Engineering Project Management.
The report shall look into reason that may cause project to fail, and how project management methodology would aid in projects. It will also have an analysis on success and failure projects, contrasting the reasons for both projects to end up as they did.
It will base on the failed project case study, and analyze on how failure could have been avoided, relating it to the nine areas of Project Management Body of Knowledge.
Introduction
A project is a temporary endeavor undertaken to accomplish a unique purpose. [10]
Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet projects requirements. [10]
Project management is no small task; it has a specific beginning and end. It is not a continuous process. Project management uses various tools to measure accomplishments and track project tasks. These may include Gantt charts and PERT charts, It frequently require resources on an ad-hoc basis as opposed to organizations that have only dedicated full-time positions, with project management risk are reduce and chances of success are greatly increased.
Project management is often summarized in a triangle. The three most important factors are time, cost and scope. Project must be delivered on time, within cost, within scope and quality must meet customer requirements.
Source: http://www.projectsmart.co.uk/introduction-to-project-management.html
Compare and Contrast of Information Technology Project Management and Engineering Project Management
Some may argue that managing an IT project is like managing any other projects, all we need to do is to apply the processes, tools, and techniques of conventional project management. This may be true to a certain extent, but a similar approach would not serve the purpose for all projects. Building an IT project is different from building a house or a contracting project. Although many of the project processes are similar, an entirely different approach to engineering is needed.
Complex projects in both IT and other engineering disciplines involve specification, design, development, testing and operational support phases. They also require practices such as thorough quality control and the sharing and management of constraints and dependencies between members of the project team.
However, as discussed above, there is a perception that IT projects have lower success rates than those in more established branches of engineering. Irrespective of the accuracy of this presumption, it is worthwhile exploring the distinctive qualities of IT projects in comparison to other engineering projects.
IT projects are not restricted to the laws of physics and the related constraints in the same way as, engineering projects. This can create a perception that everything and anything can be done using IT. However, this is definitely not the case - software also being controlled by constraints too, but often these tend to be multi-dimensional and theoretical in nature, and therefore hard to understand and communicate. But, both customers and suppliers tend to forget or simply don't understand the constraints of IT, resulting in impractical expectations and almost impossible projects. Indeed, software engineers occasionally are guilty of taking on degrees of innovation and risk far in excess of the typical levels accepted by other engineers. There is this impression that software is generally not bound by any constraints and its potential is therefore limitless.
[6]Software is effectively invisible. This visualization problem is the cause of many possible IT project failures. End users using IT systems may request for impractical and almost impossible functions, without having any sense of the level of difficulty entail in meeting their demand. However, unlike other types of engineering, it is quite unusual for user to have significant first-hand experience of IT project management. It is also extremely demanding to represent the key factors of software in a way that is accessible to all involved stakeholders, making the specification process likely loaded. Whereas in the case of a construction, for example a building it is pretty straight forward to create a physical image that can be debated by the stakeholders and be used as a draft. Most of the time graphical representations are being used for software specification, but these are subject to doubt and only deal with limited aspects of the system. Further difficulty linked with the visibility issue of software occurs during over-seeing of the project. The lack of a physical product means that it is extremely easy for the project to proceed for a substantial time before problems become noticeable, and without it being possible to verify that the time spent and expenditure of money connected with the flow of the project in the desired outcome.
[6]A common problem relating to IT projects, is the indefinable nature of software, and is abuse by the perceived flexibility of software. Unable to visualize the boundaries of what is possible or practical in IT makes people change their mind more frequently than engineering projects where constraints are obvious compare to IT. Undue requests for new features or other amendment to the functions etc. during the course of the project bring in needless and unwanted complexity. This normally contributes to time and budget over-run, thus increasing the chance of IT project failing.
Flexibility is also one of the difficulties faced by IT projects. The fact that there are usually multiple ways of handling the same problem in software engineering, in contrast with, for example, Building a building where there scope and specification tend to be better-defined, and the processes are more established. Moreover, people are quite familiar in having to adjust their processes in order to suit a building, but they will often make modification in software compare to making changes in their processes to fit an off the shelf, proven IT package.
Complexity can be a major barrier in the success of the design and the delivery of IT projects. Though almost all major projects in other engineering disciplines also have to compete with complexity, it seems that in IT projects, complexity is a lot harder to detect and less well understood. In IT, complexity consisted of multi-dimensional, encompassing scale, variety etc. A portion of the complexity is required, i.e. necessary for the delivery of the requirements, at the same time as the remainder can be considered unnecessary and can obstruct with the efficiency and consistency of the system. Complexity in large scale IT systems still remains as an area which is not sufficiently well understood. The level of complexity required in order to achieve certain objective can be very difficult to gauge during the beginning of the project. Resulting in, projects involved much more complexity than was initially planned; such projects are extremely vulnerable to failure or difficulty. For better assessments of the cost of changing specific requirements during the course of the project, intense research into methods to study and predict the behavior of complex systems is required. With technical developments in understanding the complexity should result in improvements in the design and management of complex IT projects.
[6]Majority of IT projects are required to deliver some kind of changes to business or process. In some situation, IT systems will be implemented so as to enable a major business transformation; in other situation they will be automating an existing process. Even with the aim of automation, the people involved will need to make changes to their usual practices, so business changes in some form will ultimately result. As a result, IT practitioners need - but do not always have - a clear understanding of the business and the processes concerned if the IT system is to be used to achieve the intended outcome. Problems can also arise due to lack of description of the business process given to the software engineer does not accurately represent the actual process used in the business.
Reasons for Project Failure
A project can be considered as failed when it does not meet any one of these criteria for success, projects is not delivered on time, projects is not keep within budget, and projects does not fulfill the requirements defined.
So what contributed to this failure, there is no one overriding factors that cause a project to fail. A number of factors are involved in any particular project failure, some of which overlap with each other. Here are just some of the reasons for project failure.
- Lack of user involvement.[7] Without user involvement nobody in the business feels committed to a system, and can even be hostile to it. If a project is to be a success senior management and users need to be involved from the start, and continuously throughout the development. This requires time and effort, and when the people in a business are already stretched, finding time for a new project is not high on their priorities. Therefore senior management need to continuously support the project to make it clear to staff it is a priority.
Communication Breakdown, there is a direct relationship between the size of a project team and the difficulty in keeping all members of that team up to date on changes, progress, tools, and issues. Such problems are common on larger projects, especially if people are working at different sites. In many troubled projects there is no one person who has an overall view of the whole project. Each project member needs to know how his or her part, so as to fit into the entire architecture.
- Long timescales or Unrealistic Timeline for a project has led to systems being delivered for products and services no longer in use by an organization. The key recommendation is that project timescales should be short, which means that larger systems should be split into separate projects. There are always problems with this approach, but the benefits of doing so are considerable.
- Scope [7] is the overall view of what a system will deliver. Scope creep is the insidious growth in the scale of a system during the life of a project. As an example for a system which holds customer records, it is then decided it will also deal with customer bills, and then these bills will be provided on the net, and so on and so forth. All the functionality will have to be delivered at one time, therefore affecting time scales, and all will have to have detailed requirements. This is a management issue closely related to change control. Management must be realistic about what is it they want and when, and stick to it.
- Executive Support [7], the project manager is the interface between the business and technology sides of the company. Without executive support project managers in the organization find difficulty in aligning business with their projects. The executive management also needs to be straightforward if they have reservations about the project. Otherwise, once problems are encountered in the project their support will weaken.
- Inappropriate Skills [7], most projects require various ranges of skills. Many teams lack the depth, and breath they require. It is also not easy for technology based organization to find the experienced people they need because sometimes few people in the labor market have the necessary skills. The larger the project, the more need there is also for people with excellent planning, oversight, organization, and communications skills; experienced technology skilled people do not necessarily have these abilities.
Project Management Methodology
As a Project Manager, you need a Project Management Methodology to steer your projects in the right direction and keep them on track. You also need it to help you manage your projects in a structured, repeatable manner. That way, you can apply the same approach to every project you undertake. Projects are usually divided into phases from initiation to control and to closure. Every phase produced a number of documents as part of a project control process.
- Initiation of a project
[4]All projects usually start with an idea for a service, new capability, products or other desired outcome. This idea is then communicated to the project sponsor by means of a mandate. The mandate shall provide a structured way for proposing a project and contains the projects business case.
Once this mandate has obtained approver a further document is prepared so as to break down the project in greater detail. The project definition report will be used to provide this break down information. This report is crucial to the assessment when deciding if the project should proceeded.
In particular it shall indicate the scope of work, objectives, and goals, what are the deliverables, who are the key personnel, benefits, duration and cost. If the project is approved to proceed, the contract is used to gain formal agreement from the project sponsor and budget holder to start the project. This represents the end of the initiation phase.
- Controlling and Planning of a project
This phase involves controlling and monitoring the project. To do this a detailed project plan need to be developed. The project plan is most generally in the form of a Gantt chart or Work Breakdown Structure (WBS) and identifies the stages, tasks, timeline, cost and resources needed. A good plan shall include regular milestones that serve as a gauge for the project team to focus on short term goals and the project progress. Project plans can also comprise of information about costs and other dependent projects. A Network Diagram or a tracking Gantt chart can be used to monitor progress.
Once the project is planned, it is important to recognize any factors that could create an impact on the project. This is done using an issues and risk log. The issues log is used to note down issues and devised a plan to address them. The risk log is used to note down and do grading for risks with a related action plan to mitigate them.
A criterion for a good project management and a successful project outcome is effective communication. A progress report can be used to communicate progress on a regular basis, depending on the duration of the project, to all stakeholders of the project.
[4]The control phase ends once the project has achieved all its scopes and objectives as detailed in the project definition report. A project may be stopped before completion for a variety of reasons, including changes within a business, lack of resources or higher priorities.
- Project Closure
Project closure is an important part of project management that is often neglected. A project that is not closed keep on consuming resources, even though slowly. Recognition from the customer that the project has ended and a customer acceptance or handing over document is required. Upon signing off the project is considered completed and no further work is to be carried out.
At this point it is important to look back and check if the project has achieved its scopes and objectives. This is done by using a project closure report. This document shall reflect how well the project has performed against its original business case, quality criteria, costs, duration and tolerances.
Instead of leaving valuable project experiences in peoples mind, it's a good practice to create and document down a lessons learnt report. This document can be used to pass on any lessons learn that can be useful for future projects.
Source: http://projectmanagement.cornell.edu/
Success Project
Project Name: Maris Stella High Power Monitoring System
Duration: 6 weeks
Cost & Budget: S$40,000
My company Bridex Harwal Pte Ltd has been awarded the job to do up a Power Monitoring System for Maris Stella High School (MSH). With this system, the school is able to monitor their energy consumption, as well as using our system to inculcate energy saving awareness to their student.
Scope of work as defined by the school,
- The system must be able to be access from anywhere (Internet).
- It must be able to generate daily, weekly, monthly and yearly reports.
- It must be able to monitor energy, voltage, current, power.
- User Interface to show the school logo.
- Total of 17 monitoring points.
Stakeholders,
- Project Sponsor: Maris Stella High, Mr. Alfred Tan V.P
- Project Manager: Bridex Harwal Pte Ltd. Shawn Tan
- Software Engineer User Interface: Zuo Hai
- Software Engineer System Set Up: Dylan
- Software Engineer Database: Muru
- Contractor: TL Installation Pte Ltd
- Production: Mr Neo.
A Gantt chart (appendix 1.1) is developed for this job; it stated the work to be done and the duration of each work. Frequent email corresponding with MSH and the other teams member was sent out regularly to update everybody of the status or any changes to be made .Weekly meeting is also being arranged with MSH to update the client on the status of work and presenting client with the proposed user interface, and getting comments from clients.
On the 4th week the user interface have been finalized by MSH, our software engineer proceed with uploading the software into the server, at the same period the network contracting and production have also completed.
The 5th week the whole system was installed at site and internal testing by Bridex Harwal has been completed.
Testing and Commissioning with the client was carried out on the 6th week and the entire project was handed over to MSH officially with the necessary documents sign off. A job completion dinner was held, all stakeholders were invited for the dinner.
An after action review was conducted between all members involved in this project, to understand the process of the whole projects and the problems faced. With adequate knowledge and experience in previous similar projects, and the ample manpower supplied by the company, the project was a success. Not only the project is able to complete within the timeline, the company was able to achieve higher profit through cheaper supplier.
Failure Project
Project Name: Jurong Point Metering System
Duration: 1 month
Cost/Budget: S$90,000
Bridex Harwal (BH) was given the opportunity by United Premas (UP), to set up an energy monitoring system for the whole shopping mall, so Jurong Point (JP) is able to use our meter reading and bill their tenants.
This system is the first of it kind being used by our company, the system data network shall be transfer through Power Line Carrier (PLC). All the data shall be send to a centralize Data Concentrator and using GSM network being export to another server at other location.
Scope of Work as defined by UP
- To installed energy meters at 280 location at Jurong Point
- System network work to run via PLC
- All data to be sent back UP headquarter via GSM.
- To design a user interface so as to generate monthly reports to the user JP required format.
Stakeholders,
- United Premas, Customer, Project Sponsor
- Jurong Point, Owner,
- Bridex Harwal, Shawn Tan, Project Manager
- Bridex Harwal, Zuo Hai, Software Engineer
- Bridex Harwal, CS, Software Engineer
A project Gantt chart (Appendices 1.2) was drafted, for this job. Meter installation was carried out smoothly and as per plan. By the 3rd week all contracting work was completed, but the software development is still at a preliminary stage, as due to other more profitable job commitment by other software engineer, the resources in term of human resource put in was insufficient. Due to tight schedule, and unavailable of customer regular meeting wasn't able to be carried out. Lack of new technology knowledge causes major delay in the software system. Thus the project was being overstretched by 1 month due to system unable to stabiles, system was unable to handover. Project manager counter proposed to UP, to make changes to the system architecture from GSM to direct reading of data from concentrator. Making some trade off, the system was handed over.
This project was being delayed by 1 month and scope of work was twitch in order to hand over the system, due to the delay additional cost and resources was pump in, minimizing the profit margin.
Comparison of the 2 projects
Analysis of Failure Project
Based on the failed project discussed earlier, an analysis of the Jurong Point Metering System shall be made, and how the failure can be avoided, relating to the nine areas of Project Management Knowledge,
- Project Integration Management
- No proper project plan was drafted out before the start of the project. The plan that was drafted was not dynamic and not flexible; it does not allow any rooms for mistake or delay.
- Although a Gantt chart is drafted, it is not detailed enough, and a Work Breakdown Structure (WBS) was not drafted.
- Stakeholder was not analysis, team members was not sure of their roles and responsibilities, as there are too many uncertainty in the system and technology.
- The project management does not have the experienced as well as the product skills and knowledge.
- Time for the development of the software was overrun; change control was not managed well by the project manager.
- Under the constraint of the commitment of a sales project.
- Project Scope Management
- Scope of work for the project was pre defined in the sales agreement; no major changes should be made.
- Scope of work should be realistic and achievable.
- Project Time Management
- Proper network diagram indicating critical path should be planned during the initial start of the project, as it can greatly assist in planning the time management of the project for individual tasks.
- An over optimistic estimation of time was defined, which leave no room for any slips. PERT formula can be used for estimate the project duration; which have a high degree of uncertainty.
- Unrealistic time schedule was committed by the sales for the project which cause a major delay in delivery of the projects.
- Software engineer unable to keep up with the proposed time scheduled.
- Project Cost Management
- As this is a sale, the cost estimation is already factor in, to gain a certain minimum percentage of profit margins.
- Cost Budgeting was carried out and being plan for all necessary equipment.
- Resource Planning was overlook, under estimating the difficulty of the tasks put upon the team.
- Project Quality Management
- Verifications and validations activities could be carried out throughout the project life cycle
- Problems should be identify earlier if possible, is could save lots of time and money solving the problems at an early stage.
- Project Human Resources Management
- Relationship between the team members should be good, so as to have a good and constant flow of information and update of their task status.
- Project Communication Management
- Poor communications management plan was established, no routine schedule meeting between the team member and customer, was planned due to the tight schedule.
- Basic information distribution of used, like email, phone calls and even short message system, SMS.
- Very minimum time was allocated for formal meeting.
- Task Status was not reported progressively to the project manager, and the project manager did not take the initiative to check with the software engineer on the progress.
- Project Risk Management
- Risk management was overlooked for the project, as the team was confident over the unknown technology, and assumes that it should work like ‘plug and play'.
- A proper risk management could greatly minimize potential risk that could arise, so a change control could be put in place.
- Uncertainty of the technology should not be overlook; a contingency plan should be planned.
- Project Procurement Management
- Proper procurement is carried out three quote was obtained for equipment used, and the most appropriate was chosen.
- Good relationship with vendors, have increase flexibility from contractors, as there are able to expedite the works to be carried out, and earlier delivery dates.
In conclusion, if better planning in the initial stage was carried out and performed, we could minimize the delay of the project. However, as this is a project bound by sales terms, lots of constraints exist, as if we're unable to meet this constraints we might not be able to close the sales. Negligence on the sales party is one of the major factors contributing to the failure of the projects, a more realistic time, and analysis of the resources should be made before undertaking the job. The poor management of the Project manager is another factor that contributes to the failure, as the execution of the project was not carried out smoothly.
Application of Project Management Body of Knowledge
Applying the nine areas of project management knowledge is not a foolproof plan to achieve a successful project. However, by applying this knowledge, proper control of the project and with proper project management tools and techniques, it could greatly increase the success rate of achieving the project scope.
In some situation, like the above failed project, a lot could be done to improve the project, but there are still large portions of grey area, in which it is unavoidable. The company could choose to give up the job and lose the customer or they could take up the challenged and try to overcome it the ‘unrealistic' way.
Even by applying the nine knowledge, certain area like time, cost, and scope management are sometimes not within control. Constrain in time, although is how you manage the 24hrs in a day, but you can't change the facts that certain tasks you will need a minimum time to complete. Scope is predefined by the users, if you are unable to deliver, it should not be committed, as time, scope and cost are always competing with each other, and most often you are unable to achieve the best in all three worlds.
Reference
Internet Sources:
1) http://projectmanagement.cornell.edu/
2) http://en.wikipedia.org/wiki/Project_management
3) http://www.coleyconsulting.co.uk/
4) http://www.projectsmart.co.uk/
5) http://www.projectperfect.com.au/
6) http://www.incoretech.com/impact/failures
Books Sources:
7) Title: Information Technology Project Management, 2nd Edition
Author: Jack T. Marchewka
8) Title: Project Management
Author: Mike Field and Laurie Keller
9) Title: Information Technology, Thomson Course Technology, 3rd Edition
Author: Kathy Schwalbe
10) Title: Project Management Institute (PMI), 2000. A Guide to the Project Management Body of Knowledge (PMBOK Guide).
Author: Newton Square
Publisher: PMI Publishing
Case Study for Success and Failure Projects:
From own sources.
We provide a professional essay writing service that thousands of our customers use as an effective way of improving their grades, improving their research and saving them lots of time.
