~ By Brian Krichbaum
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.
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:
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.
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 underemphasised. Here are some simple rules to keep in mind which may help you identify all the constraints:
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 programme, 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.
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 are 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 completion 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.
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 programme 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.
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 programmes 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.
Formalise the system; allow it to change and grow as it is used - but don't try to shortcut the process.
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:
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.
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 success.
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.
Brian Krichbaum is the President of Process Coaching Incorporated a consulting company committed to helping organisations improve their operational, programme management and engineering performance, using detailed organisational assessments, lean techniques, targeted short burst projects and systems coaching to build accountability and self sufficiency into client systems. © Brian D. Krichbaum. All Rights Reserved Worldwide.