Epic Software Post Mortem

This past few weeks was like no other we have ever had at St. Anthony Hospital. This was the first chance that the whole group members of the team were required to complete every major component of the Epic Software process. We as a team under took certain activities that require a lot of time for every small return, and then we at times did not manage our resources effectively. But we did have many successes, and detailing both success and failings. And this is the purpose of this report. Below is a summary of the things we learned on this journey into installing Epic here at St. Anthony Hospital. Management

Management was not a problem for this group. The group was made up of over 50 people meaning that decision making was done by consensus. This allowed us to be more flexible with most of the assigning work to people. When one or more persons were assigned too much work it was common practice for another one to be added to level the work out. Things like this raised the group morale and productivity. Communication

Management saw that communication between each group was great through this process of the project, even during the meetings with each group. By making it more efficient by putting the action items on the Epic web page, sectioned: OKC St. Anthony Hospital issues, after each meeting with different groups. Management was able to see how effective this was in communicating with each other. Everyone always knew exactly what his or hers responsible part was, and when it was due and that they could find even more information online. Email was the primary method of communication and we used it to send completed assignments back and forth, as well as post things to the Epic web page like a massage board. Stakeholders were impressed with how we communicated with the web page. Group Dynamics

The overall group chemistry was very good. We went through these team meetings smoothly and did not have any significant problems. All group discussions ran smoothly and all the teams’ members were respectful to other team members. Those groups that partake in those meetings were certain Stakeholders, Project Manager, Asst. Project Manager, IS Director of the hospital, Tech Supervisor, Training Supervisors, and other team members by phone. Training

We had a couple of successfully training sessions but found that more in depth training sessions could have been useful in the overall Epic Software process. This is especially true with respect to the networking skills. At first, all members of the team were questioned about their abilities in certain topics. After that, the most weak topic was found among the group was the User Interface, especially with the use of swing, and networking. There were two small informal training sessions that were to help enhance the understanding of each topic, but by the next day training session it was more formal and more understanding with the staff of the hospital. Overall those sessions went rather well and had a pretty respectable result. Technical

Looking back, we spent too much time on the designing and layout of the project. We ended up changing half of what we designed initially, and we had spent less time designing things that were to be thrown away later, we would have had more time to tackling other technical hurdles. It is important to note that if we hadn’t had that initial design to work with we would have had a much harder time seeing what we actually needed to do the implement for this project. Conclusion

Implementing a product in a few months and training the staff in two days is a daunting task, but we as a team got through it with success and on time. We expected that we would be in for a lot of work, and we were not disappointed. But we also learned an enormous amount about the programming, software, software engineering, requirements, designing, implementation, testing, and just computer science in general. And throughout this learning process we became better at our jobs, better team members, and better software experts. One page citation from the textbook

Managing Project Risk provides that early warning system for impending problems that need to be addressed. Because of project planning can fail many organizations find themselves in this state of perpetual crisis characterized by an inability to make effective and timely decisions (Marchewka, J.T. (2012), .p 246). Trying to understand the benefits of a risk management is that the stakeholders wants results, they don’t care how the team achieves the goals and objectives, just as long as it’s completed on time and on budget with quality work. Not providing an adequate risk management should not be an add on to the project planning phase. But should be integrated throughout the project life cycle.

The best time to assess and plan for the project risk is at the earliest stages of the project. It is better to reduce the like hood of a risk to be capable of responding to a particular risk as soon as possible in order to limit the risk impact on the project schedule and budget (Marchewka, J.T. (2012)., p. 247). And there is the commitment to the stakeholders; project management requires that commitment by all project stakeholders. For many organizations a new environment and commitment to the following organization and project processes may be required. For many mangers the first sign that the project is in trouble.

A firm commitment to a risk management approach will not allow these impulses to override the project management and risk management processes that the organization has in place. And it is important that the risk have an owner. This owner should be someone who will be involved in the project. This position may also require the risk owner to ensure that adequate resources be available for managing and responding to a particular project risk (Marchewka, J.T. (2012)., p. 247). However, the project manager is responsible for ensuring that appropriate risk processes and plans are in place.