Effective Engineering 
                Consulting Services
                                           "Helping Engineering Excel!"

Our Premise
The Problem
Our Promise
Our Approach
Our Deliverables
Case Study
Our Results
Our People
Contact Us


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.



Link to Interview Summary Report

Back to Deliverables



Society of Professional Consultants


Copyright © 2002-2013 Effective Engineering Consulting Services, All Rights Reserved