Musings on project management: Teamwork -- managing the white space

Saturday, April 21, 2018

Teamwork -- managing the white space

One of the big differences between a team and a group is cohesiveness around the goal:

There's no success individually unless there is success collectively.

Inevitably, keeping the team together to promote cohesiveness raises the question: how to keep everyone busy all the time -- other than 'painting rocks' (which is the way the Army used to do it). In the popular vernacular of project management, keeping everyone productively busy means actively managing their downtime, aka 'white space', between and amongst their planned activities.

In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'. Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.

Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
So also bring in mock testing, special event prototyping, and, of course, that bane of all:
Maintenance of team records.

One big advantage of managing by teams: the cost is relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each. Of course, many PMs are NOT comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost: