|
| |
Final Recommendations
Report:
The following is a portion of a sample report
(more recommendations are presented than listed here):
[Note: The Final Recommendations Report shown below
represents a sample output from an engagement with a software company, and the
discussion and comments reflect that fact. Effective Engineering is
equally comfortable handling engagements with companies with hardware, firmware, software,
mechanical, and a mix of disciplines.]
Effective
Engineering Consulting Services
Final Recommendations to Company-A
[Note: This report focuses on problems and bottlenecks that directly affect
engineering. There are clearly
problems outside of engineering, such as Sales and Marketing issues, that are
viewed as critical by engineering, but which are outside the scope of this
report. We will be happy to address
these issues as well, if you wish.]
Section I- Executive Summary
Company-A faces a number of critical problems that must be addressed quickly.
1)
Lack of
Clear Vision and Roadmap:
Morale in engineering is currently very low.
This is partly due to remaining engineers seeing their friends and valued
co-workers leaving as a result of frequent and continuing layoffs as financial
conditions have deteriorated. It is
also partly a function of “survivor's guilt”, and the increased workload that
has fallen on their shoulders. However,
it is clear that the most critical need to get the remaining employees out of
their current state of depression and frustration is to have clear direction
from the top of the company, which they are not seeing today.
Today engineering is suffering from poor motivation, lack of a sense of urgency,
lackluster development and testing efforts, and overall ineffective
engineering. The result is poor product definition (missing the mark on
what customers really want), longer development and testing intervals (delayed
time-to-market and higher development costs), inadequate quality (negative
reception by customers which will lose customers), and a general deterioration
of the reputation of the company and its products.
Management must present a clear company and product vision, a detailed
roadmap to achieve that vision, and a clear explanation of the role of every
employee in achieving that vision and roadmap.
This must be presented clearly with logic that explains the reasoning
behind it and projections that show how this will lead to success.
Employees must be given an opportunity to ask questions about the vision
and roadmap, and the entire senior management team must participate in these
discussions. Further, the vision
and roadmap must be followed, and not abandoned after it has been presented (as
has been the case in the past). Within engineering (as well as other groups),
you are dealing with bright people who have lived through many disappointments,
and who are currently quite cynical, so what you present must make sense and
hold real promise. With this,
employees will rally behind the management team and this vision that will make
the company succeed. It will result in
better product, faster development, lower development costs, higher quality, and
significantly improved customer satisfaction. Without this,
employees will put in their time, but their heart will not really be in it, and
they will likely look for better opportunities elsewhere, particularly the best
and brightest among them. If this
problem is not addressed quickly, before very long you may not have a company to
worry about.
A detailed plan to achieve this recommendation is attached in
"Recommendation Plan 1". Effective
Engineering's participation
in the implementation of this plan will help to ensure that this recommendation
succeeds.
2)
Inadequate
Product Quality:
a)
While
product quality has been improving, it is clear from reports from customers and
customer support that too many problems are being discovered after product has
been released. Given the complexity
of the product and the even larger complexity of the customer networks it
supports, some unusual customer reported problems are to be expected.
However, after examining what has been found to be the root cause of many
of these reported problems, it is clear that many of the problems should never
have made it out the door. Many, if
not most, of the problems can be traced to simple coding errors that should have
been caught by the developers before the code even reached SQA, much less the
customer. Development has a
methodology in place that should detect and eliminate many of these problems, if
the methodology is followed. The
problem is that some developers are taking “short-cuts” to bypass portions
of the methodology, either because they feel that they know better or are above
the methodology, or because they are feeling excessively pressured to deliver
something, whether it is fully developed and tested or not.
Some developers appear to have the attitude that they don’t have the
time to do things right (but they can make time to do things over).
This has to stop. It is
mandatory to demand quality by design.
Design specifications must be written and approved before coding begins.
Coding standards must be followed. Careful
coding practices must be followed. Code
reviews must be conducted. Memory
leak testing must be performed. All
changes must be carefully be reviewed by someone other than the developer before
the change is approved. All other
parts of the development methodology must be followed, and, if the methodology is
missing some steps, then the methodology must be modified.
If properly followed, development intervals can be significantly reduced
by enabling high quality code to be developed properly the first time.
Testing time can be reduced as well, as described below.
b)
SQA
often finds itself in the position of trying to test quality in; this can be
best addressed by fixing the problems reported above. SQA is also often forced to accept the fact that some real
bugs that are found will never be corrected.
SQA must be diligent in testing for and reporting bugs, but at the same
time, SQA must be practical in what they report as a bug; not every minor problem
that doesn’t really affect user operation must be fixed.
The Daily Review Board meeting correctly and efficiently carries out
the task of prioritizing reported bugs, and directing whether these bugs
will be fixed now, next, or never; this methodology is working well, and should
continue. Some developers look down upon SQA as second-class citizens.
This, too, must stop. SQA is
and must be full partners with development.
The goal is to deliver product of the highest quality, and feuding
between development and SQA stymies that goal.
By working in full partnership, higher quality can be achieved, and test
intervals can be reduced.
If both of these areas are properly addressed, you will be able to deliver
higher quality product and reap the benefits of higher customer
satisfaction. At the same time, addressing these issues will result in
shorter development intervals (reducing time-to-market and lowering development
costs), and will also enable the product to be developed with fewer resources
(again lowering development costs). There are net savings all
around.
A detailed plan to achieve this recommendation
is attached in "Recommendation Plan 2". Effective
Engineering's participation in the implementation of this plan will
help to ensure that this recommendation succeeds.
3)
…
Link to Interview Summary Report
Back to Deliverables
| |
|
