Articles

Product Management tools were originally meant for professionals. The first tools I learned about in the 70’s and 80’s were mainframe-based with names like Scitor and Primavera. These tools were mostly focused on resources and scheduling for projects, and had the ability to support large, complex and even multiple projects. What was interesting about these mainframe-based tools was that you could access them from any terminal connected to the mainframe. There was one project plan, and usually only one version of project documents stored in the project space. We used “Profs” for e-mail and notifications of changes in project status. However, even though these tools consolidated project objects, they were complex and often required not only a professional project manager to run the project, but the project team often needed a week or more of training.

[More:]

Then in the early 80’s the PC revolution happened. By the 1990’s, with a reasonable amount of computing power on the desktop, project management, through Microsoft Project, moved to the desktop and garnered a large percentage of the market. However, these tools were still complex, required training and were only in the realm of the project professional, those that understood work break-down structures or who had been PMI trained. Now that project documents were on everyone’s PC hard drive, there were multiple versions floating around, everyone was mailing documents back and forth and the project managenment (PM) systems itself was flooding our Inboxes with alerts and notifications.

For Everything There is a Season...

In the IT world most things seem to happen in about 10 year cycles. However, the evolution of project management seems to be on a 20 year cycle. In the 60’s and 70’s we had a consolidated mainframe approach to project management. In the 80’s and 90’s we had a more distributed, desktop-oriented PC approach to project management. Today in the new millennium we are back to the more consolidated approach, but with a difference. The difference is that each time we go through the cycle we seem to add a layer of abstraction getting closer and closer to the end-user each time. In the current iteration we have returned to software ‘in the cloud’.

This time it was not in the mainframe where the software resided, but project management software was starting to be offered as a service (SaaS). In this scenario the software was hosted on a network of servers (like Amazon’s S3 for expandable storage or EC2 (Elastic Compute Cloud)) that had the capacity to expand if the number of users increased. We now have come full circle with the mainframe, where everything can be stored in one space, online, with only one version of project documents stored in a secure project space. However, the newer SaaS PM tools promise not only less complexity and improved ease-of-use, but they often do not require a highly trained project manager to make the project successful. Add to this the fact that you can “try-before-you-buy” with many of these tools, lowering not only your initiation costs (you don’t have to buy a server, software license, or hire someone to maintain it), but also lowering your overall risk.

However, with each iteration the level of project success has not gotten any better. A recent survey of the PM literature shows:

• 75% of IT projects fail, are late or over budget (PWC, March 2007)
• 7 out of 10 UK government IT projects fail (Joe Harley, CIO, Department of Work and Pensions, Government IT Summit, May 2007)
• 85% of project success is dependent on factors related to people (Source, John McKean, Executive Director of the Center for Information Based Competition quoted from a blog)
• 60% of IT systems fail because projects neglect the organization and people changes introduced by new technology (Cranfield University/BEST project)

If we define failure as a project that is late, over budget, or does not meet the customer needs then what is causing this high rate of failure? If the technology has gotten better with each iteration, and our training of Project Managers is better, what are we missing? My belief is the realization that communication amongst project teams and project team members is poor.

“Communications failures top the list of reasons IT projects fail”, according to poll results from the Computing Technology Industry Association. About 28% of 1,000 respondents identified poor communications as the main cause of project failure, according to CompTIA (March 13, 2007 InformationWeek.")

What are some of the problems in a project management context than can happen without collaboration?

- False Consensus
- Unresolved Overt Conflict
- Un-discussed Covert Conflict
- Rigid Hierarchy
- Weak Leadership
- Unrealistic Expectations
- Closure Avoidance
- Calcified Team Meetings
- Uneven Participation
- Lack of Mutual Accountability
- Left out Stakeholders
- Forgetting the Customer
- Adoration of the Technology

From: Alan and Deborah Slobodnik, Options for Change – MA Bay OD Learning Group

Even more critical than communications, collaboration may be the key to project success. It is the level of participation, ownership and interaction that are inherent in collaboration that may hold the key to project success.

Communication, Interaction, Coordination, Collaboration

As an industry analyst firm, Collaborative Strategies is a lot more meticulous in its definitions of terms. For this discussion we will distinguish between communication, interaction, collaboration, and coordination, and use the following examples to help define each of these terms:

• Communication: Person A sends a message to person B, and person B acknowledges receipt. The message could include simple or complex information (graphics, pictures, or multimedia).
• Interaction: Person A sends a message to person B; person B acknowledges receipt and sends a message back to person A in reply. The type of information transferred in an interaction is, by its nature, complex.
• Coordination: Using communications to have multiple people work on a variety of tasks over time with a common goal.
• Collaboration: Multiple interactions occur between two or more people; each transfers complex information in pursuit of a particular common goal over a specified period of time.

For a common definition of collaboration we turn to Wikipedia, which notes that collaboration has these characteristics: creation, innovation, problem solving, participation and ownership. Collaboration in the Web 2.0 world is more about participation: working together to work things out because you’re part owner of the goal/solution. This is a big shift from the initial mainframe focus on resources and schedules and shows that we can learn each time we go through a cycle.

Collaboration and Project Management

One of the benefits of having a hosted project management tool is the increased ability for collaboration. This means that project teams can incorporate communication, interactions, coordination and collaboration all within some of these new Web 2.0 project management tools. Many of these tools include functions such as:

• User Profiles (project team member profiles)
• Expertise Discovery
• Project team chat (while in a specific project room)
• Integrated opinion polls (for team decision making)
• Private messaging (IM)
• Blogs – an interactive online journal that contains an ongoing dialog about the projects status and issues
• Wikis – a collaborative project web site that allows any member of the project team to add or edit the page(s) and can easily be linked to other project pages or resources.
• Multimedia file sharing
• Customized notifications and alerts
• Tagging, tag clouds and social tagging
• Presence (ability to detect if someone is online)
• RSS feeds
• Discussion forums for project issues and risks
• Group and role administration (supports security and access management)
• Integrated calendar management for coordination of tasks and meetings
• Rating and ranking of content
• Reputation engines, so team members can vote on different project documents