Project plans and process ignorance
Project managers live and die by the project plan. It’s their bible. We know it like the back of our hand and we assume that everyone on the team does too, but to my surprise this is rarely the case.
Unfortunately, this lack of knowledge can reduce the effectiveness of the team, negatively impacting cost, time and performance. This article will explore the problem and suggest ways to remedy it.
Corporate Product Development Process
Every company I have worked for (Sun Microsystems, Apple, IBM/Rolm, startups) creates its own unique product development process. They are similar, but the phase names are always different and the logic of which tasks belong in each phase sometimes defies explanation.
This is particularly difficult for the new employee who must get up to speed on the corporate product development process in addition to learning the processes of their own functional group. It’s no wonder that all this information gained in the first few weeks of employment begin to fade once the new employee joins a product team.
Yet a good understanding of how the various processes interact is important to the efficient execution of project plans. Following is an example of process ignorance and its affect on schedule and product performance.
Product teams at Sun and Apple consisted of about 20 individuals representing several functional areas (see figure 1 below).
Team members usually understand the development process in their own group and may eventually learn the processes of other groups as they come into contact with them. Unfortunately, the number of groups a team member interacts with is usually small (2 or 3 at most). In addition, the amount of information they pick up is a function of exposure time and chance circumstances.
For instance an Electrical Engineer (EE) typically knows the manufacturing requirements for a multi-layer printed circuit board. But they may not be familiar with the requirements of the manufacturing test engineering group with whom they have little contact.
The test engineer may need test points added to the circuit to reduce test cycle time in order to meet the throughput (number of units per hour) goals of manufacturing. If the EE is unaware of these requirements and does not incorporate them during the design stage, then the input may not come until the design review.
Adding test points to the circuit board at this point could cause unacceptable schedule delays. So much for Design For Manufacturability!
A better approach is to include manufacturing test requirements in the development plans of both design and manufacturing groups. If issues such as test coverage are included in the plans, then they will be reviewed as a deliverable at the beginning of the design cycle when it is much easier to incorporate changes and therefore increases the likelihood that they will be included.
Functional Group Product Development Processes
Functional groups also seem to believe it is part of their raison d’etre to create their own product development process with unique phase names. Every engineer learns their own group’s processes, but picks up on other groups processes through chance osmosis. Let’s look at how “supplier” and “customer” process ignorance can cause problems.
Example #1: (Service vs. Design Engineering)
On one of my first projects as a mechanical designer at Sun Microsystems, I was designing a computer enclosure out of sheet metal. Metal was used as a shield to prevent enemy spies from picking information out of the air - real spook stuff! The enclosure had flanges on the inside for mounting the computer chassis.
Once the design was finished we made a prototype. I was so proud of my new design. I beamed like a proud Papa! But before the prototype design review started, the Customer
Service person took one look and said, “How the heck are we going to service that thing with the chassis mounting screw hidden behind the mounting flange? Who’s the dope that designed this!?”
The proud Papa now had egg on his face. The design looked great on the CAD, but I forgot to consider how it would be taken apart! Lucky for me the mistake was easily fixed (with a drill and file) and the change incorporated into the next prototype.
This example highlights how a problem could have been avoided if we had followed the process. The Customer Service development plan stated that the service engineer must participate in all design reviews including the initial “paper” (CAD) review. In this case both the design engineer and the service engineer were both guilty.
As the designer (supplier) I should have made sure the service engineer (customer) attended the initial design review. The service engineer should have checked the mechanical development plan (and schedule) and made sure they attended the initial design review. Knowledge of each other’s processes would have uncovered the problem when it was trivial to fix saving precious time, money and human resources.
Example #2: (Industrial Design vs. Mechanical Engineering)
At Sun we had a very talented Industrial Design (ID) group. On a new “Thin Client” computer project, the manufacturing and design strategy called for utilizing an external OEM partner in South Korea. A problem came up during development which highlighted the very different views (assumptions) we had of each other’s processes.
Early in the project the ID group released a cool looking 3D surface CAD model of the enclosure. The OEM ME’s began adding detailed features such as wall thickness, mounting bosses, ribs, etc. However when they came across a problem they did what they normally do - they fixed it! …but didn’t tell us.
A month and a half later the ME’s sent back 3D CAD models of the finished enclosure for our review and approval. I setup a design review which included the lead Industrial Designer. The ID person noticed that a change had been made to the top vents. The change violated the new corporate “design language”.
This was bad because the new computer was one of a family of products that were being introduced with the new look. The vent shape was a key design element used to identifying the next generation of faster/better computers.
It turns out that the OEM’s mechanical engineers discovered early on that the vent shape would have prevented the parts from coming off of the plastic mold so they changed it. Apparently, they considered the change minor, not worth mentioning, and in the interest of time simply made the change.
The lead Industrial Designer was angry that he hadn’t been informed of the problem. He assumed he would be consulted whenever a change affected aesthetics which was modus operandi for all previous projects where the mechanical design was done internall
Could this problem have been avoided? Perhaps. Especially if both groups had created development plans which specified how design changes are communicated and documented and included the process for review and approval.
Had the ME’s and the ID departments created development plans and followed them, the vent issue would have been raised and resolved earlier. In our case the change was unacceptable and a decision was made to modify the design which resulted in a tooling schedule delay.
Project and Functional Development Plans
There are several ways to prevent process ignorance. Training and experience eventually fulfill that need but there is a third path that can shorten the learning time and frankly is just plain good project management practice and that is the creation, review and approval of development plans.
Development plans should be created for every functional aspect of the product. The plans can be as short as a couple of paragraphs or many pages long if necessary. The complexity of the project and the potential impact of a well (or ill) defined plan on project cost, schedule, or product performance should guide the depth of the plan.
The project manager creates a project development plan that integrates the content of all the other plans into a single document. The project manager calls a meeting where all the functional leads review each other’s plans and the overall project development plan. The Project Management Institute’s “Project Management Body of Knowledge” (PMBOK) refers to this process as Integration Management.
The project development plan becomes the Holy Play Book that the team follows when executing the project. It is a living document meaning it may need to be revised during the course of development if changes need to be made that affect schedule, cost, or performance. Since the plan is the bible, changes must be reviewed and approved by key stakeholders.
Revisions of documentation are part of “Controlling” - one of the five phases of project development per PMBOK (Initiating, Planning, Executing, Controlling, and Closing). The process of document control falls under Scope Management.
Next I will review some of the key elements of the project development plan and functional group plans.
The project plan is a high level view of the project’s development process. Its initial purpose is to communicate the plan to management for approval of funds and commitment of human resources to proceed through the next phase. Once approved by management it becomes the guide map for executing the project.
Elements Of Typical Project Plan
- Product description.
- Product requirements (e.g. six sigma voice of the customer).
- Project schedule.
- Project costs (human resources, materials, tooling, testing, etc.).
- Product cost.
- Profit and Loss statement.
- Work Breakdown Structure.
- Human resources required.
- Summary of the development plans for each functional group.
- Risk analysis (technical, schedule, and performance) and mitigation strategies.
The amount of detail to be included in the project plan should be appropriate to the scope and risks.
Functional Group Development Plan
Many companies have templates that can be used to create development plans. The templates usually include all the sections required for a complex project but can be whittled down for smaller and less complex projects. I’ve seen plans at Sun
Microsystems that were 40 or more pages long whereas at a startup a functional plan might only be a single page.
Key Topics Functional Plan Should Include
- Plan summary.
- Development strategy (key technologies, outsourcing, etc.).
- Inputs (functional spec, interface spec’s, etc.).
- Outputs (number of prototypes and their purpose, testing strategy, etc.).
- Resources (human, equipment, materials, information, etc.).
- Risks and contingency plans.
- Assumptions and constraints.
In order to avoid the problems mentioned in the examples above, the authors (and reviewers) of development plans should explore all inputs, outputs, processes, and dependencies and add specific language that will ensure the issues are detected, reviewed, and resolved as early as possible.
There are many elements that go into making a successful project. One of them is a good understanding of the product development process. The best way to ensure that everyone on the team knows these processes is to create functional and corporate product development plans and have them reviewed and approved by all the team members. Happy planning!