Re: 60 Hours per Week at Level 1 Process Maturity

[Thom Randolph <thom -at- halcyon -dot- com>]

Tony:

First, I should disclaim that I purposely choose to work at 
companies that have enough work to keep me active 60+ hours 
per week. Not because I like chaotic, ill-managed projects;
rather, because I like working long hours. Immersion is what
it's all about for me. Nonetheless...

The relationship I've seen is ALMOST as you've described. But,
it's more like the maturity level is inversely proportional to
the amount of things ACCOMPLISHED per hour of effort. The total
number of hours in a given period has as much to do with the
chaotic current-state of the project as it does with procedures
and project management. In low-maturity companies, it takes as
much time to find out WHO has the information, as WHERE they
put it, WHAT is the answer, and WHO gets the document next.

That said, the relationship between project management and the
number of work hours necessary per week is a direct one: it's 
called "resource allocation". A good project manager consciously 
allocates the project tasks over the tool- and people-resources 
with two goals in mind: 

  1) Finish at the "best" date within the limitations of goal 
     number two. This is not always the earliest possible date, 
     as in Just-in-Time Manufacturing.

  2) Utilize the available resources efficiently, having neither 
     too much nor too little of any resource, so that goal 
     number one can be met.

That's what project management IS for those people who actually 
know how. The effect you're seeing is actually one of the most
important goals in achieving a higher level of process maturity:
repeatable and predictable project planning. It's what ISO-9000
is all about.

For those who feel it's better to have fewer procedures, all I
can say is that I'd hate for any of the following entities be 
without extensive and strict procedures: my insurance company, 
the phone company repair and billing facilities, the electric 
utility billing, government tax collection, the civil and 
criminal courts, the bridge and highway building departments, 
structural and civil engineering companies, airplane and automobile
manufacturers, pharmaceutical drug manufacturers, all my credit
card transaction processing companies, to name just a few.

I truly wish computer companies had even an inkling of what
it meant to think in terms of setting up internal processes
for development. Hardware, and especially mechanical hardware
companies are a little better at it, and some non-US companies
are working hard to define engineering development processes.

Entrepreneurial ventures will ultimately fail when no one in 
management sets in place internal processes to handle sales,
customer service, manufacturing, resource planning, and a host
of other things that are absolutely critical to the company's
health and growth. Without processes, a small company can never
grow, because the time it takes to train new people, and the
resources expended for each unit of money earned prevents
the processes from scaling. When a company goes from getting
10 sales phone calls a day to getting tens of thousands, there
had better be a system in place, or they will never get anywhere
near that level. When retrieving customer account information,
a file clerk might retrieve 30 files per hour. If you try to
use 100 clerks, they will not retrieve 3000 files in one hour
(It's the old adage where nine women can't make a baby in one
month).

In order for a company to duplicate the success of the last
product, they need to understand not so much what made the
product successful, because that's a market-dynamics question.
Rather, they need to know how they were able to coordinate the
many parts of the company to create the product, manufacture 
enough to satisfy an accurately predicted demand, and deliver 
it to the customer with high enough quality that they were 
satisfied. Because engineering is likely working on the next
product while the first is still selling hotly, resource
planning must coordinate the ongoing product operations as
well as fit the new product development and release into the
existing operations.

High-tech companies often fail to realize that their chief
asset, indeed their single most important "product" is the
knowledge their workers create. To scale an engineering group
successfully from tens to hundreds or thousands of engineers 
means they must be able to share all that amassed information.
This is vital if the company is to reduce duplication of effort
and to ensure painfully expensive lessons are learned and not 
repeated.

This necessarily implies both a method for capturing the
information, as well as defined processes within which products
are designed. This also calls for good project management, 
and within that, a defined engineering development process. The
process itself doesn't negate creative outlets, and many companies
find it best to support a "creative process" apart from the more
rigorous product development process. 

The goals, once again, are to have a repeatable and predictable
design cycle for each new product that comes out of engineering.
That way the rest of the company can be ready to perform their
duties. It's not that the release date from Engineering is fixed,
but rather that the other departments have enough information to
time their activities, and so Engineering works WITH the rest
of the company. Ivory towers of Engineers never produce good
products reliably. For a company's long term outlook, it's better
to have 20 years of moderately successful products than it is
to have one stellar product and then go bankrupt.

The idea of using development processes is not to stifle creative
development, but rather to ensure everybody in the company knows 
what their role in the product design and delivery process is. 
That way, when the time is right, they'll be ready to act.

Technical writing is indeed one of those functions. There is
no reason why we shouldn't be able to predict when and how much
work we will have, based on the product development procedures 
and schedules. Yeah, sure, everything changes. That's not the
point. If the development process itself is robust, changes in
the schedule, the feature-set, availability of subject matter, 
marketing forecasts, customer profiles, and a million other things
are handled by the appropriate people throughout the development
process. Project management deals with those changes, and 
continuously keeps the machine running together. If ten new 
features are added, project management not only coordinates
the review and approval of the new features (which includes
the documentation group), but also notifies the appropriate
people of the changes, and adjusts the schedule to compensate.

The issue with software development is that most were never taught
to work from a detailed pseudo-code for formal specification.
Likewise, very few engineers even know how to validate a formal
specification, much less write one. 

The act of software engineering often has nothing to do with 
creating robust, fault-tolerant, reusable technology. Indeed,
many programmers are like painters, brushing the user interface 
and underlying code onto the canvas of a "visual" programming 
environment. There is no validation of the design, and indeed, 
there might not even BE a design in any rigorous sense. This 
is the type of coding (and ultimately, project management) that 
brought us not only the Y2K problem, but also the Hotmail
security fiasco, and so many others.

Enough rambling about that subject. I hope the above was either 
insightful or inciting. Please don't flame me; I char easily.

Best regards to all,

Thom Randolph
thom -at- halcyon -dot- com


At 03:12 PM 9/2/99 -0700, you wrote:
>
>It has been my observation that, within the software industry, the average 
>total hours worked per week is inversely related to the organizations 
>Process Maturity Level.  That is, as the Process Maturity Level decreases 
>(moving from 5 to 0), the avg number of hours worked increases.  Has this 
>been your experience also?
>
>Note: If Process Maturity Level (also called Capability Maturity Level)= 5, 
>the organization has (among other things) a very sophisticated project 
>management system in place.  If Process Maturity Level = 1, things are done 
>in a very add-hoc fashion.  Level 0 is anarchy.
>