Let's face it, nowadays going from version 7.0 to version 8.0 means working with a dispersed team of developers who aren't necessarily located in the same corner of the building - if the same corner of the world.
Software development and configuration management are often conducted by professionals in locations distributed about a larger virtual environment. In fact, the Gartner Group estimates that by 2008, 41 million corporate employees worldwide will work virtually at least one day per week.
I'd wager that the figure might even be higher for the software development community.
But is there risk in running a virtual project team?
There may be some trepidation about the absence of in-person communications. The risk of not of not being face-to-face, though, is outweighed by the merits of a virtual
In a 2005 article for the Canadian - based business publication, Business Edge , Mike
Dempster cites research done by Dr. Darleen DeRosa of Right Management Consultants
about the efficacy of global virtual teams.
In Dempster's article he stated that when "DeRosa surveyed 10 disparate, major global organizations, two-thirds of them said enhancing the performance of virtual teams was ‘important, or very important' to their business."
The popularity of the virtual team in software development has come a long way. It has evolved as an effective way of doing business for dispersed project teams.
With the right project tools and technology, any disadvantage posed by not being live and in-person with your team members is trumped by the benefits of a technology tool that organizes and archives communications in one place and accessible by all.
Many project communications are not formal or structured. Not every communication
comes out as a formal directive or correspondence. Many are unstructured, and consist of email notes, electronic "post-its" and other notes that may consist of scanned handwritten notes, and tablet-generated idea notes and sketches.
Without a common "parking lot" for communications such as these, team players may miss some important correspondence. With a common Intranet or web-based project
tool, such communication may be archived and available to all.
To understand the value and merit of a repository for structured and unstructured communications, it is important to look at how information flows in a project environment.
Mike Burk is the Chief Knowledge Officer for the Federal Highway Administration. In an article he wrote, he describes the cycle of knowledge from his vantage point. This cycle shares a close semblance to the flow of knowledge in many team environments.
"In traditional organizations, knowledge tends to flow along organizational lines, from the top down. But that pattern seldom results in making knowledge available in a timely fashion and where it's needed the most. In organizations with managed knowledge, information can flow across organizational lines, reaching the people who can use it in ways that best promote the organization's goals and that enhance service to the customer at the same time," says Burke.
"How this happens can be understood by examining the four basic elements of the knowledge management cycle: find/create, organize, share, and use/reuse."
Under "find/create," knowledge is gained through a variety of means, including publications, conferences and meetings, project experiences, research, and industry expertise. Then comes a step to "organize," the knowledge, where it is filtered and
catalogued with accessibility to it from outsiders.
Then the information is "shared" with all privy to the data by using the Web and natural communication channels created in a collaborative work environment.
The "organize" and "share" functions of knowledge warrant that a community of workers has a knowledge manager who serves as an information broker by assisting people to obtain the information they need. The knowledge manager can also serve as an advocate for knowledge-sharing practices within and beyond his or her specific community of practice.
Finally, "use/reuse," involves both informal contacts and access to reports, good practices, success stories, and other forms of communication, including exhibits, demonstrations, and training sessions. Once documented and archived, the knowledge cycle begins all over again.
Of course, to make the cycle work requires reliable technology tools that expedient and user-friendly. Because a configuration management tool describes itself as "collaborative", it does not automatically mean that its collaboration features are the best way to manage project communications. Project communications are best stored and managed in a dedicated technology tool