o Project managers need detailed cross functional knowledge.
The development, production, procurement and quality systems at your firm are complicated. It isn’t necessary for project leaders to have worked in all these functional areas, but the more the better. Understanding the workings of these areas is critical to prevent the leader from being bamboozled by the functional experts.
Detailed, first hand knowledge of the product, design and engineering systems, quality standards, manufacturing technologies and the politics of your company is mandatory.

o Technical projects should be led by technical people.
Don’t expect a leader of product development team to be successful if they can’t speak the language of the technical team. A procurement specialist or a logistics expert is unlikely to be able to fully understand the subtleties of the design and specification process; and they will have difficulty separating the critical requirements from the fluff. Engineers have disdain for those who are not technically sophisticated and can unintentionally intimidate others with the knowledge of technology; project managers must be able to ask tough questions to be successful.

Not all projects are technical in nature. Redesigning a service offering or revamping marketing plan projects should be led by those who are experts in these fields.

o Project managers must have superior organizational skills.
The great engineer who can never find the spec book or retrieve the latest test results probably isn’t a good candidate. The management of a project is an exceptionally detailed endeavor – pick someone who loves the detail.

o Make sure that your project managers are great problems solvers.
A project is nothing if not an exercise in solving problem after problem; make sure your leader knows how to deal with these issues

You will have to develop your own project leaders. Given the range of skills and experience required, you probably aren’t going to find the “right” person for the job. Pick someone with most of the skills; start by giving them the experiences needed and groom them until they are ready.

The right project manager will use the systems you have developed seamlessly, and it will sometimes look easy. The wrong project manager will take the greatest system and make it a toilsome nightmare, spending weeks preparing for routine reviews, and delivering substandard results.

2. Make sure that constraints for the project are completely defined
The bane of project management is changing or “updating” constraints once the project starts. Many of these changes are in fact oversights that should have been identified early in the process. Without solid definition of all constraints, it is too easy for significant changes to be made late in the process. Take time before the design process starts to get the definition right.

The constraints, or Scope of Work (SOW), have several elements. Customer constraints lead the list, but manufacturing limitations, market introduction timing, aesthetic concerns, governmental or industry regulations also add to the constraints. In many projects, this process of mapping the constraints is overlooked or underemphasized. Here are some simple rules to keep in mind which may help you identify all the constraints;

o Before work begins, take time to define responsibility for each element of the project. This is especially important when collaborating with outside firms as partners, suppliers, or customers. For example, who has primary and support responsibility for designing, testing, validating, and manufacturing the part?

