WTF?! No-BS PM -- Right-on-Time Projects

JIT PRODUCTION / RIGHT-ON-TIME PROJECTS

We all recognize that the just-in-time (JIT) production strategy has changed the way that many manufacturing departments have been run since its transfer from Japan to the rest of the world around 1980. Many companies have also improved their productivity by focusing on quality improvement. Quality is free and is therefore profitable. There is a clear relationship between quality and productivity. When we improve quality, we also reduce cost and improve productivity. The JIT production system is considered the essence of an excellent production approach. JIT focuses on one very simple mind-set: Eliminate waste by having the right part, at the right place, at the right time.

The major aspects of a JIT system are:

1. Break a big production operation into smaller mini-companies and let each mini-company treat the next manufacturing process as their customer.

2. The teams manage the minicompanies. Each team has its own mission, goals, and targets, as well as its own performance indicators.

3. The teams will only provide "quality products" to their customers.

4. To achieve step three, the teams take quality very seriously. They will stop production immediately when they encounter a quality problem, and will only continue when it’s fixed.

5. Teams meet regularly and track their own progress;

review production processes and work on continuous improvements, report progress to management, and ask for help when needed.

6. A senior manager sponsors the minicompany, sup porting and coaching it to ensure its success.

7. Management provides teams with training to enhance their problem-solving skills.

8. Teams are rewarded based on their results.

Application to Projects

We can apply these simple JIT and quality concepts to project management. The fastest way to complete a project is to do it right the first time. If a project can achieve this, we call it a right-on-time project. Yes, it can be done-and it costs no more than doing it wrong. In fact, the cost to do it right the first time is zero! It will only cost you when you rework your project, and studies have found that nearly 30% of the cost of every project is rework. Clearly, we are not often enough doing it right the first time! The basic right-on-time project concept is to focus on:

1. Eliminating causes of slowness.

2. Installing processes that accelerate project work and ensure that successes are repeatable.

ELIMINATING CAUSES OF SLOWNESS

All project managers want to complete their projects on time and do the work right the first time, but few manage to achieve this goal. While a project manager may work hard to remove the roadblocks that slow down a project, he or she alone cannot remove all of these obstacles. To eliminate the root causes of slowness effectively, we must address them from a total system point of view. The management team must take the lead in resolving these problems. Experience has shown that the following problems contribute to slowing down a project:

1. The project is too big or the duration is too long.

2. Project priorities are changed constantly.

3. Too many product features.

4. Not enough resources.

5. Rework caused by poor quality.

6. Poor planning, especially poor project definition.

7. Perfectionism.

Big Projects

Very large and/or long-duration projects almost always finish behind schedule. A big project with long duration (hereafter simply called a "big project") consumes most of an organization's resources, and does not provide a quick return on the investment. Worse still, because the market is often changing very fast, the new product's functions and features that were originally defined in the project scope may become obsolete because of competition. For a big project, you may have no choice but to change the project scope, to incorporate new functions and features in order to stay abreast of the competition. This will delay the project. Not only that, due to this changing project scope your project team will have to re work what was done on the project and this will require more resources and funding.

Another problem with a big project is the changing of organization priorities. A project could be an important one in the beginning but if the project duration is long, it may be come less important along the way, and very often some resources are pulled from one project to rescue another one.

This action alone will delay the large project.

The positioning and scope of a product development project is a strategic decision made by senior management. In a fast-changing technology market, any new product development project must fit in a very small and narrow time-to-market window. As a result, new product development cycles are compressed. To compensate for this problem, you have to allocate more team members to the project, and the project team becomes very large. This leads to coordination and communication problems. The communication over head alone is a very significant factor that can cause the project to proceed slowly. That is, the sheer amount of information that must flow between the project administrators and the team members can be overwhelming.

“Hope is not a strategy!”

Another problem occurs when a company is not well prepared for a major technology change, and must develop a product with many new functions and features, incorporating these new cutting-edge technologies. Many of them are still under development and their results are not yet proven.

The amount of risk incurred is significantly higher than that of a project that employs proven technology. Thus this type of project will often need a longer time to develop. All these factors contribute to the duration of a project. This is a major reason for trying to break large development projects into "bite-size" miniprojects, so that they can be completed in stages.

