What defines a small business? What defines some of the characteristics of a small business and project management?  The list below is a good start, but by no means exhaustive. 

• Low overhead
• Everyone has multiple roles
• Usually good collaboration and coordination
• Little to no IT support
• Limited budget
• Applications need to be easy to use and meet a clear need quickly
• May have multiple projects with the same people playing different roles
• Need to link documents and other objects to a secure project space
• Most interactions still done by e-mail
• Integration of mobile computing into the project mix
• Often as contractors, have to deal with project management tools of large companies
• Low start-up costs, and a free trial period
• Inexpensive online storage
• Easy administration, i.e. can grant access to the project space with 2 clicks and one e-mail
• Don't need complex dashboards or reporting tools, they know what is going on
• Task management is key and is low overhead
• Team calendar to help with coordination, should integrate with PIM
• Able to import and export from MS Project easily
• Some level of customization for each project space

The hallmark of a small business owner is their flexibility, ability to keep many balls in the air at the same time, their sensitivity to cost, and usually a total lack of IT support. Small businesses have as much need for project management tools as a medium or large business, but they need these tools to be tailored to the way they work, not a cut-down version of an enterprise project management system, or a new licensing arrangement (as Microsoft has done).

Sales

It is difficult for many software vendors to sell to small business. Yes there are over 5 million in the U.S. alone, but the sales are usually small, and may be only a few projects or involve a few people, and so the overall revenues from each sale are small.  But taken as an aggregation, these sales or subscriptions can add up to a good revenue stream for a software vendor. Imagine having a million people on your project management service, each paying $10/mo. That is $10 million each month or $120 Million a year. The problem here is cost of sales and support. If you need to interject the cost of a person into one or both of these processes, your profit margin takes a nose dive.

In general SaaS options for small business project management seem to work best. There is low start-up cost, no infrastructure required for the small business and the vendor essentially acts as IT support. A free trial period of 30 days or more can allow the small business to create one or two projects and have everyone in the business get a chance to use the system.  But even after the 30 day free trial, the small business does not have to make a big commitment.  If they are willing to buy a year's worth of subscriptions for X # of people, then maybe they get one month free. But they can also use the service on a month-to-month basis. This flexibility allows the small business to feel secure.

The other issues that contribute to their security is knowing their project spaces are secure, that it is easy to add members to a project team, and that their information is not captive to the service, i.e. if they decide not to continue with the service it is easy to export project information.

The other critical issue is support. Having great support is essential because the small business owner rarely has an IT resource to turn to.  The buck stops on the owner's desk and the last thing he/she wants to do is deal with a software problem, they need to stay focused on their business.  One idea is not only to have great support, but to create an online community of users that can be the first line of support (and is also great for product feature requests and feedback). Not only does this help to capture critical knowledge and save the vendor in support costs, but it also creates loyalty, and can cut the "churn" rate on subscriptions significantly.

Overhead

Small businesses are wary of additional overhead.  If everyone is not contributing to the bottom line (in some way) they are considered overhead, and a small business can get dragged under by too much overhead.  For this reason the project management service needs to be inexpensive, easy to use (so almost no additional training costs) and meets most business needs without exceeding them. By this I mean don't provide advanced project management functions like reporting, resource management, work breakdown structures, etc.  Most small businesses don't need to report to anyone, and don't need the advanced features. Task management is probably enough, most of the time they don't need a Gantt chart, but just have tasks connected to a team calendar for the project so everyone can coordinate and track progress.

Ease-of-use

It is important to trade additional functionality for ease-of-use. In all of our surveys, ease-of-use is rated higher than any specific function. Engineers and software designers often believe bigger is better, and have something like an "arms race" for features, with the winner having the biggest check list of features and functions. This may work well for a large enterprise or the government, but it does not work for a small business.

How quickly the software can be learned and how quickly a project can be created and customized is probably the single most critical feature in the acceptance of this kind of software by small businesses. If it takes too long to get information into the project space, or to add another team members, notify team members, and coordinate with other team members it will not happen, and the software loses much of its value. Remember the software has value because it supports behavioral norms amongst project team members.

Price

