Where does the time go?

From Chapter 2: The Mythical Man-Month

Excerpt
Since software construction is inherently a systems effort—an exercise in complex interrelationships—communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. (page 19)

Gantt Chart of Typical 16-week schedule

Brooks is wrapping up his discussion of the second 'fallacious thought mode' with a zinger. Think of it; communication "dominates the decrease in individual task time." How does that happen? Who knows where the time goes?¹

Only a wee bit of wistful contemplation is needed to find a culprit: meetings. Just to put things in perspective, I genned-up a little table of the meetings that made up the routine part of the our lives as NASA software developers. Perhaps it's of interest.

Meeting Type	Purpose	Frequency	Time	Prep Needed
Development-related Meetings
Development Team Tagups	Development status, plans and technical issues	Daily/Weekly	15->30m	No
Project Team Meetings	Project-level coordination across development teams	Weekly	1h	Occasional
Technical Interchange meetings	Two or more development teams meet to coordinate efforts	Ad hoc	1hr->3d	Yes
Task Technical Reviews
Requirement review	Discuss and approve documented requirements. Focus: Process compliance, selected requirements	Build Lifecycle	2->4h	Yes
Architecture review	Discuss and approve documented architecture. Focus: Process compliance, selected topics	Build Lifecycle	2->4h	Yes
Design Review	Discussion and approve documented design. Focus: Process compliance, selected design considerations	Build Lifecycle	2->4h	Yes
Development kickoff reviews	Review the viability of the plan for a build cycle. Focus: Process compliance, development readiness	Build Lifecycle	2->4h	Yes
Test readiness review	Discuss and approve readiness of product for testing. Focus: Process compliance	Build Lifecycle	1->2h	Yes
Delivery and Deployment review	Discuss and approve product delivery. Focus: Process compliance	Build Lifecycle	1->2h	Yes
Programmatic-related meetings
Monthly Management Reviews	Status report	Monthly	3h	Yes
Budget Meetings	Discuss and defend development and maintenance budgets	Seasonal	1h	Yes
Change Board (CCB)	Approve requirement and/or design changes	Weekly	1h	Yes
Risk Board	Discuss and diposition risks	Monthly	1h	Yes
Programmatic Staff Meetings	Weekly update on Insitutional mandates, budgets, and status.	Weekly	1h	No
Quiet hours	Individual meeting with management	Monthly		Occasional
All Hands Meetings	Senior management addresses entire staff	Ad hoc	1h	No
Software-related Project Lifecycle Reviews
Preliminary Design Reviews	Discussion of requirements and initial design. Approval to proceed to full design	Project Lifecycle	1d	Yes
Critical Design Review	Discussion of design. Approval to proceed start development	Project Lifecycle	1d	Yes
Test readiness review	Discuss and approve readiness of product for testing. Focus: Process compliance	Build Lifecycle	4h	Yes
Delivery review	Discuss and approve product delivery	Build Lifecycle	2h	Yes
Institutionally-related Meetings
Group Meetings	Line organization meetings (think homeroom)	Monthly	1h	No
Section Staff Meetings	Carefully crafted comments	Weekly	2h	No
Quiet hours	Individual meeting with management	Monthly	1h	No
All Hands Meetings	Senior management addresses entire staff	Ad hoc	1h	No

Bear in mind that a single team may support multiple tasks and multiple projects. Team members often present the same material in different meetings. Also, note all the required preparation; it's significant.

By the way, the developers who support these meetings are also supposed to program. Daunting eh?! There are no ivory towers on the NASA grounds, and precious little time to think deep thoughts. Bear in mind that not everyone goes to every meeting. However, the more senior the engineer, the more meetings must be attended, the less time there is for careful thought.²

Are all those meetings necessary? I believe so. Here's a few reasons why:

• Meetings can be an efficient way to exchange information and coordinate activities.
• In a matrix managed organization, every developer has several managers. At a minimum there's a line manager and a program manager.² More than likely, there are multiple line managers and program managers with skin in the game.
• Every manager must meet with the team. Even on the face of it, to do otherwise would be considered negligent.
• Management perception of status is capricious. Misinformation is readily spread. If it crops ups, it must be guarded against.
• Failure is not an Option. Delegation is risk. The culture-of-consensus is a meeting culture.

Even if no one is added to meet the 'unmeetable' milestone, communication in a large organization will quickly soak up development time. The build-in communication aides and high-level of integration in the new breed of software process tools (e.g. IBM Rational Jazz, or the plethora of agile support tools) should help, but only for a while. If the past is any indicator, the added automation will become a liability as additional artifacts become the stuff of meetings. Efficiency is elusive; culture forces are resistant.

Is there hope? Yes, but only with leadership that has a stomach for risk. Regrettably survival usual means a stomach ectomy.

^1. Who Knows Where the Time Goes is an 60's anthem written by Sandy Denny of Fairport Convention.   Here's a link to a beautifully performed cover song by Judy Collins.

^2. For a top-notch engineer, I estimate that as much a 50% to 75% of work week can be taken up with meetings.

^3. Line refers to institutional organization. e.g. business unit, division, section and group. Line managers are responsible for hiring the staff projects need and ensures that staff complies with institutional rules. Program management refers to management of funds. Program managers are responsible for delivering products on time and on schedule.