[Source: Article in Gantthead by Ian Whittingham, PMP ]
If nothing else, it makes me feel vaguely virtuous, in the way that having my blood pressure taken or cholesterol checked does. No matter, I always have to click around the Programs menu to find it, hidden away in the Accessories folder under System Tools, sandwiched between Disk Cleanup and Files and Settings Transfer Wizard. But when I click Analyze, I realize I have not been as diligently attentive to the needs of my laptop as I should have been.
A braided ribbon diagnostic displays the state of my C drive: wide expanses of white space delimited by irregularly spaced red threads, interspersed with blue lines of varying thickness. Just as in nature, file management appears to abhor a vacuum. A pop-up window chides me: “You should defragment this volume.”
What the diagnostic graphically depicts is the extent to which the files on my PC have become fragmented across my C drive. But if I switch to the peripheral memory store that occupies my E drive, the analysis is much more reassuring: large blocks of blue predominate the ribbon display. This depicts the ideal state of contiguity in which all files should reside. The bluer, the better.
The variations in these color-banded patterns--red for fragmented files, blue for contiguous files, green for unmovable files and white for free space--are generated by algorithmic behavior designed to overcome the limitations imposed on the storage of information by both the physical properties of my laptop’s storage media and the algorithms that write files to the drive. Ideally, to optimize read/writes and utilize efficiently the media’s storage capacity, files must be moved around with the aim of allocating them contiguously in the memory store, so that any available free space is maximized.
However, the continuous process of adding new, amending existing and deleting unwanted files creates churn within the memory store. As churn impedes contiguous file allocation, file extents are created to workaround the distribution of the free space available. But as more files are added, amended or deleted, more extents are created, causing more fragmentation across the volume and a consequent degradation in performance. All of this occurs in the background, unnoticed by me; which makes defragging my disk drive a necessary and periodic chore.
And so I click Defragment and wait for the ribbon display to imperceptibly re-arrange itself, bit by bit, as files are compacted and relocated. But as the diagnostic ticks closer to 100 percent complete, watching the restoration of my disk drive’s integrity I am suddenly struck by the recognition of a best practice that might equally apply to a project team as to my PC: the periodic defragging of the project team.
Project teams are just as susceptible to performance degradation, caused by churn, as the storage media on my laptop is. But what are the symptoms of churn in a project team? And how might they be remediated so that team performance is restored?
A defining characteristic of highly performant project teams is integrity. In project teams, integrity is most commonly manifest in how the team accomplishes its work. Integrity derives from the ability of each team member to operate in a coordinated and proactive manner such that the effectiveness of individual actions is reciprocated and compounded by those of other team members. Thus, the project tasks that each member performs are integral to the overall performance of the team.
There are many ways to achieve team integrity, but the most obvious root to this is through effective role definition. Each team member must have a clearly defined and acknowledged role within the team, with minimum overlap with other team roles (except where required in the case of back-up, or to maximize resource allocation to a critical path activity or function). However, this involves much more than just compiling a RACI (Responsible, Accountable, Consultative, and Informational) matrix of team member roles, and then posting it to the project website. The key here is acknowledged role.
Unless the responsibilities and accountabilities of an individual team member are explicitly acknowledged by the other team members, boundaries and ownership can rapidly become blurred or porous. If project tasks are being left unresolved and unclaimed, or if multiple team members are working on the same task in apparently disjointed or uncoordinated ways, these may be incipient symptoms of churn.
In highly matrixed organizations, contention for team resources by competing projects may also be contributory to churn. If team members are dividing their time (and attention) among multiple project threads, there can be loss of focus on meeting project objectives. As pressure increases to meet deadlines and work packages or tasks are completed in isolation without regard to integration with other project tasks, further dislocation can occur. This coping behavior is similar to the file extent workaround: tasks are allocated to the time available without regard to quality or scope of work. Thus, tasks become fragmented from their objectives. On software development projects, for example, code builds created in such environments often exhibit a higher rate of bug fixes and post-release patches.
By their intrinsic nature, distributed teams are more susceptible to fragmentation than co-located teams. While large scale meetings might appear to be an effective forum for project leaders to set direction and communicate status, it may not be true for each project team member. For example, conducting a project meeting via telecom with 20 participants across four times zones for 75 minutes each week does not necessarily create a strong sense of team cohesion, nor is it an effective use of each participant’s time. Consider that such a meeting will consume 25 man hours per week of time (almost two man months per year) and will tie up 190 point-to-point communication channels among the participants.
Just as partitioning the volume on a disk drive can reduce the number of read/writes and reduce churn, you can apply a similar principle to team member interactions such that only the specific needs of the project that are relevant to a team member’s domain expertise or functional role are engaged. But to achieve this, a trade-off has to be made in the amount of facilitation effort required of the project manager. The communication needs of each team member--as it affects the performance of their project contribution--must be well understood and acted upon by the project manager to be effective.
As in the process of disk defragmentation, the project manager also needs to create contiguity within the project team. Viewed simplistically, contiguity can be taken to mean nothing more than project team member co-location. And certainly agile project teams fit this analogy very well, especially in the results they achieve. However, contiguity can also mean much more than just physical continuity and interaction. Contiguity should be a source of team cohesion and integrity.
One way in which it can be achieved in distributed and virtual teams is by continually relating the functional responsibilities and tasks of team members to the achievement of business objectives. When teams lose sight of the objectives they also lose the point of the tasks they are executing. And although this may not always ameliorate the effects of churn, it is one way in which project managers can help their teams to defrag themselves and restore team performance.