Small businesses are very price sensitive.  But even they can afford $10/month/person or project, without having to worry they are breaking the bank. If the project management software or service proves to be invaluable in running the business, then they might be willing to pay a bit more for its use. This is where premium pricing comes in, giving these businesses access to specific project or process templates. Adding more sophisticated features through premium pricing is one way to go, but it is important to add features that small business need for projects, and not to fall back on functions being offered to large businesses, most of the time these will not fly, and that effort is for naught. Premium services takes some real thought about what can enhance the project process for small businesses. Maybe it is the ability to mash-up data from inside or outside the organization with a project plan or import into a secure project space.  Maybe it is specific industry or process templates?  But it is not reporting or other aspects of complexity that the small business does not want or need.

Conclusion

For all of the reasons listed above, we believe that smaller vendors in the project management space will serve small businesses better, because of flexibility, pricing, delivery model, and providing core features without much overhead. In order to make sure you find the right project management product or service I have included the checklist below:

1. Is there a real need for this type of product or service in your company?
2. Have you defined what features you need for a solution and prioritized them?
3. Do you need to include people from other organizations in projects?
4. Is email integration critical for you to get team adoption?
5. Is it a product or service?
6. Is it task management or much more?
7. Is it low cost, and offers a monthly subscription plan?
8. Is there a low start-up cost (or a free trial)?
9. Are there any user forums online where they talk about service and support?
10. Is it easy to use (you can get proficient in less than an hour)?
11. Does it require any resources to get started?
12. How easy is it to import and export data?
13. Does it offer enough online storage, or more storage at a reasonable price?
14. Is there a migration path?
15. Do they offer templates (especially if you are doing recurring projects) or premium services?

Read more.....

This is a simple comprehension that stands to the reality test time and again, people that know each other, communicate better. 

This perception clearly stands the test time and again. People that know each other, that have met face to face, preferably in sociable circumstances, communicate better with each other even when they are geographically apart from one another.

Somehow these people have created a language bond, by using non-verbal communications, and this has added an additional layer to their verbal communications which reduces considerably misunderstandings and frictions.

That is why we (Ignite Outsourcing) have a plan called "exchanging ambassadors". In this plan, Israeli project managers meet with their Eastern European peers once every quarter, to strengthen their communication bonds. Like I said, people that know each other, communicate better.

It's hard to explain this, but drinking a glass of beer in a local pub in Kiev or a Tel Aviv night club can sometimes make all the difference between a successful project with good communications to a project full of misunderstandings and malfunctions.

Read more.....

Project proliferation is a way of life, regardless of size, scope or industry. Whether it's a pharmaceutical company, a software company or a school board, every organization has too many projects in the works. Now instead of being overwhelmed by work, we are overwhelmed by projects. Companies are turning to software to help organize lives and help manage project-based work.   

Companies have always had to deal with change. In the past, by and large, change was predictable. Nowadays, change has become not only more rapid, but also more complex and ubiquitous. The Internet, Web 2.0 and the whole cluster of technologies that depend upon and enhance  the Internet, brought about not just new products and services, but also new industries, new competitors, new ways to interact, and new business models.

Why is the Internet causing so much change? The e-mail is not that much different from a memo; an electronic invoice resembles its paper predecessor; and intranets look similar to the enterprise resource planning systems. The Economist compares the Internet to a chameleon:

"It is not simply a new distribution channel, or a new way to communicate. It is many other things: a market place, an information system, a tool for manufacturing goods and services. It makes a difference to a whole range of things that managers do every day, from locating a new supplier to coordinating a project to collecting and managing customer data. Each of these, in turn, affects corporate life in many different ways". (Source: Economist, November 2000)

In recent years project management has gained solid reputation. It is an area of expertise that is becoming increasingly crucial to the achievement of strategic objectives. Only 30 years ago, the initiation of projects within businesses was the exception rather than the rule. Now, however, project management is one of the fastest growing professional disciplines in North America. Membership in the PMI (Project Management Institute) has grown from 71 in 1969 to 5000 in 1984 to 95,000 in 2007.

The way we quantify, qualify, apportion and dispense work is often carried through the framework of projects. At every organizational level - from strategic action at the executive level to single-day routine maintenance - work is being managed with an effort to balance time, cost, performance and risk.

Wikipedia defines a project as "a temporary endeavor undertaken to create a product or service.'

Project proliferation is a way of life, regardless of size, scope or industry. Whether it's a pharmaceutical company, a software company or a school board, every organization has too many projects in the works. Now instead of being overwhelmed by work, we are overwhelmed by projects. Companies are turning to software to help organize lives and help manage project-based work.

