I’ve been working in the SDN / BPX WIKI for a while now on the Community Project where various community members have been collaborating on “virtual” projects using Web 2.0 technology. As someone who has been in the IT business for over 20 years now (from developer to architect to consultant), I wanted to explain my impressions concerning the applicability of this new technology regarding IT projects in a corporate setting.
The use of Enterprise 2.0 technology in IT projects is still undergoing examination in many companies. There is often a great deal of skepticism regarding these tools where managers are looking for actual business cases to support their usage.
A caveat: Although Web 2.0 and Enterprise 2.0 technologies are still in a definitional phase, it is not quite easy to say exactly what current (or future) technologies are to be considered. I would like to focus on the use of the WIKI (and partially the use of Instant Messaging).
A caveat: This isn’t an easy endeavor inasmuch as the area to be discussed is quite broad and encompasses a wide variety of project types. So let’s focus on process improvement projects and software development projects.
The focus on a “corporate setting” is critical to distinguish these projects from open-source projects where often different ”rules of behavior” are in place. Of course, some corporations are deeply involved in open source projects (for example, Eclipse) but this blog focuses on a different type of project – one that focuses on internal process improvement in an abstract context.
Before we begin, let’s take a quick look at the characteristics of most IT projects (and indeed of most projects) in a corporate environment:
- There are fixed expectations concerning milestones.
- A project has a certain structure which is broken down into steps. The structure used as well as the steps selected can be quite different based on the project methodology, the type of software to be developed and other criterion.
- The accomplishment of tasks is linked to particular individuals (or groups of individuals).
There are other characteristics that are present but these listed above are those that relevant for our discussion. This blog assumes that such project characteristics exist in most corporate settings.
Now let’s look at the some of main benefits of E2.0 technology (I “borrowed” this picture from Dion Hinchcliffe’s blog “Enterprise 2.0 as a corporate culture catalyst”).
It is evident you will see that there may be a certain conflict between the project characteristics described above and the characteristics associated with the usage of E2.0 technology.
One critical factor when attempting to host IT projects in an E2.0 setting is too remember that users involved – irregardless of their role in relationship to project – often have certain expectations about projects (including those discussed above) that must be met if the WIKI is to accepted as an appropriate support tool. The corporate existence of these individuals is based on the abstract “project” and its concrete manifestations. To expect individuals, who have been indoctrinated in this culture, to work together on projects based on E2.0 technology (where such constructs do not exist) is often questionable. Thus, it is important to balance the excitement of using “cutting-edge” E2.0 technology with the practical and psychological necessities of including project-related characteristics in your WIKI environment.
The Role of E2.0 Technology in Projects
One question concerns the role of these new technologies in projects:
Project Lifecycle: Do these E2.0 tools accompany the project throughout its entire lifecycle or are they just used for particular phases in the lifecycle. In the Community Pilot, we are attempting to use the WIKI for the entire project lifecycle. We started discussing process analysis and are now in the implementation phase. We are using a an Methodology from SAP (regarding Composite Applications) to structure/guide the pilot. (The question whether the use of this methodology is a hindrance or assistance to the goals of the pilot is another question…)
One of the major capabilities of the WIKI is for anyone who has access to the WIKI page to be able to change its contents. One intriguing question is how this ability fits into a typical project lifecycle. Normally, one project step follows the next until the project is complete (for example, projects based on the waterfall software model). Of course, a software project that is based on the agile software development model where there are various iterations may use the resulting updated documentation during the next iteration.
Of course, most IT projects involve software coding. Should this activity be placed in the WIKI as well with the WIKI acting as some sort of source control mechanism where developers check their code in and out? Of course not.
By necessity, users must exploit different tools that have evolved over time to perform certain project tasks (ARIS process design tool, test tools, etc.). However, since many of these tools are also Web-based as is the WIKI, then it is possible to embed them in the WIKI. The use of the Gliffy Plug-in for SDN/BPX WIKI has finally arrived shows one example of the use of WIKI plug-in technology to deal with these media breaks. A first step might be the inclusion of these other tools via URL. The next step might be the inclusion of these tools via the WIKI plug-in which would mean the inclusion of WIKI-specific characteristics in these tools.
This problem is also evident in the transition between phases. I have written various blogs about the problems associated with transferring data from process design environments to the process run time environments. The problem is also evident in the use of the WIKI. When I create a Gliffy Diagram in the WIKI that should be used as the basis for a UI diagram in Visual Composer, the UI expert has to recreate the UI design from scratch rather than using my initial sketch in Gliffy as a basis. There is supposed to be a Gliffy API coming but the transition between phases still requires many manual actions.
Although there are a variety of plug-ins for the WIKI, there will always be some sort of project content that doesn’t fit the WIKI model.
Although there are some project artifacts that are not ideal for the WIKI, there are other content types which are important in projects and sometimes often go unnoticed and undocumented. Through the use of scripts in the Big Machines Pilot, we are attempting to document the interactions of project members which is often a project information source that is missing. We are using those conversations that take place in Instant Message chat sessions and transferring them to the WIKI. In this way, it is possible to see how project decisions were based. Although the final decisions are often documented, the process of reaching these decisions is often not present.
Conclusion:
I think based on what I have seen in the Community Project, it can be said that E2.0 usage is appropriate for certain types of projects (at least based on existing model of IT projects in corporate setting)s. For example, environments in which project participation is voluntary but the potential user group is restricted to users with a certain motivation to contribute may be the most appropriate for E2.0 usage. One example of this environment might be on a company’s extranet where different customers might work together on a project improving a process that affects all.
I too am product of a corporate culture that determines how I judge projects and which characteristics I value in projects. My experiences in this environment are also evident in my demand for structure and consistency. When I start a new project, I’d like to be able to reuse the experience I’ve gained on previous projects (concerning how a project should be run, what steps/tasks are present and in what order, etc.).
Perhaps, it is these assumptions concerning projects that must be changed. Perhaps, the structure of a project should be newly defined by those involved every time a new project starts. What we need is a new definition of the “corporate project” that reflects the changing face of the cutting edge technology present in E2.0 platforms. The fact that this might threaten corporate institutions (such as KPIs and computer metrics) is a given.
The definition of this new type of corporate project based on E2.0 collaboration will be the challenge that awaits us all.
4 Comments
