It_205_Week_8_Checkpoint

U.S. Census Bureau Field Data Collection Project: Don't Count On It The Field Data Collection Automation, also known as the FDCA is of extreme importance to U.S. Census Bureau. The FDCA was meant to replace the paper copies and maps that the workers from the U.S. Census Bureau were taking door to door to collect the household data. The replacement was to be a handheld electronic device that recorded the data making it a breeze to collect information on each household. This new device would lower costs, improve the quality of information, and to be more thorough. The biggest thing for the workers is that it would save them so much time, making it easy to get the results out sooner. The FDCA would impact decision making by leading the decision maker down the right or wrong path. It would make it easier, if it worked, for the decision maker to find the mistakes and the good points too. It would impact operational activities by making it faster going door to door and simpler for the Census Bureau instead of being on paper. The problem that the Bureau has is classified as a mixture of technology, people, and organization factors. To describe a few would include how the handheld devices are too slow and are not consistently reporting data, the program had an accountability issue, no certified program managers or highly qualified executives, poor testing procedures, the bureau did not give the specific requirements, the device technology would fail while transmitting data to the central data processing center, shortage of a risk management process, ineffective management oversight and the lack of experience for this magnitude of a project from Harris. It seems that every person was at fault in this project. The biggest problem was that the performance problems with the devices were reported to project management but was not recognized as a risk going forward. None of the problems were documented. The application that was to display and record the performance of the devices on the Web had not even been developed. They could not know for sure that the devices were ready for the census because there was no way to measure the performance the right way. The management, Harris, and the devices were at fault. The steps I would have taken to control the risk would be the implementation of the device, meaning all activities working together toward one main goal, the adoption of the device and technology. Another step I would take is to make available Project Management Software which automate the creation of Gantt and PERT charts, ability to define and order tasks, assign resources to tasks establish start and end dates for the tasks, tracking progress, and administering modifications to tasks and resources. I would also make a prototype and use it constantly to see if it could handle the pressure. A feasibility study, system design, system testing, acceptance testing, test plan, training and documentation, production and maintenance, rapid application development, joint application design, management backing, hiring project leaders who are highly qualified, run a requirements analysis, encourage user participation, use of an organizational impact analysis, alternative methods, prototyping, cloud-based platforms, and portfolio analysis are just a few more things I would do to control the risk in this project. I would follow the steps initially anyways and 1.) define and understand the problem, 2.) develop alternative solutions, 3.) choose the best solution, and 4.) implement the solution. If done the right way, the bureau could have made a great improvement! Reference Page Laudon, K.C., & Laudon, J.P. (2011). Essentials of MIS (9th ed.). Retrieved from The University of Phoenix eBook Collection database.