Project Managment - As it Ought to be!
for PDF version
Most of us are beyond the point where we believe that successful
project management can be accomplished by following a formula or merely using the
right system. It’s not that the tools are unimportant, or that the systems don’t
work, because they do. However, the systems and the software only make the job
easier; they aren’t the elements of success.
Great ideas aren’t great products until they can be made and sold at a profit.
Solid project execution can help bring this about.
1. Pick and empower the right person to be your project leader
The project manager needs to be one of the best managers in the company and
picked at the onset of the project. After all, they have a difficult job. They
must manage diverse teams with members who all have “real” bosses elsewhere in
the company. When picking someone to be a project manager, keep these
requirements in mind;
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
Detailed, first hand knowledge of the product, design and engineering systems,
quality standards, manufacturing technologies and the politics of your company
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
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
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
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
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
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
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
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
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
o Reporting project status relative to the project plan
Related experiences of the executives can often be beneficial to the project
teams; the review provides the regular opportunity for this type of interface.
Conversely, the project team will have the opportunity to directly report
obstacles, roadblocks, or other difficulties.
o Identifying major concerns, customer complaints, or obstacles to success
o Reporting on changes to the project plan; SOW changes or changes to program
o Update financial projections
o Allowing for direct, two way communications between executive team and the
New Product Development Systems (NPDS) establish regular Phase or Gate Reviews to
provide formal approval of projects before proceeding to the next phase. The
dates for these reviews need to be established during the project planning phase:
the review requirements are established by the NPDS itself. These reviews are
deep dives into the status of the project and are a critical part of the checks
and balances that are required to uncover potential issues to project
But these reviews are not enough. Involvement of the executive team needs more
consistency than can be provided during these brief, formal reviews. The project
team should be supported by informal and frequent visits of the executives.
Review the work product of the project team. If the team is in the planning
phase; review and comment on the plans. Review the statement of requirements
documents – make sure that the definitions are what you want up front. Remember,
this is your future business.
So, what are you waiting for? If you haven’t developed a NPDS, or
if you aren’t satisfied with the one you are using – start working on the new
one. If you don’t have a regimen for developing project managers, then why not
start today. You will be glad you did when it's time to start the next project.