Business change and stakeholder engagement in projects. Changes to the IT used in an organization often change the way the organization works.
IT can change people’s jobs. It can even cause staff to lose their jobs, and in other cases create new roles that need to be filled. The driver for IT change is to enable an organization to generate new value and benefits.
Winning stakeholders’ support for a project is important for project success. Unless time has been spent communicating with stakeholders and making sure that users know exactly what to expect of the new system, the project could meet its formal requirements but still be seen as failing to provide benefits by its users.
The starting point for stakeholder engagement is the creation of a communication plan which identifies the key information stakeholders need about the project and when and how that information is to be conveyed. Chapter 8 on Project Organisation touches upon this topic.
DEVELOPMENT PROCESS MODELS
Section 1.4 identified the need for a well-defined, repeatable and predictable system development life cycle. A project’s life cycle is shaped by the products it delivers. Reference: “Project Management and the Development life cycle”, https://phron.org/project-management-and-the-development-life-cycle/ Whatever the life cycle, it will be a set of activities each of which follows a particular method. For example, design and construction could adopt an Agile approach. Every activity in the process will have defined inputs and outputs contributing directly or indirectly to the deliverables to the customer.
Effective development methods are made up of an overall set of techniques and activities from which team members working on a new project of a particular type can select the most appropriate subset. The method should never require a task that does not produce something useful for the project.
The conventional system development life cycle for IT projects was described in Section 1.4. This has certain general characteristics that could apply to a number of different life cycles. However, it assumes that technical processes will vary according to the type of project. For example, as we have already seen, there are different project types (with differences in the types of processes carried out) where software is to be developed and where an existing software application is to be obtained from a vendor. In Section 1.5, it was noted that to make projects more manageable, the processes could be split up or sequenced in different ways. Here we look at some of the options for this.