Typical project management seems to consist of establishing goals, forming a team, formulating task lists, recognizing and connecting dependencies and putting a timeline together. Then it’s full speed ahead. Once the planning is done, a team embarks on the tasks assigned and management focus becomes a timing review. It seems that the more comprehensive the project lines, the higher the confidence in overall project success.
As the different components of a project are accomplished, the parts are assembled into the whole. It’s a team effort and everybody’s opinion is equally valuable. A project team should be proud, regardless of whether it succeeded or not, whether it delivered an admirable or a mediocre product.
All this project management stuff is useful and enables a level of organization and discipline in a complex environment. However, it is only one part of the overall aspects of a project. Asking whether an engineer is done yet does not address the quality of the work executed and does not address whether the team is doing the right things to accomplish its goals. The technical competence of a project team is assumed and technical skill assured by having a documented process and specifications for the various tasks within the project.
A documented process is expected to guide inexperienced team members in the execution of tasks. It is accepted that documented processes can replace workforce competence and experience. What can be wrong with everything being written down and documented? All we need to do is follow the process and proper results are practically guaranteed. If something goes wrong, it’s a process issue. Better documentation will assure future success. However, in real life, an inexperienced team will spend its time and effort floundering and trying to understand the process. It will often make inferior choices because of a lack of good judgment due to inexperience and time running out.
The importance of quality in technical work is often overlooked and much harder to quantify than the timetable. Technical specifications can be used to document expectations, but meeting specifications does not ensure an admired product. If the technical work is sloppy or erroneous, is the ultimate outcome not suspect? Sometimes the errors will be lost in the ether of the project and will not have much impact on the accomplishment. The result is a product that works but does not fully satisfy the customer or deliver to the degree expected. Sometimes the errors are great enough to cause serious problems; the product, as well as the reputation of the organization, becomes tainted.
Nothing humanity does is infallible, and perfection is impossible to achieve, but striving for it minimizes the chance of disaster. Dividing a project into separate tasks between contributors and making sure that there is no duplication of effort is a project methodology that sets up the probability of later problems. Challenging projects, where technical aspects are not well understood, are especially prone to problems if the project is subdivided and allocated between team members.
Conducting periodic design reviews does not ensure that errors will not creep into the design and execution. There is never enough communication and understanding of everything to discover and recover from the buried ineffectual decisions.
So how can the accomplishment of objectives be made more certain? One method to consider is duplication of effort, where teams with various competencies are assigned the same challenge and then given time and resources to understand, consider solutions and finally present the results of their investigations to the broader team for review and consideration.
Though this approach can be considered a waste of resources, in truth each team will probably come up with incomplete solutions containing a number of accurate insights and understandings. The key is for an open-minded larger team to review the work, comprehend and cherry-pick the insights and partial understandings, and then gather the tidbits together into a more inspired and comprehensive framework of understanding. This gathering of information can open the door to the next level of understanding and set the stage for inspired solutions.
Gene Lukianov spent 20 years at Chrysler, working in vehicle dynamics and analytical dynamics. Now a consulting engineer, he runs VRAD Engineering, providing vehicle and suspension design services to the OEM and aftermarket industries