While a company may sometimes want to seize a new market opportunity by immediately creating a product to cater to its needs, it should not happen regularly. Pursuing projects that were not planned in the product roadmap is a reflection of poor market understanding, analysis, and fore casting. Management must address this critical problem as quickly as possible. Only when management has a full understanding of the market and is in control of the product introduction schedule can the size and scope of the project be planned and organized accordingly.

As a rule of thumb, a right-on-time project should not run longer than nine months, and the size of the full-time team should not exceed 10% of the company's development (innovation) resources. Smaller, short-duration projects are much more flexible than big projects; they have far fewer changes and are much easier for the team to grasp, plan, and execute. Thus, the chance for the team to accomplish the committed project targets is very high. The sole objective of right-on-time projects is to achieve 100% of project deliverables on time, every time.

Project Priorities Change Constantly

As an individual or company, if you don't know where you're going, you will end up somewhere else.

This is also true for projects. The project team must know its priorities clearly. Normally, the project manager is responsible for setting up a priority list and keeping the team members informed. If project priorities change constantly, due to internal and external factors, the project team will have difficulty completing their tasks as required. No project manager likes to see this to happen, but in some companies priorities change daily.

The most common factors that cause constantly changing priorities are:

1. Changing market conditions. This happens mainly in long-duration projects. When the project duration is more than a year, there will usually be many changes in the marketplace. The project schedule may become very critical, which in creases pressure on the team to work faster, or the project may become less important, resulting in resources being "robbed" for other more important projects. This is the main disadvantage of a long-duration project. The longer the duration, the more frequent are the changes and the more rework there will be.

2. Too many stakeholders or decision makers who have different interests in the project. For a big project where the project managers have to interface with many stakeholders, it’s very difficult to have one common priority list to cover all the different interests. As such, a project manager may have no choice but to change the project priorities from time to time to cater to the special concerns of some stakeholders. In other cases, when there is more than one major decision maker in a project, it will be even more difficult to keep a common priority list for the team.

Too Many Product Features

Before a new project is approved, it’s normally justified with many new technological changes, enhanced with many new product features or functions that will impress customers.

The more new product features and functions, the bigger the project team will be, and the longer the duration. However, as was previously stated, many of these new technological changes are yet to be tested and normally take time to prove.

More importantly, their completion date is unpredictable.

When a new project utilizes many new technological changes at the same time, it slows down.

To overcome this problem, we should apply a solution that was developed by the automobile industry a long time ago. This reliable solution is that they will make sure each new product will reuse at least 75% of existing technology and design. For the 20 to 25% new changes, only minor changes or proven "new technology" will be used in a new model. (Proven "new technology" refers to technology that is being used in another car). Just look at the new car models on the market and note that, very often, the only change is a face-lift, or application of a feature that is already being used in another model.

Reusing existing technology and design has another major advantage, which is that the project team will be smaller and the duration will be much shorter. This fits very well with the definition of right-on-time projects.

Too Few Resources

No company has unlimited resources. Yet most companies undertake more projects than their resources allow for. When this happens, many people get assigned to several projects at once. (One company we know of has allocated people to projects at a 110% rate. That is, before a project starts, it’s already decided that the project members will have to work overtime to meet the project schedule. This might be justifiable on a single project, but all of their projects are run this way!) Changing project scope to include more product functions and features affects other projects (and the resources needed to do this are normally pulled from lower-priority projects). Thus it’s difficult to add the resources necessary to complete these new, unplanned tasks.

Where possible, you should allocate only full-time team members to a project. Often, when management tries to maximize its resource utilization, they assign staff to more than one project-these people are called "part-time" project members (e.g., 20% to one project, 30% to another project, and 50% to yet another). The net result of this approach is increased setup time as a person constantly shifts from one job to another. And setup time is waste.

To overcome this, it’s clear that we must assign only full-time team members to a project. In addition, you should allocate only 80 to 85% of your resources to projects.

Every system should have some reserve capacity to handle unexpected "turbulence."

Poor Quality and Rework

