TechEstate Project - Business Plan Example

Project Management: Project Charter Purpose This charter is from Unlimited Software Technologies for the development and implementation of a tenant management system. The project is named TechEstate 1.0. This charter represents an agreement between Unlimited Software Technologies and the client company, MyHouse Real Estate Company. Problem Statement MyHouse Real Estate Company makes use of the manual system of storing and retrieving tenant data. The system being developed is expected to automate services offered by the client company. Currently the client company requires physical appearance of tenants to the offices to pay rent or consult for other services. This creates a situation whereby long queues are experienced during certain times of the month. There have also been issues of forgery due to the manual way of documenting data. MyHouse Company has also been experiencing problems related to data retrieval. Decision making in the firm has been weighed down. Therefore, it is not easy to information that is timely and precise. Project Objectives This project is required to fulfil the objectives given below in its completion: Automate data storage and retrieval services Save the client company, money associated with data storage space Save the client company, money associated with forgery or misrepresentation Improve data security Be easy to use and learn Provide an online portal offering company services Project Deliverables The following items should be end products of the project: An executable application Documentation of the project- this includes a user manual and a technical manual A presentation of the project Assumptions Computer literacy – it is assumed that users of the system at MyHouse Company are computer literate. Therefore, little training will be required. Training will only entail the usage of the application to be developed. Stakeholders The system being developed will benefit a lot of people in its operations. Stakeholder Description Senior Managers at MyHouse This represents the senior managers who make the decision to the commission this project and ultimately develop an application system Technical managers at Unlimited Software Technologies This represents managers who break down tasks and duties in order for the project to be successful. Software developers or practitioners This represents persons who develop the codes and designs that help in developing the application system. End users at MyHouse This represents persons who belong to the client company, MyHouse, who will make use of the application in their everyday operations. Clients of MyHouse This represents all potential and current tenants of MyHouse who wish to access and make use of online services. Others This represents any persons who will make use of the system in any way as time goes by. For instance, a credit reference bureau may require to calculate a customer’s credit by accessing their tenancy payments and records. Table 1: Stakeholder Description Work Breakdown Structure Level WBS Codes Element Name Description 1 1 TechEstate 1.0 Entails all effort to put into operation a new tenant management system. 2 1.1 Initiation Entails all work undertaken during the initiation phase. 3 1.1.1 Recommendations and Evaluation Involves evaluating the project and offering recommendations. 3 1.1.2 Develop a project Charter The project charter entails an agreement between the client and the developer company. 3 1.1.3 Submit or deliver the project charter This involves official submission of the project charter to the necessary parties. 3 1.1.4 Review of the project charter by the project sponsor This involves a thorough review of the charter by the sponsors of the project 3 1.1.5 Approval and signing of the project charter After review of the charter, the sponsors approve and sign a binding contract. 2 1.2 Planning Entails all the effort that goes into the planning phase 3 1.2.1 Create a preliminary scope declaration Involves drawing up the project scope that will guide the project. 3 1.2.2 Create a project team Choose a team that will adequately handle this project. 3 1.2.3 Set meeting times for the project team Come up with a schedule detailing the times when various stakeholders should meet. 3 1.2.4 Come up with a project plan Involves drawing up a plan that will be used as a guide for the project. 3 1.2.5 Submit or deliver project plan Involves officially submitting the project plan to the project sponsors. 3 1.2.6 Milestone: Approval of the project plan This represents a project milestone, which is the approval and signing of the project plan. 2 1.3 Execution Entails all the effort that goes into the execution phase. 3 1.3.1 Meetings for the project team kick off This is the first meeting held by the project team. 3 1.3.2 Interview end users Involves identifying the requirements of the staff users at MyHouse. 3 1.3.3 Interview the clients Involves identification of the requirements of the clients of MyHouse. 3 1.3.4 Draw up requirements documents Involves drafting up a document that is comprised of all system requirements. 3 1.3.5 Review and revise the document Involves brainstorming of the system requirements to identify their feasibility options. 3 1.3.6 Validate and verify the requirements of user 3 1.3.7 Design the system This involves providing a design of the application. 3 1.3.8 Acquire software and hardware Involves gathering of all software and hardware required for the development and implementation process. 3 1.3.9 Install the application system Involves installation of the application system on the client computers 3 1.3.10 Test of the application system Involves running test scenarios to troubleshoot any defects or malfunctions. 3 1.3.11 Training users Involves providing users with training on how to run and troubleshoot the system. 3 1.3.12 Go live (Implementation) Involves implementing the system to the whole organization. 2 1.4 Control Entails all effort that goes into maintenance and control of the application. 3 1.4.1 Project management 3 1.4.2 Project status meetings These meetings provide team members with the status of the project. 3 1.4.3 Risk management Involves a thorough analysis of the risks associated with the project. 3 1.4.4 Revision of the project management plan Involves carrying out 2 1.5 Closeout This is the last phase of the project. 3 1.5.1 Procure audit 3 1.5.2 Documentation This is an ongoing process during the whole project duration to document project details. 3 1.5.3 Revision of records and files as needed Any changes made to the project should be updated. 3 1.5.4 Acquire formal acceptance 3 1.5.5 Store the records and files Records and documents concerning the project should be documented. 2 1.6 End project This stage signals project termination Table 2 : Work breakdown structure Project Budget Plan This project will require the use of both human and material resources in order to be successful. The resources required are available at Unlimited Software Technologies. Human Resource type Work (hrs) Key project Phases Hourly rate ($) Project manager 1100 All S230 - 280 Requirements analyst 310 Requirements 180 - 200 ATM specialist 1200 Requirements and Design 350 - 450 Software architect 340 Design 150 - 200 Programmer 1300 Execution 150 - 200 Verification Engineer 1180 Requirements, Design and Execution 150 - 200 Software designer 480 Design 150 - 200 Validation Engineer 650 Requirements and Design 150 - 200 Quality Analyst 260 All 150-200 Database Engineer 90 Design, Execution and Installation 150-200 Technical Writer 270 Closeout 150 - 200 Training Specialist 250 Training 150 - 200 Table 3: Project Budget Plan Communications Plan This communications plan is developed in order to fulfill the following objectives: Guarantee that notices for meetings and requirements are done in a timely fashion Facilitate effective group communication Effectively assess the outcome of different communication strategies Ensure the most favorable outcomes for project expectations and communications Types of Communication These types of communication ensure that information is passed to the necessary parties in a timely fashion (Heerkens, 2002). Executives This represents communication between the top executives of unlimited software technologies and the other employees such as programmers, system analysts, quality analysts etc. In this communication, the executive offers direction and feedback to the team in regard to the project in question. Employees This represents communication from the employees of unlimited software technologies and their executive management. In this communication, the employees provide project status and feedback to the executives. Project Team Communication in this case is internal. In this communication, team members update each other on the group’s progress. In this way, the project is synchronized preventing cases where on group should wait for a long time for feedback in regard to a certain issue. Means of Communication It is prudent to provide different means of communication. This is because different communication means have different guidelines and formality levels that guarantee that information is effectively passed (Heerkens, 2002). The way in which information is organized is also as significant as the way it is passed. The following shows some of the communication means that may be used in relaying information regarding this project to different parties. Team meetings Web Conference calls Email Executive communication Informal word of mouth Paper Executives Activity Stage Tools Responsibility Audience Frequency Outline project objectives and goals Initiation Meeting Initiation sponsor Project team once Collect feedback after launch of project Initiation Email, focus groups or informal Project team and the executives All employees and managers Regularly Discuss goals and project timeline Team meeting Project manager Project team Whenever new information is available Carry out a Demo session to demonstrate functionality of the application Deliver, Build Web and email Project manager or project lead All employees and managers once Table 4: Communication Plan Risk Management This process requires brainstorming sessions between the customer and the project team. This also involves identifying the unknowns and all project assumptions. Stakeholders should be consulted in order to identify and quantify risks associated with the project (Ben-David & Raz, 2001). A table that details risk categories will be created and updated during the course of the duration. In this table, there will be risks pertaining to the project, various markers that determine the risk rating and rating of risk in question. Categories Low Risk (L) Medium Risk (M) High Risk (H) Risk Rating (L, M, H ) Comments Budget Factors Client’s downward pressure The client has signed the contract and has agreed to the project budget The client has signed the contract but insists on a lower budget The client has not signed the contract or is very insistent on a lower budget H Client does not sign contract Performance Factors External software or hardware interfaces There are very little or no interfaces or integration required Some interfaces or integration may be required There is a need for extensive use of integration or interfaces H Development process factors Identification of errors and bugs at an early stage Incorporation of peer reviews during the whole development process Use of peer reviews from time to time the testing phase is expected to identify all bugs and defects of the system M Risk Response Plan This section highlights responses to the three risks identified above. After identification of the risks, it is imperative to find ways to manage these risks. In order to respond to risks, the following questions need to be answered. After answering, quantification is required in order to come up with a rating system. When the action is due The persons responsible for the action The metric that is to be watched The metric trigger value Management of risk response should be carried out regularly in order to accommodate and respond to any new changes that might occur during the project duration (Sandoy, Aven & Ford, 2005). The following designates numerous ways in which the risks that are mentioned above can be managed. Client’s downward pressure – this is an exceedingly huge risk because if the client pulls out, the project will no longer continue to work. Hence, it is significant to have the client onboard from the initiation of the project. This entails providing regular feedback and project status reports to the client, involving the client in the development process, and adequately explaining the benefits that incurred by the project. By using this method, the clientele feels like he or she is part of the development group. When there is transparency during the development process, the risk of the client feeling like they are being overcharged is profoundly low. External software or hardware interfaces – it is extremely significant for the system being constructed to be able to integrate in the organization as seamlessly as possible. Therefore, software and hardware required to provide an interface is exceedingly crucial. When developing the system the developers should be aware of the client’s operating system. Otherwise, they may develop an application that is not compatible with the client’s operating system. In such a case, there are two ways that this situation can be handled: The client needs to change their operating system or a new application that is compatible with the current operating system has to be developed. Both of these options are expensive; therefore, it is vital to consider integration of the new application in the organization. Identification of bugs and defects of the application - there are different stages whereby application defects can be identified. However, it is imperative to consider the size and magnitude of the project before making a decision on checking of defects. A large project that entails the development of a large application may require regular checking of errors and defects. This is in order to avoid massive changes during later stages of the development process. However, small applications may be checked for defects on completion of the project. References: Ben-David, I., & Raz, T. (2001). An Integrated Approach for Risk Response Development in Project Planning. Journal of the Operational Research Society, 52(1), 14-25. Heerkens, G. (2002). Project Management. New York: McGraw-Hill. Sandoy, M., Aven, T., & Ford, D. (2005). On Integrating Risk Perspectives in Project Management. Risk Management, 7(4), 7-21. Read More