IT Project Management - The balanced scorecard Project managers can use one of several approaches to measuring the quality and success of an IS/IT project. For example, balanced scorecards are a...

IT Project Management - The balanced scorecard Project managers can use one of several approaches to measuring the quality and success of an IS/IT project. For example, balanced scorecards are a simple and effective way of gauging the level of user adoption and success of an IS/IT project. In this Discussion, you will explore how using a balanced scorecard could improve the project performance of an example project in a case study. To complete this assignment, complete each item below: To complete this discussion, complete each item below: • Identify and explain the four perspectives of the balanced scorecard that can translate an organization’s vision and strategy as shown in the figure below on page 2 • Explain how you could apply them to improve the IS/IT project performance of the Astro Bank case study on Page 3 below. Your document should have 400 words
Cases and examples
Astro Bank
The management of the project teams for both the legacy and new systems started badly. Separate project teams were established for each. No roles, responsibilities, or rules were established. The project leader assumed that everyone had previous project experience and knew what to do. The projects began to deteriorate. The new system project team had never worked together before. Many were junior people who lacked project management experience. The work was not getting organized. The team just started in and began on tasks. The legacy system team was the reverse. Team members had operated in a bureaucratic project management mode for years. However, the projects were merely maintenance, operations support, and minor enhancements. Their approach was ill-suited to devel-opment and major interface work. They treated the new work like the old. Their project meetings were almost social occasions. The project leader faced change or failure. The first step was to impose project management similar to that described above on the new team. Members of this team were the least resistant and most accepting of organization. Once this process was in place, it was time to turn to the legacy system team members. There were two alternatives. The project leader could attempt to invade their existing culture in their organization. This was seen to be very risky and would run into management as well as staff resistance and dissension. The project could afford neither. The alternative was to involve the legacy system team members as individuals within the new system project team. This was the first step. Over time, the project leader then carved out a subproject for the legacy system team and ran the group under the same rules as the new sys-tems project team. Meetings were held in the offices of the new systems development area—away from the legacy system staff.