IT Project Alignment in Practice

IT Project Alignment in Practice

Andreas Nilsson
Copyright: © 2015 |Pages: 27
DOI: 10.4018/978-1-4666-7473-8.ch002
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

IT projects live in dynamic and interorganizational settings. As the project context changes, IT projects run the risk of not delivering intended utility to the organization, despite delivering according to the project plan. There is a need for IT projects to continuously align themselves with their surrounding context in order to stay relevant. In this chapter, a pragmatic model for IT project alignment is presented and demonstrated. Results show how the model can be used as a support to traditional IT project management methods. The chapter is concluded with a presentation of three projects to further the understanding of IT project alignment in practice.
Chapter Preview
Top

Introduction

IT project scope has co-evolved with the industry from being an internal product development affair to today’s service oriented, interorganizational maze. A “normal” IT project (e.g. a company developing an app-based sales channel) includes representatives from several functions of the using organization, several vendors of solutions and experts in various domains such as unit managers, business controllers, process designers, systems analysts, requirement engineers, coders and testers. This makes IT projects interorganizational in essence.

But despite a distributed, interorganizational and cross-functional new normal of IT projects, the way to organize and run the projects have remained relatively unchanged for the past decade (Sauer and Reich, 2008). IT projects are still being organized according to traditional project management methods (such as PMI, Ibid) starting with the definition of scope and goal of the project, followed by the decomposition of these into logically connected tasks with an allocated time- and budget. A project is considered successful if it is completed according to the plan; incentive structures for involved project workers also award following the plan. But due to the interorganizational nature of IT projects, I argue that it is no longer possible to predefine and simply execute a plan. The dynamics following an interorganizational and cross-functional context will change the preconditions and basic assumptions of the project several times before the end of the project making significant parts of the plan irrelevant (Kappelman et al, 2006).

Looking into some statistics related to IT project success confirms that something is wrong; more than 80 percent of the projects fail to deliver within time, scope or budget (Parr & Shanks, 2001; Nelson 2007). For something considered strategically important for business (Xue at al, 2012), this is an alarmingly high number.

Large companies have met the increasingly complex IT environments and interorganizational nature of IT projects with investments in frameworks supporting management of complex interorganizational settings. Examples of these frameworks can be found within enterprise architecture (e.g. Zachman & Sowa), IT governance (e.g. COBIT) and project offices (e.g. PPM) to name a few. Also, large IT vendors have developed complete global delivery frameworks stipulating how to provide service based IT delivery to their customers (e.g. ITIL). But these frameworks does not support operative IT project management, they are developed for an IT governance perspective of single, large organizations. On an operative basis, there have been developments of agile approaches such as SCRUM (Schwaber, 2009) and extreme project management (DeCarlo, 2004). These have been developed in order to be adaptive to changing project- and system requirements, but they lack an interorganizational focus.

In fact, most IT projects are still run according to traditional IT project methods building on logic reluctant to change and external influences (Shwalbe, 2010). According to Bainey (2004) this may be the cause of several IT related issues leading to project failure and low IT utility.

Complete Chapter List

Search this Book:
Reset