For an enterprise to be successful with DPM it must:

1. Choose the right project (portfolio management)
2. Run projects successfully (Capture success factors, monitor the progression of the project without additional overhead, communicate the development of the project to team members and other stakeholders)
3. Promote development of human resources through project (continuous learning, knowledge management etc.)

Project Portfolio Management

The only way to tame project proliferation is to determine which projects should be done, which projects can be done, and which projects should be delayed or stopped, this is often called Project Portfolio Management and resides in the Project Management Office (PMO). These project opportunity decisions must be made at the portfolio level, not the individual project level.

Effective portfolio management means knowing the relative value and risk associated with every project that has been proposed or is under way. It means knowing how resources are deployed across projects and how many project resources are available for new projects. It means making tough decisions about which projects will be done and when, if at all - based on a shared understanding of each project's potential for adding value to an organization

Recognize the power of a portfolio of projects that is aligned with an organization's strategy. Project portfolio management is different than management of a single portfolio and more than a summary Gant chart of many projects

As the project is being implemented, the team needs to know answers to such questions as: What is expected? How are we doing against those expectations? Management needs to know: How is the project progressing against objectives, schedule, and budget?  With today's Web 2.0 tools this is even easier to do using SaaS (software as a service)-based tools.

Resource Management

Executives struggle with resource management issues on two levels: the aggregate level of resources that will enable the company to achieve its goals and allocating resources for competing initiatives such as specific programs.

What many organizations lack is a comprehensive toolset that allows them to consolidate and compare across projects as well as the ability to simulate alternative scenarios. With such an operational infrastructure in place, companies can move to the next phase... linking resource consumption to deliverables to gauge productivity of the resources.

Managers also need to track the extent to which their strategic objectives are being met and to clearly define and make visible bottlenecks and obstacles that prevent them from attaining their (project) goals.  Project managers need to manage resources much more actively to deal with: dependencies, degree of predictability; degree of management discretion in allocating resources; attitude towards management's measurement of productivity; facilitate development of an accurate profile of a resource; the need to find in-house experts to better utilize resident knowledge, much of which is not formally documented; create a standardized profile format to utilize resources both inside the enterprise and also in the value network those you work with outside the enterprise on an ongoing basis).

One of the assumptions in resource management software modules is that people update their profiles. So a project manager, when looking for a new team, has access to the latest information. But given people are people, resource updating does not often happen on a regular basis. 

One way to deal with this expertise issue is to have software that not only enables you to profile and find expertise, but also learns, so that the experts are not continually bothered by the same novice questions. In addition, such tools need to update the resource automatically, as people often forget, and then the profiles are useless if they are not up-to-date.  Another option is to make the software smarter. One way experts can transfer some of their knowledge is by using templates. Tools like Clarizen take this one step further and allow you to store all your project notes, files and discussions within a template so that the next one to use the template will benefit from what you learned in your project.

Personal Networks to Social Networks

Tracking down this expertise and getting it applied to your project is often a frustrating experience. However there are some new tools in the Project Manager’s arsenal. Some of the larger vendors have not only encouraged a social network within the enterprise, but they have also supported extensive profiles, which can be tagged (with keywords or terms) and then help you find these elusive experts.  In addition some companies have been able to link “work products” to the profile and also enable these documents and objects to be part of your search.

These new Web 2.0 tools, when coupled with traditional project management functions, not only can help the professional project manager be more effective, but can also help those who are not professionals to be more effective  with their project goals. However, the Enterprise is doing a dance with these Web 2.0 tools and has not yet adopted them in mass, apart from a few specific areas. These tools do not tie project management to the desktop (as in the past) but allow anyone with a browser and the right password to access project information and be effective.

This is not to say that SaaS project management tools are not secure. Many tools not only have password access, but group and role access. This means that if you are not part of the group, you will not even see the project listed, and what you can see is limited by your role in the project. Objects in the project space can even be encrypted, offering an additional level of security. 

Project managers have evolved with the tools, and today often support teams that are geographically distributed. In addition, project managers are often only assigned to larger projects, leaving the smaller projects to be run by non-professionals. Fortunately, not only is the software getting smarter but also much easier to use, taking less time to get up to speed for any member of the project team.  I don't see the role of project manager going away, but as the software gets better it allows smaller organizations, that may lack project professionals, be more effective in reaching their project goals.

