Wealth Information Presented through the PMI Website - Case Study Example

Wealth Information Presented Through the PMI Website The purpose of this paper is to provide an overview of the seven project intensive industries based on the report Project Management 2010 + 2020 while highlighting the possible projects in the seven mentioned industries. The paper also provides a detailed explanation of various issues touching on project management all through the globe with respect to Finance and Insurance industry. Wealth Information Presented Through the PMI Website Introduction Every project has a set of variables that gets into it and several external factors which have an influence of whether a project succeeds or fails. Generally, the level of success of projects has remained below average because of lacking consideration for such factors during the project cycle. It is worth noticing that the success of a software project goes beyond the level of knowledge and skills of the involved team hence the need to have all issues possibly affecting the project enlisted in time (Pressman, 424). A project intensive industry is one in which the occupational employment entails a great deal of project-oriented work. As per the report Project Management 2010 + 2020, the project oriented industries include manufacturing, finance and insurance, oil and gases, business services, utilities, information services as well as construction. There are a number of possible projects in the seven project intensive industries. In the finance and insurance sector, a possible project would be the development of new financial accounting software to automate the process of policy premium calculations and preparation of reconciliation statements. In the construction sector, a new project would be an effort to repair an old railway line. In the oil and gases sector, a new project would be to relocate the residents of a recently discovered oil-rich region intended for exploitation so as to increase the exported quantity of oil. In the business services sector, a new project would be to increase geographical scope of sale of a given product. In information services sector the possible project would be a campaign to encourage varied business enterprises to embrace cloud services. In the manufacturing sector, the possible project would be to replace human labor with robots in the production process and finally in the utility sector, the possible project would be the electrification of a given rural area. The remaining section of this paper focuses on the various project management issues surrounding the above stated possible project in the Finance and Insurance industry. Project Drivers A project driver refers to an individual charged with the duty to set directions in a project. There are two options when choosing the project drivers for the E-Accounting system project. The first option is to choose the drivers while the project commences whereas the second option is to appoint the teams at every level that the project reaches. In spite of the set of challenges that larger projects bring about, the involved team will always be presented with a learning opportunity. Choice of the most appropriate path can make an E-Accounting project suitable for smooth running, more appealing outcomes and delivery of services that go far much beyond whatever might have been promised by the involved team (Wiegers, 83). On the other hand, difficulties are likely to be encountered in delivering high quality service within the predetermined time and within scheduled budget in the event that the team deviates from the initial plans. There are a number of factors that will dictate the success level of the E-Accounting project and it is crucial to understand how different aspects of the project could be influenced while the project is underway. Of these aspects, there are those that can be put under control such as choice of the database management system for use in the back end while aspects like query performance could remain unpredictable. Also, there are aspects that remain undiscovered or unseen until such a moment that they occur. The E-Accounting project will constitute enablers. The enablers do not have to perform the managerial roles in this given software project. They will be looking into all elements that can help to empower the involved team by imposing things like high morale and satisfaction. However, there is the common belief that a project where the project managers serve as enablers has higher possibilities of resulting into a higher quality service or product. Use of the enablers can help to have every team member feel appreciated aligned to the overall objective for the reason that they are able to work well with every team member. Furthermore, the enablers can be helpful in establishing an emotional connection between the team members and the intended goal of the E-Accounting system under construction. 
Project Constraints The E-Accounting system project, like all other projects, is bound to face certain constraints. Any manager who wishes to succeed in projects should factor in cost, scope and time issues (Welland and Atkinson, 331) and try creating a common balance between these three factors. Some of the constraints likely to befall the E-Accounting software project are Scope This aspect of the project will cover all that will be carried out as part of the project along with the distinct service or product that the targeted users anticipate concerning the project. Time This project aspect handles issues pertaining to the project’s schedule. It is under this constraint that the time required to complete the E-Accounting software is stated. Quality Under this constraint, the quality of the intended application is to be identified. Also stated under this constraint are the components of the application that will leave the targeted users satisfied following the completion of the software project. Risks Under this constraint, all risks likely to affect the software project are identified along with the plans to reduce the effect of the stated risks on the software project lest the risks bring the entire project to a halt. Functionality The E-Accounting software project, being a new development in the Finance and Insurance sector, is likely to be unclear of the functionalities that are to be implemented (Pomberger, and Blascheck, 155). The project might be reliant upon certain external applications as its data source and this can result into performance issues because the external data sources could be themselves unreliable. Delivery All deliverables presented for approval require a given number of working days for review and it will not be very easy setting time bounds for review actions and approval cycles. Resource Other than the possibility of a great portion of the participating team being unfamiliar with the technical aspect of the application’s construction and the key staff resources being just partially available, a number of the staffs in the project might not have sufficient skills regarding the targeted operating environment of the application. Again, the team used in requirements gathering could constitute fellows who are not in a position to provide the functional requirements of the E-Accounting software. Budgetary Constraints It can be tricky trying to obtain an accurate estimate cost particularly if external consulting requirements are involved. The data sources used in preparing the estimates cannot also be relied upon. Organizational Issues The introduction of this new application affects the finance industry in entirety. This has the meaning that the product has to be delivered at a similar time for people in the industry. Project Issues As per the statement by Chemutur and Cagley, an issue that is discovered by a project team during a project ought to be recorded inside an issue register (289) awaiting action. Otherwise it can turn to be a project killer. Examples of the issues that can affect this project are: Incomplete Requirements Having a set of incomplete requirements is a real killer to software projects like the E- Accounting software project. The project’s budget risks being flooded in case the involved team fails to spend good amount of time during requirements gathering and system documentation while making plans for the project. The worst bit is that the entire project can stop in case the increasing budget cannot be sustained. Incomplete requirements also have the disadvantage of resulting into services or products that ruin the satisfaction and confidence of the targeted end users on the constructed application. This therefore makes it necessary for the involved team plus the team leader to revisit the requirements elicited from the end user to verify the already documented requirements then extract some extra requirements without relying on the level of confidence possibly portrayed by users while stating the system requirements (Whiten and Jeffrey, 131) Poor Communication Disasters can be unavoidable if targets and objectives are poorly communicated among team members. It is useful that the project manager handles the following issues while the project begins a) Determine the manner of communication on the project related issues b) Create a project communication plan document that will be helpful in setting good and realistic expectations c) Keeping schedules pertaining to useful communication such as project status reporting Inconsistent Meeting Schedules This is a weakness in the communication sector. It would be important that the project stakeholders participate in carrying out meetings, regularly report project status and maintain frequent communication. Regular reports on the project status can increase customer confidence while consistent communication helps to strengthen the team. Unattended Budget In every project, E- Accounting software project inclusive, overruns are likely and can bring a whole project down if not identified then corrected in time. Therefore, it would be recommended that the budget of the E-Accounting software project be managed on a weekly basis separate from the long term budget. This measure can help evade a situation whereby the budget for a project gets so much out of control that any corrective or proactive action proves hard to realize. Poor risk management It is a common practice for team members give a minimal emphasis to risks related to the software projects. Treating risks with a little regard can be a great project killer. It is thus recommended that every possible risk is identified at the start of the project then plans for avoidance and mitigation of the same be put in place. All these factors narrow down to the need for a risk management plan in a software project. Possible Expansion This section briefly describes the need for the implementation of the Social Fashion Application to take future growth into account. The major intention is to accommodate for future changes whilst keeping at minimum the impact to the already operating system functions. Examples of changes that would need to be planned to include: The resulting E-Accounting software application should take into account the possibilities of future growth. The main intention of the participating members of the project cycle is that the application remains accommodative of future changes while keeping a minimal effect of the future changes on the already working system functionalities. Examples of the changes to be planned are the change in the physical operating environment of the targeted users and the changes in the organizational structure. Conclusion A software project, if properly planned and strictly followed, can result into a high quality product delivered within budget and schedule while remaining accommodative of the possible future changes. Thus, it is important that the involved team of a software project takes care of every factor that can influence the project’s success. References Dag I.K,Ray Welland,Malcolm P. Atkinson. (1997). Software Constraints for Large Application Systems. Norway. Chemuturi, M., & Cagley, T. M. (2010). Mastering software project management: Best practices, tools and techniques. Ft. Lauderdale, FL: J. Ross Pub. Pomberger, Blascheck G. (1996). Object Orientation and Prototyping in Software Engineering. Prentice. Consulting, G. (2012, June 12). Implementing Business Software Systems: Key Factors for Success. Retrieved February 25, 2014, from www.greenbeamconsulting.co.uk: http://www.greenbeamconsulting.co.uk/articles/implementing-software-11.html Whiten, Jeffrey L. (2007). System Analysis and Design Methods 7th Edition. McGraw. Pressman, R. S. (2001). Software Engineering a Practioneers Approach. Gustafson, D. A. (2002). Theories and Problems of Software Engineering. Kensas: McGraw. Wiegers, K. E. (2009). More About Software Requirements: Thorny Issues and Practical Advice. New York: OReilly Media, Inc. Read More