Studies have found that about 30% of all project costs go to rework. This means one of every three people working on a project is spending all his or her time re-doing what two other people have done wrong. Two of the major reasons for rework are poor planning and ever-changing project scope. When project scope changes, the project team has no choice but to rework what is done to keep the project relevant, as was explained above. Poor planning-especially poor resource allocation-is another factor. A project member who is working on more than one project will quite of ten take shortcuts to save the time, which may increase errors and thus rework. Another cause of rework is unclear task requirements.

To overcome these problems, the project team must establish definitive quality expectations for the project and among the project team members. They must understand the quality requirements for completing a task and the next "customer's" expectations. These requirements and expectations must be discussed and documented up front. This minimizes disagreements and arguments later in the project life cycle.

Poor Planning

It has been said that if you fail to plan, you plan to fail. When a project is on a tight schedule or is perceived to be late, many project managers rush to start project work with no planning whatsoever. This is called a "ready-fire-aim" approach, which usually results in false starts, people going in the wrong direction, and much rework. There are two major problems with this approach:

1. Unilateral planning: In the rush to start up the project, and with all good intentions, the project man ager plans the project for the group (sometimes by just telling the team what should be done, without any reason and/or references) and then turns it over to them to execute. The team is unlikely to commit to this plan and deliver work as required. For one thing, they often don't understand the plan, and the project manager's estimate of task durations is likely to be optimistic. In addition, the project manager is very likely to forget some major factor that will later intrude and cause significant delays.

2. The "ready-fire-aim" approach is adopted because of the belief that people could get the work done by the time they could prepare a proper plan. The truth is that the more important the deadline, the more important the plan. Only when you have for ever is a plan unimportant. A simple way to under stand this is to imagine trying to reach a destination in an unfamiliar location without benefit of a roadmap (a plan).

Perfectionism

It’s one thing to want to improve processes continuously.

Perfectionism, however, is paralyzing, because by definition it can never be reached. The main reason for perfectionism is fear. Sometimes, you just don’t know how the market will react to a new product. Will customers accept it? Because of fear of product rejection, the product definition grows until you have a "do-everything" product. This can only be avoided if marketing clearly defines product requirements in terms of "must-have," "wants," and "nice-to-have." In general, the product should only include the must-have features on the first release. The wants and nice-to-have features can be added to subsequent product releases.

INSTALLING A PROCESS

When you have eliminated the causes of slowness in one project, your next step is to ensure that success for every project. While it’s true that every project is unique, "Product development is one area where extra effort of process de sign is rewarded handsomely. It’s one of the few non-repetitive processes that warrants careful process de sign". As such, you should establish a standard modular process that is specially tailored to your business and industry. This process should specify the unique requirements of your industry in the project life cycle (concept stage, definition stage, planning stage, execution stage, and closeout stage). The purpose of a standard modular process is to ensure that the project team has a template for planning, review, and other actions. Most importantly, it provides a common platform to share lessons learned from various projects.

The modular process as proposed: "The simplest approach to combining structure and flexibility is to build the development process out of modules. By altering the use and sequence of these modules we can produce millions of possible process configurations without losing control". The modules are based on the particular design needs of the product being developed. These modules should have clear input and output requirements and spell out any special actions required of the cross-functional team.

E.g., at the concept stage the standard modules include:

1. Report on product market position.

2. Benchmarking, competitive analysis.

3. Business case (resource requirements, target price, quantity, and introduction schedule).

4. Customer-needs analysis.

5. New technology availability.

At the definition stage the standard modules include:

1. Previous team lessons-learned report and recommended actions for future projects.

2. Product final specification.

3. Process and equipment specification.

4. Final customer requirement specification.

5. Updated business case (target price, quantity, and introduction schedule).

6. Key suppliers/key component availability.

7. Committed resources allocation plan.

8. Quality plan and requirements.

At the planning stage the standard modules include:

1. Project plan with WBS by week.

2. Resource utilization plan.

3. Process and equipment delivery schedule.

4. Key components delivery schedule.

5. Risk assessment.

6. Contingency plan.

7. Product introduction plan and timelines.

At the execution stage the standard modules include:

1. Product prototype build.

2. Engineering samples build.

3. Qualification samples build.

4. Pilot line setup, equipment setup.

5. Process verification and trial run.

6. Software verification; beta test module.

7. Design verification test module.

8. Design maturity test module.

At the project closeout stage the standard modules in-