Read more.....

The offshore model may be less expensive on a monthly basis but, at the end of the day, when project total costs are measured, one should multiply the monthly cost by the number of months the project lasts.

There are a few roles and tasks that cannot be accomplished effectively without face-to-face communications, such as requirement definition, interface definition, graphic interface design, etc. Actually, every assignment or job that require customer feedback, should be done face-to-face in the customer's environment and in its language.

For this reason we build distributed teams with clearly defined roles. The onsite teams reside on the customer site and are responsible for gathering all customer info and fixing the requirements and architecture design deliverables based on customer feedback. The offsite teams, on the other hand, for the most part, do all the development and tests based on guidelines provided by the onsite team, with minimal customer contact.

This delivery model, called the Onsite-Offshore delivery model , is more expensive than a pure offshore delivery model because it relies on local personnel that are notably costlier than offshore personnel (After all, cost is the reason we looked into offshore to begin with, no?). However, the offshore model may be less expensive on a monthly basis but, at the end of the day, when project total costs are measured, one should multiply the monthly cost by the number of months the project lasts. This multiple, ends up being less expensive in the Onsite-Offshore model than in the pure offshore model.

The reason is simple - in the Onsite-Offshore model the number of miscommunications  with the customer is significantly lower than the pure offshore  model. In fact, with the right management, the Onsite-Offshore will perform just as well (as far as time and product quality) as the classic onsite model but at significantly lower costs.

Read more.....

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 succeed. 

