This article originally appeared on the BeyeNETWORK
The idea of the project is deeply embedded in IT. When we meet a colleague we have not seen in a while, one of the first questions we are likely to ask is, “What project are you working on now?” If we think about our careers, it is often in terms of the series of projects we have worked on. We compare projects: this one was well managed, that one was doomed from the start, and this one introduced new technology. It is almost as if working on projects is unquestioned. Yet, there are reasons to doubt the wisdom of the project approach, and it is legitimate to ask if working through projects is really suited to the way enterprise information management (EIM) should be conducted.
If EIM is to be a horizontal function charged with managing the data assets of the enterprise, much like human resources manages the personnel assets, projects are likely to be problematic. Surely a mature EIM function would consist of a set of services that are constantly available to the enterprise, supported by a robust infrastructure, and delivered by well-defined business processes. This is not to say that projects do not have a role in EIM. However, EIM is unlikely to be successful if it is simply a pool of resources with skills like data modeling that can be placed on general IT projects that are essentially self-contained silos. In the short term, such a project-driven EIM unit may deliver value and may well be perceived as successful if the projects are perceived as successes. Yet, in the long term, nothing is done to help manage the enterprise’s information assets. Indeed, being project driven simply helps to create the “data mess” that so many enterprises find themselves in today, where nobody knows very much about the data landscape, data integration is enormously difficult, and data related issues abound in BI applications.
What is a Project?
Yet, projects are a very attractive way of working. After all, there are special features of projects in IT. The major one is that IT projects have been oriented to the development of applications. Prior to the 1990s, this meant that such projects were concerned with the custom software development for operational systems. In this context, the systems development life cycle (SDLC) was developed and became recognized as the way in which an IT project was run. There were, of course, ancillary methodologies; but like the SDLC, they were still oriented to building custom software. The SDLC consists of a well-known “waterfall” where one stage is completed and another begins, proceeding through requirements, analysis, design, programming, testing, implementation, and production support. Variations have arisen on this theme, but the waterfall approach of the SDLC defined the IT project for many years, and continues to do so today.
The use of SDLC seems to go hand in glove with projects. There are phases that culminate in the implementation of a system. At this point, the project is essentially over for the “developers” and “architects”. Whatever was built in the project is implemented in production and is the responsibility of another IT area, such as production control, and is maintained in a manner that is not like a project.
Significant as the SDLC is, it really does not define a project, and a definition is important to any discussion of the project approach. I have been fortunate in that a good deal of my career has involved working with the development agencies of the United Nations. These agencies fund and manage projects in the third world aimed at promoting social and economic development. Since their unit of work is the project, the UN agencies have thought long and hard about what a project is. They have concluded that the important characteristics of a project are that it has a start date, an end date, objectives, inputs, outputs, and outcomes. I would submit that this set of project attributes applies equally well to systems development projects as it does to socio-economic development projects.
Projects, Ownership, and Adam Smith
However, in IT, the project approach can be problematic. I have observed that it leads to a culture among developers and architects where these professionals move from project to project without completely taking “ownership” of what they create. Unfortunately, this is even more true for consultants who are hired only for the duration of a project. This transience, coupled with not really “owning” anything, is a way of avoiding responsibility – perhaps not intentionally, but that is the way it works out nonetheless. Systems that are put into production and later found to be inadequate cannot be handed back to a team that has dispersed, each individual going his or her own way to work on new projects. The concept of “ownership” is of course a little difficult to define. Usually, no developer has legal title to what he or she is developing, but the way the word is used really implies a high level of responsibility. This level of responsibility cannot exist longer than the developers have custody of what they are producing. It ends when the project ends.
All this sounds a little contrary to the idea of the division of labor, which has been familiar since the time of Adam Smith. This 18th century luminary found that an individual person took much longer to make a pin than a team of pin makers, each specializing on making one part of the pin. This was a key concept that was applied repeatedly in the industrial age with enormous success. Yet, does it apply to the information age? Is building a system and then giving it to an organizational unit to implement the same as cutting a piece of wire and handing it to another team to file to a point?
This is not a trivial issue. Application systems tend to decay into black boxes. As time goes by, fewer and fewer people understand what goes on inside them, until it is judged that it is no longer safe to make any changes to the application. The first, and perhaps greatest, loss of knowledge occurs when the development project ends. This scenario does not map to the manufacturing processes of the industrial age and the insights of Adam Smith.
Projects for Everything
A few decades ago, in-house systems development was much more common. Since the 1990s, however, the purchase of COTS (commercial off the shelf) software has become a lot more common. Today, there is even less focus on creating, or buying, new applications, and much more on integrating existing data assets. This can be seen in the focus on areas such as business intelligence and master data management.
This evolution away from building operational silos to activities that require a lot of knowledge about the existing environment is less suited to a project approach. It requires, for instance, a body of knowledge about the existing data landscape. A project will only care about producing artifacts for the project alone, and only for the lifespan of the project. Thus, if source data analysis is undertaken for a project, then the results are likely to be stored in spreadsheets and documents. These artifacts will vary in their design (and probably quality) from project to project, and there will be no processes in place to ensure they will be kept updated at the end of the project.
A New Approach
Legacy data administration units were typically groups of experts who moved from project to project, and rarely looked back. If EIM is a new approach to the competency of managing the information assets of the enterprise, it is unlikely to be well served by the project approach. It must consist of business processes that run continuously in an integrated fashion, and which are supported by an infrastructure of applications and databases. We can no longer afford to produce analysis and design artifacts on projects that serve only the project and become irrelevant or unreliable after the project ends. This means that at some level, analysis and design must be undertaken in a way that spans projects and which integrates their outputs.
None of this is going to be easy. However, the increasing focus on integration, and the management of physical data assets, is a far cry from building operational silos. Projects are likely to be with us for a long time. Yet, they must become part of a larger framework so that they can contribute to and reuse the information knowledge artifacts from other projects. Projects must also be evaluated to truly understand the lessons learned from them. Finally, EIM itself cannot be based on projects, but must be a set of sustained business processes.