o Remember: Assumptions are only bad if you don’t document them. Make sure that they are ` all documented.

o Recognize: Projects always involve change. Be prepared by deciding in advance how SOW changes will be handled. Do approval authorities need to be established? SOW management makes or breaks projects. When the sales department or customer decides that the part needs to be stainless steel instead of plastic – the scope of the project has changed and the parameters need to be updated.

Learn this lesson well. It could save you millions. During one of the major development projects I managed, the customer constantly asked for new or upgraded features to be added to the scope. But we had a detailed, approved SOW, and an effective SOW change management system. At the conclusion of the program, when the customer’s procurement team was trying to pull cost from the project, we were completely covered. All of the SOW changes were approved and we were able to improve our margins.

3. Utilize pull planning rather than task planning approaches
Two difficulties with project management are keeping a project on schedule and on budget. Failures to meet requirements in these areas have resulted in an over reaction in the level of detail put into early project plans. Nice little catch phrases like “He didn’t plan to fail, he just failed to plan” distort the realities of the situation.

Task based plans focus on the work that needs to be done and how long it is expected to take to complete this work. In the more complicated models, we are encouraged to estimate the minimum time, the expected time, and the most likely time each individual task or subtask will take. The more detailed the plans, it is argued, the more predictable the results. The job of the project manager is to make sure that the tasks are being completed in accordance with the plan.

But task based plans break down and subsequently lead to micro-management. The break-downs are seldom because we don’t keep up with the schedule. It is more likely that tasks were omitted from the plan or the resources required were greatly underestimated. In short, the plan becomes a substitute for responsibility and excuses like “We did it per the plan, it just didn’t work out” begin to be heard.

Ironically, the response to these issues is to create more and more detailed plans, which are likely to conclude with similar failures, because the real causes of our project failures have not been addressed.

Pull planning offers a dramatically different approach. Instead of focusing on the tasks, or the work, it focuses on the desired results. For example, when planning a validation test, a pull plan defines the objectives and the timing of the test. It defines the design release levels and the types of tooling to be used. The plan specifies the confidence that the team needs to have in the results and the methods or particular tests to be performed. If there are any secondary considerations or objectives, such as using the build event as a learning opportunity for production associates, these are also listed. The consolidation of these plans for each controlling event becomes the project plan. The project team pulls and manages necessary resources to deliver the results for the controlling events as the project proceeds.

Even with a project using pull planning methodologies, there will be times when task planning is necessary. However, they are short-term, specific events on which the team is currently focused. For example, if a prototype event needs completed to facilitate a validation test, then release of Purchase Orders, delivery of components and planning of lab resources must be done on a micro level and in great detail. It is necessary to the success of the project.

But don’t try doing it months in advance. There are just too many unknowns to make it valuable. Instead, team members will become frustrated as the plans decompose. Project leaders will eventually give up and “re-plan” the project.

Don’t waste your time building a Microsoft Project Plan which defines exactly when specific tasks need to be accomplished. It is impossible to comprehend at the project initiation all the tasks that will be required to complete the project. Focus instead on deliverables and results required at specific, predetermined milestones. Then make sure you have a project team with the expertise, the knowledge, the responsibility and the authority to determine when and how to complete the work to ensure successful completion of the project.

4. Communicate, Communicate, Communicate!
Project management is solely about communications. The project leader that does not communicate well will fail. There must be communication within the team about responsibilities, targets, and requirements.

Additionally the team must communicate with management, customers and suppliers. When people on the team aren’t performing to expectation – or when they are performing well above them – their managers need to know. If there are issues that are threatening success, or newly found opportunities, management must know.

When a roadblock appears due to technical issues, reach out to experts and other teams. It is likely that someone has had experiences that will ease the path to the solution. When innovative ideas are discovered, trumpet these successes.

Good communication skills cannot be learned soon enough. During my first experience as a program manager, we were experiencing a significant issue that was a result of poor design decisions. In order to save face, I decided to keep the issue under wraps “for a couple of days” until we could solve it. Fortunately, after two weeks, with the problem still looming, a team member spilled the beans, and management became fully aware of the problem. I learned quickly that the issue itself was of less importance than the sharing of all information.

Pride or fear cannot be allowed to prevent communication within teams, with management or with other teams. Communication is the primary purpose of project management – don’t neglect it.

5. Develop your own New Product Development System



In the business climate today, the requirements for product development are extensive; environmental regulations or recycling rules mandated by the government, requirements for durability tests set by the customer, building or painting permits required by local authorities, as well as internal corporate requirements… and the list goes on. If you are part of the automotive industry there are APQP and TS 16949 requirements. It is too much for anyone to remember.

Teams need checklists to ensure that the critical developmental tasks aren’t being overlooked. It isn’t good enough to rely on the memory of your project team, management team, or executive team to ensure that everything gets done. Define the requirements, plan the programs around them, then check and report results against the requirements. Use this system as a tool for success, not just a series of tasks that have to be completed.

Formalize the system; allow it to change and grow as it is used – but don’t try to shortcut the process.

6. The executive team must stay involved.
These projects are the future of the business. As such, they merit the attention of the executive team. Stay involved in the projects to ensure things are going as planned.

Good projects have mechanisms built in to keep top management involved. Periodic reviews to provide face to face interactions between team members and executives are key to project success. Such reviews need to be conducted often; at least monthly. Don’t combine the reviews with other staff meetings or strategy sessions – it sends the wrong message. Specific purposes for these monthly reviews include:

o Reporting project status relative to the project plan
o Identifying major concerns, customer complaints, or obstacles to success documented.
o Reporting on changes to the project plan; SOW changes or changes to program risk
o Update financial projections
o Allowing for direct, two way communications between executive team and the project team.