---

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.

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 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 http://news.zdnet.co.uk/itmanagement/0,1000000308,39287110,00.htm)
• 85% of project success is dependent on factors related to people (Source, John McKean, Executive Director of the Center for Information Based Competition quoted in http://sandhill.com/opinion/daily_blog.php?id=15&post=129)
• 60% of IT systems fail because projects neglect the organization and people changes introduced by new technology (Cranfield University/BEST project http://www.cranfield.ac.uk/university/press/2005/04072005.cfm)

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, http://www.learninggroup.org/MEETINGS/05_00_fastteams.htm

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
• 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

Project Collaboration 2.0

As you can see from the functions list above, Web 2.0 project management tools offer many more ways for members of a distributed project team to interact, take ownership and participate.

Some of the key capabilities of Project Collaboration include:

• The ability to support real-time project team interactions
• Attention - focused interaction with other project team members or project documents and objects
• Presence (detection) and the ability to find and bring someone into the project context when needed
• Networking and community - the ability to connect to other project teams
• Visualization -the use of multimedia tools to show project situations, issues and risks in a way that all project team members can understand and help with the solution. Tools like Mindjet can help project teams get started by seeing the relationships between the project, its resources and challenges.
• Situational applications - ability to use a blog or wiki to quickly transform the tool to meet your purpose.
• Group memory - a project space where not only all of the project documents and Gantt charts are but also the IM/Chat, e-mail and even a record of the F2F meetings are stored, so that you have a complete project record.

With all of these new ways for project teams to collaborate, perhaps with this new SaaS model for project management we will begin to see the project failure rate start to decrease. But like anything else, shifts like this take time.  We believe that Project Collaboration 2.0 will really take hold in the SMB market first, since they are more likely to use SaaS tools and don't have IT resources or trained project managers. If the SMBs are starting to see a dramatic rate drop in project failures then some of the larger companies will begin to adopt these technologies.

Read more.....

Existing research indicates a significant improvement in software development projects, in the quality, time and budget, when applying the methodology of Agile development. Is it possible to apply Agile methodology to offshore projects?           

Research conducted on teamwork communications compared different instruments to transfer information between two people, and measured the time the information was transferred and the level of accuracy in which the information was received. The same piece of information was transferred between two people by different communication methods, and each communication media was graded by its effectiveness.

The research showed that information transferred in the form of visual communications (face-to-face), received the highest score in effectiveness. Information that was transferred through only vocal communication (phone), showed 90% effectiveness in comparison to face to face communications. When using email to communicate, the research showed only 30% effectiveness in comparison to face-to-face communications, a significant decrease. The same information transmitted by an Instant Messaging software received a 16% (!) effectiveness in comparison to face-to-face communications.

Many researches had proven a significant improvement in software development projects, in the quality, time and budget, when applying the Agile development methodology. Is it possible to apply Agile methodology to offshore projects?

There is one principle in Agile development that seems completely contradictory to offshore development – face-to-face communications. In spite of that, there is a practical way to make the Agile development process suite decentralized teamwork.

Can one manage a development project without face-to-face communications? The answer is, typically ‘no’. As the project becomes more complex and requires more interaction between the development teams on the client’s site and the remote development team, face-to-face communications can determine whether the project will be a success or failure from a content, quality, budget and timeframe perspectives. Furthermore, Agile software development elevates the principal of face-to-face communications. Nonetheless, there is a practical method to align the Agile development method to distributed teamwork.

In the upcoming posts, I’ll elaborate on the foundations that our doctrine of Agile development is based on.

Read more.....

E-mail has been around for the last 30 years, why is it still so popular? Why do people use it for all types of collaboration?

---

I admit I get hundreds of e-mails every day and I spend at least an hour each day dealing with them (reading them, sorting them, deleting them, responding to them, etc.).  I have e-mail forwarded to my PDA, so when I am out and about I don't miss any of them.  But e-mail has been around for the last 30 years, why is it still so popular?  Why do people use it for all types of collaboration? 

9X better than e-Mail
If e-mail is such ancient technologies (in Internet time) why does everyone use them?  John Gourville, in HBS's Marketing department, did research investigating why so many new consumer products fail to catch on with their intended audiences despite the clear advantages they offer over what's currently on the market.  He talks about the '9X problem' --  "a mismatch of 9 to 1 between what innovators think consumers want and what consumers actually want."[1] The 9X problem goes a long way to explaining the tech industry folk wisdom that to spread like wildfire a new product has to offer a tenfold improvement over what's currently out there.[2] 

According to Andrew McAffee, a professor at Harvard, and a keynote speaker at the Enterprsie 2.0 Conference in June 2007, “Email is virtually everyone's current endowment of collaboration software.” Gourville's research suggests that the average person will underweight the prospective benefits of a replacement technology for it by about a factor of three, and overweight by the same factor everything they are being asked to give up by not using email. This is the 9X problem developers of new collaboration technologies will have to overcome.”

E-mail Inertia

I use Microsoft Outlook for my e-mail (a love/hate relationship). Outlook is the predominant player for not only e-mail but as a PIM (personal information manager) as I keep my calendar in it as well as tasks and track my time for client work, etc.  Because Outlook is the leader in this area there are lots of software that hook into Outlook, to either put data in, pull data out, or use my Outlook data for some other reason. A good example is TimeBridge, a tool, in Beta that I am currently testing to help in the process of setting up meetings. There are many collaboration tools and project management tools that also hook into Outlook, which makes me less inclined to get rid of it because there are lots of tools that hook to it that I can get additional functionality from.

The Medium is the Message

It is important to use the right medium to communicate and collaborate within a project team. For example, e-mail is great to let people know of status or give an update on a project, but it is the wrong tool for an extended discussion on a complex project issue. It is even more the wrong tool to use to discuss emotional or personal issues the project team may be having because e-mail does not convey any of the emotional tone or information, and a delicate situation can be made worse if misread because of lack of cues provided in the e-mail.  IM/chat is a bit better, you get immediate feedback, and you can clip in emoticons, but even so it is the wrong medium to discuss complex or personal issues that always arise on projects.

But IM is not persistent, by that I mean that when the conversation is over it goes away.  Often in projects you want to look back at these conversations and decisions, so it is important for these interactions to be persistent.  If the project is in a regulated industry you may be required to keep IM messages for up to 3 years. This brings us to Virtual Team Spaces (VTS) like;

- Huddle
- Near-time
- Jive’s Clearspace
- Webex WebOffice

Many of the VTS tools have a variety of collaborative functions that can be adapted for project work. Blogs, wikis and threaded discussions are often part of these applications. They all support group and role-based security and all offer storage for documents of all types. They are frequently used as a team project space, where a calendar, document storage, IM/chat, and other functions are used by the team to facilitate collaboration and coordination within the project. However many of these tools don’t offer real project management functionality, but rather do light weight task tracking.

Another option is to focus on some of the Web 2.0 project tools that have more project management functionality but are still are offered through a “Hosted” model or are SaaS (software as a service) where you pay a monthly subscription fee for use of the application. Tools like Clarizen recognize the need for collaboration and have built these functions right into the product and made collaboration part of the project management process to help support a virtual project team

Why Move?

So what would make me abandon e-mail, which is quick, easy to use and I have customized with filters, etc. and already has over 2GB of data in the (pst) file.

-          E-mail is becoming increasingly a noisy communications medium (i.e. spam), so I have to mine it for the important nuggets of information in all that spam noise.

-          Second it is not secure. Not that I imagine someone will pluck a critical e-mail of mine out of the ether, but rather e-mail is fraught with viruses, and so less safe than other options.

-          E-mail does not always get through, it is not always a reliable means of communication

-          E-mail often does not allow large attachments (gnat charts, CAD diagrams)

-          E-mail does not allow me to hold a conversation with more than one person

-          E-mail does not provide a convenient record (but an inconvenient one where I would have to search for all the appropriate e-mails to the project)

-          E-mail is not integrated with project content and calendar

Although e-mail, IM or SMS are all good for notification or alerts for a change in status or a project related event, and they are a good way to alert one team member or the whole team, they tend to fractionalize my collaboration, requiring that I use different tools for different functions or different types of interactions.

So am I in enough pain to abandon e-mail for a Web 2.0 PM tool? Probably not, but I am getting there. The first step is to start using one of these tools for a small project with a few people and see if you have to radically modify your behaviors and how uncomfortable this might be. If it is not too bad you might want to switch over to one of these tools because of the advantages in functionality it provides.  However, to get over the 9x problem, it will have to be low cost, easy to use, try-before-you buy, secure, and very easy to invite colleagues or project team members into. It should provide a persistent space for project team documents and discussions and ideally it would provide me with the “presence” and status of all the project team members.

You can probably get all but the last item from Clarizen and a variety of other tools, but the ability to see presence and status of team members has not yet been integrated into most Web 2.0 project tools. Neither has location (GPS tracking), which could be very useful for large and distributed project teams.

Maybe if the spam quotient gets higher, or I get more sick of dealing with my inbox, or the project tools move more into the Web 2.0 space and start providing functions (like presence and location) that I can’t get from any e-mail tools, then I will start to move over to these tools and use my e-mail less!

 David Coleman is the Founder and Managing Director of Collaborative Strategies (www.collaborate.com). He is a frequent blogger on the Collaboration blog (at the same address) and is the co-author of the forthcoming book “Collaboration 2.0” due out in October. He can be contacted at: davidc@collaborate.com.  

[2] Andy Grove, "Churning things up"  Fortune, July 21, 2003

Read more.....

Whoever has experienced outsourcing a software project, either as a supplier or a client, can appreciate the following advantages afforded by Agile development in the context of an offshore project:

• In order to give feedback, the client receives monthly deliveries instead of waiting for the finished product, at which stage most of the budget will be spent and budgetary flexibility will be virtually reduced to zero.
• Misunderstandings and short circuits in communication are manifested at a much earlier stage and corrections are therefore less costly.
• Actually seeing the product during the development process helps the client to finalize the requirements and thus reduce the risk of deviation from the cost estimates and time schedule.
• The supplier gains a working tool for risk control.
• The client feels that he is in full control of the project's progress and is therefore more satisfied with the supplier.
• The frequent client feedbacks create more effective communication between the offshore teams and the client. This improves the rate of production and better connects the offshore teams to the client's business logic, that in turn accelerates the rate of convergence on the final requirements.
• The Agile development process fosters more involvement in the project by the offshore teams, that in turn reduces the attrition rates so typical of offshore development.

In the final analysis, if the advantages are so great, why do the outsourcing suppliers not clamor to equip themselves with Agile-based development methodology?  Why do clients not always request Agility from the supplier?

From the client's point of view, the answer is mainly connected with his psychological resistance to unfamiliar development methodology and to the greater degree of involvement required of him.  The feedback at the end of each development cycle requires the client to invest more resources than would be needed by him for a standard Waterfall-based outsourcing process.

The answer is somewhat more complex from the supplier's point of view.  Major suppliers are more hesitant about the effectiveness of the Agile development process for large and complex projects, because of increased overhead costs, despite the fact that using the right architecture (such as SOA) most large development projects can be subdivided into a number of small projects.  On the other hand, smaller suppliers find it difficult to adopt a process that demands such a high degree of discipline and skill on the part of the R&D team members.  In order to propose and apply this type of develo