Progress reports are generally made (in this context) from the
engineer or other technical staff to management. They may be
oral or written; they may represent personal or project progress;
they may be informal or formal; they may be weekly, monthly,
quarterly, or given in some other increment. All of that depends
on your organization.
What must be considered in your particular case is based on
- Who's giving the report, and to whom?
- How many people are on the team?
- How many levels are there between the presenter and audience?
- Are all intermediate levels represented? And do intermediate
levels get to throw in their two credits before the report
is submitted? (I've seen this part of the process bog down
the whole thing.) Or do you have direct access to everyone
in the organization?
- Does your information flow only upward? Or is it routed to
others on your level or below?
- Does your information reach customers?
- What happens if the project hits a roadblock? Suppose
- someone gets sick
- someone goes down a blind alley
- there's a hold up in another department or with a vendor
- What are the project goals? Are they persistently measurable?
Are they the right goals?
Sometimes you're limited by your organizational culture:
- Management only wants to hear the good news. Sometimes
managers who hear nothing will assume the news is good
-- perhaps better than anything you've experienced!
- An intermediate manager will not allow unfiltered info
to go up to the next level.
- The amount of time the audience will put into reading
or listening to your report is inversely proportional
to its rank. The higher on the management chain, the
less time you have to make your point.
- Other project managers may rush into their projects
without planning persistently measurable goals, and
their approach may be seen as effective because they're
fast.
- Some managers may still be hesitating using an automated
reporting system, being comfortable with paper.
In general, a progress reports will include
- Major achievements for the reporting period.
- Intended activity for next period.
- Risks approaching.
- Open questions and requests for direction.
The first two are usually mandatory, the others included as needed.
Accompanying information can include
- project specifications (at whatever system or subsystem
level is appropriate)
- results from design reviews
- schematics and other engineering drawings
- parts ordered and received
- documentation of critical components
- vendor specs
- subcontracts
Some engineers hate preparing progress reports. Some even see them
as works of fiction. But they do have the following advantages:
- A standard reporting process eliminates
ambiguities.
- Regular reviews can be planned for by sales, marketing,
and other essential non-engineering staff.
- An archived reporting system serves as a reminder of
commitments team members have made.
- Good organization reinforces management confidence in
the engineers.
Archival is critical because
- You want everyone to be working from the same info, and
for that info to be the "latest and greatest."
- You want information currently in use to be protected
from unknown and unapproved updates.
- You want to ensure compliance with regulations.
References
Friedman and Weinberg,
Handbook
of Walkthroughs, Inspections, and Technical Reviews.
Dorset House, 1990.
Gause and Weinberg,
Exploring
Requirements: Quality Before Design.
Dorset House, 1989.
Weinberg, G.
Becoming
a Technical Leader.
Dorset House, 1989.
Harrold, D. "Digital Paper." Control Engineering,
09.2000.
What You Can Do
- Have a reporting process in place before you start.
Make sure that
- it's easy for everyone on the team to follow
- it has reviews set up at every appropriate point
- reports are logged and archived, to prevent team members
from bypassing the reporting process
- reports from team members are collected at a single point
- reports are turned in
- Choose appropriate, measurable, consistent goals
and stick to them.
- Remember that if you are the project leader, you
must be better organized than the rest of the team.
Neither reports nor projects are self-organizing.
- Be brief. Too much information is as bad
as too little. Allow for periods of inactivity in certain
areas.
- Make sure your reports only goes to those who really
must have it. Others may see it as junk mail. If
you're not sure who needs it, assume (until management tells
you otherwise) that you can distribute it freely within one
level up or down on the management chain within the organization.
- If something goes wrong, seek management help right
away. Waiting for a formal presentation to bring up
issues will sometimes result in having Bad Things happen.
- Let management know if for any reason you're
not on-time and within-budget. Withholding that information
will hurt more than revealing it. Remember that a delay is
built into reporting for every intermediate level of management
until the report reaches its final destination.
- Carefully document any lessons learned.
- Don't point fingers. Blaming someone on the
team (or off the team) for a problem will not solve the problem,
nor will it make problem team members perform better, and it
certainly won't make you popular with the other team members
or with managers. It's a lose-lose scenario.
- Recognize that reporting is WORK. Don't
ignore it in favor of your "more technical" responsibilities.
|