How to Product Success in Your business?
Hi Friends,
You can see how to product success in your business. Drawing on the IS literature, several researchers implicitly argue that project success is a function of the success of the information system produced by the project (e.g., Ballantine et al., 1996; Delone & McLean, 1992, 2003; Seddon, 1997; Seddon, Staples, Patnayakuni, & Botwell, 1999). Completing the main project deliverable “to scope” (specification) may not be a valid or sufficient measure of project success if the deliverable is not also accepted and used by the intended client/end-user and/or does not provide sufficient benefit to them. In the case of information system deliverables, this success criterion might comprise measures of information quality, system quality, service quality, intention to use, actual use, user satisfaction, and net benefits (DeLone & McLean, 2003).
The same concept, however, can be applied to buildings and other civil infrastructure, for example, produced by construction and engineering projects (Baccarini, 1999). Clients/users have different interests and expectations of a project to triple constraint stakeholders. They center on fitness for use and other benefits associated with improvements in the nature and conditions of their work. A project can succeed in delivering an information system “on time, within budget and to specification” but fail to gain user acceptance or use of the system.
It is well-recognized that this can occur, for example, when a system specification lacks adequate user input to its definition and/or when user requirements change due to evolving business circumstances. This view of project success is fundamentally consistent with Pinto and Slevin’s (1988a) seminal model of project success and Kerzner’s (2003) definition. Pinto and Slevin (1988a) modeled project success as comprising two components: success of the project itself, as indicated by time, cost, and performance subcomponents, and client success, as reflected by use, satisfaction, and effectiveness of the project in benefiting intended users. Similarly, Kerzner (2003) defined project success as completion within time, cost, and specifications (the traditional triple constraints), as well as with minimum or mutually agreed scope changes and acceptance by the client/user (what I have called product success).Kerzner added two additional components: completion without disturbing the main workflow of the organization and without changing the corporate culture.
The intent of these components is not to argue that projects should not be vehicles of change within the organization but an acknowledgement that projects execute within an existing operational organizational context with established values and norms of behavior. This is consistent with the view of a project as a discrete change activity within an organization.